In our 2013 RSA Guide we wrote that 2012 was a tremendous year for cloud security. We probably should have kept our mouth shut and remembered all those hype cycles, adoption curves, and other wavy lines because 2013 blew it away. That said, cloud security is still quite nascent, and in many ways losing the race with the cloud market itself, expanding the gap between what’s happening in the cloud and what’s actually being secured in the cloud. The next few years are critical for security professionals and vendors as they risk being excluded from cloud transformation projects, and thus find themselves disengaged in enterprise markets as cloud vendors and DevOps take over security functions.
Lead, Follow, or Get the Hell out of the Way
2013 saw cloud computing begin to enter the fringes of the early mainstream. Already in 2014 we see a bloom of cloud projects, even among large enterprises. Multiple large financials are taking tentative steps into public cloud computing. When these traditionally risk-averse technological early adopters put their toes in the water, the canary sings (okay, we know the metaphor should be that the canary dies, but we don’t want to bring you down).
Simultaneously we see cloud providers positioning themselves as a kind of security providers. Amazon makes abundantly clear that they consider security one of their top two priorities, that their data centers are more secure than yours, and that they can wipe out classes of infrastructure vulnerabilities to let you focus on applications and workloads. Cloud storage providers are starting to provide data security well beyond what most enterprises can even dream of implementing (such as tracking all file access, by user and device). In our experience Security has a tiny role in many cloud projects, and rarely in the design of security controls. The same is true for traditional security vendors, who have generally failed to adapt their products to meet new cloud deployment patterns.
We can already see how this will play out at the show, and in the market. There is a growing but still relatively small set of vendors taking advantage of this gap by providing security far better attuned to cloud deployments. These are the folks to look at first if you are involved in a cloud project. One key to check out is their billing model: do they use elastic metered pricing? Can they help secure SaaS or PaaS, like a cloud database? Or is their answer, “Pay the same as always, run our virtual appliance, and route all your network traffic through it.” Sometimes that’s the answer, but not nearly as often as it used to be.
And assess honestly when and where you need security tools, anyway. Cloud applications don’t have the same attack surface as traditional infrastructure. Risks and controls shift; so should your investments. Understand what you get from your provider before you start thinking about spending anywhere else.
SECaaS Your SaaS
We are getting a ton of requests for help with cloud vendor risk assessment (and we are even launching a 1-day workshop), mostly driven by Software as a Service. Most organizations only use one to three Infrastructure as a Service providers, but SaaS usage is exploding. More often than not, individual business units sign up for these services – often without going through procurement process.
A new set of vendors is emerging, to detect usage of SaaS, help integrate it into your environment (predominantly through federated identity management), and add a layer of security. Some of these providers even provide risk ratings, although that is no excuse for not doing your own homework. And while you might think you have a handle on SaaS usage because you block Dropbox and a dozen other services, there are thousands of these things in active use. And, in the words of one risk officer who went around performing assessments: at least one of them is a shared house on the beach with a pile of surfboards out front, an open door, and a few servers in a closet.
There are a dozen or more SaaS security tools now on the market, and most of them will be on the show floor. They offer a nice value proposition but implementation details vary greatly, so make sure whatever you pick meets your needs. Some of you care more about auditing, others about identity, and others about security, and none of them really offer everything yet.
Workload Security Is Coming
“Cloud native” application architectures combine IaaS and SaaS in new highly dynamic models that take advantage of autoscaling, queue services, cloud databases, and automation. They might pass a workload (such as data analysis) to a queue service, which spins up a new compute instance in the current cheapest zone, which completes the work, and then passes back results for storage in a cloud database.
Under these new models – which are in production today – many traditional security controls break. Vulnerability assessment on a server that only lives for an hour? Patching? Network IDS, when there is no actual network to sniff?
Talk to your developers and cloud architects before becoming too enamored with any cloud security tools you see on the show floor. What you buy today may not match your needs in six months. You need to be project driven rather than product driven because you can no longer purchase one computing platform and use it for everything. That is, again, why we think you should focus on elastic pricing that will fit your cloud deployments as they evolve and change. So an elastic pricing model is often the best indicator that your vendor ‘gets’ the cloud.
Barely Legal SECaaS
We are already running long, so suffice it to say there are many more security offerings as cloud services, and a large percentage of them are mature enough to satisfy your needs. The combination of lower operational management costs, subscription pricing, pooled threat intelligence, and other analytics, is often better than what you can deploy and manage completely internally. You still need to ask hard questions and be very careful with technobabble pillow talk, because not all cloud services are created equal. Look for direct answers – especially on how providers protect your data, segregate users, and allow you to get your data back if necessary. Finally, walk away if they want you to sign an NDA first.
Here’s to the Server Huggers
Many of you are considering private clouds, or have one already, to reduce the perceived risks of multitenancy. As we wrote in What CISOs Need to Know about Cloud Computing, we think private clouds are largely a transition technology to make server huggers feel they are still in control. Well, that and to hold us over until there is more competition in the real public cloud market – as opposed to outfits merely offering a different form of hosting.
Most of the private cloud security focus is, rightfully, on network security. The key questions to ask are how it affects your network topology, and how well Software Defined Networking is supported, because this is the first place we see SDN establishing a beachhead. Also understand the costs and hardware requirements of supporting a private cloud. You definitely need something that supports distributed deployments, tightly integrated with the cloud platform.
The Cloudwashing Dead
Finally, we see no shortage of cloudwashing, and expect to see a lot more at the show. Nearly every product will feature a ‘cloud’ version. But by this point you should know what to look for, to determine which are built for cloud, and which are merely the same software wrapped in a virtual appliance or an endpoint/server agent that has barely been modified. Ask for reference clients who have deployed on Azure, Amazon, or Google – not just on one of the many semi-private hosted cloud providers.
Reader interactions
2 Replies to “RSA Conference Guide 2014 Deep Dive: Cloud Security”
There are two main problems with the cloud:
* Controlled access to the data.
* Access to logs.
The first point is that I do not have full control over who has access to my data. Exploits and security breaches is not a part of what I am thinking here, but who has a more or less “legal” access to my data. And if I operate from country A and the data is stored in country B and C—which legal system does apply? And what if the security laws are different and maybe even in conflict with each other? Who, others than me, can authorize access to the data? And under which laws?
The second part is vital for security monitoring: Full access to the logs. Let’s take email as an example here. Most targeted attacks have an email component in them, and access to the email logs are vital for detecting breaches. Will the service provider of my cloud based email give me full access to the logs related to my email accounts? Probably not (I know for sure at least one who don’t give me that).
And how about privacy laws related to the logs? Especially when the user, the one doing security monitoring and the data are in three different countries?
I like the concept about cloud computing, but find it too immature to be used for a production system with high demands around security yet.
Until the problems are solved, they can use name calling, such as “server hugger”, as much as they want, without that affecting my position…
Okay, here are some answers:
1) You *can* control access to your data, and fully manage the country issue. Contact me directly and I can explain how. there are a bunch of techniques to resolve this issue, supported by multiple cloud providers. That really isn’t an issue anymore if you plan appropriately.
2) Depends on the service. SaaS is weakest here, but still often manageable. Partially, you have to trust the provider that below a certain level they will take primary role is discovering breaches (especially for SaaS). I know providers who do this much better than most enterprises. MUCH. In other cases, you *can* get the logs. But it all comes down to understanding where the cloud provider draws the lines, and how that changes your risk profile and security controls. There are a lot of options here to handle nearly every situation.
3) Again, you can control this. You can FULLY control where your data is with most enterprise-class cloud providers. The ones that won’t provide this, will lose.
There are many cloud deployments that are far more secure than what most people run internally. It isn’t a problem with the cloud, but in understanding cloud computing, where the lines are, and how to adjust controls.
These problems have been solved is what I’m trying to say. But they haven’t been solved equally among all providers, so vendor risk assessment and selection is key.