Let go, let Cloud.
Pretty soon the New School Guys are going to say everything I wanted to say, only better, and I can hang up my cleats and get out of the game.
Alex Hutton, who appears to be catching up to David Mortman in the number of blogs he appears on, had this post over at the Verizon blog on clouds and the evolving role of the CISO. The magic phrase is this:
[T]he Cloud transition is about how to gracefully lose control over computing assets.
Ten years ago, IT outsourcing meant that you hired the bodies from somebody else, but they still did what you wanted them to do. Someone else paid them and managed their benefits, and if they had a management structure, it was embedded within yours. That didn’t achieve economies of scale as much as everyone hoped, so these days, instead of buying (or renting) the bodies, you’re buying the service—which means they get to do it THEIR way, presumably to save money. Hence, the hounds^H^H^H^H^H^HCloud.
It should be intuitively obvious, but everyone keeps hitting their faces against the same lamppost over and over again: “economies of scale” means “cookie-cutter.” It means one size fits all, and you’re stuck with the resultant blisters or chopped-off toes to make your organization fit within the shoe. In theory, everyone is in favor of standards, but there are an incredible number of different ways even to implement the same standard, much less choose among several standards to implement. IT is not “cookie-cutter” by any stretch of the imagination, even at the lower ISO layers.
So with the “cloud,” you’re expected to buy someone else’s implementation of infrastructure/platform/software/whatever, and you’re not SUPPOSED to change it. If you’re not supposed to change it, why would you need to know exactly how it’s being done? This is the conundrum for today’s CISO.
As Alex says, you start giving up visibility, which means you need to trust that cloud provider. Not only do we lose the important data necessary to form risk decisions, but we also lose the ability to implement and respond to risk. Take a very small example: say that you have an uptime SLA with your provider that says that if something is down, they have to have it back up and running within four hours. Sounds good in the contract, but in the actual execution, this means that if your server is shooting out warning errors, you would probably start making plans to replace the failing hardware (or whatever it is) proactively. Economy-of-scale providers don’t do proactive; it’s not economical. So THEIR operational rule will be, “We’ll replace it when it fails, and not before.” And you will spend a lot of time watching tickets go by that state as the resolution, “We rebooted it and the errors went away.” A slowdown in performance is not the same as an outright failure, so you will have no recourse but to sit and watch your business limp along. (I’m actually surprised that we don’t see more arson in hosted data centers, where someone in desperation sets fire to a server to get it to FAIL ALREADY.)
So there are two main areas of expanded risk that need to be calculated: our knowledge into the state of the system, and our ability to control the controls. I’m only a FAIR padawan, so I haven’t been inducted into the mysteries of calculating this far down, but I’ll bet someone around here can shed light on it.
As we get dragged kicking and screaming by our business areas into the Cloud, it will be very interesting to see whether the CISO’s accountability is correspondingly reduced, and whether more real liability is transferred to the cloud provider. I’m not talking performance penalties here; I’m talking REAL liability, in which the provider shoulders the total loss incurred by an incident on their watch. When are we going to start seeing cloud providers sued by their customers?
I’m getting the popcorn and the lawn chair ready.
Posted by shrdlu on Thursday, May 07, 2009
(5) Comments • Permalink •
