Risk and PCI-DSS

December 17, 2008

I recently had lunch with a friend and we spent a lot of time talking about PCI. I am heavily involved in some PCI-related activities at work that has resulted in me knowing more about PCI then I would care to. I wanted to document some of the subject matter we discussed especially with regard to: how to approach a PCI compliance assessment project, states of compliance, and articulating risk related to requirement gaps.

So where to begin? Well, you can start by going to the PCI Standards Council website – there is a load of information there. You can find out:

1.    The merchant level of your business based on the number of card transactions your company performs.
2.    The kind of validation actions you are required to take.
3.    How your “validation actions” need to be validated.

One point I would like to throw out there for companies with numerous subsidiaries is you need to work with your QSA to determine if the subsidiaries that are under your company umbrella are separate from a compliance perspective or if they are under the compliance status of the parent company. Not understanding this early in the process could result in a lot of wasted time.

Another point on this topic is that one needs to understand the flow of PAN through your environment. Visually (and accurately) representing this very early in the process will reduce assumptions and be of great benefit through the assessment lifecycle.

In general, PCI Compliance seems to be very binary – you are either compliant or not; the severity of one’s non-compliance is where the grey is. Non-compliance can result in fines, increased transaction fees, and whatever other penalties exist. I will end this thought with stating that not all QSAs are created equal nor are all payment processors created equal. On the PCI Council website – they advise people to choose QSAs that know your industry – that is great advice. Some payment processors will recommend QSAs for you. Do your homework and make sure it is a QSA you are comfortable with.

Let’s talk risk and PCI. I think of PCI risk different then some folks. I separate the risk of being non-compliant from the risk of the gaps themselves. Let me explain.

Risk associated with just being non-compliant (no incident has occurred): Merchants can be fined for not being compliant. In this type of scenario – the merchant’s payment processor could levy the fine. As a matter of fact, the card associations can fine the payment processor who can then fine the merchant. Fine amounts can vary and there is no guarantee that you will be fined for being out of compliance. Also, it would appear that fines for this type of non-compliance are independent of the number of requirement gaps. So whether a merchant has one requirement gap or dozens – the fine is for being non-compliant. If an organization is not compliant – the expected annualized loss magnitude for not being complaint would be the expected monthly fine amount multiplied by 12.

Risk associated with being non-complaint; an incident has occurred. This is where the pucker factor starts. This is a situation where a merchant has suffered a breach and is non-compliant or possibly even compliant. There are numerous resources out there about the fines that can be levied against the merchants by the card associations, payment processor fines / increases transaction charges, card replacement costs, reputation costs and much, much more. This is a worst case loss scenario from a risk perspective. For large merchants, I would think that monetary impact would easily be hundreds of thousands of dollars to a couple million dollars; more depending on the size of the breach. TJX is a good *worst* worst case benchmark.

Risk associated with the gaps themselves. When it comes to assessing the gaps – or risk issues – I prefer to assess them independent of the compliance status. Even though a single risk issue can result in a state of non-compliance which has its own risk (fine) amounts – what good is it for the risk issue itself to assume the risk amount of not being compliant in cases where you have multiple gaps? So, I prefer to think of them independently. This allows for better mitigation prioritization, cost benefit analysis, and being more objective in how you articulate the risk to the decision makers.

If you think about what I have written you can easily imagine a situation where a merchant could justify remaining out of compliance because the cost of not being compliant (in absence of a breach) is cheaper then becoming compliant. For some companies that may be a viable option (though few would probably ever admit that is their approach), but most companies want to be compliant, want to show due care to their customers / consumers, and do not want to take the chance on a breach and the reputation impact that comes with that.

Finally, for most companies – achieving compliance cannot happen with one stroke of the magic wand. There may be a period of time between gap identification and mitigation, which means the company, needs to manage that risk accordingly. I hope some of my thoughts above might help with that (combined with your legal council input, leadership input, your QSA, etc.)

Now, if the PCI Security Standards Council would take more of a risk based approach in determining level of compliancy and magnitude of fines – that would be pretty cool. And no, using CVSS scores to tag technical vulnerabilities is not really a risk based approach.

** Late addition to the post ** – My next post will be about a positive PCI QSA experience I recently had.


PCI, Risk Management & “The Blackberry Arsenal”

October 21, 2008

Recently I was assigned to a special project to be the information risk management representative for a payment card processing provider RFP.

One of the vendors was an organization based out of a prominent US city with loads of financial institutions. I will refer to this vendor as N; of which one of their subsidiaries – referred to a n – is the actual business unit that provides the actual card processing services. So, for practical purposes – n does the real work; but N is responsible for the big RFP responses and on-site sales pitches. For blog purposes, I will refer to the combined entity as Nn – sort of like me and mini-me…bad attempt at humor – but you get my point.

