I don't care what anybody on the pro-PCI side of the argument says, PCI is absolutely a distraction. How do I know? Because I've just realized that I've been completely distracted by it in my new/current position. For those who don't know me too well, I'm currently the Director of Security & Compliance for a small-ish tech firm in Phoenix, AZ. This position was newly created, and the first task handed to be on the way in the door was to get a suitable PCI remediation plan in place for our merchants (yes, we have 4).
When I started this job back in February, I immediately tackled the remediation plan project, and along the way concluded that it really needed to be framed as part of an overall security roadmap. So, I delved into the massive amount of details that is PCI DSS, as well as overloading my brain thinking about the bazillion things that are components of a full-fledged security program. The result? Complete paralysis from the sheer volume of work required across the board. "How in the world are we going to get this done? We don't even have a budget or staff right now!"
Thanks in large part to a great conversation with a very, very good friend last night, I finally had an epiphany. I've let myself get completely away from my philosophy of security. In particular, I've gotten away from the principles that I established in the TEAM Model in my Masters thesis. If you try to tackle the whole - the long list of everything that needs to be done (see my white paper PCI: Requirements to Actions for an example) - then you will get completed overwhelmed by everything that needs to be done.
Ironically, this is a solvable problem. It means going back to fundamentals (see! technique is important!) and addressing the core fundamentals of the organization. In my case, it means getting back to a core action plan that does the following:
1) Define core requirements. If you don't know what the core business requirements are, how can you align to them? If you don't know what your fundamental expectation for risk management is, how can you build a risk management program to meet that expectation? One of my favorite Dad'isms is "If you don't tell people your expectations, then you shouldn't be surprised when they don't meet them." Brilliant advice, and something that goes to the heart of this issue.
2) Assess and manage risk. Once you have established a baseline set of requirements around which to rally the wagons, you then must determine your baseline risk profile and establish an approach for managing it. The good news is that there are several known good ways to assess risk. The bad news is that there aren't any full frameworks (yet) for managing risk. There are partial attempts here or there, but nothing truly comprehensive (this will be remedied).
3) Then implement change. Before any changes are implemented, you have to have a plan. You need to know the business requirements, and you have to know the relative risks. Otherwise, you cannot prioritize a single thing, and then your program devolves into one of pet security projects based on whomever is in charge. If your security leader is really good (*ahem*:) then they'll probably get you on the right track intuitively, but let's never assume that the person in charge is actually that smart (obviously I'm not).
4) Audit (and measure) it! I'll be mulling over the metrics piece for the next couple weeks, but let's stick to the TEAM Model for a minute here and recognize that we need routine audit, but not in the traditional sense. We need the new school of audit, which is as much about reiterative, ongoing security testing and measurement (metrics) as it is about compliance and checklists. In the next version of the TEAM Model this will be addressed. How we do things today is clearly not effective (in the audit world) and ripe for evolution.
Evaluating What Went Wrong
So, for me, one of the top questions to be considered when evaluating my own failings (see my post "Knowing One's Strengths") is what exactly went wrong. This question, I believe, is where I find hard proof that PCI is in fact a distraction.
When I first started talking to my friends about this job and the potential, I was quickly reminded by my grad advisor that this would be the perfect opportunity to test out the TEAM Model in real life. Then I walked through the door as an employee, started looking at PCI, wrote "PCI DSS v1.2 in a Nutshell", and *whoof* I got buried.
In addition to writing the nutshell guide, I also undertook writing a complete security roadmap. From scratch. Off the top of my brain. But I was really dumb about it. Because I was in this detailed, overwhelmed state from PCI, I then produced a roadmap that was itself overwhelming. Drinking from the firehose is rarely a good idea, and yet here I was trying to jam it into my maw all the same.
Baseline conclusion: my pain is largely self-inflicted, but the trigger was getting sucked in my PCI, despite knowing better. (it's kind of like being in a bad relationship that you can't quit)
Correcting Course
As noted above, now that I've identified the problem, the next step is to get back onto a reasonable, rational track. It's time to return to fundamentals and start doing what I know to be the right approach: the TEAM Model. As part of this effort, I've now opened the door to return to a sensible approach. Get the fundamentals in place, get the wheels turning, and then get a prioritized list of projects lined up that maximize the benefit to the company (note that I'm intentionally avoiding "ROI" or "ROSI" here;).
Next up: getting stuff done. w00t! :)
Take little, manageable bites.
Always, ALWAYS document things that you are hitting roadblocks on and copy management so that they are aware, and you have covered yourself if they accept the risk.
Again... take smaller bites.... and now chew.
Accomplish what you can change, define the importance in a non-threatening method to management, focus on changes that do not require budgetary consideration first. Prove yourself in these changes and thus adding trust from your management.
God speed!