Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Who has responsibility for cloud security? A Network World roundtable

John Dix | March 26, 2013
As more organizations leverage the cloud for critical business applications, they are discovering one of the greatest challenges is combining existing internal controls with cloud protection efforts. Highly regulated business and government organizations in particular must maintain comprehensive security and compliance postures across these hybrid systems.

But getting back to the original question about the security pain points in the hybrid cloud, I'd add that sometimes when you're looking at these new reference architectures and developing a new model for the cloud, certain enterprise teams may default to imposing legacy solutions onto a cloud environment, whether it's hybrid or just purely public.

And while everyone wants to use solutions they're familiar with, sometimes these controls do not scale for the cloud. In addition, you need to think about the controls at the appropriate level of abstraction, and consider and frame it in the context of the risk that the control is really addressing or mitigating. So this means understanding what is new and different in the cloud, and implementing a control that is appropriate for the cloud and allows the benefits to be realized.

NW: So my first desire is to extend all my legacy controls to this new environment, but, by the sounds of it, I'll always have to bolster these controls for the cloud.

SUTHERLAND: In this cost-sensitive environment you need to start with reusing existing infrastructure, and there's plenty that can be reused. The point is, just be aware of the nuances and limitations of certain tools.

AMMON: Let's ignore the security controls utilized by the cloud provider below the visibility of the customer, i.e., from the hypervisor to the concrete slab. You are left with three categories of security tools: 1) Tools provided within the cloud such as firewall and VPN; 2) Existing enterprise security tools which operate no different within a cloud environment; and 3) Additional security tools necessary to manage the unique environment presented by the cloud. Here are two examples of new requirements for cloud security tools: First, due to the nature of cloud elasticity, these tools must accommodate an auto-scaling architecture and be able to automatically discover new systems and apply policies. And second is the challenge presented by the advent of the all-powerful cloud API layer. Within the API layer users are implementing the practice of auto configuration ... basically machines building machines. That requires a new security paradigm to manage the unique challenge to auditing and controlling automated machine-to-machine privileged access. This will certainly require new cloud-specific security technology.

NW: Is it different when you're talking about SaaS in particular? Do you just have to take what they give you?

ROTHMAN: Where we've seen a lot of SaaS players open things up a bit is in the area of identity. So instead of having to manage all of these different authoritative sources and user lists, you can get around it through the magic of federation (some suppliers support standards like SAML to provide specific assertions and integration) so you don't have to use the SaaS players' identity model.

 

Previous Page  1  2  3  4  5  6  7  8  Next Page 

Sign up for MIS Asia eNewsletters.