Shared Responsibility A Key To Effective Cloud Security

As enterprises seek to expand their systems out in the public cloud, it is critical to find cloud service providers that can offer a strong commitment to infrastructure security—preferably with SLAs to back it up. But it is also important to understand that even the most secure cloud providers can only go so far toward protecting enterprise applications and assets out on the cloud. At the end of the day, cloud security follows a shared responsibility model.

"Security in the cloud is a shared responsibility. The cloud service provider is responsible for the security of the infrastructure and the customer of the cloud service provider is responsible for security of the application or service running on top of the infrastructure," Praveen Rangnath, senior director of cloud product marketing at Splunk. "However, there is overlap in that cloud service providers must provide real-time data and metrics to enable their customers to gain real-time visibility into their security posture."

DarkReading recently caught up with Mark Carrizosa to talk shared responsibility. With 15 years of security experience, most recently Carrizosa worked at Walmart as principle security architect for the retailer's e-commerce platform. This week he moved to the vendor side of the house to start work as vice president of security for cloud DMZ service provider Soha. He took the time to discuss some of the lessons he learned in his former role as a security practitioner.

DR: Do you think that people at this point understand what their security responsibilities are when shifting to the cloud, or does there still need to be awareness as to how the shared responsibility model works?

Carrizosa: There absolutely needs to be increased awareness with this.  Going into AWS or into these cloud hosting providers, yes there may be some contractual obligations that are buried down in some legal document that says, “You share this or we share the responsibility for security: here’s your half, here’s our half.”

But I think with the migration from on-premise to cloud, companies have been jumping in wholeheartedly -- some with their eyes open, some blindly -- to try to take advantage of these cloud benefits. But I think what we need to do is take a step back and ensure that organizations really understand what their responsibilities are in terms of securing their applications, and where that line is drawn so they can be sure that before they move into these environments that they’re doing their due diligence. They need to ensure that through no fault of their own their organizations don't fail to adopt a more robust security model.

DR: What are some of the challenges and some of the best practices around shared responsibility that you've run into as an architect?

Carrizosa: In my experience there’s a lot of different security controls that are required to operate effectively up and down the application and infrastructure stack.

In this shared responsibility model, these organizations like AWS and Azure have this model where they will take care of the infrastructure components while we take care of the application side of the house. And you end up with this collaboration of security effectiveness that is essentially supposed to make up for that security up and down the stack.

However, there are tools that could be used for application-type security for securing environments, but oftentimes they need to be pieced together or architected in a manner that fits all of these different disparate solutions like firewalls, IPS’s, WAF, application delivery controllers. And in a cloud-based environment, moving quickly utilizing those controls is not always easy to do.

You may be able to add some items in there, but the key point here is that you then have to manage all of these systems and monitor these systems disparately.

The driving factor here is finding a way to be able to get as much value from a single pane of glass to basically shed light on your environment and what’s going on and how you’re protecting it. To have to go through dashboard after UI after report to correlate all this information is a detriment to security because it takes time to identify this information.

And in addition, it’s not necessarily dealing with one cloud but what if the organization wants to prevent vendor lock-in and move into multiple clouds?  Maybe some of them are on-prem, some of them are in Azure, some of them are in AWS, Rackspace, or  whatnot. You have to figure how to have a clear vision of all of these environments together to make security decisions properly.

DR: What would you say is the number one problem that hasn’t been solved yet today?  What are some of the pieces of the puzzle that aren’t there yet?

Carrizosa: From my perspective going into a DevOps world, you have all of these functions are joined into single teams for better agility and for a better experience throughout the application. Traditionally you had multiple teams handling multiple responsibilities – such as development, change management, QA, or operational support – nowadays you get these segregation of duty issues with these single teams managing the entire stack of the application or the infrastructure. Those types of issues are being brought to life more often because you end up with possible bugs or you may end up with an individual who has access to do anything and everything without so much as a good sense of governance throughout the entire process.

It’s not perfect: it’s a developing effort. But I think one of the big keys that should be addressed very soon is how do we ensure that these single teams who operate throughout multiple responsibilities do so with the proper checks and balances throughout the process to ensure that applications and environments are secure from the jump as opposed to having security bolted on at the end as a stage gate and possibly hindering delivery.