The Virtual Data Center

For the most part, I’ve avoided talking about the current state of security in the cloud.  For one, there are many, many smart people and great bloggers already talking about it and I love reading what they write (and almost always agree with it, almost ).  And two, I spend a good bit of my day job (and have for the past 3 years) focused on the ideas around contextual-based access and security: security has different meanings and requirements depending on the context of how a particular service is accessed or invoked.  Now that’s some cool stuff, and the cloud access model is a natural extension of contextual-based access. You’ll see much more on this idea from me over the next year-ish or so.

Over the holiday break, I spent a good bit of time thinking about how and when cloud security was really going to become a watercooler issue (while playing Super Mario World on the Wii Virtual Console, ironically enough). We’re nowhere near there yet - heck, we’re still discussing the nuances of the cloud itself; we have to build that before we can worry about who or what gets in. But there a few anecdotal things that kept coming back to me:

1. In a previous life, I used to audit the security of data centers, from the physical rack and cage installations (even testing the man gates, now that was fun) all the way down to the network and applications.  I even conducted interviews of all DC staff, both enterprise and hosting, on what they knew, how they responded in the event of a breach, where root passwords were kept, all that meaty security goodness. My goal was to verify that a particular application was installed in the most secure running environment available, primarily to limit legal exposure should there be a breach against this application.  What I took from that multi-year experience: It’s extremely expensive to conduct these types of audits, and at some point the liability baton is passed to the people actually implementing the technology, away from those who designed it.  I could interview people all day, and spend weeks walking through their network, but once I left the premises and filed my report, it was up to them to stick to those procedures. We had to trust (in our case legally) that what I saw remained in place.

2. As I’ve mentioned here before, I own a small photography company, so small in fact, I use a cloud provider (for lack of a better term) for all our business documents, including balance sheets (very basic stuff: sold 10 photos, bought a new lens, etc). Before the end of the year, I was spending a nice, cold, snowy Sunday in beautiful downtown Bellingham at a local coffee shop where, over their WEP-enabled wifi network, I was working on said balance sheet, getting ready for the fun that is tax season. Me being extremely security conscious, I immediately noticed that the cloud App provider doesn’t use SSL to access my docs, and in fact, says they don’t even offer SSL unless I pay a much higher premium. Now lucky for me simply changing the login URL manually to HTTPS worked fine and I was happily encrypted. But I’m guessing I’m in the minority and most of their users won’t notice that they’re accessing what could be sensitive documents in a completely insensitive manner, or that it could easily be forced to work. Most users who got to step two would read the Help and see they had to pay for that service and then do their own value assessment: is the risk worth paying extra?

3. Amazon’s lack of security notification in their AWS mid-December, well documented by Craig on CloudSecurity.  A weakness in Amazon’s signing algorithm opened up the possibility for more-frequent-than-normal cryptographic collisions (yep, the same core issue that’s currently plaguing SSL CA providers who use MD5). Amazon did fix the problem, but it took them 7.5 months and they kept it under wraps, a very common response in the security world.

So noodling on these three things while on vacation led me to this realization: Cloud services are going to create a new level of trust between end-users, providers, and enterprises. There’s no way around it, simply because there are so many moving pieces to a cloud service that are outside our control.  There’s nothing in the world I could have done during the 7.5 months that Amazon was fixing their signing flaw except change my transport to Amazon, and I probably wouldn’t have done that because the issue wasn’t public and I didn’t know about it. Once I start sending requests into the AWS, I have to trust that the systems in place are going to work and work securely.

Now that’s a big leap: one that I wouldn’t make with a more standard computing model. But in the cloud model, we have to trust so many new components in the stack. Of course we can have safeguards (SSL) and checks and balances (pen-tests, people who responsibly disclose security flaws) but at a minimum, those require near unfettered access to systems that are no longer in our control and require knowledgeable people to address them. In my auditing days I had unfettered access, during a specific window of time. Once I was done my access went away, so even then there was no continual checking of those systems.

So moving forward, as the security people tear apart the (in)security of cloud computing, the rest of the world will just need to take that leap of trust. A lowering of our standards for what we can control in the cloud’s outsourced data model. As an end user it kills me, but I know I have to make those sacrifices if I want to use those services. So I have to modify my level of trust, and apply new and stronger safeguards to the rest of my workflow processes (personal and professional) to make sure I’m able to recover if/when there is a massive breach that’s beyond my control.  My recovery is something I can control, and I definitely trust myself.