Sarbanes-Oxley doesn't like the cloud. It's nothing personal. The cloud didn't steal the yogurt in the office fridge that clearly had "SOX" written on the label with a Sharpie. The cloud didn't delete the recordings of Breaking Bad on the DVR that Sarbanes-Oxley was finally going to watch this weekend. It's nothing like that. It's simple: Sarbanes-Oxley doesn't like the cloud because it doesn't trust the cloud's security.
Other contributors to Wall Street & Technology have written insightful pieces about various security requirements of SOX, but one topic that deserves more attention is encryption. Encryption deserves a brighter spotlight because it is indispensable in making SOX learn to love the cloud. It is important to note that financial services have been living with encryption for a while, but that has primarily been in their own corporate data centers. Yes, it creates performance bottlenecks. Yes, it is a nightmare to manage. Yes, it's incredibly expensive, but it's up and running in those data centers, and that is a very good thing if you ask SOX.
But encryption in the cloud is a whole other can of worms.
The Challenges of Encryption in the CloudDeploying encryption in a cloud environment is very different because of the dispersed nature of cloud computing. Encryption in the cloud is hard. So hard that less than half of companies that work under mandates like SOX, HIPAA and other similar regulations have successfully implemented encryption processes in their cloud deployments. IT departments are being asked to deploy more on the cloud in order to save money, but that is leading to a head-on collision with security vulnerabilities, availability problems and compliance liabilities of the cloud; creating a no-win situation.
So what does encryption in the cloud look like? It requires a four-pronged encryption strategy involving mobile VPN (Virtual Private Network), encryption at rest on the disks, SSL certifications and encryption within the applications themselves. Don't bother looking for that in the fine print of the SOX regulations because you won't see it spelled out there. SOX is a little coy about encryption. In contrast, HIPAA regulations for healthcare companies are much more explicit and (pardon the medical pun) prescriptive.
While SOX is not as explicit as HIPAA in calling for encryption, it is no secret that no encryption = no SOX compliance. The key clauses that get to the heart of this issue include DS5.11 (regarding the exchange of sensitive data), DS11.6 (regarding the security requirements for data management), and DS5.8 (regarding key management).
The SANS Institute, which helps set widely adopted standards for security, has elaborated on these SOX requirements by recommending a series of specific measures that put encryption in very sharp focus. The bottom line is that you need all four of those prongs in order to have a successful, compliant encryption strategy, but which scenario would you prefer?
Option 1: Your company is directly responsible for all four prongs.
Option 2: Your company has a partner (cloud provider) to take care of three of the four prongs by building it into their cloud infrastructure?
Encryption Is Important for a ReasonBefore you choose an option, we should talk about why encryption is so critical. Other security issues tend to be far sexier than encryption, such as fancy biometric access controls like retina scanners. Encryption is definitely not the Scarlett Johansson, Halle Berry or Ryan Gosling of the security world, but it is important for a reason. Encryption plays a major role in not only preventing security breaches, but also in mitigating risk in the event of a security breach by reducing or eliminating fines, loss of credibility and a whirlwind of other negative outcomes.
Take the wild world of healthcare as an example. If lost/breached healthcare data has been encrypted and the keys remain safe, the responsible organization is not required to report the incident publicly; saving itself from breach-response protocols that are embarrassing, costly and time-consuming to implement. Simply put: Encryption saves their bacon and mitigates these risks. It's the last line of defense in the event that other security measures and human procedures have failed, and it can save millions of dollars in fines, as well as hard and soft costs for healthcare companies.
The most common approach to implementing encryption in the past has involved "bolting on" encryption products. Third-party encryption solutions would be installed in the data center as an additional layer between sensitive data and the outside world. Unfortunately, bolted-on encryption hardware may cost upwards of six figures per implementation. That adds up, even for financial services companies that have deep pockets. Worse, this approach to encryption forced users to be responsible for time-consuming, burdensome and complex key management that was vulnerable to a lot of errors. Even worse, bolted-on encryption had a significant impact on data throughput and backup processes, which are killers for companies in the financial services industry. Those challenges were significant, but surmountable in a company's own data center. However, all of that multiplies in a cloud environment.
The problem with encryption in the cloud is that the model that has traditionally been used in corporate data centers simply doesn't work in the cloud. You can "bolt-on" encryption in a traditional data center, but you can't bolt it on to the cloud without running into unintended consequences with other important business functions like having performance and backups working at an acceptable level. It's like trying to put birthday hats onto an infinite number of surly cats. Good luck with that.
But there is a new approach to encryption in the cloud that takes a "built-in" approach.
A New Model for Encryption & the Cloud
So what does a more effective model for cloud encryption look like? For one thing, it needs to focus on encryption "at rest," not just encryption for data "in transit." It should also be built into the server architecture rather than bolted on as an after-thought. It needs to leverage both symmetric and asymmetric encryption. And it also requires cloud providers to take more responsibility for encryption rather than treating it as an add-on or third-party issue for a few customers with sensitive data.
Building encryption into the server hardware within a SAN (Storage Area Network) is critical because it removes performance bottlenecks and makes it simple to achieve encryption at rest. Using built-in, hardware-based data encryption, data is encrypted when written to drives and decrypted when read from drives. This type of back-end encryption ensures there is no risk of stored data exposure when drives are removed or arrays are replaced.
A built-in model for cloud encryption also eliminates the burdens and vulnerabilities of complex key management, which bolted-on encryption requires. Building encryption into the hardware allows financial services companies to automate key generation, key distribution and key management, removing a huge burden, especially for consumer facing applications. It facilitates appropriate separation of administrative responsibilities so that application or server administrators do not have access to the key management system of the storage array. This is important when deployed within a company, and it is critical when IT infrastructure is outsourced.
None of this is possible without a commitment from the cloud provider, which brings us back to options #1 and #2 above. This new approach to cloud encryption depends on the cloud provider building three of those four prongs into their infrastructure (mobile VPN and SSL certificates to protect data in flight as well as encryption at rest on the production disks and any backup storage). The technology exists for cloud providers to do that today. The obstacle isn't a technical one; it's a cultural one. It's a mindset that treats regulatory requirements (re: SOX, HIPAA, etc.) as solely the customer's responsibility instead of their own. That will change if regulated companies insist on a more collaborative model for implementing encryption as part of a robust defense-in-depth approach to meet both the security and compliance aspects of these regulations.
This isn't a blueprint for cloud encryption in the distant future; it's a blueprint for today. Financial services companies are doing this right now with the help of cloud providers that are committed to solving this encryption challenge. Look for evidence that security and compliance is part of your cloud's culture, not just a checkmark. With the right touch from the right partnership, maybe cloud can coax a purr out of SOX after all.
About the Author:
Steven Aiello is a Senior Product Architect at Online Tech, which provides compliant data center services to companies in the financial services industry and other regulated industries. Aiello holds a Masters' Degree in Information Assurance. Other certifications include CISSP (Certified Information System Security Professional), ISACA CISA, VMware VCP (VMware Certified Professional), Cisco CCNA (Cisco Certified Network Associate), Comptia Security+, and Certified Incident Responder (New Mexico Tech). Steven's many years of experience at companies like ADP and healthcare IT service providers have given him deep experience and appreciation for the intersection of security and compliance in regulated industries.