Most of you who read this blog and forum have better things to do than sit around on Twitter all day. I respect that, and your time, so in case you missed the #ConvCloud chat today you shouldn't have to miss the high points of what turned into a fantastic conversation.
As I see it, being the IT managers of many of your organizations you have two options - "get with it" and understand and embrace coud - or become irrelevant in your business as they adopt alternate IT ... so let's get you caught up.
While there were several questions posted and discussed in several veins of conversation, the one many of us got hung up on and never left was this: "How do you decide what to build internally (private cloud) and what to consume externally (public cloud)?"
One of the main hang-ups came from what I feel is a fundamental mistrust for public clouds... or public (also associated with shared) infrastructure in general. We went around and around trying to pick apart why we don't trust public clouds or outsourced providers for that matter, so here are some of the key take-aways I got from today's chat.
1. Public clouds are highly untrusted by the information security audience because their track record ofavailability failures (you want a mind-blowing example see this: https://forums.aws.amazon.com/thread.jspa?threadID=65649&start=0&tstart=0 )
2. Shared infrastructure is largely untrusted because of the risk of 'shared collapse'; the notion that if on tenant is compromised, everyone will fall victim
3. Public cloud providers probably don't care about your security as much as your business
4. Public cloud security doesn't exist because no one knows what it really means
5. Public cloud is more risky, or less risky, as a general rule
I get why item #1 above is true... we've watched Amazon and Microsoft's Azure clouds fail and take out entire businesses for large chunks of time without very much recourse. Typically, the provider will offer you some free service, or maybe in the best-case pay a small penalty equal to what you're paying for the service. If you're a company that's put their entire business model out in a public cloud and your business is down for 24 hours, the $500 you paid for that 24 hours of dead service coming back to you is a slap in the face.
If I understand issue #2 correctly I think it largely stems from the notion that anything can be compromisedor rooted which breeds a healthy distrust for anything public. We, in information security, are also control freaks and when we don't have a device we can control, we can't attest to its security and get get nervous. I've said it over and over that we need to move away from the control model into a governance model where we acknowledge you're not going to be able to touch and have absolute control over every aspect of your risk... get over it, as any notion that you have control now is a delusion. Furthermore, assuming that because you control the environment that you somehow have a better handle on security is a flat-outfallacy. I'm not saying it's never true, just like I refuse to believe it's never always true. If you look across the large swath of data breaches out there, most are still happening at the data center level which means the victim was responsible for doing their own security and was in control of their own environment... you can't tell me many of those wouldn't have been better off with a shared-service model in a cloud somewhere, where they would have at least had a chance at better security.
Issue #3 stems from doing poor due-diligence on your provider, period. If your complaint is that your provider doesn't have the same goals - or doesn't make your goals their own - then you only have yourself to blame. Get a new provider. Your cloud provider's mission should align closely to yours ...or else you're doing it all wrong again. Look, it doesn't make sense for a Financial Services company to drop into a public cloud like perhaps Amazon which has clearly demonstrated a lack of give-a-darn for security in the past, and to do so is irresponsible at very least.
I'd like to call crap on issue #4. Organizations like the Cloud Security Alliance for example are making measurable gains in demonstrating cloud controls, and defining the security paradigms for the new way of elastic, public infrastructure computing. It's your job as the consumer to make sure you're using a provider which is up to your standards. As the consumer if you don't know the level of your provider's security posture, perhaps it's your fault that you've not done the due diligence to get enough assurance or your provider is simply not transparent enough. On the other hand, if your provider claims a level X of security and an incident happens that proves this was not the case - and you're not protected against that - then your legal team failed you. Legal issues are one of the key hold-backs from consumers adopting cloud quickly... getting those contracts to read right is difficult and you need to make sure you're comfortable with how you're diving into the pool.
Issue #5 is what causes otherwise rational people to have irrational arguments - generalities absolutely fail in this (as many other) case. I think Martin (@armorguy) summed it up nicely when he said: "Cloud is *not* less risk, it's not *more* risk - it's *different* risk. Depends on how you use it." And that really says everything right there.
From the executive level, the fact that the security staff at your companies strongly feel that they can't, or shouldn't allow the move to public cloud at all should trouble you. A wholesale distrust for the public cloud, to me, means that either your security employees have no trust in the enterprise's ability to re-structure its security posture from the old fortress mentality to the necessary 'data-centric' or 'application-centric' approach, or that they simply don't understand how to apply security to the new paradigms of cloud computing. This shows either a lack of education, or a lack of trust in your enterprise capability. I think, if I understand everyone, we're all very uncomfortable with someone else having the technical responsibility for something we (in Information Security) have the legal responsibility for. This is a classic problem, and I firmly believe the only resolution for this irrational fear is the shift from control-based security to a governance-based security model. You can't do it all yourself ...and more importantly if you're not taking advantage of the massive benefits of cloud computing - choice, consistency, confidence then you're losing out. One of my big talking points on cloud lately is the incredible levels of agility that we can possibly gain from cloud adoption - and businesses are understanding this and turning to the cloud for answers when IT fails to deliver them timely and appropriate services they need to be competitive in this business climate. As a C-level executive it's your job to make sure that you're meeting the business need for agility and that you're able to properly do risk analysis and explain cost/benefit of a public cloud strategy where applicable.
So, I think the CIO, much like the CISO, has a choice to make ... do we make our peace with and adapt to (and embrace) the new model of elastic computing, or do we become irrelevant to the business?
If you have thoughts on the matter, obviously please do ask them with the #ConvCloud hashtag and I or one of the people following will address - we're happy to engage any of you on this absolutely critical topic.
Remember, join us next time - May 3rd at 1:00-2:00pm EDT on the Twitter hashtag #ConvCloud. Don't miss out.