One of the most recently discussed topics of the PCI DSS version 2 is the requirement 6.2, which will introduce a mandatory change of internal procedures, impacting both the patching process and the risk assessment, starting from July the 1st 2012.  The mentioned requirement states the following: Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities. ntt_foto_4Based on our experience, the most popular question submitted to QSAs from PCI DSS compliant entities is whether or not requirement 6.2 will affect the existing patching process and in particular those actions that have been established for years in order to comply with the previous requirement of section 6 which enforces the installation of all critical security patches, normally provided by the vendors, within 30 days of release.

The quick answer would be no!

Let's look at reformulating requirement 6.2

Any PCI DSS compliant entity has to demonstrate the ability to identify new security vulnerabilities and assign a priority to each one of them. Based on documented criteria (6.2.a); any PCI DSS compliant entity has to demonstrate the inclusion of external sources for security vulnerabilities information (6.2.b).

The process of identifying new security vulnerabilities and the implementation of a RIsk Based Scoring System translates, for most companies, into a overhead caused by the required interactions between different IT departments and by the mandatory parsing of information as received by various channels.

We will try to identify the various channels mentioned. The very first resource for information of newly discovered security vulnerabilities is represented by the vendors' security alerts. By subscribing to vendors' newsletters, or any other alternative communication methods, the PCI DSS assessed entity can demonstrate the compliance against 6.2.a, which only requires the involvement of external sources in the discovery process.

Reviewing the official document "Navigating PCI DSS 2.0", it is clear the PCI Council tries to draw the attention of the intended community to the usage of "common industry vulnerability news groups and mailing lists for vulnerabilities and potential workarounds that may not yet be known or resolved by the vendor".

This translates into the implicit suggestion of subscribing to one of the many vulnerability intelligence advisories available. We agree with the above statement.

From a QSA perspective, the customer must be able to demonstrate that all in-scope technologies are monitored, in terms of security vulnerability awareness, by subscribing to the respective vendor newsletter. The advantage of relying on a dedicated advisory to obtain regular information concerning newly discovered security issues in a "vendor-independent" approach is immediately evident.

By identifying the most immediate channels for information on security vulnerability we managed to automatically comply with requirement 6.2.a, which we believe will not cause any additional effort. Another way of obtaining information and discovering new security vulnerabilities is from 0-day exploit research teams, penetration testing and secure code review, ultimately by the usage of vulnerability management advisories such as those your company utilizes to perform internal vulnerability assessment and detection of intrusions (via IDS/IPS).

So what do we have to do once we know how to gather information on newly discovered security vulnerabilities and once we are assured of compliance with 6.2.b by using external sources?

We would simply need to rank the findings based on specific criteria.

The PCI SSC clearly states a risk ranking should be based on industry accepted best practice. We, at Advantio, share this reasoning entirely and it will help avoid populating the PCI DSS market with various different implementations with the same objective, justified by the fact that each CDE is unique. CVSS 2.0 and NIST SP 800-30 are examples of industry accepted risk ranking systems. As the CVSS is a common pattern within the PCI DSS domain, mainly used to validate external scanning results, the best option would be to generate an internal risk ranking system based on this CVSS algorithm.

Today, the majority of the services that provide security advisories can present reports and lists where each vulnerability is categorized with a CVSS score. Furthermore, it is becoming very popular to provide penetration test reports classifying findings by CVSS; the same approach is utilized by ASVs and internal assessment tools. The CVSS is without a doubt becoming the reference for vulnerability scoring.

Sometimes, due to it's nature, CVSS is not applicable for scoring a code review exercise and in this case the discontinued CWSS project becomes an option. Note that the requirement 6.2.a offers the choice of developing a whole risk ranking system from scratch, if this is really the way your organization wants to go.

Once the choice of the industry best practice is made (CVSS in our example), it is important to understand how to customize the risk score of all discovered security vulnerabilities, starting from a known value. Please note that the CVSS score of any vulnerability can be easily calculated with the NIST provided tool.

Various approaches can be applied to implement this strategy

One we propose relies on the introduction of so-called "risk modifiers", that is multiplicative indexes which help redefine the CVSS score in terms of internally defined risk criteria.

The choice of how to personalize the obtained scope is up to the individual company due to the uniqueness of every Card Data Environment. It is not the scope of this article to provide details on the CVSS algorithm which can be found on the FIRST website. We want, however, to propose a general strategy based on two simple concepts: "Promotion or Demotion" of a given vulnerability.

In practice - and without going too deep into any technical implementation - the basic idea would be the following. The customer defines his own alternate risk ranking based on levels (for instance, "low-medium-high-critical"). The whole CVSS range then gets mapped according to the level of risk so that, whatever their number, the threshold CVSS score "4" represents the upper-boundary of the "medium" level.

Any value over "4" is indeed considered to be a high severity issue according to PCI DSS. Now, whenever a new vulnerability is discovered, the customer calculates a CVSS value. At the same time and independently, the vulnerability is placed in one of the risk levels. If there is a match between the CVSS value and the risk level, no further actions are required in terms of PCI DSS.

If not, a multiplicative "risk modifier" is applied to the original CVSS score, which is recalculated in order to obtain a new score finally falling within the correct level.

Of course, such an approach could be used beyond any PCI related "Promotion and Demotion" tasks in order to simply fine-tune the CVSS score to a more suitable value. In any case, it would surely be worthwhile taking the opportunity to address the PCI DSS 6.2 requirement by speaking in terms of a standard and measurable means (CVSS) whilst basically relying on internally developed risk definition criteria. Please let us know your opinion by commenting this post!

Marco Borza

Written by Marco Borza

I am the Founder of Advantio.
Technology has been my passion since I was a kid; when I first heard the handshake of an old 300bps modem I realised security would be key in an interconnected world. Since then it has become my passion and primary focus.
The reason why I've started my own business is to make IT Security simple.

Certifications: CISSP / CCSA (Checkpoint) / ITIL Foundations / ACSA (ArcSight)/ Linux+/ PCI-QSA / PA-QSA