Disturbances in the cloud

Cloud computing is cool, no doubt about that. There have never been more good looking and futuristic looking schematics been made in Visio. Thousands of presentations, workshops and even conferences have been held on the subject.

One question however has not be clearly answered yet … what about data ownership? What about privacy of that data? When your applications are running in the cloud you are also handing over your data to whoever is running the data center. How sure are you that they protect this data as they should do? What about these situations:

  1. Your cloud partner goes out of business and your data becomes a valuable asset that can be sold to pay of debt. How well are you protected from this scenario? Or … what are the guarantees about confidentiality? Think SalesForce …
  2. Your cloud partner goes out of business without any warnings, your applications are offline, your data is not accessible. Worst case you got a couple of days notice, best case a couple of weeks. Does your disaster recovery plan takes this into account? How fast can you move to a new cloud partner or your own data center? How much data will you loose? How recent is the data you go online with after recovery?
  3. Your cloud partner decides to disable a feature in their application, a feature you depend on. Does your disaster recovery plan takes this into account? This is not far fetched, in a small way this is what happened when Microsoft decided to disable anonymous comments on their Live Blog. They even did this retroactively and so revealed identity information of authors who previously had been anonymous.

None of these scenarios is purely technical in nature and none of these scenarios are far fetched. You can probably think of many more realistic and sure to happen situations.

In relation to the 3th scenario … how many companies have application versions that are far behind the lastest public version purely because of functionality or compatibility they depend on? At least all of the companies I have came into contact with are in this situation. If you run everything on your own servers you have a greater deal of control then you can imagine at first. Companies should do their homework when moving some of this into the cloud, they are often giving up far more control then they think they do and want to do. Contracts alone won’t solve it either.

Share

Prank calls and counter measures.

Gunnar Peterson linked to this fun but interesting story:

“He sounded just like Obama,” she said on Thursday, referring to President-elect Barack Obama.
Sensing she was the victim of a spoof by a South Florida radio station, she promptly disconnected the call.

Trouble was, it was Obama.

A chagrined Ros-Lehtinen told the Fox News Channel that she also hung up on Obama’s chief of staff, Rahm Emanuel, when he called her back to explain it really was the next president on the line.

Both Emanuel and Obama tried to convince her the call was for real.

“Guys, it’s a great prank, really,” she said she told them.

It took a subsequent call from California Democratic Rep. Howard Berman, chairman of the House Foreign Affairs Committee, to finally convince Ros-Lehtinen to talk to Obama.

To convince her that it really was Berman, she said she told him, “Give me the private joke that we share.”

These type of prank calls, when someone calls you and pretends to be a high ranking official in some country, used to be low probability and medium impact risks. Low probability since there was a border most people did not cross. We all laughed with prank calls where a radio presentator pretended to be some unknown person who wanted to order something so extraordinary that it was hard to believe it was true … but funny. But pretending to be the President of France or the President-elect of the United States, that was a whole different story. That was not done, who knows what the repercusions would be! It was also a medium impact risk because in most cases the victim of the prank call was not a VIP or anything, often even just a receptionist at a company. The impact was all personal and completely forgotten after a couple of weeks.

But recently some people changed all this. Today this is a medium to high probability and high impact risk. Certainly a higher probability since others have done it and got away with it. Surely a higher impact was well, just look at what happened to Sarah Palin. It’s not something that is forgotten after a couple of weeks, this is something that sticks to your career now.

But my congratulations to Ros-Lehtinen who did not only recognize the change in the risk profile but also employed a simple but effective counter measure: use of a shared secret.

Share

And the solution is … SSL!

Today I attented a talk from Microsoft about their new Azure Cloud Computing platform. They had hired David Chappell to present the first topics that introduced the whole concept and the specific offering Microsoft is making in this area.

It was all interesting, David Chappell is a gifted speaker. At one point however I got disappointed. David was explaining how REST was a very good choice for communicating with cloud services. Amazon, Google, Microsoft … they all have cloud data services that can be accessed using a REST api. Someone in the audience asked how, if they don’t use SOAP with WS-*, how can they secure this. David’s answer came quickly “oh … use SSL … it’s only one endpoint talking to another endpoint, SSL can secure that”.

The days that there was always single network connection between the consumer (client) and the producer (server) are also over. At both sides, the message passes through various firewalls, gateways, messaging infrastructure … before being delivered to the real message endpoints. You can’t use SSL to protect it all. SSL will just protect a single network connection.

With the current solutions and architectures, people need to understand that message level (or application level) security can never be achieved by depending on transport level security alone. There are just too many hubs between the two endpoints. You need appropiate security controls at the message level as well. If people insist on using REST for scenario’s that go beyond low assurance needs, they must think about message level security and trust controls that are independent of the transport layer. If we continue to neglect message level security in REST while at the same time promoting the usage of REST in cloud data services, we are destined for a security nightmare in the near future.

The topic of REST and security is also definitely not new.

While we are at the topic of “built security in, from the start” … may I kindly ask both Microsoft and Adobe to support WS-* security standards in their RIA technologies (SilverLight and Flex). If Microsoft really is serious about security as they so often claim these days, then why does SilverLight 2.0 does not have support for web services security beyond just SSL? It looks like a missed opportunity for which we will pay dearly in a couple of years.

On the bright side … a lot of the services Microsoft will offer on their Azure platform will have full and first class support for claims based access control. At least a standards based authentication is possible. They do seem to think it also solves the authorization problem … that is wrong. Perhaps more on that later.

Share