This was a long time in coming. The original PCI list received a lot of criticism for just being a long laundry list. I don't think there's a single company in the world that could honestly claim to be in total compliance. Companies - especially those new to PCI - don't know where to start with the hundreds of new security requirements that have just landed on their lap.
So it's certainly a good thing that the PCI Council folks were kind enough to prioritize the requirements into 6 categories. (Although in the legal fine print the PCI Council insists that the prioritization is for information purposes only and that all requirements are still mandatory for compliance).
Let me start out by saying that I basically like the concept behind PCI. Too many security regulations are just empty fluff. For all its imperfections, PCI puts its money where its mouth is - detailing specific technical measures companies need to take to achieve security. PCI doesn't always get it right (more on that later in this post) and there clearly needs to be some change in the surrounding audit mechanism. But I still think that the standard as a whole kind of works in improving the overall security of the companies subject to it. This is a classical case of security economics at work; the PCI stakeholders (the credit card companies) have a direct financial interest in preventing actual breaches that lead to loss.
The PCI Standard can get away with requirements no state or federal regulation ever could. Legistlators try to avoid mentioning specific technologies in legislation. This is a good thing for limiting the influence of lobbyists and preserving technology neutrality (any one who has had the misfortunte to deal with electronic signature regulations knows how messy it can get when specific technologies find their way into legislation). But PCI is not a regulation and does not depend on a legislative process to be updated. It can specifically mention certain technological concepts and then update them over time. Although you sometimes mistakenly here in the news about "PCI being adopted as law" in certain states, this is almost always a complete misrepresentation (as in the case of Minnesota, whose PCI-inspired law only enacted a few very generalized versions of some of the PCI requirements).
The PCI Standard can get away with requirements no state or federal regulation ever could. Legistlators try to avoid mentioning specific technologies in legislation. This is a good thing for limiting the influence of lobbyists and preserving technology neutrality (any one who has had the misfortunte to deal with electronic signature regulations knows how messy it can get when specific technologies find their way into legislation). But PCI is not a regulation and does not depend on a legislative process to be updated. It can specifically mention certain technological concepts and then update them over time. Although you sometimes mistakenly here in the news about "PCI being adopted as law" in certain states, this is almost always a complete misrepresentation (as in the case of Minnesota, whose PCI-inspired law only enacted a few very generalized versions of some of the PCI requirements).
The Prioritized Approach gets some priorities right and some of them can IMHO use improvement. The document says that data is culled form actual breaches, giving the PCI Council data that most of us don't have to determine what is important and what isn't.
The Prioritized Approach hits the nail on the head with priority one - removal of sensitive data and limit data retention. This information security principle seems so obvious and yet I rarely see it stated in such a clear and succint way. The lowest hanging fruit - the bananas practically falling off the branch - is the deletion of customer data you just don't need any more. It's also the easiest thing to get buy-in from the rest of your organization - it requires few resources and has a very high risk-reduction-to-effort ratio. So absolutely no argument on this no-brainer for priority #1.
The relationship between 2 and 3 is likely to generate the most controversy- it is here that the PCI Council prioritizes network security over applicaiton security. But in today's environment, is it better to have hardened applications sitting on open machines or the other way around? The actual threat from web application vulnerabilities is still not well understood, and there are a number of items on OWASP Top 10 type-lists that do not pose a particularly high risk. But something like failure to validate input (priority 3) is in my opinion responsible for more attacks than some of the networking PCI requirements (eg installing a personal firewall on employee laptops, priority 3).
Currently almost all items in PCI Requirement 6 (Develop and maintain secure systems and applications) are assigned priority 3, and almost all items in PCI Requirement 1 (Install and maintain a firewall configuration) are assigned priority 2. I predict this will probably evolve over time, since there are clearly some app security issues which are more important than network issues.
A couple of final thoughts - the Prioritized Approach puts the appropriately low priority on pyhsical security. One of my recurring pet peeves when dealing with vendor security whitepapers is the overemphasis on physical security. Physical security is well understood, is implicit in doing business, and has much stiffer criminal penalties associated with it. When looking to implement an information security program, "restricting physical access to publicly accessible network jacks" (priority 9.1.2) has been justifiably pushed down to priority 5.
All in all the Prioritized Approach is a nice addition to the PCI Standard. For all its troubles, PCI is the closest we have to an industry consensus on what is considered reasonable security.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.