Back to Basics for Easier Compliance

Back to Basics for Easier Compliance

Dean OcampoJuly 25, 2011, 10:56 am

PCI 2.0 Virtualization Guidelines are now almost 4 weeks old, and after a few speaking events and internal discussions, it’s apparent that what we’ve been advocating for over a year was right on the money- and that’s the strategic use of encryption as an enabler for cloud in a broken trust model. It’s not like we had a crystal ball, we just happened to focus on the fundamentals of the cloud problem, the core requirements we see common in all regulations, and the solutions automatically narrowed themselves down. Let me take a little time here to share the logic we used on the regulatory side and how, at least in our opinion, sticking to these principles will keep you safe across regulations and across expected new regulations.

At the heart of all IT security practices are two essential ingredients: security first principles and situational awareness of the systems under control. Typically regulations address the former (e.g. SOX) and some become prescriptive and recommended controls for the latter (e.g. PCI). I’ve worked in this business for nearly 15 years and can tell you almost all regulations follow the same recipe. About the only variation comes from the politics around the regulation (governmental, spending by PACs, industry pressure, etc.) and the degree with which the designers knew anything about IT (take SOX vs. PCI, a classic example of IT neophytes vs. IT experts). So let me try and articulate the first principles here:

Ensure Data Confidentiality: Target data (credit card numbers, patient information, your inseam size, what have you) should remain confidential and only accessed when required. In IT systems, the gold-standard for guaranteeing this is encryption. Otherwise you have to provide a long list of inferential controls (by which one can line up defense in depth to infer that the data under control can remain confidential) and guarantee the same level of protection afforded by encryption. Classic example is PCI 3.4 and compensating controls, discussed here.
Ensure Data Integrity: Data should only be manipulated when it needs to be and you should know about it if it is. Really, #2 is a partial response to ensuring that #1 above wasn’t breached. Encryption, when used with hashing and authentication, does this. Otherwise, just like above, you need to list compensating controls that infer that you have control of the data (Database Activity Monitoring comes to mind, it watches the data and lets you know when someone was acting on it).
Ensure Non-Repudiation of the Actions: This is done by good authentication and is included in encryption strategies. However, there’s some wide variation here depending on risk. Basic risk utilizes password authentication and the gold-standard for higher-risk levels is multi-factor authentication. Regulations are increasingly mandating MFA because of the following: a) password’s are so easy to guess/brute force/dictionary attack b) APT and spearphishing have shined a light in how rudimentary it is to break into systems and c) regulators are generally decreasing risk appetite and requiring MFA given all the publicity of breaches that began with a breach of passwords. About the only new question comes to us thanks to RSA; ie, are we getting an authentication system that is completely broken? However, given the points above, without using encryption, non-repudiation is again using an inferential model. So the subtle point here is that encryption can definitively do this, but needs to be used with the right crypto algorithm and key management. This is why we have NIST approved algorithms and FIPS/Common Criteria certifications. These systems have literally been battle proven to prove non-repudiation.
Provides Proof of Ownership Through the Transactions: Like the legal systems, for evidence to be acceptable in court a clear chain of evidence must be established for its entire reasonable life. Otherwise the evidence can become tainted and suspect. Now the smarty pants out there will have already said somewhere in this article that, “Dean, encryption isn’t perfect, get real.” And I would agree with you, this is why this point comes up. Encryption must be implemented correctly with the same degree of trust and secure software development practices as everything else. This is partly why we have the NIST/FIPS/CC requirements and certifications- they provide the system with a means to test and ensure the best security possible. And this is precisely why Key Management is such a significant part of these requirements. Key management is the mechanism for proof of ownership in encryption. But my point is in encryption you only have to worry about a dozen things (I’m just making this number on the spot, the exact number isn’t important, it’s the scale) to worry about to get it right, without it you are talking hundreds. Again, just ask any PCI auditor to show you the amount of time an audit requires for a system adherent to PCI section 3.4 vs. one that is using the compensating control provision. I had an auditor at the Cloud Computing Expo express this best when he said, “Don’t check the box saying you are using compensating controls unless you absolutely have to, it’s like checking a box that says ‘fail me’.” But if you do encryption right, and follow the Key Management requirements of the regulations, you can prove ownership through its lifecyle.

It’s for these essential facts that we got cloud security recommendation right. When you look at the cloud, with the split responsibility model and break in the trust foundation like I discussed here, only cloud encryption can solve the four points above that serve as the foundation for compliance regulations. This is, after all, why they just showed up in the PCI regulation and a lot of folks who’ve been thinking about this just said, “No kidding.” Anything else requires perfection of design, implementation, and process. And like the unicorn, I am still looking for the customer who’s gotten all of those right. And Wikileaks, Anonymous, and LulzSec have found a lot of the guys who didn’t. -Dean