Passing the New Guidelines on PCI Risk Assessments

Thursday, March 07, 2013

Stephen Marchewitz


Typically at SecureState, we get asked about the standards for a security risk assessment, what it should include, and where you can take shortcuts to get a good return on your security investment. This is especially true when you’re looking at PCI DSS compliance, as the options are becoming clearer. While PCI DSS compliance has been a requirement for several years now, it’s been fairly subjective as to what a compliant program looks like and how an organization actually goes about it. While that can still look to be the case, here are a few things to consider.

The Basics

Using a common sense approach as a guideline, a risk assessment has only a few boundaries letting you know if you’re on the right track. It should be:

  • Simple
  • Clear
  • Validated
  • A Vehicle for Continuous Improvement

You’ll want to work with a company that uses a rational, defensible, “sane” process for assessing risk. Not unexpectedly, assessors will like to see the use of industry accepted methodologies. For most organizations, they’re going to look to use NIST SP 800-30, ISO27005, COSO or OCTAVE as a guideline or goal for their “to-be” state of the security risk management program. If you don’t use recognized methodologies in this way, you’ll most likely have to explain how and why you have strayed. Obviously, knowing the typical state of companies today, these may be cost prohibitive; thus it is important to use best and realistic current practices as the stepping stones to get there.

Here is what I see that will need to be done if a QSA holds a company to the fullest extent of the intent of the standard (as defined in the PCI-SSC 11/16/2012 SIG guidance on PCI Risk Assessments).

Components of a Compliant Risk Assessment

We see robust risk assessments most likely including (to one degree or another) the following:

  • Key Stakeholders (a listing and analysis of their goals)
  • Risk Assessment Team
  • Risk Assessment Methodology (including associated framework)
  • Business Processes (mapped)
  • Listing of the Business Infrastructure Components (the dependent systems: hardware, software, etc. of those business processes)
  • Identify Critical Assets (Asset Inventory and (Rough) Value)
  • Threat Groups and Analysis (i.e. Sources of Threat)
  • Vulnerability Groups and Analysis
  • Third Party Risks (a listing of them)
  • Data Flow (certainly for the PCI environment)
  • Control Analysis (In place/Not In Place)
  • Validation of Controls (Penetration tests, Scans, Ruleset Reviews, etc.)
  • Cost/Benefit Review of Remediation or Treatments)
  • Risk Treatment Plan (or Mitigation Plan)
  • Communication Plan
  • Scheduled Annually

Ideally, these results should be Quantitative. Qualitative methods are best used when ‘guesstimates’ are enough, and when the cost vastly outweighs the benefits of understanding. However, this may or may not be accepted by PCI assessors going forward (nor with the advancement of most Enterprise Risk Management programs).

A couple of other notes on this: It does not seem that you will fail if your process is not “repeatable,” meaning exact results need be replicated, eliminating any subjectivity in the process. This had been posited by some QSA’s in their interpretations over the years, even though the feasibility of this is just about impossible for most common sense organizations looking at the cost-benefit of such an exercise. ISO and others use the Shewhart/Deming cycle of Plan-Do-Check-Act (PDCA), which is the foundation for every good process out there.

Quantitative Approaches

At SecureState, we use the Independent Risk or iRisk equation and SEI’s Capability Maturity Model integration (CMMI) as the simplest engine to get from where most organizations are today to where they need to be for basic, sound, risk management. We are also proponents of FAIR (Factor Analysis of Information Risk) as another methodology if you’re looking to take risk management outside of the basics of security, incorporating operational risk as well. The big takeaway is there needs to be better rationale for the things you are and aren’t doing for managing your security program. And that rationale needs to be quantitative wherever possible. Both the iRisk and FAIR equations or taxonomies are quantitative, which again makes them much more defensible when speaking with risk officers or auditors— PCI or otherwise.

Common Sense Isn’t So Common

As with all things PCI that we’ve seen come out, it’s clear they’re simply trying to get organizations to use common sense. Oftentimes the reason QSAs get a bit pointed and short is that it’s tough to get people to listen unless they do. Ideally, what PCI is looking for is what any rational person would want out of a risk assessment. In addition to the components above, it really simply needs to improve the ability of organization to communicate regarding compliance and security issues, bridging the gap between executive management, security, risk management and audit to execute and improve the security of organizations in the most cost sensitive manner. As an industry, security is making progress. Sometimes it’s kicking and screaming, but it’s progress none the less. 

Possibly Related Articles:
PCI DSS Enterprise Security
PCI Risk Assessments compliance
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.