A friend of the blog recently pointed me to an article that used the term:

“PCI Risk Management”

Now usually when I see a term like this, I can only imagine that such things are the byproduct of rapidly decaying brain cells.  In my mind I imagine there’s a conference room somewhere with some marketing types all hopped up on the vapors from industrial solvents spewing terms like “protectivity” or “advanced adaptive deep packet inspection” into the ether with all the acumen of an intoxicated long-horned bovine.

BUT

I thought about this, and it’s really not a bad idea - depending on how you define it.  Now I just couldn’t make the effort to read how the author used the term (I have a short pain threshold), but here’s my thoughts on what PCI Risk Management should be.  If we define Risk as the probable frequency and probable magnitude of future loss.

Then managing the risk inherent in PCI DSS compliance could mean:

1.)  The expected frequency of being out of compliance and how much that will cost us.

Because let’s face it - being in or out of PCI compliance is still a subjective judgment.  First, we have what our ever-qualified assessor says.  But in the case of an incident, it’s really someone else who has the final say in whether or not we were “compliant” at the time of incident.  So we can only know for certain if we’re in compliance after the fact - i.e. after there’s an incident.  So if we cannot really “know” if we’re compliant - we have a probability problem to solve!  Sounds like “risk” or “secure” doesn’t it?

So we could view the PCI as a threat community to deal with.  This gives us the first angle of what we could call PCIRM (this sort of term begs to be it’s own acronym, doesn’t it?) - the simple creation of a probability statement that says there is some belief that we could be found out of compliance - regardless of our efforts - and the calculation of what the impact would be to our organization (like defending frivolous 90 bajillion $ law suits from tiny financial institutions whose lawyers smell blood in the water).  Note that you may or may not want to add the value of the money and time spent on PCI compliance into your loss magnitude calculations.  It’s a sunk cost at that point.

However, there’s another side of the coin.  We can find out the risk of being out of compliance, but is there risk in being *in* compliance?  I think there is.  So our second aspect of PCI Risk Management might be:

2.)  The expected frequency of being in compliance and how much that will cost us.

An alternate view of how we could view the Payment Card Industry as a threat community would involve trying to figure out the probable frequency with which they will make onerous demands of our security budget, and the impact of those demands.

Now note that we would have a “secondary risk” to measure here.  I’m thinking that it’s not improbable that our PCI efforts may not be the most efficient use of or time and money.  So if we’re spending money on what PCI says we must, and neglecting areas of our IRM landscape that would actually reduce organizational risk more than those PCI efforts - then PCI compliance is costing us some real value by reducing our capability to manage real risk.  However,  and it’s quite a long tail event but, imagine that we’re unlucky and an incident happens!  This incident may become, in no small probability, the byproduct of PCI requirements.  Being diligent in risk management, we might want to study this likelihood, too.

So there you have it.  In both cases PCI Risk Management involves looking at the Payment Card Industry as a threat community, and determining the probable impact of having to deal with PCI DSS.

Now if you’ll excuse me, I have a white paper to write and I’m fresh out of acetone-based paint remover.

POST SCRIPT

I should make it clear that Risk Management should (and is) obviously being performed by those with PCI concerns.  PCI, if you will, is simply a sort of ISMS.  And the development of an ISMS can assist IT management with the process of developing metrics and analysis concerning the organizations capability to manage risk.  There’s nothing wrong with PCI in this regard.

But I figured I should make the effort to read what the author was advocating, and the document this “PCI Risk Management” term was drawn from was really a set of “best practices” for PCI and “best practices” above and beyond what PCI requires.  This is not risk management (and no, adding “risk assessment” - in quotes because the author is really referring to vulnerability management - to the list of best practices doesn’t make it risk management, either).  It is more witch-doctory.