Do I Need Vulnerability Scanning to Validate Compliance to the PCI DSS?
The short answer to this often-asked question is ‘Yes’! There are, however, a number
of other misconceptions surrounding this area of compliance and we will hopefully
be adding some clarification in this blog!
One misconception that we frequently encounter is when the term ‘vulnerability
scanning’ is confused with ‘penetration testing’. Whilst vulnerability scanning and
penetration testing are without doubt complimentary, they are distinct activities
which both need to be completed for overall compliance to be achieved. Penetration
testing comprises activities performed by qualified and specialist personnel who attempt
to actively breach an organisation’s defences.
Penetration testers will attempt to exploit any vulnerabilities present to either elevate privileges, access sensitive or confidential information or to deny access to a resource. Vulnerability scanning is the process whereby operating systems, databases and other applications, in addition to network infrastructure, are assessed and scanned for the presence of known vulnerabilities and insecure configurations which could lead to a breach if exploited. Vulnerability scans might be used by penetration testers to narrow down the scope of attack to focus on particularly vulnerable areas or components in an environment.
Expanding on the concept, vulnerability scanning comprises internal and external processes which analyse an organisation’s internal environment and external, public-facing interfaces respectively. If the organisation concerned is classified as a Payment Card Industry Data Security Standard (PCI DSS)
Level-1 merchant, service provider or has been unfortunate to have suffered a data breach, both internal and external vulnerability scanning processes are necessary to achieve compliance. In addition, dependent on the agreed level of validation, the results may need to be documented in a formal report on compliance (RoC), verified by a qualified security assessor (QSA).
Many organisations provide both internal and external vulnerability scanning services. However, only organisations certified as ‘approved scanning vendors’ (ASVs) are permitted to provide external scanning services. ASVs provide reports which indicate either a pass / fail result in terms of PCI compliance for the related vulnerability scanning controls.
For those organisations not falling into the aforementioned PCI DSS categories and, therefore, allowed to self-certify via the various self-assessment questionnaires (SAQs), external vulnerability scans from an ASV, as a minimum, need to be performed for compliance. This is a topic of some debate, as not all of the SAQs explicitly require external scanning as part of the control subsets.
A prime example being SAQ A, which is designed for merchants who have totally outsourced all of their payment-related functions to compliant third parties and who do not store any cardholder data (CHD) electronically. While SAQ A does not formally require compliance with any controls from Requirement 11 of the PCI DSS, the introduction of the SAQ states that all required documentation, including ASV scans, must be provided to acquirers, payment brands or other requesters.
Due to the increased focus on smaller merchants who’ve been victims of breaches recently, experience shows that certain card brands are requiring the submission of ASV scans for most merchant and SAQ types. For those organisations without any external-facing interfaces or who only process transactions via P2PE or dial-up terminals, an argument can be made that ASV scans are unnecessary.
Below is a summary of the SAQ types and their relation to the need for internal/external vulnerability scanning.
SAQ A – No official requirement, but submission of quarterly ASV scans is recommended
SAQ A-EP – Submit external ASV scans and ensure internal scans are performed
SAQ B – No official requirement
SAQ B-IP – Submit quarterly ASV scans
SAQ C – Submit external ASV scans and ensure internal scans are performed
SAQ C-VT – No official requirement
SAQ P2PE – No official requirement
SAQ D (Merchant) – Submit external ASV scans and ensure internal scans are performed
SAQ D (Service Provider) – Submit external ASV scans and ensure internal scans are performed
As the practice of scanning for vulnerabilities has been maturing for decades, the number of vendors offering these services has increased exponentially, and the methods and technologies make this process easier to implement and achieve than ever before. With all the options and skills readily available, no organisation should be falling short and not achieving this control as part of their compliance initiative.