Passing the Internal Scan for PCI DSS 2.0
Last updated on: September 6, 2020
Merchants subject to Payment Card Industry Data Security Standard (PCI DSS) rules are often blindsided by DSS changes, arrival of new payment technologies, and newly emerging business context. In addition, many organizations still narrowly focus on annual PCI assessment instead of on running an ongoing compliance program. This article will provide insight on the updated PCI DSS requirement, highlighting the need for internal vulnerability scanning ("perform quarterly internal vulnerability scans"), which was less visible in previous versions.
Whether you are facing PCI compliance or if you have been PCI compliant in the past, you may already know what it means to have a passing external scan; it means that a PCI Approved Scanning Vendor (ASV) will perform a vulnerability assessment of your public IP address space according to the guidelines issued by the PCI Security Standards Council (SSC) in the ASV Program Guide. Typically, it also means that your public IP address space does not contain any vulnerabilities with a CVSS score of 4.0 or higher, or that you have compensating controls in place to mitigate any vulnerabilities in your public IP address space.
Internal Vulnerability Assessment
Beginning June 30th of this year, the PCI SSC is going to require that you also show proof of passing an internal vulnerability assessment. This requirement is detailed in the PCI DSS Requirement #11.2.1/11.2.3, which describes the testing procedures for internal vulnerability assessments. The key aspects of these assessments are that they must be completed quarterly, and after any significant change; the assessments must also be performed by qualified internal or external resources. Lastly, the assessments must document a “passing result.”
To obtain passing results, the PCI DSS references that “all ‘High’ vulnerabilities defined in PCI DSS Requirement #6.2 are resolved.” The basic requirements are that you are able to perform a vulnerability assessment of your internal IP address space and that you are able to show that your environment does not have any “High” vulnerabilities, which is the subtle change from prior standards.
The purpose of PCI DSS Requirement #6.2 is to define the process by which you identify vulnerabilities that are to be considered “High,”“Medium,” and ”Low.” Specifically, PCI DSS Requirement #6.2 states: “Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.” The requirement also includes notes describing how risk rankings should take into consideration industry best practices and other criteria unique to your own environment; this can include CVSS base scores, vendor-supplied patch rankings, and the criticality of the underlying system components themselves.
The key aspect of PCI Requirement #6.2 is that you have a list of vulnerabilities that you (and your organization) have ranked according to your own process. Then you need to leverage these risk rankings in your vulnerability assessment against your internal IP address space. This will allow you to produce a report that shows a passing scan against your internal scope based on the risk rankings of vulnerabilities you have specified.
Quarterly Internal Scans
This brings us back to the requirement for internal scanning. It is important to remember that you need to perform these scans quarterly and after any significant change to your environment. This will mean that you will want to make sure that however you are assigning risk rankings and using risk rankings in concert with your vulnerability assessment tool, it is simple and repeatable. The ability to automatically produce an internal assessment report quarterly and after any change is a critical component of maintaining your PCI compliance.
It is also critical to review your PCI scope, which defines what IP addresses (both internal and external), are involved in the delivery of your payment card infrastructure. You will want to make sure that you can represent this scope in your vulnerability assessment tools to reduce the manual work that can be involved managing scope changes and reporting.
In conclusion, having a structured approach for dealing with PCI DSS changes, involving relevant stakeholders, evaluating their impact, and planning controls to close the gaps, should be adopted by security teams. This will help make any security program resilient to environmental and regulatory changes and ensure that the organization can maintain PCI compliance.
This is the first time I am hearing the PCI SSC is requiring internal scans that we show proof of passing scans. I have been looking all over the documentation and there has not been any information that this information will need to shared after June 30th. Can you please shed some light where this information would be on the PCI website?
You can view the documentation here >> https://www.pcisecuritystandards.org/security_standards/documents.php The "Navigating the PCI DSS 2.0" document provides the most insight into what the PCI Security Standards Council expects for each requirement.
Here is a quote from the most recent PCI Assessors newsletter released by PCI SSC:
ISAs and QSAs
June 30, 2012 Cutover for Requirements 6.2 and 6.5.6
An upcoming change affecting PCI DSS reporting includes the
June 30, 2012 cutover date for PCI DSS v2.0 Requirements 6.2 and 6.5.6. Currently, these requirements are defined as a best practice but will soon be enforced as required.
How does the cutover date affect compliance with PCI DSS?
1. After June 30, 2012, organizations will be required to assign risk rankings to newly detected vulnerabilities affecting the CDE as part of the ongoing vulnerability identification process established in Requirement 6.2.
Guidelines for classifying risk are provided by the Council as follows:
◦ Risk ranking systems should be based upon industry standards or best practices.
◦ The risk ranking assignment should classify risk in a manner which facilitates prioritization for remediation. (Example: High, Medium, Low)
2. When application development is in scope of an entity’s CDE, Requirement 6.5.6 will necessitate testing against the vulnerabilities classified as "high" risk as part of the secure application development process.
3. Additional Testing Procedures are indirectly affected by the cutoff date and include:
2.2.b: Updating of system configuration standards as new vulnerabilities are identified
10.4.a: Vulnerability identification in time synchronization technologies
11.2.1.b: Internal vulnerability scanning relative to vulnerabilities classified as "high"
11.2.3.b: Internal vulnerability scanning relative to vulnerabilities classified as "high"
Please use the above information to educate the Merchant community on the importance of implementing risk ranking requirements within the organizations' vulnerability management process. By taking proactive measures to ensure that proper controls are in place prior to the June 30 deadline, Assessors can help to ensure that Merchants do not risk falling out of compliance.
The actual deadline of June 30th has been referenced in the PCI DSS v2.0 under requirements 6.2 since its initial release.
Let me know if this helps or if you are still looking for some additional information we can help find.
We are also doing a webcast shortly to review these requirements.
You can register here:
There are a couple of things to keep in mind with regard to 6.2 and 11.2.1.
The need to perform the internal scans (11.2.1) is not new and has been a longstanding requirement. It is affected by the 6.2 requirement however, due to the fact that vulnerabilities that are classified as "high" must be remediated as part of the internal scan process. To be clear, the previous version of the standard simply stated that scans had to be repeated until "passing results were obtained". I am quite sure that not everyone was clear on what "passing" meant in this context.
The evolution of requirement 6.2 in the 2.0 version of the PCI DSS moved from simply stating that we must identify newly discovered security vulnerabilities to requiring that we define a process that ranks vulnerabilities according to risk. It also states that the process should be based on industry best practices. 6.2.a that Alex is talking about becomes a requirement (instead of being considered a best practice) at the end of June.
So to stay on track, we should monitor vendor security alerts relevant to own systems and subscribe to security advisories. Then simply evaluate how these vulnerabilities affect our own cardholder data environment. The Qualys tool provides CVSS scoring data and that should likely be a big part of the ranking. Getting back to requirement 11.2.1 (internal scans), when we test the CDE each quarter, we resolve the high risk vulnerabilities and re-run the scan.
When it comes time to attest to your compliance, the assessor is the one who will need to see that the risk ranking process exists, and will need to see the results of the scans that were performed.