Rational Survivability

I’ve said it before and I’ll say it again: SaaS is not the definition of Cloud Computing.  It’s one element of Cloud Computing.  In the same vein, when you mention “Cloud Security,” it means more than the security features integrated by a SaaS provider to protect their stack.  Oh, it’s an interesting discussion point, but Google and SalesForce.com are not the end-all, be-all of “Cloud Security.”  Unfortunately, they are the face of Cloud Security these days.  Read on as I explain why.

Almost every webinar, presentation and panel I’ve seen in the last six months that promises to discuss “Security Services in the Cloud” usually ends up actually focused on three things:

1. Managed security services (on-premises or off-premises) of traditional security capabilities/solutions, re-branded as Cloud offerings and
2. Managed services utilizing a SaaS model for one or more security functions, re-branded as Cloud offerings
3. A hybrid model involving both managed services of devices/policies and one or more hosted applications (nee SaaS) re-branded as Cloud offerings

Let’s take a look at what these use cases really mean within the context of Cloud Computing.

Managed security services (on-premises or off-premises) of traditional security capabilities/solutions:
Basically, these services are the same old managed services you’ve seen forever with the word “Cloud” stuck somewhere in the description for marketing purposes.
An example is a provider has NOCs/SOCs and manages security infrastructure on your behalf.  This equipment and software can be located on your premises or externally
and because it’s Internet connected, it’s now magically Cloud based.  These services have nothing to do with protecting Cloud-based services, but rather they suggest that
they *use* the Cloud to deliver service.

Managed security services utilizing a SaaS model for one or more security functions:
Any managed services provider who uses a SaaS stack to process information on behalf of their customers via the Internet is re-branding to say they are Cloud based.
The same is true from a security perspective.  Anti-spam, anti-virus, DDoS, URL filtering services, vulnerability management,  etc. are all game. From Google’s Postini
to OpenDNS’ services to Qualys’ vulnerability management, we’re seeing the rampant use of Cloud in these marketing efforts.  Further, vendors who offer
some sort of Cloud-based service that has integrated security functionality (as it should) claim to offer “Cloud Security.”  In all of these cases, scaling is traditionally
done at the software layer and is generally hidden from the customer and how the service scales isn’t usually based on Cloud Computing capabilities at all.

The Hybrid Model
Some providers offer a combination of managed on/off-premise security devices used in conjunction with SaaS offerings to broaden the solution.  There are any number
of MSSP’s who have an Internet-based portal (via VPN) and an on- or off-premise set of capabilities involving appliances and SaaS to deliver some combination of service.
This model can extend to fixed or mobile computing services where things like Clean Pipes are provided.

The challenge is trying to understand how, where and why the word “Cloud” ought to be applied to these services.  Now I want to be clear that there’s nothing particularly “wrong” with branding these services as “Cloud” except for the following:

If you look at the definition of Cloud (at least mine,) it involves the following:

• Abstraction of Infrastructure
• Resource Democratization
• Services Oriented
• Elasticity/Dynamism
• Utility Model Of Consumption & Allocation

In the case of security solutions which are generally based on static allocation of resources, static policies, application controls built into an application and in many cases dedicated physical appliances (or fixed-utilization shared virtualized instances,) customers can’t log into a control panel and spin up another firewall, IDP or WAF on-demand. In some cases, they don’t even know these resources exist.  Some might argue that is a good thing.  I’m not debating the efficacy of these solutions, but rather how they are put forward.

Also important is that customers don’t get to pay for only the resources used for the same reasons.

So whilst many services/solutions may virtualize the network stack or even policy, the abstraction of infrastructure from resources and resource democratization get a little fuzzy definitionally.  That’s a minor point, really.

What’s really interesting is the two items I highlighted in boldfaced: Elasticity and the utility model of consumption and allocation.  Traditional security capabilities such as firewalls, IDP, A/V, etc. are generally implemented on physical appliances/networking equipment which from a provisioning and orchestration perspective don’t really subscribe to either the notion of self-administered elasticity or the utility model of consumption/allocation whereby the customer is charged only for what they use.

To me, if your Cloud Security solution does not provide for all of these definitional elements of Cloud, it’s intellectually dishonest (the definition of marketing? 😉 to call it “Cloud Security.”

This is important because “security” is being thought of from the perspective of SaaS or IaaS and each of these models have divergent provisioning, orchestration and management methods that don’t really jive with multi-tenant Cloud models for security.*  As it turns out, the most visible and vocal providers of application services are really the ones peddling “secure cloud” to serve their own messaging needs and so in SaaS stacks, the bundled security integrated into the application is usually a no-cost item.  In other models, it *is* the service that one pays for.

I’ve talked about this quite a bit in my Frogs presentation in which I demonstrate how the lower down the stack provider stops (from SaaS down to Iaas,) the more security a customer is generally still responsible for — or that of a provider.  Much of this is due to the lack of scale in security technology today and static policies with a network disconnected from context and state and unaware of the dynamism of the layers above it:

Without invoking the grumpy-magic-anachronism-damage +4 spell, I am compelled to mention the following.

Back in 1995 I architected one of the world’s first global managed security services using a combination of multi-layered VPNs from across the globe to a set of four regional Internet gateways through which all Internet traffic was tunneled. We manually scaled each set of dedicated clustered firewalls for each customer based on load.  We didn’t even have centralized management for all these firewalls at the time (Provider-1 and VSX weren’t born yet — we helped in their birth) so everything was pretty much a manual process.  This was better than managing CPE devices and allowed us to add features/functions centrally…you know, like the “Cloud.” 😉

Not much has changed with managed security services and their models today.  While they have better centralized management, virtualized policy and even container-based virtual security functions, but we’re still stuck with mostly manually provisioning and a complete disconnect of the security policies from the network and virtualization layers.  Scale is not dynamic.  Neither is pricing.

At the end of the day, from a managed security perspective, be wary of claims of “Cloud Security” and what it means to you.

/Hoff

*This is one of the compelling elements of converged/unified compute fabrics; the ability to tie all the elements together and focus on consistent policy enforcement up and down the stack but for managed security providers, this will take years to make its way into their networks as the revenue models and cost structures for most MSSP’s are simply not aligned with virtualization platform providers.  Perhaps we’ll see a bigger uptake of OSS virtualization platforms in order to deliver these converged services.