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

LSE has launched a new blog called “Africa at LSE” as part of their African Initiative, which takes a freshly critical view of Al-Qaeda’s effectiveness and its future.

Even though the Arab Spring has all but passed Al-Qaeda by, it may yet give al-Zawahiri an opportunity to stamp his authority in the early days of his leadership given his contacts and access to networks in Egypt and North Africa.

However, Dr Brahimi is sceptical that he will be able to do so.

“Al-Qaeda seem to miss every chance made available to them. For example, they squandered the enormous opportunity presented by the US-led invasion of Iraq, which was widely viewed as illegitimate.

“As a vanguard group supposed to be protecting Muslims, this was their moment to step up. They didn’t and their story in Iraq is that of shameful and unrelenting internecine bloodshed.

An interesting paper on measuring and controlling events.

This article presents the event calculus, a logic-based formalism for representing actions and their effects. A circumscriptive solution to the frame problem is deployed which reduces to monotonic predicate completion.

It uses the example of water filling a container to explain sequenced events without reference to time.

The domain comprises a TapOn event, which initiates a flow of liquid into the vessel. The fluent Filling holds while water is flowing into the vessel, and the fluent Level(x) represents holds if the water is at level x in the vessel, where x is a real number. An Overflow event occurs when the water reaches the rim of the vessel at level 10. The Overflow event initiates a period during which the fluent Spilling holds. A TapOff action is also included.

[…]

In other words, the formalisation yields the expected result that the water stops flowing into the vessel (at time 15), when it starts spilling over the rim, and that the level is subsequently stuck at 10.

I am reminded of system logs; events described on their own are all good until you try and map one system of measure against another system of measure…then you need some way to express events relative to a central measure, or time. The TapOn event would be at 5:15UTC, for example. I also am reminded of the scientists who marvelled at an Amazonian tribe.

Ten days ago DailyTech gave a long and thoughtful analysis of Bitcoin economics and risk called “Digital Black Friday“. It boiled down to this paragraph, which sounds to me like the equivalent of regulation.

…market volatility poses a very serious risk to BTC users — be they miners, traders, or merchants who accept BTC as payment for goods or services. To that end, a major improvement would be for Bitcoin exchanges to implement mandatory market closures if the currency value dropped below a threshold. In theory this would be relatively easy to implement, and we expect that it will be done at some point to prevent one-day flash inflation/deflation

Of course this was viciously attacked by proponents of a “free economy” who argued that controls are always unjustified. Check the comments at the end of their story and you will find statements like this one:

The concept of artificial market limits has no place in a free economy and cannot stand in one.

DailyTech compared the crash to the stock market, which seems fair, but what they did not include in their analysis was the possibility of a malicious actor. They did not mention the risk of someone stealing accounts and then dumping all the Bitcoin. Yesterday they updated the story with the title “Mega-Hack of Bitcoin“.

Mt. Gox is admitting to a major breach and has shut down, in an unprecedented action. In all, approximately $8.75M USD worth of Bitcoins appear to have — at least temporarily — been stolen in the intrusion.

Suddenly all the individual investment accounts were 0wned by a single entity, and that entity decided they would exercise the freedom to dump value, crash the market and run. The response from Mt. Gox to reports of breached accounts, cited by Daily Tech, is notable.

As I already replied you, your funds were stolen by someone logging in onto your account with your password. Your funds are right now on a bitcoin address and have not moved since then.

As a reminder we assume no responsibility should your funds be stolen by someone using your own password.
…
The coins stolen from Mt.Gox were not stolen using any CSRF exploit… [the thieves] logged in on users account using the correct login and password. We have logs showing the loggin succeed on first try.

Blame the user is rarely, if ever, a safe response to security incidents. What actually happened, now documented by dataloss.db, is that the Mt. Gox user database was leaked. Then more than 100K Bitcoins were sold and hundreds of thousands more went missing.

It appears that someone who performs audits on our system and had read-only access to our database had their computer compromised. This allowed for someone to pull our database.

Interesting that they say it was someone who performs financial audits, as if to deflect blame. Here’s another way of saying the same thing: our system did not detect that an infected system was accessing our database, and we did not notice suspicious activity to highly sensitive data — that someone was downloading the entire database without authorisation/need.

Now the “anarchistic” darling of economic theory is facing questions of compliance: Why did Mt. Gox use weak ciphers to protect the database? Why would they wait to fix inactive accounts? Why did they allow read access to the database from a compromised system? Why did Bitcoin allow for a market crash? Now even free market advocates want to know.