Aug 14 2010

How would I write a framework to replace PCI?

Published by at 6:42 am under PCI

I’ve been working in and around the payment card industry for over four and a half years now.  A year and a half working for a service provider and seeing the worst of credit card storage possible and three years of performing Payment Card Industry Data Security Standards (PCI-DSS) assessments have shown me both the best and the worst of how merchants, service providers and other entities protect our cardholder data.  I’ve seen, and made, huge mistakes in implementing and securing cardholder environments.  I’ve assessed clients who’ve gone far beyond the requirements of PCI to truly secure their networks and I’ve seen administrators struggle to get even the most basic security measures in place because they don’t have the resources to do more.  Throughout all my experiences the one thing I’ve always been able to do is learn from the failures and triumphs of the individuals I deal with and I think I’ve gained a pretty deep understanding of the credit card systems and some of the things that are required to maintain a base level of security in today’s world.  And when it comes down to it, that’s all a framework like PCI is, an attempt to create a security baseline.

While I do have a lot of experience in PCI, I will never claim to have the all the answers to securing a cardholder environment.  I won’t even claim that I understand all the implications that writing a policy and technology framework like the PCI-DSS.  But I do have some ideas around how I’d do things differently if I was writing the requirements.  Boy do I have some ideas.  And I know that I have a lot of friends and peers in the industry who are more than willing to give those ideas a thorough looking over and thrashing to separate the wheat from the chaff and help me winnow out what’s useless from what can really help the industry in the long term.  So over the next couple of months, I’m going to lay out a series on how I’d write the PCI-DSS.  I expect that many of the ideas I throw out will be torn apart, but I want to encourage people to start thinking about how we can change the standards going forward.

One of the reasons I’m starting this right now is that the PCI Council has just released Summary of Changes for PCI 2.0 and changed from a two year to a three year lifecycle.  While the changes aren’t set in stone as of yet and all we have so far is an outline of what these changes are, what we have seen is nothing more than minor clarifications and minimalistic guidance for virtualization.  Since the new changes aren’t fully revealed yet, it’s hard to be too tough on the PCI Council; yet minor changes coupled with lengthening the time between revisions seems to be a plan to calcify the PCI-DSS and protect anyone from having to make major changes to their environments.  I feel there’s been enough time and feedback that this approach is not in the best interest of security nor is it really in the best interest of the public.  Bluntly put, the change to a three year life cycle should have been accompanied by a major revision of the requirements, not the minor tweaks we’re getting.

I won’t call what I’m thinking of PCI; the PCI-DSS is what it is and I can’t change that directly.  What I’ll be writing is just a series of thought constructs based on what I think are the real steps we should be taking to secure the credit card process.  I want to think outside the box that we’re currently in, looking at what we do now and trying to understand how we can do it better without tearing apart the merchants and service providers with additional costs and burdens.  I’m realistic enough to know that anything that requires large amounts of time and money are going to be met with screams of denial and pain.  But I also know we can refocus many of the efforts we’re making now and use the same tools we already have in place more effectively.

I want to start with a few principles that I think everything else should derive from.  And I know even these principles need to be challenged and refined.  The first of these is simple:  Everything flows from policy.   This is currently the last requirement in the PCI-DSS and I have always thought that it was the biggest mistake that was made when the original CISP requirements were written up.  As it stands now, policy is stuck onto the end of the requirements almost as an afterthought, even though in many companies it’s what gives the teams trying to secure the environment the ability to make clear cut decisions about what is and isn’t acceptable in the cardholder environment.  It’s also very helpful in getting the budget to purchase the tools you need.  Of course, I’ve already had one person tell me that starting with policy is doomed to failure, but this is my framework, so too bad.

The second principle is Keep it simple.  Come on, 200+ requirements??  How many of these are redundant, needless or just a vestige of something that is no longer reasonable to require.  We’re still required to check for a stateful firewall, even though every firewall built in the last 5 (10?) years is stateful.  I’m sure you can think of dozens of other requirements that are similarly outdated and needless.  Why have requirements that are simply placeholders that serve no real purpose?  Once a requirement becomes outdated, it needs to be retired to make room for something more important.

My final principle is Concentrate on results, not technologies.  There are very few things I like to see more in an assessment than a client who’s met with the PCI-DSS in a way that goes well beyond the simple requirement and actually secures their environment.  Andy Ellis, aka @CSOAndy is one of my heroes in the industry because of everything that he and his team have done to secure Akamai.  I need to talk to him to see how much he’s willing to disclose about what Akamai does differently, but let’s just say that his compliance assessments are truly unique and not something you ever want to send a junior assessor to deal with.  My goal is to develop a framework that concentrates on the results we want to see, not the tools you have to have in place to make it happen.

I think I’m taking on an impossible task here.  But I my goal isn’t to tell anyone what they’re doing wrong; it’s to come up with alternative ways to meet the same goal, which is securing the credit card process and promote security for enterprises overall.  I’m going to stumble a lot, I’m going to make mistakes and people are going to tear my ideas apart.  But if I can get you thinking about how we can do things differently, I’ll consider this experiment a success.  I want people to consider what we’re doing now and how we can do it better.  Some of my ideas will be thought of as impossible in the ‘real world’; some ideas will be taken almost directly from the PCI-DSS. And some will be taken directly from friends and peers.  My biggest fear is not being criticized for the effort; my biggest fear is that it’ll be ignored.

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

8 responses so far

8 Responses to “How would I write a framework to replace PCI?”

  1. PaulMon 15 Aug 2010 at 5:31 am

    Great post, Martin! To your point on focusing on results instead of technologies, this is really the core problem with security standards compliance across our industry. One of the things that I have always found refreshing about PCI-DSS, as opposed to other security standards like HIPAA and GLBA, is that it was very prescriptive of practices and technologies. This is great for your IT department as the requirements document can function as an implementation checklist. However, this approach also infers, if not promotes, the notion that safeguarding cardholder data has a beginning and an end. And so merchants approach it as if once you can put a ‘Y’ or ‘N/A” next to each requirement that you’re done. And this is where I like to point out that Heartland were fully compliant with PCI-DSS, that their QSA certified them while they were compromised and actively being raided for card numbers.

    Focusing on results would be great, but it requires the PCI Council to be able to levy hefty fines or other consequences in addition to active regulation of individual businesses in order to be effective. This can’t happen today because the current design of PCI is to avoid this sort of thing. PCI is industry self-regulation with the intent of avoiding similar government regulation. I’m not advocating government regulation as a solution, just pointing out the intentional limitation of PCI’s scope and power to actually hold merchants and processors accountable for results.

    So what then? What’s missing from PCI 2.0 is the focus on fraud detection, response, reporting, and improvement . Simply protecting the data will never be enough because as long as attackers can easily and inexpensively convert stolen data into money with a reasonably low risk of being caught, they will get the data. Requiring merchants and processors to account for and improve their anti-fraud practices, perhaps requiring them to participate in coordinated investigations and response, has the potential to deter criminals and devalue stolen credit card data. That could actually move the ball for the whole industry.

  2. Martinon 15 Aug 2010 at 5:50 am


    While specifying the technology was refreshing when it first became a standard, the ties to specific technologies have also become one of the weaknesses of PCI, since the standards are so slow to change. If there was more change, more updates to keep it current, I think specifying tech would be fine, but as it’s currently going we’re only going to get more and more out of date as time goes by.

    One of the things I’ll be focusing on is decreasing the amount of cardholder data that merchants have access to, let alone store long term. I don’t want to spoil future posts, but merchants, service providers, acquiring banks, etc. all have to focus on minimizing their contact with and storage of cardholder data. And as you mention, detection is another huge part of the equation.

    Glad I could start some thought, go and expand on the ideas. Challenge them, come up with your own. We need to shake up the industry a little.


  3. Matt Pressonon 15 Aug 2010 at 7:48 am

    I like the thought of focusing on results instead of technologies. In many cases, some of the toughest things to prove to a QSA is that you meet the “intent of the control” even though you may not implement the specific technologies that the control references. In my opinion, clearly stating and describing the outcome that should be targeted would greatly improve the overall process.

  4. Geoff Webbon 16 Aug 2010 at 6:28 am

    Definitely a worthwhile post. I would agree the right approach is to be focused on the results – I think it’s equally important to be clear on how to measure those results. I would also question the value of moving to a three year cycle. It is unclear to me whose interests that serves.

    Keep up the good work and I’m looking forward to seeing what you start to come up with.

  5. Mister Reineron 17 Aug 2010 at 2:00 am

    This might seem like an unusual approach to coming up with a replacement PCI framework , but have you ever thought of developing the “ultimate” PCI architecture? If money were no object, what type of hardware, software, personnel and process would you put in place? Could it scale down to fit each tier or would it not be possible?

    If results oriented security is all that matters, then it has nothing to do with policy at all. It becomes a matter of merchants choosing from a menu of predefined architectures (approved product list) and processes that have already been certified as compliant for their particular tier. If you want simple, that’s as simple as it gets. Then everything becomes standardized, easier to implement, easier for merchants to outsource and easier to check for compliance.

    I know, easier said than done, but I think it’s a viable alternative.

    Just some food for thought. =)

  6. Bill Frankon 22 Aug 2010 at 11:16 am

    Hi Martin,

    Personally, I would like to see PCI-DSS take an approach more akin to the SANS Twenty Critical Security Controls for Effective Cyber Defense. Their four key principles are:

    (1) Offense must inform defense – knowledge of actual attacks that have compromised systems provides an essential foundation for on which to construct effective defenses.

    (2) Work from a prioritized baseline of information security measures and controls

    (3) Most controls must be automated – there is no way for an organization to cost effectively defend itself with manual controls

    (4) Measure the effectiveness of controls – Automated techniques, where possible, should be used to measure the effectiveness of deployed controls.

    I understand this would present difficulties for assessment.

    One last thought – while I understand your point that everything must flow from Policy, I would add that Policy flows from Visibility. In other words, you need context in order to build effective policies.

  7. Davi Ottenheimeron 26 Aug 2010 at 12:43 pm

    I see much of what you are saying in other compliance frameworks. The ISO 27000 series, for example, starts with policy. COBIT 4 focuses on results, etc.. Have you considered the other frameworks as alternatives?

  8. […] month when I wrote my post “How would I write a framework to replace PCI?” I had the kernel of an idea that I just had to get out in some form.  It’d been […]

%d bloggers like this: