Cloud Zone is brought to you in partnership with:

Eric Berg is vice president of products at Okta. He has more than 18 years of experience across engineering, marketing and business development and has successfully driven product, business, and marketing for both early stage SaaS companies and high growth software businesses within larger organizations. Eric is a DZone MVB and is not an employee of DZone and has posted 38 posts at DZone. You can read more from them at their website. View Full User Profile

Defining the Enterprise Cloud Service: Strong Encryption Throughout

10.23.2012
| 3518 views |
  • submit to reddit

Curator's note: This post was written by David Baker. 

During the past few weeks, I’ve written about what it takes to build a cloud service that’s ready for the enterprise. Essentially, there are three characteristics that set true enterprise cloud services apart from their consumer counterparts: Security. Reliability. Trust. When evaluating an enterprise cloud service for those characteristics, there are five traits to look at:

  • Development for the enterprise
  • Endless 9s reliability
  • Benchmarked and audited service
  • Strong encryption throughout
  • Singular focus on the customer

I saved the “strong encryption throughout” category for the finale because it’s the most important component — and it’s very easy to do incorrectly.

Before coming to Okta, I helped run a security research and consulting firm based in Seattle. By traditional company numbers, IOActive was not very large at 50 employees. However, managing 40 white-hat hackers — in 15 different countries — is a lot of work! And despite its size, IOActive is one of the leading high-end security services and research firms. As vice president of services, I was responsible for the success of more than 150 engagements every year. These engagements had an incredibly diverse range, which included reverse-engineering the hardware and firmware of the next generation of computer motherboards and ICS devices, reviewing millions of lines of code for the latest desktop and virtualized operating systems, cloning RFID badges, and launching social engineering tests.

During my 15+ years in corporate security, I’ve seen many systems and applications that have handled security by incorporating weak encoding to strong encryption, and nearly everything in between. And I have seen a lot of built-in encryption security gone very wrong. I’m not an expert in cryptography, but any penetration tester with a bit of experience will have several war stories of how he easily cracked a “proprietary” encryption protocol or was able to decrypt the target data with an encryption key that was stored in the same database. This happens all of the time. Whether you are using EC2, Rackspace, or even iCloud, remember that the infrastructure is shared. The economy of scale does have security challenges associated with the shared nature of the cloud.

As CSO at Okta, I not only need to segment the Okta service from its noisy neighbors, but I also need to further segment our customer service instances from one another. To accomplish this with traditional security measures, I’d have to stand up dedicated servers and additional networks segmented with firewalls. Then, I would have to add web application firewalls and intrusion detection on each segment to ensure proper segmentation and security of the higher OSI layers.

But this traditional approach would fail at Internet scale in the cloud. As we embrace this disruptive technology, we must often use different means to achieve the same goals of confidentiality, integrity and availability. This is where encryption throughout is important to achieve that logical security perimeter and data segmentation.

Encryption is not just for the data at rest in the cloud. End-to-end communications security is important, too. The enterprise cloud must enforce strict transport layer security with only strong ciphers for all connections. While at IOActive, I often saw security assessment results where web services did not enforce these configurations because they didn’t want to inhibit those using older browsers. That logic makes sense for common consumer web applications. But an enterprise cloud service should not be the weak link in the communications protocol security chain.

Strong encryption is critical for data at rest in the cloud. Think of it like this: You have enterprise customer data and want to secure it like a bank secures money in its safe. The better the encryption scheme, the better the safe. These days, AES-256 is that safe of choice for companies. It’s strong and allows for rapid processing, which is important for Internet scale services. However, a strong safe is only part of the equation. You still have to protect the key to the safe. Simply put, don’t store the key hanging around the data you are encrypting. Sounds obvious, right? You’d be surprised how often developers focus on building the safe and forget all about securing and managing the key.

Solid key management is also critical to strong encryption throughout the cloud service. And it gets complicated, too. Enterprise clouds need unique keys to encrypt each customer’s data, which is important to logical segmentation of customer data. So, a thousand customers means a thousands unique keys to access, secure and rotate. (Rotation is very important!)

Bottom-line: Every enterprise-ready cloud service should use encryption throughout its service. As a customer, ask your cloud service provider about its strict transport layer security mechanisms, how they securely store data at rest and how they securely manage customer encryption keys (and be wary of shared keys). Also, request to see the vendor’s SOC 2 Type II or penetration test report as proof of their encryption audits, or see how it stacks up to the other security criteria I’ve discussed in this series.

Feel free to get in touch with us at Okta, or find me on Twitter (@bazaker) with any questions.

Published at DZone with permission of Eric Berg, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: