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 
The links:
CSO Online Debate Part 1 of 2:
http://www.csoonline.com/podcast/513988/The_Great_PCI_Security_Debate_of_2010_Part_1
Network Security Podcast Part 2 of 2:
http://netsecpodcast.com/?p=391
Southern Fried Security Podcast – Special Episode:
http://www.southernfriedsecurity.com/episodes-0-9/special-episode—interview-with-josh-corman
ShmooCon 2010
[video src="http://www.shmoocon.org/2010/videos/PCI-Panel.flv" /]
BSidesSF Panel Video
http://www.ustream.tv/recorded/5164678 (pt 1)
http://www.ustream.tv/recorded/5165234 (pt 2)
PCIGuru,
I’m sorry to see you’ve concluded that I lobbed a “mindless attack”.
As is often the case in this day and age, it looks like you’re debating an article someone else wrote, based on incomplete excerpts from my talk, instead of debating either my talk itself or discussing it with its author.
The Signal-to-Noise ratio in our space is not helping. If you’d like to discuss the actual presentation – or the actual message – or my actual positions and thoughts, I’d be happy to engage.
Is this post driving Signal? or driving Noise?
I’m willing to bet your desire is to drive signal – so we should do that.
For example, my talk *did* in fact discuss ways to improve things. Far from mindless, the presentation leveraged insights gleaned from 6+ months of rational, adult debates and conversations with QSAs, merchants, vendors, thought leaders, etc. Also, the word cloud was mentioned once in the entire presentation, in passing. I don’t have all the answers, but the discussions and process are moving thought forward.
PCI DSS is not a simple issue – and can be polarizing with unthinking haters and unthinking fans.
Rational, thoughtful, criticism and discussion is critical to leadership.
We may not agree – but discussion will lead to awareness, education, and effective paths forward.
Here are a few of the links to the debates – the conversation is helping and maturing as we go. We are far from done.
My apologies if I have gotten things wrong. I have heard or read all of the links that you provided and assumed (my bad) from the articles about your Interop appearance that you had changed your mind on the PCI standards. If I have misrepresented your position, I again apologize and welcome your further comments regarding the PCI standards.
Good article. It is worth noting that the latest version of the PCI standard has come a good way in being more specific than the previous version. For example, how to handle wireless specific threats is defined clearly – perform wireless scan reguarly. With so many attack vectors available for the crackers, a guideline in the form of standard is definitely desirable.
Thanks,
Gopi
AirTight Networks
This is an excellent article which IMHO points out that no security standard or compliance standard is perfect. These standards, however, help move the needle and make network administrators aware of true best practices and threats they might not even have considered.
For example, one myth that we run into at AirTight is, “I do not have wireless deployed, so Wi-Fi is not a threat to my data.” The PCI SSC in its Wireless Guideline, issued in July 2009, makes it very clear that all locations which collect, transmit or store credit card data must be scanned one per quarter for wireless threats. The reason – you have no idea if wireless has been brought into your environment through the use of iPhones, smartphones,or the multitude of devices which are euqipped with Wi-Fi and brought into the enterprise. The soft AP of Windows 7 is a perfect example.
Yes the standard is not perfect but it is a good start. I only wonder why anyone would do the bare minimum to monitor any network for only a moment in time, which is what a quarterly scan does. A good security policy is essential and then you must have the means to automatically monitor and enforce it 24/7. Once you have that, you get compliance.
Again, good article.
The interpretation that timely patching is not needed because the exploits that are being used successfully are usually months old is one I’m not so sure is accurate.
Could the reality be that the organizations that do perform timely patching are not the ones getting breached with those types of exploits? And that the organizations who lag way behind in patching are getting whacked because they rarely patch? And that older attacks are used just because they’re more reliable, being more mature?
My real job is to
1: Learn from the mistakes of others before they happen to us.
2: Make our defenses strong enough that a non-targeted attacker will simply go on to a softer target.
3: Throw up enough hurdles and tripwires that even a targeted attacker will get noticed bfore they attain their final objective.
In short, my job is not to outrun the bear, just to outrun my buddy. 🙂
Ray