Scans required for PCI DSS compliance

[ This article was originally published here ]

This is the fifth blog in the series focused on PCI DSS, written by an AT&T Cybersecurity consultant. See the first blog relating to IAM and PCI DSS . See the second blog on PCI DSS reporting details to ensure when contracting quarterly CDE tests . The third blog on network and data flow diagrams for PCI DSS compliance is . The fourth blog on API testing for compliance is .

As a risk-based response to the continuous, and varied assaults on our systems by criminals, the PCI DSS standard requires a minimum of 20 technical scans per full year for merchants, and 21 for third-party service providers (TPSPs) The table below lists them.

New entities going through compliance for the first time can provide just the most recent quarter’s worth of each of the applicable scans (and rescans, if necessary) as long as they are “clean”, i.e., they passed all the required elements with no critical or serious findings.

Some of the standard’s requirements must be performed “periodically” which is in quotes because the standard does not define the period covered by that term. As a result, QSAs look to clients to use their risk assessments to define and justify periodicity for the various contexts in which the DSS grants discretion to the assessed entity. Each period thus derived should then be documented in the Entity’s Policy, Procedure, compliance calendar, or internal standards documentation set as appropriate.

Some of the scans prescribed by the standard must be completed quarterly, others annually, and all have the caveat: “and repeated after a significant change”, this accounts for the qualifier “minimum” adjacent to the initial scan counts above.

Please refer to separate guidance on what constitutes a “significant change”.

PCI is VERY unforgiving if ASV scans do not occur within a 90-92 day cadence. Remedial or correction scans must be provided as soon as practicable to prove that the CDE was vulnerable for the shortest practical period. A client may not wait for the next month’s scan to prove remediation. However, if a vulnerability takes a long time to fix, documentation of following the process and mitigating arrangements (such as additional firewall or IDS/IPS configurations) will need to be shown instead.

Many entities miss four of the required quarterly scans since they are not explicitly defined in the Standard but are referenced in Section (not Requirement) 3.1 of the Report on Compliance, which asks about the environment and methodology used to confirm the scope of the CDE. (Requirement 3.1 is in Section 6 of the ROC).

The scan they miss is the one that answers the question “how did you prove there is no cardholder data (CHD) outside the Cardholder Data Environment (CDE)”. Since Requirement 3.1.b asks for proof of a quarterly process to ensure that all legitimate CHD is identified and removed when its retention limit expires, it follows that the scans for unexpected CHD should be subject to at least the same periodicity.

In fact, unexpected CHD can be a breach risk, and while processes should ensure unexpected CHD is impossible to create, staffers can sometimes create ad-hoc processes to overcome limitations of the sanctioned ones. The unexpected CHD could become problematic in many ways. Physical and logical access may not be limited to those with a job-specific function; encryption may not be performed; the process is undocumented and therefore unmaintained; retention may be non-compliant with policies; disposal may be insecure or non-existent.

Two likely places to find unexpected CHD are the test (QA) environment, and operating system-, or web server application-, level crash dumps. For a large organization with many staff, we recommend scanning the systems of all personnel with direct primary account number (PAN) access or implementing a DLP solution that monitors everything real-time.

To close, every scan should be producing log information and even, possibly, alerts about security issues. Some organizations whitelist the tester to allow more in-depth testing after uncredentialed tests are complete, or if the blocking threshold is too low.

Please check the logs to ensure that you are seeing the testing and adjust thresholds or configurations appropriately. If you whitelist the tester or silence the alerts because you “know it’s coming from the testing”, remember to take them off the whitelist and re-enable the alerts after testing completes. It’s also good practice to review the logs and alerts anyway to make sure no-one piggybacked on the testing to achieve anything nefarious.

Required scans

AT&T Cybersecurity provides a broad range of consulting services to help you out in your journey to manage risk and keep your company secure. PCI-DSS consulting is only one of the areas where we can assist. Check out .

Ad