PCI Compliance Every Day – Requirement 11

Regularly Test Security Systems and Processes

When the subtitle to a PCI DSS section includes the phrase “regularly test,” you must assume that many of the requirements contained within that section have some timing frequency associated with them.

The most widely known requirements in PCI DSS 3.2 section 11 with a timing implication are the quarterly external and internal vulnerability scans (11.2). External vulnerability scans are required to be done by an approved scanning vendor (ASV). Internal vulnerability scanning can be done by anyone that is deemed qualified to perform the scanning (as defined by the Penetration Testing Information Supplement). And if any of the vulnerability scans fail (i.e. one or more vulnerabilities with a CVSS of 4.0+ are identified), the organization needs to remediate the problem(s) and rescan within 30 days.

Where organizations run into issues with vulnerability scanning is the quarterly timing of those scans. Years ago, PCI SSC chastised Qualified Security Assessors’ (QSA) for not enforcing the quarterly nature of scans. As a result, the SSC clarified their definition of “quarterly” and published that clarification in FAQ #1087. Quarterly, as defined by the Council, is three months or 90 days plus or minus two to three days. The FAQ goes into further detail regarding exceptions and how to deal with those exceptions to the three months/90 day rule. Most vulnerability scanning solutions allow for the scheduling of scans, so there is no legitimate reason not to run these scans.

The next most widely known requirement (11.3) with a timing implication is the annual external and internal penetration tests. As with vulnerability scans, if issues are discovered during a penetration test, the organization must remediate the issues and conduct the test again. The biggest problem encountered with penetration tests occur when organizations attempt to present a vulnerability scan as a penetration test.

For both vulnerability scanning and penetration testing, the biggest mistake organizations make is not conducting these activities after making significant changes. Both of these activities are required after any “significant changes” are made to the environment. It is up to the organization to define what is meant by the term “significant changes” as it pertains to their environment. But once significant changes are defined, if changes are made that meet those criteria, then the vulnerability scans and penetration testing need to be performed regardless of their timing. QSAs are required to review change control documentation using the significant change definition and ensure that, if such changes are found, those changes also have corresponding vulnerability scans and penetration tests conducted afterward. To address this situation, we recommend organizations add a “significant change indicator” to their change management system. Then, they can easily flag and find those changes, and know vulnerability scans and penetration tests should be run after those changes are implemented.

Given the always changing nature of most organizations, it is nearly impossible for organizations to get away with only four quarterly external/internal vulnerability scans and one penetration test per year. To maintain compliance, organizations should vulnerability scan monthly so they are never out of compliance with scans. However, they can still run afoul of the penetration testing requirement after a significant change.

One requirement that gets easily overlooked is 11.5.b, which requires organizations at least weekly to perform critical file integrity monitoring (FIM). This typically is met with an enterprise FIM solution that monitors critical files in near real-time, which easily meet the weekly review requirement. However, where organizations typically run into issues with this requirement is the follow up on alerts. The problem occurs when alerts are generated, but there is no proof that the alert was researched and cleared or remediated. The easiest way we have seen for organizations to address this situation is to have alerts flow automatically into their service ticket system so the alerts do not get lost.

For the requirements in 11.1 that address wireless, there is a need to conduct scanning for rogue wireless networks at all facilities that are in-scope at least quarterly. For large retailers, this can be highly problematic as it can take an entire year to manually scan every location for rogue wireless. As a result, organizations with many locations implement automated wireless security solutions that scan in near real-time for rogue wireless networks. These solutions maintain an inventory of wireless access points as well as scanning for rogue wireless networks. The one downside is that these solutions typically have a high false positive rate due to cell phone hotspots, other access points near the facility and other issues. Some cell phone providers and telecommunication companies have seen this as an opportunity and offer scan result filtering to remove a large portion of the false positive results to make these solutions easier to manage.

The final requirement in section 11 with a timing implication is 11.4.a which requires an organization at least annually to confirm intrusion detection/protection mechanisms have been implemented that can monitor and assess all network traffic. Organizations sometimes make network changes and missed putting intrusion detection/prevention controls back into place to monitor all network traffic.

It is key to have all of these business as usual (BAU) requirements integrated into your day-to-day, month-to-month security activities so that they are not something special you do only when trying to go through your PCI compliance assessment. Having them integrated into your normal operations makes it more likely that you identify an issue before it becomes a major problem.