Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

6/8/2015
08:00 AM
Connect Directly
Twitter
RSS
E-Mail
100%
0%

Shared Responsibility A Key To Effective Cloud Security

Former Walmart security architect talks shared responsibility in the cloud and the reason security architecture needs to change in cloud environments.

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.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.