Attestation Aggravation?
With the introduction of the ASV changes on September 1, 2010 ASV’s were to begin providing merchants with an Attestation of scan Compliance. The details of the attestation are documented in the ASV Program Guide v1.0, which was released in March of 2010.The introduction of the attestation was intended to bring a reduction in errors with a more formal process of engagement between the merchant and ASV.
But exactly what is the ASV attesting to?
The ASV Program Guide version 1.2 requires that the ASV provide the merchant or service provider an Attestation of Scan Compliance attesting that the scan results meet PCI DSS Requirement 11.2 and the PCI DSS ASV Program Guide.
That’s not how I read it…
There seems to be some inconsistencies amongst ASV’s as to what exactly they are attesting to as a part of the required ASV Attestation of Scan Compliance. In working with different ASV’s over the past years I have come across three different methodologies on what an ASV is attesting to:
- There should be NO vulnerabilities on a given host at the time of attestation
- All identified vulnerabilities have been addressed within 30 days of when they were identified
- All identified vulnerabilities must have been addressed within 90 days of when they were identified
As an example, Qualys (who supplies their scan tool to a large portion of the ASV industry) has implemented a rule within their platform that fails a given host if that host has not been scanned within the last thirty days. This helps them to support their methodology of attestations – vulnerabilities should be addressed within 30 days of when they were identified.
The differences in these methodologies have a huge impact on organizations with a large ASV scanning scope. It is very difficult for an organization of size, running many different operating systems with different patch/release/test cycles to achieve an attestation under these types of attestation requirements.
This is not necessarily an issue with patch timing, it’s an issue with the alignment of different patch cycles and how that is reflected on a particular scan. Let’s take an example – an ASV scan scope of 100 system components contains the following platforms:
- Microsoft Windows
- Redhat Linux
- Cisco IOS
- Juniper OS
- HPUX
- F5 Networks
This approach also presents some inconsistencies with the requirements of DSS Requirement 6.1, which as an example, allows a risk based approach to prioritize less critical security patches for implementation beyond 30 days.
Where’s the sweet spot?
The ASV scanning element of the PCI requirements should be a validation that the merchant or service provider has a working program in place for patch and configuration management by providing proof that vulnerabilities are being addressed in accordance with PCI DSS 6.1 and 11.2. While the stricter attestation requirements by some ASV’s provide a reduction in risk for the ASV, it can also provide operational hurdles for larger organizations.
At this point in time, PCI DSS 11.2 provides no further clarification other than clean scans are required on a quarterly basis. If the merchant can prove to the ASV that vulnerabilities that were identified have been resolved within a 90-day period, I believe that this meets what is currently documented in 11.2.
Establishing the time that vulnerabilities must be remediated by should be based on risk to the organization while meeting the minimum guides of compliance requirements. It should be up to the merchant or service provider to establish these time frames according to their business risk. Unfortunately in some circumstances, this timing is being established based on risk to the ASV and what they will attest to, not risk to the merchant and their operating environment.
Hopefully the highly anticipated next version of the PCI Program Guide will bring some much needed clarification in this space.