The Hidden Risk of a Meltdown in the Cloud

[Netmaker]

Most of the hype about "security" is about access, IIRC. The "cloud" allows access anywhere, and redundancy means you're less likely to loose data to hardware failure.

I take it you're talking about hype from a positive perspective. That being the cloud service provider is going to provide a level of access and redundancy that the customer themselves couldn't or wouldn't.

Consider a company with a large call center who has hosted their customer support system with a cloud service provider. The company has gone to every effort to ensure local redundancy but has no control over the long haul back bone connections. If they and their service provider happen to be in the north-east where fiber is laid next to train tracks they can easily have a multi-hour service due to train derailments, icing of bridges, draw bridges (yep, that really has happened)...

And so they lose the ability to support their customers even if they've retained their phone service.


Another example - Microsoft's recent Azure outage due to a leap day programming error on their part (which is really laughable) left all of their customers without service. Any major company hosting an important application or system with a cloud provider would need to factor in platform redundancy - that is, architecting their app/system to be able to run on more than one cloud provider's platform.

They would need to do this for two reasons - the first would be for operational redundancy in case of an actual outage. The second would be to avoid vendor lock in so they wouldn't be subject to pricing extortion, or the cloud provider deprecating features/APIs they depend on, or the cloud provider going out of business...

In the past it was considered good practice to abstract your operating system interfaces both to avoid vendor lock in and to be able to support multiple operating systems (if you were a product developer selling to customers). The same logic applies to cloud hosting.

The danger of "the cloud" is that people (management) will see it as a magic bullet. Much like outsourcing call center operations or software development to India was seen, only to find out the gotcha's through painful direct experience.

[krenshala]

Multiple times in the past the entire Internet (or extremely large swathes of it) have been brought down either by fat fingers or ignorance when an ISP has "blackholed" the Internet.

Effectively what occurred is that the operator broadcast that they had the shortest path to every route in the Internet. Consequently all Internet traffic was sent to that operator. Much hilarity and hair pulling then ensued.

A "normal" (D)DoS is bad enough to deal with, that had to have sucked. Glad I haven't been involved in anything like that (yet).

The future issue is that nobody will truly understand what the Internet is and consequently not even be in a position to devise "appropriate preventive measures" because there will be no way to know what to prevent against.

I think it will be more that some will understand the Internet in general, but not specifics, and others will know the specifics of certain areas, but not the generalities very well.

The transition to IPv6 may provide for some excellent opportunities to prove the point as we work through exactly what the failure modes are in practice as opposed to theory.

A Cisco or Juniper core router code update also provides similar opportunities.

Considering the issues that crop up from IPv4 right now (e.g., just this morning I ran into "only half my IP block works!" ... turns out the subnet mask was wrong so he could only access the first half of his block of 32 IPs) IPv6 is definitely going to allow for large "learning opportunities". This reminds me, I really need to dig into IPv6 so I can explain it to customers if/when they ask.

There's an old adage that it's impossible to make a system that's foolproof because fools are so ingenious.

My favorite line on the topic: A computer allows people to perform human error at inhuman speeds.

[DeltaV]

The dangers of the Pentagon’s cloud

[choff]

Ties in with skynet is coming.

[ScottL]

We do the same thing here in my organization where cloud became a nifty way of saying we virtualized our environments to consolidate servers. This really became available with the increased specs of server hardware and when you can do more with less, it looks like a win-win for managers. Some will claim "that's not a cloud" but actually it is in that it consists of networks of networks. I imagine the pentagon is doing the same, so their locally administered "cloud" will be no more susceptible than it was before.

The concern still with public clouds like Azure or Amazon's service should be the fear of locational security. While it is touted as a positive feature, physical location in the cloud is a very real concept and concern. As I've said before in previous posts, the minute your data and/or apps/services transfer across national borders, it becomes governed by that sovereign nation. Consider the scenario of a financial institution that goes with the cloud for application and data services. This institution while just moving around bytes here and there may find that some portion of its infrastructure is now hosted in any eastern European country where hosting services are required at any time to hand over certs and keys to police or military. Now your financial data is at the mercy of that nation as a trade off for up-time. Scary stuff if you ask me.

[hanelyp]

I did some poking around the Amazon cloud service recently. You can specify which of their data centers hosts virtual servers for you. Their static content web servers, on the other hand, routinely store copies of the data several places around the globe for faster service.