The the European Network and Information Security Agency (ENISA) posted in November 2009 a very thorough assessment of cloud security. Here are their “most important classes of cloud-specific risks”:

• Loss of Governance
• Lock-in
• Isolation Failure
• Compliance Risks
• Management Interface Compromise
• Data Protection
• Insecure or Incomplete Data Deletion
• Malicious Insider

They end the list with a disclaimer:

NB: the risks listed above do not follow a specific order of criticality; they are just ten of the most important cloud computing specific risks identified during the assessment.

I counted the list, then I counted it again, and one more time just to be certain. Unless I am missing something I only see eight, not ten. Data Protection also seems to overlap with Insecure or Incomplete Data Deletion, which could bring the list to seven.

Those details aside, it also occurs to me that these are not cloud-specific risks. We discuss them outside of the cloud all the time, and I mean all the time. Some could be said to be more service-provider oriented than in-house, but items like insider threat definitely can not be termed specific to the cloud. Insiders are, well, inside everything.

The full document actually gives thirty-five risks (R.1 to R.35), which it distributes on a map by severity and likelihood. This is a typical assessment practice and very useful. However, it does not seem to correspond well with the executive summary and list of eight (seven) mentioned above. How were risks in box five excluded from the top list, for example?

In conclusion I find this an excellent reference document. It is interesting to see an assessment performed of a concept rather than an actual service. That gives me the feeling that it is more of a template for assessments, not a report on risks found in an operating environment. Perhaps those on the team (e.g. Google, Microsoft) were hesitant to publish a more tangible level of tests.

The assumptions that had to be made, due to this approach, could be the reason their final analysis appears to stays extremely high-level. It does not look different from assessments of non-cloud environments, but it gives eight critical risks (2, 3, 9, 10, 11, 14, 22 and 26) to consider when talking to a cloud provider. I am left asking myself when remediation will begin…for the concept of cloud.

It looks like stormy weather in the clouds of Google.

Their Developer Blog announced yesterday they no longer are charging for Datastore CPU costs because of performance problems.

As many of you know, App Engine’s Datastore performance has been seriously degraded over the last few weeks. In addition to May 25th’s 45 minute Datastore outage, applications have seen an increased latency and thus errors as a result of timeouts. As a rough estimate, we have seen Datastore latency increases of around 2.5x.

They explain this problem as a byproduct of their own success.

There are a lot of different reasons for the problems over the last few weeks, but at the root of all of them is ultimately growing pains. Our service has grown 25% every two months for the past six months.

Stock image from PhotoBucket:

Congratulations might be in order until you realize they also are announcing that they watched a problem coming for six months yet kept adding accounts…now that services are failing and systems are down something will have to be done about it. A cost change is an interesting way of trying to compensate for the mistake until things improve. However, it seems a lack of foresight is what really needs to change.

The site says fees will return when performance is at a level they “consider acceptable” or when they “are proud” of the service. In the meantime, they “appreciate your patience”. These phrases ring hollow to me, especially when compared with the more precise language and data offered at the start of their announcement. It sounded better when they said problems are expected for the next two weeks but not longer. It also would sound better if they said fixing the problem is just a start; they next will work on how to address issues more proactively.

Security management requires system availability and recovery to be measured in order to be proactive. A time objective (in this case two weeks) and a point objective (what is acceptable?) have to be documented and tested at least annually. These tests can help find problems and create solutions before a real outage occurs. This is a known internal IT requirement and so nothing less should be expected from a cloud.

A story about sting operations using Facebook caught my eye in the La Crosse Tribune.

University of Wisconsin-La Crosse student Adam Bauer has nearly 400 friends on Facebook. He got an offer for a new one about a month ago. “She was a good-looking girl. I usually don’t accept friends I don’t know, but I randomly accepted this one for some reason,” the 19-year-old said.

He thinks that led to his invitation to come down to the La Crosse police station, where an officer laid out photos from Facebook of Bauer holding a beer — and then ticketed him for underage drinking.

For some reason? I bet the police know the reason. Great example of how the police make use of social engineering methods.

The article does not explain whether the police acted on suspicion or if they had any particular reason to launch a probe into Facebook accounts of minors. Perhaps some would argue that establishing a “friendship” is all that is needed to authorize a search for incriminating evidence, like inviting a plain-clothes officer into your home.

Reuters reports that 147 AK-47 rifles have been seized in Texas.

Acting on a tip, police in the border city of Laredo stopped a truck on Saturday and found the AK-47 rifles, along with more than 200 high-capacity magazines, bayonets and 10,000 rounds of ammunition, Laredo police told reporters.

This news item brings to mind the speech by President Calderon of Mexico last May to the US Congress. He said 75,000 weapons had been seized since 2007 and 80% of them were traced to the US. He was making an appeal to reconsider the Federal Assault Weapons Ban (AWB) enacted in 1994 by President Clinton (under the Violent Crime Control and Law Enforcement Act) and allowed to expire in 2004, during the Bush presidency.

Although the US Congress has debated several versions of a new AWB since 2004, none have passed. President Obama has hinted that he now wants the US to support CIFTA (Inter-American Convention Against the Illicit Manufacturing of and Trafficking in Firearms, Ammunition, Explosives and other Related Items) more than another AWB. The news of this raid will surely help that effort.