FedRAMP and PCI – A Comparison of Scanning and Penetration Testing Requirements

July 9, 2015 Matt Wilgus

Overview

In the last 30 days, the FedRAMP Program Management Office (PMO) has published guidance for both vulnerability scanning and penetration testing. The updated guidance comes on the heels of PCI mandating the enhanced penetration testing requirements within its requirement 11.3 as part of the 3.0, now 3.1, version of the DSS. These augmented PCI requirements, introduced in the fall of 2013, took effect on June 30th. For many cloud service providers this means the requirements for vulnerability scanning and penetration testing are more thorough and will require additional resources for planning, executing and remediating findings. This article will walk through the updates and discuss the differentiation between FedRAMP and the PCI Data Security Standard (DSS).

Vulnerability Scanning

PCI: Requirement 11.2 of the PCI DSS obliges organizations to, “Run internal and external network vulnerability scans at least quarterly and after any significant change in the network.” Many organizations will provide their ASVs a listing of Internet facing IP addresses and/or hostnames and the scans will be performed. Internally, a similar process will occur, where a list of in-scope internal IP addresses or hostnames are provide and the scans will be performed by the ASV or an in-house team.

FedRAMP: The FedRAMP document titled, “FedRAMP JAB P-ATO Vulnerability Scan Requirements Guide” was developed for CSPs undergoing the approval via the Joint Authorization Board (JAB); however, agency authorizations can also use the guide. There are several differences with FedRAMP’s guide as compared to the PCI DSS including:

  • Scans must be performed with authentication (i.e. credentialed scans), which PCI doesn’t require.
  • Scans include the full system boundary, which is often, but not always, larger than the in-scope PCI environment, which consists of the cardholder data environment (CDE) and associated system components.
  • Scans must be conducted monthly, where PCI is quarterly.
  • CSPs musts use must use operating system and network vulnerability scanners, database vulnerability scanners and web application vulnerability scanners. PCI doesn’t provide the same level of detail and alludes to network vulnerability scanners. It is notable that web application scanning is one way to address compliance aspects of PCI DSS requirement 6.6.

Penetration Testing

PCI: For years there has been a debate about how a penetration test should be conducted in support of PCI DSS compliance. In March 2015, the PCI Security Standards Council published an information supplement providing additional guidance. This document offers useful information, however the PCI Standards Council emphasizes that this is just guidance – and the DSS within Requirement 11.3 is still the letter of the law. Also, testing is required from an internal and external perspective, along with testing networks, systems, and applications. In addition, PCI DSS 3.0 introduced additional requirements for a formal testing methodology and testing of segmentation controls. These new measures went from recommended to required on June 30, 2015.

FedRAMP: Also on June 30, 2015 FedRAMP published a document titled, “FedRAMP Penetration Test Guidance.” The goal of this document was similar to the PCI guidance and has overlapping content within methodology, reporting and qualifications. However, the most significant difference is the emphasis on attack vectors and scope. For example, the PCI guidance states social engineering testing is optional, whereas the FedRAMP guidance details tasks including “unannounced spear phishing exercises targeted at the CSP system administrators.” Additionally, the FedRAMP requirements touch on additional aspects of internal testing, such as those specific tests and attacks that should occur from the perspective of a credentialed system user. Physical (facility) penetration testing is also covered in the FedRAMP guidance. While not recommending that 3PAOs scale walls, it does ask for the 3PAO to verify that locks and other physical security mechanisms are in place. Some of these tasks can also be found in Requirement 9 of the PCI DSS.

Next steps

Unlike the PCI update, the FedRAMP penetration testing guidance did not include an implementation timeframe or any caveats around being just “guidance.”. As such, the requirements are effective immediately. As this guidance was not available prior to June 30th, some assessments underway may not have taken the guidance into account in its entirety. CSPs and 3PAOs are encouraged to work with their JAB or Agency authorizing officials to review the attack vectors and ensure that security assessment plans sufficiently assess risk based on the goals and objectives of FedRAMP and standards such as NIST 800-115.

References

PCI:
PCI DSS - (Requirement 11.2 and 11.3 starting on Page 94)
PCI ASV Program Guide
PCI Penetration Testing Information Supplement

FedRAMP:
FedRAMP Continuous Monitoring Strategy
FedRAMP JAB Vulnerability Scanning Requirements
FedRAMP Penetration Testing Guidance

About the Author

Matt Wilgus

Matt Wilgus is a Practice Director at Schellman & Company, Inc. Matt leads the Security Testing and Assessment offerings. In this role he heads the delivery of Schellman’s penetration testing services related to 3PAO and PCI assessments, as well as other regulatory and compliance programs. Matt has over 19 years’ experience in information security, with a focus on identifying, exploiting and remediating vulnerabilities, in addition to extensive experience enhancing client security programs while effectively meeting compliance requirements.

More Content by Matt Wilgus
Previous Article
The Panama Papers, Mossack Fonseca and the Writing on the Wall
The Panama Papers, Mossack Fonseca and the Writing on the Wall

The release of details contained in the Panama Papers will be one of the biggest news stories of the year. ...

Next Video
DevOps, Security, And The Software Development Life Cycle
DevOps, Security, And The Software Development Life Cycle

A walk-through security and compliance implications for modern SDLC, with a heavy attention on DevOps.