Securosis to Cloud: Wakey Wakey

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

2 thoughts on “Securosis to Cloud: Wakey Wakey”

  1. Davi,

    You’re picking and choosing quotes so out of context it’s like a political attack ad. Not sure what i ever did to piss you off, but here’s a response…

    We’ve never claimed cloud is mythically complex. I *have* said it’s different than how most security is practiced today, and very few people have dug in publicly beyond the surface issues.

    Also, not all clouds are the same. If you think I equate the complexity of Dropbox to vCloud or OpenStack, you are very mistaken. The Dropbox bit *was* easy to spot, as I’d even posted back in April (and why we encrypted stuff when we first started using it).

    And you clearly haven’t read our other posts, nor to you acknowledge that Dropbox (and our post) is a consumer play, not something for enterprises. You also provide no practical advice for people who want to protect what they have up there, referring to non-existent standards and audits?

    Drop the logical fallacies and we can have a real conversation…

  2. Rich, thanks for your response.

    You’re picking and choosing quotes so out of context…

    I have used quotes about cloud security to discuss cloud security and I link to the original source. I do not see that as out of context. What context would you like me to put them in?

    We’ve never claimed cloud is mythically complex.

    Admittedly my paraphrase was a paraphrase, not a direct quote. However, I quoted you directly above: “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. ”

    So either you are saying you believe it takes mythical ability to understand cloud security or you have to admit that you believe in unicorns. Your move.

    I *have* said it’s different than how most security is practiced today, and very few people have dug in publicly beyond the surface issues.

    That’s a fair statement. I also have said similar things (I would change “most” to “some”). I haven’t found where you have said that but I guess we agree after all.

    Also, not all clouds are the same. If you think I equate the complexity of Dropbox to vCloud or OpenStack, you are very mistaken.

    Ok, call me mistaken. I thought for a minute we were on the same page. So would you say some clouds are mythically complex?

    And you clearly haven’t read our other posts, nor to you acknowledge that Dropbox (and our post) is a consumer play, not something for enterprises.

    Perhaps you could point to one of the other posts that you think is relevant? Or do you mean that I have to read all your other posts? Clearly you have not read my other posts. Does that make us even?

    Besides, I don’t see why you want to make such a distinction. Has cloud really been an enterprise “play” or has it tried to attract consumers of IT? Are you relying on the same distinction used by people who say that Apple computers are a consumer play, not something for enterprises? What’s the point of this distinction?

    Not sure what i ever did to piss you off […] You also provide no practical advice for people who want to protect what they have up there, referring to non-existent standards and audits?

    When I point out that you have made a mistake in your analysis you speculate on my mood and say you haven’t seen my solutions. Those are classic logical fallacies.

    1) Refutation by Caricature – the mood of a person does not bear on truth or falsity of their statement
    2) Tu Quoque – just because you say I have not found or tried the solutions I reference does not mean your argument is sound

    There are several good texts that explain how your reasoning shows a serious error in risk analysis (e.g. Visual Explanations by Tufte, Waltzing with Bears by DeMarco and Lister).

    Imagine how security disclosure would work if you were to apply your argument — require people to provide a solution before they were allowed to bring up a problem.

    And, as I said earlier, clearly you have not read my other posts. You should check the Encryption Key Management Infrastructure (EKMI) standard I presented in 2005 and worked on a well-known standards technical committee to release to the public in 2009. What was your practical advice for key management? I did not see that in your post.

    Drop the logical fallacies and we can have a real conversation…

    I’m an eager student of logic and I’m ready to learn. What fallacies have you found? You haven’t mentioned any.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.