When the topic of encryption comes up in conversation (and doesn’t it always?), skeptics are fond of interjecting self-satisfied statements along the lines of, “The question isn’t whether encryption is crackable, but when will it be cracked?” In the face of such smugness, I usually counter with the ego-deflating rejoinder, “Let me know when you’ve joined us in the cloud era.”
You see, when data is encrypted in the cloud, your keys remain within your control; thus only authorized users have access to protected data. Unauthorized users will only see indecipherable codes, which is fine, but how do you think unauthorized users will attempt to access and exploit said data?
Shifting Attack Vectors
In his latest update for Metasploit, Rapid7’s Christian Kirsch noted that attackers have shifted their attack vectors from exploits to credentials, and for good reason: as data migrates to the cloud, users are a much cheaper and more readily available attack vector than whatever vulnerabilities there might be in a cloud service vendors’ applications or infrastructure. In other words, if I’m going after your data in Box, am I going to waste my time trying to break into Box’s datacenter or looking for a “zero day” in their application? Or would it be simpler going after your Box users through a phishing attack?
To that end, turning on two-factor authentication and investing in workforce phishing education are better security investments than encryption. But what about that compliance checkbox? Isn’t encryption required by SOX or HIPAA?
Encryption: Handy for Checklists
Sarbanes-Oxley states that management is accountable for establishing and maintaining internal controls and procedures that enable accurate financial reporting and assessing this posture every fiscal year in an internal control report, and public accounting firms that prepare or issue yearly audits must attest to, and report on, this yearly assessment by management.
Sarbanes-Oxley Act Section 302 expands this with compliance requirements to:
- List all deficiencies in internal controls and information, as well as report on any fraud involving internal employees
- Detail significant changes in internal controls, or factors that could have a negative impact on internal controls
So what does that mean in terms of compliance requirements to protect data for public companies?
When it comes to protecting data in the cloud, encryption is handy for building checklists, but not much more. The theory is that only authorized personnel and programs see decrypted information, while all others have no access to the data. Encrypting the data ostensibly creates a “clear” attestation trail, because if only users who are allowed to access the data can access the data, then it’s easy to attest for when data was touched and by whom. But if the attack vector is the user and the user is compromised, then in the context of encryption-based attestation, such a breach would not be marked as a deficiency, thus failing the regulatory requirement, and landing the impacted company in hot water.
SOX is more about assurance and attestation, and encryption in that context is essentially lipstick on a pig. In many ways, as long as your cloud vendor supports SSL, that’s probably the extent of any potential encryption benefit. In fact, investing in more encryption will likely yield negative returns.
The same goes for HIPAA where encryption is also never mentioned by name, and for good reason. Here’s the meat of what HIPAA says about Protected Health Information (PHI):
The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate and there is a reasonable and appropriate alternative.
This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered, as well as the results of the risk assessment on which the decision was based.
Compromised Users Undo Encryption
Specific internal security controls need to be identified for protecting this data and, most importantly, auditing must take place to attest for the efficacy of the controls. But in the context of cloud adoption, especially SaaS, as long as the vendor supports SSL, you’ve got “good enough” encryption. If you go deeper, you end up breaking down the reporting mechanisms which would enable the most important regulatory output: attestation.
Enterprise security postures must be regularly re-assessed – including any changes or deficiencies as a result of changing conditions; in the spirit of compliance controls, they’re intended to be guidelines that survive technological paradigm shifts. The security value of encrypting data at rest in the cloud is nominal when a user with sufficient access privileges has been compromised, which is increasingly the preferred attack vector. Modern compliance best practices should shift resources away from prevention and towards attestation.
