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
High Stress Levels Impacting CISOs Physically, Mentally
Jai Vijayan, Freelance writer,  2/14/2019
Valentine's Emails Laced with Gandcrab Ransomware
Kelly Sheridan, Staff Editor, Dark Reading,  2/14/2019
Making the Case for a Cybersecurity Moon Shot
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  2/19/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-8980
PUBLISHED: 2019-02-21
A memory leak in the kernel_read_file function in fs/exec.c in the Linux kernel through 4.20.11 allows attackers to cause a denial of service (memory consumption) by triggering vfs_read failures.
CVE-2019-8979
PUBLISHED: 2019-02-21
Koseven through 3.3.9, and Kohana through 3.3.6, has SQL Injection when the order_by() parameter can be controlled.
CVE-2013-7469
PUBLISHED: 2019-02-21
Seafile through 6.2.11 always uses the same Initialization Vector (IV) with Cipher Block Chaining (CBC) Mode to encrypt private data, making it easier to conduct chosen-plaintext attacks or dictionary attacks.
CVE-2018-20146
PUBLISHED: 2019-02-21
An issue was discovered in Liquidware ProfileUnity before 6.8.0 with Liquidware FlexApp before 6.8.0. A local user could obtain administrator rights, as demonstrated by use of PowerShell.
CVE-2019-5727
PUBLISHED: 2019-02-21
Splunk Web in Splunk Enterprise 6.5.x before 6.5.5, 6.4.x before 6.4.9, 6.3.x before 6.3.12, 6.2.x before 6.2.14, 6.1.x before 6.1.14, and 6.0.x before 6.0.15 and Splunk Light before 6.6.0 has Persistent XSS, aka SPL-138827.