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.

I got to talk to Bob Russo from the PCI Council in July, and he’d hinted at the level of change.  And maybe I’m just not realistic in asking for major changes.  Despite the fact that PCI has been around for a while now, there are still a lot of merchants and service providers who have issues complying.  It may be that the realistic thing for the Council to do is continue to build support and compliance with what they have now, rather than pushing to increase security by making major changes.  Sometimes it is better to accept minor changes you know you can enforce than to try for something grander that you’ll never attain.

I’m hoping to get another chance to talk to Mr. Russo.  I’ve asked nicely, really I have.  I’d like to understand why this is the sum total of changes they’re making before switching to a three year lifecycle.  I’m not sure I’ll like the answers, but I still want to hear them directly from the man who’s in charge of the group setting and managing the PCI Standards.  Obviously, my approval is not necessary, but as one of the people who helps enforce the PCI Data Security Standards, I want to understand the reasoning.

I believe that the Visa best practice papers for tokenization and truncation are just like the PCI standards themselves; they’re a good place to start your journey, but these requirements aren’t enough to build your entire security stance from.  It’s up to you to continue from here to determine how the particular technologies are going to impact and secure your environment.  I think the difference between providing guidance and issuing edicts is something we’ll be talking about next Sunday at Defcon, so this is good timing.

I agree with many of Adrian’s criticisms, including that Visa could have just given more specific guidance overall.  But I also understand Visa’s need to keep the guidance vague enough so as not to provide undue direction to what is basically a fledgling market space.   Which is exactly where I see the tie in with Josh Corman’s primary argument about the PCI Council; intentionally or not, they are steering the security market space through the PCI standards.  Visa could be a force for good in the tokenization and truncation markets if they predict correctly and back solutions that are for the best over the long term.  Or they could be seen as stifling innovation if they issue poor guidance.  Much like the PCI Council.

Earlier today I heard someone make the statement that the majority of companies who are compromised are using encryption in some form, but they still got compromised.  He was reminding me that none of the other silver bullet’s we’ve thought would save us from the bad guys have worked, so use truncation and tokenization, but know they won’t solve all our security issues.  As is so often the case, they’ll just move the attack to other targets and use other vectors.

If you’re part of a merchant organization or somehow dealing with credit card numbers and you’re not considering tokenization or truncation, why not?  Is it lack of time, lack of resources, lack of management backing or something else?  Have these technologies simply not risen to the level where you felt the need to take them seriously?  I’m curious as to why you might not be looking at a technology that could limit the amount of sensitive information on your network.  I’ve talked to a number of merchants over the last year and there’s been plenty of interest in the ideas of tokenization and truncation, but I’ve only seen a few merchants actually making a move towards implementation.

I hope the next guidance we’ll see comes from the PCI Council, giving instructions on how both of these technologies can be used to reduce the scope of a PCI assessment.  What can you take out of scope?  What common mistakes might bring systems back into scope?  What should we be looking for in an implementation?  These are still relatively new technologies, the implementations differ significantly enough that greater direction and care are going to be needed in their assessment and validation.  There are some things that are laid out in the Visa documents, but I think we need to look for more specific guidance from the Council.

Network Security Podcast, Episode 205, July 13, 2010
Time:  44:44

Show Notes:

• Listener Mail
• Interview with Bob Russo
• FBI Raids ‘Electronik Tribulation Army’ Over Witness Intimidation.
• Letter to the client.
• Tonight’s Music:  Missing You by Blue Matters

Here’s a letter of my own with several more points to ponder.

Dear Client,

We’re about to start on an effort of many months of work that both of us hope will culminate in the issuance of a compliant Report on Compliance.  There will be surprises and setbacks along the way, but I’m sure that we can work together to overcome them.  My job is to help assess the security of your cardholder environment and provide you with honest feedback about your compliance with the PCI standards.  Your job is to provide me with the information I need to make that assessment.  Together we will document your environment and show that it is both secure and compliant.

Several things you should know:

1. Securing your data and your network should be the goal and PCI is just a signpost along the way.  Please, please, please don’t make the mistake of thinking once you pass your assessment that you’re secure and you have no more work to do until next year.  PCI is a good starting point for securing your environment, but each company is so unique that there are innumerable holes it leaves open to exploitation.  And the assessment only covers your cardholder data environment: what about the rest of your network?
2. I am judge, but I am not jury nor executioner.  I will make judgment calls on the state of your environment and I may find things I do not believe are compliant.  You may agree or you may think your controls and safeguards are sufficient.  Make your case to me, and if we still don’t agree, we can bring in other QSA’s within my company to review the situation, starting with my manager.  Sometimes they’ll see something I didn’t. 
3. I will never leave you wondering if I found something wrong.   I will always try to let you know at the end of the day, if not at the end of each meeting, if I have any questions or concerns.  It’s in both of our best interests for me to be as transparent as possible.  The sooner you know of an issue, the sooner you can begin investigating and getting it resolved.
4. You are my client and it is my job to help you receive a compliant RoC.  I will give you the best advice I can to help you achieve compliance.  But it is up to you to establish the policies, procedures and controls needed to reach this goal.  If I identify a requirement that is not being met, I will bring it to your attention and help you address the issue in a timely and cost conscious manner.

Clear communication is a good salve for many of the pains an annual PCI assessment brings.  I look forward to learning about your company, your network and your people.  And I hope that the lessons I’ve learned helping dozens of companies become compliant can be used to help you avoid some of the pitfalls and false starts of compliance.

