When I was at Veritas, we did a security audit of a newly-built data center product. A bunch of hackers were called in and they found some critical security holes, including two within my own code.
My code was close to the kernel and I assumed that it was shielded by the layers of other code on top of it. As a new young engineer, full of self confidence and ego, I walked to one of the security experts and defended my work by claiming that the software using my work should already be secure and I shouldn’t be repeating the same security code in my work.
I think the hacker nailed it with a simple answer – “The best security architecture assumes that the layer on the top is already compromised”.
Year 2011 saw some of the worst cloud security incidents. There were over 535 incidents recorded affecting over 30.4 million sensitive records (source: privacyrights.org report). I guess my favorite was attack by Anonymous on Sony (details here), primarily because of the learnings it offered.
And if you look at what really happened this week with Dropbox, it’s quite relevant to the statement above. An employee password was compromised and their account had a project file with customer email addresses and details. Was it oversight to believe that these customer email addresses were protected in the cloud? How many of us are doing something similar? Dropbox was probably a victim of its own popularity and at scale everything breaks (source: Urs Hölzle, Google). But there is lot to learn from these incidents.
At Druva we constantly try and learn from these incidents. We also regularly invite security enthusiasts and audit teams to review our architecture. Following are a few learnings we have implemented at each level to secure the cloud :
- Network and At-Rest encryption
- Two-Factor authentication of critical users and admins
Within the Cloud/ Inner Layer
- Two-Factor encryption (patent pending by Druva) – a bank locker like system where neither cloud provider or the user has full access to encryption keys
- Sandbox data for every customer, so a compromised user/customer shouldn’t be threat to all
Employee Access and Control Policies
- Clearly separate the cloud access control – between Design, Architecture and Operations team. The person designing the security should have to access to the cloud, and vise versa.
- Data/byte scrambling to avoid any direct access to data
As cloud becomes more affordable, its widespread adoption will be inevitable. But the long term adoption from enterprises will depend upon how it gains the CSO’s trust. Simply encrypting data and getting an audit will not help. As a majority of the cloud service providers use other infrastructure services like AWS, the foundation for secure cloud will depend upon each layer within the cloud to establish security and even redundancy with the underlying layer.