Aug 14 2010
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.
8 Responses to “How would I write a framework to replace PCI?”