The security curmudgeon presents an excellent rebuttal to The Ponemon Institute’s analysis of breach data

Aside from pointing to the obvious conflict-of-interest due to vendor sponsorship and a lack of citation or substantiation for claims, curmudgeon raises the biggest question of all — is it really news.

Breaches have been rampant for years. Compromises that may or may not have involved the breach of sensitive data have been staggering for years. Zone-H.com shows almost 50,000 incidents (mass defacements generally don’t count as separate intrusions) in the last decade. Does Ponemon consider this when making the statement above? Or would Richmond / Ponemon like to qualify what “publicized” means to them? Just because you don’t look at a given publication, doesn’t mean it wasn’t publicized.

Hear him hear him! Here’s my favorite part:

How can you say with any certainty that “most are mercenaries, members of criminal syndicates or representatives of unfriendly countries”, if they “quietly get in and out”? How can you say anything about their demographics if they were undetected?

Exactly! At least Ponemon did not say the unidentified threats are Chinese.

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.