What Do I Need to Scan to be Compliant?

The Payment Card Industry Data Security Standard (PCI DSS) requires several types of scanning to be completed. This article provides an overview of the types of scanning, frequency for scans, and what it typically applies to in the environment. The table below provides a summary of this.

Validate Scope with Cardholder Data Scanning

PCI DSS does not require you to specifically complete scanning for cardholder data unless you are completing an S-RoC (Supplemental Report on Compliance) / DESV (Designated Entities Supplemental Validation). However, customers often use cardholder data scanning to validate the scope of their assessment or to validate that they can use a particular self-assessment questionnaire (SAQ) which requires you to attest that you are not storing any cardholder data.

When scanning for cardholder data, it is just as important to scan where you think there may be cardholder data as where you would not expect there to be cardholder data. We quite often find cardholder data including recycle bins, application log files, database tables in the wrong field, and even PowerPoint presentations!

Protect Your Web Application

PCI provides two options for how you can protect your web application in Requirement 6.6. The two options are:

• Manual or automated application vulnerability security assessment tools or methods at least annually and after any changes OR
• Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications to continually check all traffic.

The important thing to note in Requirement 6.6 is that it specifically states that the manual or automated security assessments are not the same as the vulnerability scans performed for Requirement 11.2.

Many of the companies that provide vulnerability scanning offer separate tools focusing on web application vulnerability scans. And these services can be added on fairly easily. Once you find a service that can check for common web application vulnerability (e.g. OWASP-type vulnerabilities), it’s a matter of scheduling your scans and creating a process for fixing vulnerabilities that are identified.

The biggest challenge in Requirement 6.6 is that it requires testing after any change. Depending on your release cycle, this may be several times a day, once a month, or even less frequently. The important thing is to ensure that changes to your web application are aligned with scheduling scans. We recommend aligning the scans with your release to UAT or pre-production and then running the scans again after the release to production.

To round out the process, ensure that there is a process to get information from the web application vulnerability scans to your developers so that they can fix any issues before the change is pushed to production.

Web application scans need to be run against any external-facing web application.

Wireless Networks

Much like Requirement 6.6, Requirement 11.1 offers two ways that you can approach identifying any rogue wireless networks or devices in your network:

• Wireless scanning
• Automated monitoring (for example, wireless IDS/IPS, NAC, etc.)

These scans need to be carried out even if you do not have any in-scope wireless networks in your environment and needs to be carried out across all of your in-scope locations (including offices and data centres). Some data centres provide rogue wireless scanning as part of their Attestation of Compliance (AoC), but make sure that Requirement 11.1 is included in the scope of the services or you will need to ensure there is a process to complete this scanning yourself.

As part of the scanning process, the goal is to understand what “normal” looks like. So getting a baseline understanding and working from there to identify things that change  and identifying criteria to understand what is suspicious will help you streamline your manual processes.

Internal and External Vulnerability Scanning

PCI requires that internal (Req. 11.2.1) and external (Req. 11.2.2) vulnerability scanning are carried out at least quarterly and after significant changes.

Your external vulnerability scanning must be carried out using an Approved Scanning Vendor. Make sure that you check that your vendor is on the list of ASVs on the PCI website.

Internal vulnerability scanning does not have to be carried out by an ASV, but many of the ASVs offer both internal and external scanning tools which can make the process easier than running multiple tools.

Scans and Re-Scans

The first thing you should do is make sure that you are scanning everything that needs to be scanned.

For external scanning, this means scanning any external interface that has the ability to affect the security of your in-scope environment. This means that aside from scanning the IP address for your payment page (or redirect page, etc.), you should may also need to be including things such as:

• VPN connections
• Externally accessible management services
• VoIP services
• Mail servers
• etc.

We often see that supporting services get missed in external vulnerability scans.

For internal vulnerability scans, you need to ensure that they cover all of your in-scope environment including the CDE, your management zones, and potentially even workstations that are in-scope.

It’s not enough to just scan your environment once per quarter though. You need to make sure that you achieve a passing scan each quarter. You also need to be able to show that you are running (and passing) internal and external vulnerability scans after any significant changes.

What is a Passing Scan?

The PCI SSC has two FAQs that are useful to read:

• FAQ 1152: Can an entity be PCI DSS compliant if they have performed quarterly scans, but do not have four “passing” scans?
• FAQ 1087: For vulnerability scans, what is meant by quarterly?

For external scans, make sure that there is a process to get an attested scan each time you run the scan (at least quarterly). We recommend that scans are run monthly in case vulnerabilities are identified that need to be fixed. This gives you the longest possible timeframe to fix the vulnerabilities and still get a passing scan with in the quarter (90 days).

For internal vulnerability scans, the scanning process does not include an attestation process. So you need to make sure that as part of the scans, all the “High” and “Critical” vulnerabilities are addressed as well as vulnerabilities that do not result in an automatic failure. There may also be other vulnerabilities that you as an organisation want to address but that do not fall into either of these categories.

With internal vulnerability scans, the process of managing “false positives” is managed internally and you need to ensure that any false positives are recorded and actioned so that when your QSA reviews the results, they understand the findings (especially if there are vulnerabilities present which result in a failed internal vulnerability scan).

PCI does understand though that sometimes it may take multiple vulnerability scans to get a passing scan. Therefore, they set out clear guidance in FAQ 1152 for what is needed to meet the quarterly scan requirement:

• Scans of all in-scope systems were performed for each quarterly period, and all in-scope systems are covered by the entity’s scan-remediate-rescan processes.
• Rescans were performed as necessary, and show that vulnerabilities identified in the initial quarterly scans have been remediated, for all affected systems, as part of the quarterly process.
• The entity has processes in place to remediate currently identified vulnerabilities.
• Repeated failing scans are not the result of poor remediation practices resulting in previously identified vulnerabilities not being properly addressed.

The last bullet point is probably one of the most important ones. A vulnerability should not be present on your scans quarter after quarter showing the same failing vulnerability on the same server as this would in most cases indicate a poor remediation processes.

What Happens if I Miss a Quarterly Scan?

The biggest question is always: what happens if a scan is missed or the requirements for a passing scan are not met? If your QSA is not able to get evidence of four passing scans in the last year, they will not be able to mark this requirement as in-place. In the worst case scenario, this could mean that you could be non-compliant for several quarters while the requirement for passing scans is met.

This is why it is important to ensure that you:

• Schedule and automatically run scans more frequently than quarterly.
• Regularly review the findings of these scans
• Have a clear remediation process in place
• Regularly perform re-scans until the failing vulnerabilities are fixed.

Remember, always scan-remediate-rescan!

Need Help With Scanning?

Read more about Confide’s Managed Vulnerability Scanning Services and Card Scanning as a Service. Contact us to find out how we can help you.