I talk to Jack, Josh and a lot of other people about PCI fairly regularly.  I’m fairly confident I know their positions on compliance and they have a good idea of mine as well.  Jack’s a good moderate who sees both the good and bad, while Josh sees it as a tidal force in the security market space, and not one he likes.  Where PCI points, the money goes, like it or not.  But this talk won’t just be about PCI, we’ll talk about compliance in general, the good, the bad and the ugly. 

If you, by some chance, are around at Noon on Sunday, come see the discussion.  The question I have for the audience is simple, “How has compliance affected you and/or your company?”  Has it’s affect been positive or negative? Given the crowd we’re drawing our audience from, it could generate some very interesting responses.  I’m curious to see how a group that collectively thinks of themselves as hackers feels business attempts at compliance frameworks really affect the work they do.  I expect to hear more annoyance with compliance getting in the way of real work than anything else.

This should be a fun way to end Black Hat and Defcon.  Josh and I really haven’t had it out over whether compliance being a market force is a good thing or a bad thing and this is a good venue to draw him out on the subject.  I’m looking forward to it.

She’s got a number of good points; we see all too many clients who just want to have their PCI assessment and then ignore the whole thing for the next 8-10 months, until the whole process starts over again.  They don’t want to think about PCI at all during that time, they don’t realize that there are a number of requirements that mandate continuing effort on a daily basis, not just when the assessor is on site.  And we never, ever see clients putting lipstick on the pig just to cover up a deficiency until the assessor is gone.  Oh no, never that.

But there is an upside to being a QSA.  Some security departments have learned to do an awful lot with very limited budgets.  Some clients understand that attaining compliance as a side effect of security is actually cheaper and easier than trying to do it the other way around.  Some clients actually want an honest review of their environment that identifies potential weaknesses outside of a strict interpretation of PCI.  And every so often you run into a client who’s doing something unique and unusual that doesn’t meet the letter of the law of PCI but still manages to exceed the intent of the requirements, sometimes by quite a bit.

These are the clients who keep me from pulling my hair out.  I find it rejuvenating to talk to a client about the security impacts of changes to their environment honestly, rather than trying to argue an interpretation of PCI that doesn’t require them to make any changes or worse, leaves them less secure if implemented.  When a client understands their own environment and knows why their data is where it is, it makes my job, and theirs, so much easier than when clients are doing their discovery while I’m on-site.  And sometimes I’m actually working with a client to secure their environment, rather than fighting to get them to implement basic security controls.

I recognize that being a PCI QSA and consulting with clients on meeting the DSS requirements is a balancing act; we try to balance security against the DSS against budgetary and manpower constraints.  And since we only have two hands, balancing three competing limitations is hard, very hard.  If you’re in this field and you don’t feel burnt out from time to time, it means you don’t care.  And that is probably a bigger vulnerability than most of the technical requirements in any compliance framework.

It’s the clients who view the security of their company as a calling that keep me coming back.  It’s easy to check off a box, go home at night and ignore what’s happening to your business while you’re away.  But some security professionals are intensely passionate about what they do and how well they’re protecting their enterprise.  These are the people who make being an assessor worthwhile.  Because even if you’re arguing with them about an interpretation or commiserating about a requirement that sounds stupid on the surface, you know these people care and at the end of the day, they don’t just walk away thinking their job is done, they worry about bettering their company’s security the next day.

Next post I’ll address Branden William’s post “Why ISA’s are qood for QSA’s“  Can you say “arm chair quarterbacks”?  I knew you could.

One of the big questions that comes up over and over again is how effective is PCI in securing the merchant environment.  And the answer is, no one really knows.  Breach disclosure laws prior to 2003 were non-existent, and even once California passed SB1386 and got the legal ball rolling, breach disclosures have been spotty at best.  Now that we’ve got some 40 states that have some form of breach disclosure law, the information we’re able to gather is much more consistent.  Unluckily, we still lost the ability to have any real baseline to measure the success of PCI against and anyone who says that PCI is or isn’t effective is mostly going on their own anecdotal evidence, not hard data.  Verizon’s Incident Metrics Framework may help in gathering statistics going forward, but we’ve already lost the data needed to measure the effectiveness of PCI.  (Disclaimer:  I work as a QSA for Verizon Business)

As tokenization and E2E2 take hold, we’re going to have another chance to see how effective PCI is in securing the merchant environment and whether or not merchants are really going to secure their environment without the threat of PCI hanging over their heads.  There’s almost nothing in PCI that a shop with a good security program shouldn’t be doing in the first place.  Firewall reviews, anti-virus, log monitoring, IDS, etc. are all safeguards that are mandated by PCI but are security measures that any good security shop should be putting in place for their organization by default.  The fact that many organizations couldn’t get the funding for some of these tools until PCI came along is a measure of how hard it is to get the budget for security.  And if organizations start losing the funding for these projects because tokenization and E2E2 have taken the majority of their systems out of the scope of PCI, we’ll know that PCI was the real driver for the safeguards, not any real concerns over security.

PCI is expensive.  Security is expensive.  Not necessarily because the tools are expensive, but because merchants ignored security for years and have had to spend a lot of money and time to implement the tools they should have been running in the first place.  If they can reduce the scope of the systems they have to protect through new technologies and no longer have to be assessed on an annual basis, do you think they’re going to keep paying for the tools that they implemented just for compliance or do you think they’re going to let their IDS and log management tools fall by the wayside?  I know that some of the shops I’ve seen will keep the tools and keep using them properly.  But I think the majority of merchants are going to go back to their old ways and do the bare minimum that their security group can fight to keep.  If your company’s marketing department depends on PCI to make sales, I’d be very afraid of tokenization and end-to-end encryption.