I recently participated in a LinkedIn group discussion regarding the PCI DSS requirement 11.2 that states you must perform a vulnerability scan against all in scope devices on a quarterly basis. While this important requirement is a cornerstone of a robust vulnerability management program, there are instances where it may prove to be infeasible for some entities to adhere to the letter of the law. For example, a retailer with several hundred or thousand locations may be hard pressed to effectively perform scans in a timely or cost efficient manner. Over the past several years, I’ve worked with several merchants who have developed creative vulnerability management programs to creatively address the spirit of this PCI requirement. While different PCI QSAs (Qualified Security Assessors) may interpret this requirement differently depending on whether they take a risk-based approach to PCI or an auditor’s black/white approach, we have found this pragmatic approach to work for our clients many times.
Many large retailers are challenged with trying to scan thousands of remote devices within a three-month time period. In addition to time window challenges (i.e., many retailers will not run scans during store hours) and bandwidth challenges (most scans are run from a centralized scanner, so the scan speed is hampered by whatever bandwidth is available for that retail location), it can be very expensive to purchase a scanning license for every single device at the retail locations.
Retailers may be able to scan a sample of their systems at retail locations during a quarter to meet the spirit of this requirement. This strategy relies on the following assumptions, and I’d love to hear from you if you have some suggestions on what we can add to the list:
- All retail systems are maintained in a PCI compliant manner (should go without saying).
- All retail systems strongly adhere to a build standard.
- The results of the sampling of these systems validates the point above.
- All updates/upgrades/patches are applied consistently across all retail systems.
- The POS systems have NO access to the Internet.
- If there ARE any vulnerability scan findings, the fix is applied across ALL retail systems and not just the scanned sample (this may be a small price to pay to not have to scan all systems each quarter). You must also perform a validation scan against any system that had a finding.
- If there ARE any vulnerability scan findings, it is imperative that you perform a root cause analysis since this would be indicative of a vulnerability management process in need of fine tuning.
- Scan all new systems as they are built, prior to release to production (this constitutes a potentially "significant" change).
Scan What When?
First and foremost, I am not advocating that you scan a sample of your centralized or core systems – this strategy focuses on retail locations where there are mainly point-of-sale systems in remote locations. You must scan all in-scope core systems every quarter. Period.
For those who are considering this strategy for their retail locations, we’ve seen the following sampling methodology/frequency work. Have you seen any successful strategies like this or perhaps others that you’d recommend?
- Scan all of your systems over the course of a year. This means you should mix up your sampling each quarter.
- We’ve often seen large retailers scan 10% of their environment each month so that 100% is scanned within about 10-11 months.
What About Cardholder Data Discovery in my Retail Environment?
The same holds true for performing cardholder data discovery scans. Licensing costs for many cardholder data discovery tools is quite high, and often for retail locations, the cost of these tools can exceed the benefits, especially when there is often little probability of cardholder data residing on these systems. Mileage may vary here, but retailers with POS environments where there is no logical means of storing unencrypted cardholder data should have little need for performing a full blown discovery scan at all of their retail locations. That said, I’d still strongly recommend performing a cardholder data discovery scan against some of these systems since what you don’t know in this case can hurt you. As the case with vulnerability scans, if for some reason there are findings, then:
- Perform a root cause analysis to determine how cardholder data got on to the system in the first place and create a process to prevent it from happening in the future (or for monitoring/alerting if it does happen in the future).
- Figure out why the cardholder data resides there and ensure it is not needed for business reasons. (Remember – this discovery would be that of a previously unknown repository!)
- Create a process (i.e., write a script) to eradicate the entire retail environment of this rogue cardholder data (including all systems that were not part of the discovery scans).
This strategy may not work for everyone. If you have a heterogeneous retail environment, you’d be hard-pressed to follow this plan. While the PCI DSS does not explicitly state that all in-scope systems must be scanned on a quarterly basis, it would be the general expectation of almost any QSA, unless proven otherwise; and it is possible that your QSA will be adamantly opposed to this heresy. That said, if you work closely with your QSA, you may be able to build your case (based on the recommendations above) for scanning a sample of your environment each quarter.