Warning: snarkyiness ahead.

Several people have emailed me and asked my opinion on the Securosis Dropbox post. They ask if it is an “about-face”. In the past this company has boasted how they are among the very few who understand cloud security.

The number of people who truly understand cloud computing is small. And folks who really understand cloud computing security are almost as common as unicorns.

I was dubious back then. I poked fun at the unicorns and the mentality of exceptionalness.I went the opposite direction and tried to show cloud security is easy and anyone can figure out how to audit it.

Now I am being asked if I am surprised to see Securosis coming around to the humble side of their rainbow-colored VIP rope — cloud security can be obvious and easy.

We are fans of Dropbox here at Securosis. We haven’t found any other tools that so effectively enable us to access our data on all our systems

Enable access to data on all systems…sounds fun. But what if you want your data to be secure too? Securosis says anyone could have seen the risks all along. Dropbox clearly was not a secure service.

I always knew the Dropbox folks could access my data (easy to figure out with a cursory check of their web interface code in the browser), so we have always made sure to encrypt sensitive stuff.

Hey, what happened to the elite few who could understand cloud security? We just have to “encrypt sensitive stuff”? That is far from unicorn-like knowledge. Securosis does not label the big new Dropbox breach as complex, let alone approaching mythical knowledge. They instead call it a “fundamental” flaw.

It’s one thing for their staff to potentially access my data. It’s another to reveal fundamental security flaws that could expose my data to the world.

Poking and fun aside, I wrote about the encryption issue (staff access to data) at length already. Securosis is correct. What distinguishes the latest incident at Dropbox from the prior one is measure of a “reasonableness”. If a service offers authentication using a password, then certain business assumptions are known and well-established. In other words, if their security is based on a password and then they make a mistake by turning off the password (fail-unsafe, fail-open, etc.) it’s a mistake.

The previous controversy at Dropbox was not a mistake, it was a decision. They let internal staff have keys to unlock customer data for several reasons. Unlike a mistake, their decision with regard to encryption is not so easily argued to be unreasonable.

The statements by Securosis that cloud is mythically complex and only they can understand have given way. Their new story about levels of security that are reasonable — based on “cursory” and “fundamental” concerns — makes more sense. They propose what amounts to an IT department using common knowledge to drop out of the cloud provider model and roll their own security.

…here are a couple easy ways to encrypt your data until Dropbox wakes up, or someone else comes out with a secure and well-engineered alternative service.

Voila, no unicorns needed for these “easy ways” to secure data in the cloud using traditional encryption.

However, they lose me when they suggest a vague “wake up” standard for security. It sounds a lot better than waiting for a unicorn to arrive, but it’s still too vague for me. How will anyone know when a cloud “wakes up”? Who decides they are awake? How will we know when a cloud is “well-engineered” for a reasonable level of security — the kind of security you already know and practice?

The answer is likely to be found in compliance standards.

A customer of Dropbox should audit for sleepiness based on a reasonable definition of being awake. Securosis oddly leaves these details out of their story.

If Dropbox can drop password protection, they can drop other controls as well. Change management is suspect. Monitoring is suspect. Segmentation is suspect. More to the point, if you follow the Securosis advice and use traditional encryption that still does not mean you are safe on Dropbox. Encryption is easy but management of encryption can be complicated enough to break the entire model of “effectively enable us to access our data on all our systems”. Their solution does not fit the problem statement.

Scurosis’ non-cloud security solutions do not bode well for their position on cloud. Customers benefit from using encryption but that is just one control, and not sufficient without additional controls and procedures to protect the encryption. They do not touch on key management, for example. Customers still need clarity around how they should validate security, including key management practices for encryption when sharing files through a service provider.

I am glad the unicorn tone is gone, but I do not recommend waiting for an awakening. Audit providers early and often and don’t accept “you wouldn’t understand” as an answer. A standard of security reasonableness is influenced by steps taken to verify service provider controls. The use of encryption with a wait-and-see approach can easily backfire.

Updated to add: ATC-NY has set of python scripts for forensic analysis of Dropbox client data