PCI QSA Goodness

December 18, 2008

In some of my posts, I have been somewhat critical of the PCI-QSAs. My biggest frustration is when you cannot get a clear answer from an assessor on complex scenarios and complex technologies. I have made comments related to ‘not all QSAs are created equal’, ‘the value add that QSAs do not deliver on’ and probably a few others that make QSAs and their pool of certified assessors grit their teeth and think negative things of me.

From the QSA perspective, I can appreciate the frustrations they have in getting adequate information from a merchant. The way I see it, that frustration is part of the job they signed up for. Maybe it is a Marine thing – but I have high expectations of professionals that are the subject matter experts of a beast like PCI-DSS. I want to deal with QSAs that actually know technology, understand security controls, are able to contextualize a security control as applied to a technology, and are willing to tell you that you are either right or wrong – not some of this wishy-washy, not willing to take a side approach that leaves as much uncertainty about a scenario then when you first started seeking feedback.

I recently had an opportunity to collaborate with a QSA that really impressed me. The company is called Payment Software Company (PSC); based out of San Jose, California. PSC is a boutique firm that specializes in the payment technology niche.

The folks at PSC know the “payment card industry” and have been a part of it long before PCI-DSS became what it is today; I would even say that is part of their value proposition. From my perspective this is a powerful differentiation between QSAs that have assessors that only know PCI-DSS and are jumping on the PCI-DSS make a quick buck band wagon and not providing as much value.

Another observation I would make about PSC is that they really understand how technology and security work together and what it means from a PCI-DSS perspective. The *leaders* of the company know technology and security at a very granular level; to an extent most reasonable folks would not anticipate. The reason this is important is because it helps with understanding the intent of some of the PCI-DSS requirements as well leveraging compensating controls when there may be a gap.

For fear of sounding repetitive, the PCI Security Standards Council encourages merchants to choose their QSA wisely. I have only worked with a handful of assessors from various QSAs, some good and some not so good. The PSC team easily stands out from all the others – an example of PCI QSA goodness.

I really hope I cross paths with the PSC  team again – sooner rather then later!

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.

Risk Convergence Frustrations

December 12, 2008


Risk convergence is quite the buzz-phrase in the world of risk. People are flying around attempting to model operational risk against enterprise risk curves. Some folks are still trying to crack the useful “risk metric” nut. Disparate groups in the same company that do risk assessments in different context are beginning to collaborate. I work in a large company where risk convergence is occurring.

As to be expected, it is year end at the “big company” and time for some risk reflection. Executives – and I somewhat use that word loosely – love to pimp “accomplishments” – and I use that world loosely as well. The crown jewel risk convergence accomplishment for this year was a common risk vernacular. Now, there was some hard work that went into this accomplishment that involved a lot of inter-department politics, egos and who knows what else. There is a lot of value in having a common risk vernacular – I do not argue that. But having a common risk vernacular does not really contribute much to decision making when it comes to risk.

In most large companies, risk issues or control that are found by Internal Audit teams usually get reported to the CEO and the Board. It is reasonable to assume that some of these findings are actually read by the CEO or the Board or other interested parties that have a C at the beginning of their title. But I have seen IT-related Internal Audit findings numerous times and none of them have ever articulated exposure the company faces by having the identified “risk issue” or “control issue”. I have seen some that there is probably some significant exposure and have seen others where there is little if any exposure.

The frustration I have is that information risk management issues are being treated differently then risk issues found by other risk groups. This can result in the following (and this is more through the lens of information technology):

1.    There are numerous times where risk groups will write issues for the same IT area. Thus, from a mitigation stand point – there is competition for the same resources. Issues that have more visibility from a leadership level usually get prioritized above issues that have less visibility.

2.    Some risk groups are able to articulate exposure in terms of dollars. Other groups articulate in terms of levels of bad. So, a not-so-bad issue (little if any monetary exposure) that has more visibility from a leadership perspective can get prioritized above a risk issue where expected annualized loss is significant.

Maybe I have unrealistic expectations when it comes to risk convergence – or maybe I am being too eager. What I want to see and continue to reinforce to those that will listen, is information that is actionable:

1.    Risk issues that have dollar values.
2.    Equal treatment of risk issues.
3.    Consistent classifying of risk issues (from a qualitative label perspective)

I do not believe that risk convergence is really that radical where it should take years in a big company to achieve. I think there is unwillingness by the functional risk groups to give ground. I think there is unwillingness by leadership to tackle some tough risk-related obstacles– and choose instead to focus on common language that quite frankly a small groups practitioners that make far less money could have done.

I am professionally and personally excited for 2009. This post is really a venting but should not be taken as an indicator as the norm of where I work at. There are some really super cool risk convergence efforts I am participating in as part of my job. I hope I can share some information about them in the coming months – even if vaguely.

What are your thoughts on risk convergence? Have others observed these frustrations? Can anyone share some success stories?

Have a great weekend and thanks for reading the post!