PCI DSS V2.0 Risk Assessment

The PCI SSC released an updated version of its prioritised approach earlier in May with a small number of updates to milestone setting for specific requirements. One of these requirements is 12.1.2 which has moved from milestone 6 to milestone 1. This is a significant change as it means that this requirement is now in scope for alternative programs such as VISA TIP and that a new emphasis has been placed on this requirement.

So what implications does this have for planning, executing and maintaining a compliance program to the PCI DSS standard?

It implies that a full risk assessment using a formal methodology should be the first step in starting a compliance program and the first thing to do on an annual basis in maintaining a compliance program. This is something of a departure from the more established approach of executing a gap analysis against the standard and proceeding from there. The standard mentions three specific methodologies OCTAVE, ISO 27005 and NIST SP 800-30 but allows room for others (perhaps also COBIT/ISACA Risk IT).

So what is the difference between a risk assessment and a gap analysis? The answer would be quite a bit. A gap analysis is control focused, it simply asks the question is this control implement and can it be verified. Fairly binary and easy to do and produces a view that is control centric. A risk assessment is far more subjective and quite a bit more complex. First we need to clarify what we mean by risk. In the context of PCI DSS it can probably be summarised as simply ‘an expression of the impact and likelihood of a data breach involving cardholder data’. Sounds simple enough so far?

Here is where it gets a little more complicated. First the impact will be determined by the volume of cardholder data and also if any sensitive authentication data is also present. This may vary in different parts of the network and therefore a compromise may have a different impact depending on where the compromise occurs and how far it spreads. Second the likelihood needs to take into account the threats, vulnerabilities and the effectiveness of the current countermeasures to these threats and vulnerabilities. In this case the countermeasures are the ‘controls’ in PCI DSS (yes I know they are called requirements in PCI DSS but for the rest of the universe they are called controls, i.e. they control risk).

So here is where we sync back with the gap analysis but with a twist. Rather than looking at each individual control we need to look at each individual asset or asset group. By identifying the controls that should apply to this asset or asset group and reviewing the effectiveness of the controls we can calculate a relative risk value. Based on the relative risk value we now have a new way to prioritise our program (i.e. deal with the highest risks first).

It is worth noting that in a risk assessment it is the effectiveness of the control that is evaluated. While this process introduces more subjectivity to the assessment process it also does a better job of ensuring the controls are not only fit for purpose but actually deal with an identified threat.


Comments (1)

Said this on 7-30-2011 At 01:49 pm

Always a good job right here. Keep rliolng on through.

Post a Comment
* Your Name:
* Your Email:
(not publicly displayed)
Reply Notification:
Approval Notification:
Website:
* Security Image:
Security Image Generate new
Copy the numbers and letters from the security image:
* Message: