Last week, Josh Corman of The 451 Group gave a speech at Interop in Las Vegas bemoaning the shortcomings of the PCI DSS. Not only that, he stated that the PCI DSS is not protecting credit card data and the coming updates to the standard will not improve things. So what did Mr. Corman suggest we do to improve things? Nothing. All he did was complain. Supposedly, Mr. Corman is a leader in the security industry. As a leader, do not whine and complain, give us some specific suggestions and guidance to improve things.
His first complaint is that the PCI DSS does not specifically address cloud computing. Why does a security standard have to address a specific type of computing platform if it is not necessary? The PCI DSS does address the differences of hosted computing environments of which cloud computing belongs. However, the remainder of the PCI DSS should apply to any environment – hosted, cloud, whatever you choose to call it. The PCI DSS is structured so that it addresses only those platform differences that are truly different. For example, a change that is coming in the new version is requirements to address specific differences to virtual computing environments.
What I think Mr. Corman is complaining about is those of us in the PCI compliance business that have discussed the problems with PCI compliance in the cloud environment. While the cloud computing movement offers some significant savings, it also opens up a number of new issues in meeting PCI compliance. What I think Mr. Corman was implying is that he wants rules to get around these issues so that merchants can be even more insecure, but reap the benefits of cloud computing.
The problem with cloud computing is not that it cannot be secure and comply with the PCI standards. The problem is that, like every other “next best thing computing platform” before it, cloud computing is moving faster than people can understand and secure it. We do not even have a standard definition for cloud computing yet, let alone understand all the aspects of securing it. As a result, early adopters are finding all sorts of flaws and issues that need to be addressed to improve security and PCI compliance. So, by all means, we should all jump on the bandwagon before those issues are resolved so that we can all suffer from poor security together. Great leadership.
Another point he makes is that patching does not prevent breaches. He uses the statistics from the last Verizon Business Services report that stated that of the 90 breaches they investigated; only six were related to patching issues. Therefore, Mr. Corman says the statistics do not support patching as a critical activity. This is a damned if you do, damned if you do not issue. The problem is that most organizations patch when they feel like it, not when they truly need to patch. As a result, some patches are applied timely while others may not get applied until a problem occurs. The real way to patch is to base patching on criticality and relevance to your environment. Unfortunately, Microsoft, Sun, Red Hat and others do not make this sort of analysis easy to perform. IBM and their PTF process for mainframes, does do this. So, vendors need to take a page from the IBM mainframe playbook and start to make some sense out of patching so that it is not just a “throw it against the wall and see what sticks” type of approach.
That said, there has to be something done about patching. While the PCI DSS does quote an arbitrary 30 day requirement, most QSAs I talk with understand that as long as an organization has a reliable and auditable patching process, it does not matter the speed with which the patches get implemented as long as they are implemented. The problem is that most small and mid-sized merchants are very sloppy about patching. As a result, the 30 day requirement was for their benefit so that they know there is a time limit.
His final remark that tweaked my craw was that “The bottom line is that there isn’t enough data to know whether PCI works or not and whether security controls businesses would have put in place in the absence of PCI might have worked better.” Obviously, Mr. Corman has never been out in the field or he would know better. In the organizations that I have worked with, the PCI DSS was the catalyst to shedding light on security and operations practices that were believed to be working. However, detailed examination for PCI compliance determined that these practices were, in fact, not working and in some cases were not being performed at all because people did not understand their importance. In other cases, while the practice was being followed, it needed changes so that it was properly focused on identifying issues and threats. These organizations are all Fortune 1000, so one would think they have the experience and maturity in security that small and mid-sized companies do not. However, until they had the PCI DSS to use as their baseline, they had no idea of the issues they faced.
Mr. Corman’s comments imply that security people know the right things to be doing and do them. However, experience shows that every security person has their own ideas of “best practices” and those do not always add up to what the PCI DSS is requiring. However, Mr. Corman is right in that the PCI DSS is only the start. In order to be truly secure, an organization will need to go above and beyond the PCI DSS requirements to be secure.
Just like security is not perfect, neither is the PCI DSS. However, barring any new approaches, it is the best we have at the moment to protect credit card information. I am all for constructive criticism as long as it is backed up with ideas on how to make things better. So, if Mr. Corman has ideas on how to make it better, then by all means tell us. Just do not use the bloody pulpit to vent and then expect us to somehow read between the lines.
UPDATE: Please see Mr. Corman’s response to this post in the Comments.
PCI Guru 