As to be expected Nn showed up in force. Color coded apparel, great shoes, smiles, and the type of financial savviness one would expect from a reputable financial services provider. I was pretty impressed and to be honest, a show in force like this is what I expect given the size of the company I work for and the attention PCI-DSS commands. After the typical hand-shaking niceties and genuine attempts to find commonality between each other – the love fest started.

About 90 minutes into vendor Nn’s presentation, I asked some of my basic due diligence questions. Now keep in mind from previous posts, that I consider information risk management professionals to be intelligence analysts – always gathering intelligence about threats, attack vectors, etc. For a vendor not to think that potential clients are not checking up on them is mind-boggling – but more on that later.

One of my typical questions for any vendor that I assess for risk is: “How does your information security organization manage information security risk?” It is a fair question from my perspective and acceptable answers can be very simple or very complex. I prefer simple but complex is OK as long as they answer it and try not to dodge the question. In this case, vendor Nn answered the question sufficiently. But I still had some reservations regarding the big N and the little n. So, the follow-up question was this:

“In 200X your company (N) suffered a security breach. What has company N done to ensure the same vulnerability does not exist or cannot be exploited moving forward within company N and its subsidiary n?”

Well my friends (a McCain’ism), the love fest came to a halt right then and there.

The talking stopped!

The deer in the head lights look overcame the faces of the team representing Nn.

Nervous glances started being cast.

The Nn sales team lead responded with the following: “What breach?”

My response: “The breach in 200X that shows up in a simple Google search phrase “Nn security breach PCI”.

Nn sales team lead response: “I am not aware of that!”

My response: “We would like a formal statement regarding the security breach, the business unit impacted, and what has been done to prevent a repeat occurrence within the impacted business unit and any other business units owned by N.”

Nn sales team lead response: “Let us follow-up with you!”

My response: “Thank you!”

At this point, the Nn sales team broke out their Blackberry arsenal. And over the next 60 minutes there was more Blackberry thumbing then I have ever witnessed in a 60 minute period. The love fest had migrated to the sales team, their Blackberries, and other entities miles away; though deep down inside I would not be surprised if there were one or two messages between the Nn sales team to each other talking about the new A-hole they just stumbled upon.

Two hours later…during a break… (the love had still not returned to its original levels…)

Nn sales team member X: “I am sorry we could not speak to your question earlier today.”

My response: “That’s OK. I appreciate any follow-up responses you can provide.”

Nn sales team member X: “Well, we really did not know about this security breach, but our legal and PR departments will prepare a response. We really did not know about this.”

My response: “Thank you, we look forward to receiving it! You know, there is a neat Google service that let’s you set up email alerts based on keywords you define. I use it all the time to keep tabs on my company as well other companies. It is a great sales information tool.”

Nn sales team member X: “Thanks I will look into that!”

A few hours later, and some more Blackberry thumbing, the Nn sales team left. Only half of the team bothered saying bye to me and shaking my hand. I cannot blame them – I understand the frustration. In a previous consulting role (that included sales engineer responsibilities) – I saw my share of blown sales pitches and uncomfortable situations.

So here are a few thoughts:

1.    Companies that experience security breaches – of which the acknowledgment that it occurred is public – need to educate their sales team / marketing folks (the entire company it can be argued) that their reputation matters and that they could face tough questions. To not think that other financial services companies or companies looking to use their card payment services will not ask them about recent breaches is ludicrous.

2.    The fact that Nn recently suffered a breach but could not speak to it right then and there does NOT disqualify them from further consideration. It is important to point this out and underscores the importance of being objective and looking at all aspects of one’s security posture. In addition, this underscores the power of taking a risk-based approach to assessing risk.

3.    Ever heard the term “hate the sin, not the sinner”. It is somewhat applicable here. I honestly believe the Nn sales team did not know about the breach. A simple Linked-In search on the Nn sales team (at least three of them) confirms they were with Nn at the time of the breach – but that does not mean they had privileged knowledge of it.

4.    Don’t be afraid to be the friction point – by asking tough questions. Tough questions can be asked – but asking with a sense of humility and tact goes a long way. The reality is that sometimes, tough questions cannot be asked unless you are direct and to the point. A lot of us are getting paid good money to perform an appropriate level of due diligence – let’s earn it.

5.    At the end of the day, there are a few things the Nn might say they learned from their trip:

  1. A-hole’s company cares about security.
  2. We need to be better prepared to know about security in our company and how to speak to past incidents.
  3. Just because we are PCI compliant does not make our sales efforts easy.
  4. We need to stop at the airport bar before the flight takes off.

So there you have it. Another day, another dollar – I love my job.


Follow

Get every new post delivered to your Inbox.