Cloud
6/8/2015
08:00 AM
Connect Directly
Twitter
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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
5 Reasons the Cybersecurity Labor Shortfall Won't End Soon
Steve Morgan, Founder & CEO, Cybersecurity Ventures,  12/11/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Gee, these virtual reality goggles work great!!! 
Current Issue
The Year in Security: 2017
A look at the biggest news stories (so far) of 2017 that shaped the cybersecurity landscape -- from Russian hacking, ransomware's coming-out party, and voting machine vulnerabilities to the massive data breach of credit-monitoring firm Equifax.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.