We’ve made it to the final post of the series “Will The Real CSPs Please Stand Up?” If you haven’t read the first three entries you can find them here, here, and here.
In this last post I continue where I left off with where the carriers fall short and what could
The challenge is that there is no one single definition of what secure means. An underlying and unwritten assumption in the NIST and CSA definitions is that the cloud service provider must be flexible enough and mature enough in their own processes to meet the security requirements and expectations of their customers regardless of what those expectations might be.
That means that service providers have to be prepared to in essence be "all things to all people".
This sounds reasonable on its face. After all companies have been deploying dedicated systems and services for different customers for years. But the multi-tenant nature of the cloud makes for some interesting conversations around the system architect's table.
Let's say you want to support only a couple of vertical markets and each of them have their own set of requirements, constraints, expectations, governing laws, etc.
Focusing just on compliance frameworks for a minute we get things like ISO17799, ISO27001, GLBA, HIPAA, PCI, SOX, SAS 70, and on and on.
NIST has decided that a way to meet the requirements for disparate cloud customers is in deployment models; namely public, private, hybrid, and community. Implementation of a given deployment model should allow the carriers to actually be successful at deploying clouds that meet the disparate requirements of their potential customers. For instance a carrier might deploy a completely private cloud to support a set of government customers, as well as a community cloud to support a segment of their non-government customer space such as colleges and universities. Each of those deployed clouds would have its own set of security controls in place to meet the relevant requirements. One thing to keep in mind is that, while it might not be EASY to comply with some of the compliance frameworks or federal regulations, at least they're known entities with a relatively finite set of controls.
Even more interesting is when customers throw their custom requirements in the mix. Let's say for example that Customer A has a password complexity policy of alphanumeric, >6, to be changed every 90 days. While another Customer with a similar profile, meaning that they will likely be placed on the same cloud, has a password complexity policy of alphanumeric plus special character, > 8, to be changed every 30 days. The cloud will have to be able to expose services to support each of those customer requirements. Sounds easy enough until you get 10, or 100s, or 1000s, of customers.
Let me ask it this way. How many of you have networks with a mix of Windows, Macintosh, Linux, whatever, desktops and servers? Pretty much everyone. How easy is it to enforce a single policy on all of those systems? Not very. And that's just across operating systems in a single enterprise. Now imagine you have a 1000 enterprises and throw in applications on top of that.
How long have we been talking about Single Sign-On? According to a guy named John Haggard who presented at the Single Sign-On Summit in 2008, the idea has been around since at least 1982 with the concept of "Logonid Inheritance".
Don't forget, also, that a service provider already has an internal infrastructure to support that is made up of networks, services, end-user systems, applications, data, support personnel, etc. and yes each with their own set of security controls and requirements
What is a service provider to do? Do they leverage their existing infrastructure and personnel and just absorb the extra work? Or do they build another ecosystem complete with dedicated systems, networks, hardware, applications, personnel, etc. and try to separate out the duties? How many parallel teams, ecosystems, too lchains, etc. can one company support?
Think about it. In a typical enterprise you might have a network or two, a set of servers, some databases, etc. All of those systems have differing threat profiles and risk factors and a mature organization will address each one individually. In a service provider market that problem space is exponentially more complex.
It all sounds very daunting. And unfortunately it doesn't stop there. There is a class of thinking that has been known to propagate through the carrier space and I think that if not taken very seriously and dealt with it could be the coup de grace for the carriers as cloud service providers.
I'm sure you've heard the term "not invented here". It encompasses the idea that it's better to build something oneself than to use something someone else developed. I know for a fact that there are people at the carriers that are guilty of that sort of thinking, just like there are at virtually every company. Add to that the fact that the carriers have been dominant players in their preferred market spaces for a long time and a sense of "if we're not doing it it must not be important" tends to set in.
That thinking is changing. There have been some pretty well-publicized acquisitions in the last few years and most of the carriers have a "cloud offering" of some form or another or are rolling one out in the near future.
So I do think we're starting to see at least some of them get a clue
I don't think it's enough though. My unsolicited advice to the carriers is to look around at what's going on in the industry today. Look at the niche players. The ones that are focusing on a particular aspect of the cloud's constituent parts. These companies might be small compared to the market valuation of the carriers but a lot of them have cracked some pretty hard problems.
There are companies that have cracked the problem of scale with distributed systems, mesh networks, what have you.
There are companies that have cracked the problem of ease of use and consumption with the use of APIs.
There are companies that are beginning to do serious work on automating cloud resources and modifying configurations and provisioning based on load or some other "intelligent" metrics.
There are even companies like the one I work for that have cracked at least parts of the security problem in ways that have never been seen before.
What I'm saying is that if the real CSPs would stand up and be willing to Partner Partner Partner; if they can get out of their own way and leverage existing technologies and innovations without feeling like they have to invent or outright own it themselves or modify it so much that it becomes unrecognizable, an actual, usable, functioning cloud that meets all the NIST prerequisites might just be possible today.
Will there still be challenges if the carriers start actively partnering? Yes of course.
Integration, look and feel, information sharing, changing regulation and compliance requirements and on and on. There are always problems when one is trying to change the world. But I have no doubt that, like Microsoft entering the browser wars back in the 90s, once the carriers figure out how to get out of their own way and truly engage, they will be a force to be reckoned with.
And finally, just to give you, my intrepid readers, a little perspective on something else that makes the carriers such strong potential “cloud killers”, just keep the following in mind.
The 2012 figures for Amazon.com, Amazon Web Services parent company, puts their revenue at somewhere around $61 Billion (Amazon Web Services revenue is not broken out separately but industry analysts estimate around $3.8 Billion for 2013) which is upwards of TEN TIMES the revenue of the next closest competitor Rackspace.
Why do I call these numbers out? Because, given that AT&T’s and Verizon’s 2012 revenues were $127 Billion and $115.8 Billion respectively, it should be obvious that there are some sleeping giants. Right now they’re asleep or clumsy or both but there’s no guarantee that that won’t change.
So, in anticipation of that day I only have one question to ask. Have you hugged your telco today?
Thanks for reading.
Joe can be reached in the comments section below, via email at jdk at calibersecurity dot com or on twitter @joeknape.