This post is part of a multi-part series about the Securosis Guide to the RSA Conference (download the RSAC-G PDF). Please scroll to the bottom for links to other posts in the series.

To be honest, we are a bit biased on this particular topic. Our day to day work has been shifting to cloud projects for a number of years now, but the jump in terms of pure numbers the past year was pretty astounding. So much so that we are changing our logo to have a pretty little cloud in it, because even Securosis could use a little cloudwashing.

As analysts we've been strong proponents of cloud computing and cloud security, but the projects we've been involved with over the past 12-18 months put the entire industry about 2-3 years ahead of the adoption rates we expected, perhaps more. Every single organization we talk with, even casually, is working on one or more cloud projects. This even includes the kinds of enterprises that typically lag on new technology adoption.

Let's take a look at the different kinds of projects we see, and how you can use the RSA Conference to speed them up.

CASB becomes a Checkbox—We still hate the term "CASB" (Cloud Access and Security Brokers). The truth is, it's a mashup due to some infighting over coverage areas among analysts inside Gartner. We prefer the term Cloud Security Gateways, but we lost that battle faster than an ant in Pamplona.

If you want greater control over the use of Software as a Service (mostly) in your environment, with a smattering of intelligence on PaaS and IaaS, then CASB is the way to go. Last year we thought the market was over-saturated, and we finally saw the first wave of acquisitions clean things up a bit. The CASB tools on the market are all very competitive, making decisions a bit tough at times. 

We suggest you walk in with a list of what tools you already have in house, SaaS platforms you support plus your network security toolkit, and use that as a first pass filter to find compatible products. The needs in this particular market are so consistent and glaringly obvious that it can be tough to really differentiate between the products. They all hit the basics, so take the time to see which one just looks more usable to you. The two areas they seem to be most trying to differentiate on are threat detection/prevention (including workflow), and data security (e.g. better DLP).

There does seem to be a pretty big maturity line. You'll see very quickly which products are above and which are below. Since the market is starting to settle, be really careful going with anyone that looks like they have a ways to catch up. Holding a great pace at mile 12 isn't all that exciting when the winners are already at the beer tent and they are taking down the finish line.

Building New Applications on the Cloud—Most of our hands-on work lately has been helping organizations architect and implement security for "new" cloud applications. Typically these are either completely new applications being designed for, and deployed on, Infrastructure and Platform as a Service, or existing applications that are redesigned from the ground up.

That's our first tip—you can't drop ship an existing application to the cloud without it blowing up in your face. You need to pick a cloud provider, then design a new architecture to leverage the agility, resiliency, and economics of that particular provider. You can design for portability to a point, but fully portable apps cost more, are harder to maintain, and tend to be more fragile.

And the security? it's okay to keep your list of general requirements (e.g. "assess all the vulnerabilities"), but toss out any of the specifics. By far we see more success on both the non-security and security sides if you treat these deployments as total redesigns. The more expectations you allow to limit your choices, the harder it is to get the best results.

This is a situation where the vendor floor won't be much help. Many of them are still clinging to existing deployment and business models, and they can only sell to you if you also stick to the old ways. One quick litmus test is to fund out if their product can deploy in an auto scale group. That doesn't mean you might still not need these tools, but it is certainly a warning sign that you should look at other options first.

There will be a very small group of cloud-first products at the conference. Even if you end up with something more-traditional, we highly suggest you give these folks a listen. They are rarely names you already know, are purpose-built for cloud, and love APIs, workloads, and auto scaling.

The upside is that the cloud and virtualization track is pretty strong this year. Real examples from real organizations managing new cloud projects at enterprise scale. 

Keep in mind, this section is focused on discrete projects, not building out an entire program. Most clients we work with start with one or more projects like this to get their feet wet and adjust their existing controls and processes. It's really a great way to get started, and tends to give you more flexibility since decisions are limited to just that project. This is the chance to play around and get a better sense of what you need as you scale, which takes us to the next section...

Building a Cloud Security Program—There's a big difference between your first few isolated cloud projects and having to support dozens, or hundreds, of deployments and assets. A simplified project-based approach won't hold up, and you need to look to extend your existing security program in ways that don't break the reasons people use the cloud in the first place. 

Yeah, you have to move faster.

The RSAC can, again, be pretty useful. One of the biggest challenges when moving into cloud is harmonizing operations. you can build a few one-offs for projects as you get your feet wet, but once you need to support something at scale you hit an entirely different set of requirements. This is especially true when you need to maintain some consistency between everything you do now, and everything you need to do "up there."

For example, one of the biggest challenges we commonly encounter is cloud auditing and logging, and then ensuring they are compatible with existing logging/auditing and incident response capabilities. Everything from basic tool compatibility to redesigning processes comes into play. RSAC is a good time to both survey your existing product vendors, learn some of the new best practices in sessions, and talk to your peers.

The areas we tend to see consistently come up are logging/auditing, identity management (one of the easier problems) endpoint security agents (your existing ones probably won't work at cloud scale), network security, and vulnerability assessment. Plus overall config/systems management, which has security implications but isn't always managed by security.  

Unless you're a brand new startup extending your security program to the cloud is the very definition of building an aircraft in flight. That's why we really suggest testing things out in the isolated projects, but deeply engaging with those teams so you can build the centralization you need to scale. It isn't easy, but we do see a lot of organizations succeeding. It's your culture, not your tools or vendors, that's the best indicator of how smooth a transition you can expect.

— Rich Mogull

Check out the complete series: Introduction
Theme posts: Threat Intelligence & Bothan Spies, R2DevOps, Escape from Cloud City, The Beginning of the End(point) for the Empire, Training Security Jedi, Attack of the (Analytics) Clones
Deep Dives: All Threats, All the Time..., Data Security Deep Dive, Cloud Security Deep Dive