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

9/14/2017
02:00 PM
Ben Johnson
Ben Johnson
Commentary
Connect Directly
Twitter
RSS
50%
50%

Cloud Security's Shared Responsibility Is Foggy

Security is a two-way street. The cloud provider isn't the only one that must take precautions.

The slew of data leakage incidents involving Amazon Web Services this summer made for good headlines, but what should security professionals learn from them? Despite the good work by the UpGuard researchers who discovered unsecured AWS S3 buckets, it's hard to say whether malicious actors have found the sensitive data or not. It's not unreasonable to assume, however, that with all the headlines, the black hats of the world already have written the equivalent of search engines to automatically find more of these hidden data treasure troves, increasing the potential damage of future leaks.

With this in mind, it's important to take a step back and remember cloud providers' shared responsibility models. In the case of AWS, AWS is responsible for the security of the underlying cloud infrastructure, but you're responsible for the data and systems on top of that infrastructure. Although this may seem clear-cut, it's not, and the nuances of the model are important to understand.

Most cloud security incidents result from a combination of misconfigurations or inadequate protections put in place by the enterprise, and too much complexity or a lack of inherent security policies by the software, hardware, or service provider. In the case of the recent AWS data leaks, both the cloud providers and their customers should reflect on how they contributed to each incident, and how they can do better going forward.

The Enterprise Side
Enterprises need to better understand the risks of the cloud. Availability and uptime are important benefits, but they don't necessarily mean data is "only available to me." Data also can be available to the bad guys if enterprises don't get the configurations right. A lot of cloud providers aren't managing enterprises' data. They're just providing an infrastructure, so the management (and protection) of data is the responsibility of the enterprises themselves. What's more, enterprises need to make sure they are maintaining access control lists properly, performing quality assurance on configurations and policies, and auditing who has access to what.

The Cloud Provider Side
This isn't an Amazon-only issue, but with Amazon dominating the market, it will certainly receive most of the breach headlines. Microsoft, Google, and every other cloud provider that allows enterprises to utilize storage systems and apply security policies will find themselves in similar situations when users incorrectly configure their protections. While cloud data leaks may not be the providers' fault, part of their shared responsibility should be to make it easier for enterprises to get the configurations right. Some providers will employ technologies like machine learning to identify anomalies in security policy, making it more difficult for enterprises to get into a vulnerable configuration.

In the case of AWS, the company should recognize the need to make the system smarter. (Its announcement of Amazon Macie demonstrated it's doing so.) For example, it should perform a sanity check for situations that are unlikely, such as exposing huge swaths of data or permissions that allow anyone to read data. It also needs to have simpler workflows. AWS is the standard, but, as with most things, the selling points for CIOs always seem to come before the selling points for CISOs, so security is a second-class citizen to flexibility and availability. When there is flexibility in creating policies and rules, there's complexity — and when there's complexity, there's risk and vulnerability.

In the end, Amazon needs to do more, but the issue goes back to the challenges faced by the enterprise: too many security controls make it harder to install, configure, deploy, and monitor its services and apps, and too few security controls leads to risk and vulnerability. Amazon must take a stronger look at what security is built-in, but it will always be first and foremost the responsibility of AWS customers to make sure their systems and data are appropriately protected. After all, it's not AWS's data that may get stolen. It's the enterprise that is really at risk.

We more than likely haven't seen the last of the cloud data leaks. Each one will offer its own lessons, but operating within the shared responsibility model, and understanding its nuances will ensure that enterprises can manage this risk with confidence. Outsourcing computing power and storage doesn't mean your security is outsourced, so you're still on the hook for protecting any sensitive data that you place in the cloud.

Related Content:

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.

Ben Johnson is CTO and co-founder of Obsidian Security. Prior to founding Obsidian, he co-founded Carbon Black and most recently served as the company's chief security strategist. As the company's original CTO, he led efforts to create the powerful capabilities that helped ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
dimitri-dr
50%
50%
dimitri-dr,
User Rank: Author
9/18/2017 | 2:59:26 PM
Re: Amazon Security
Shared security responsibility is like playing 3D-Chess. 
obsidianben
50%
50%
obsidianben,
User Rank: Apprentice
9/18/2017 | 2:24:25 PM
Re: Amazon Security
HMAC is related to encryption (https://en.wikipedia.org/wiki/Hash-based_message_authentication_code).

Encryption in transit is usually preferred, although it is more nuanced than that. Sometimes the services or the use of the data being transmitted means that encryption adds too much processing or latency to the operations, and therefore the distributed system would have to be segmented off or have other controls in place to avoid needing encryption. Aside from that, when in doubt, encrypt!
jenshadus
50%
50%
jenshadus,
User Rank: Strategist
9/18/2017 | 12:36:38 PM
Amazon Security
I agree that AMazon needs to streamline their security, and simplify instructions.  I was just reviewing one of our security configurations, and I was scratching my head a couple of time.  They use abbreviations that I don't know such as HMAC...whats that/  Hidden MAC addresses? MAC security? What about encryption in transit?
7 Tips for Infosec Pros Considering A Lateral Career Move
Kelly Sheridan, Staff Editor, Dark Reading,  1/21/2020
For Mismanaged SOCs, The Price Is Not Right
Kelly Sheridan, Staff Editor, Dark Reading,  1/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
IT 2020: A Look Ahead
Are you ready for the critical changes that will occur in 2020? We've compiled editor insights from the best of our network (Dark Reading, Data Center Knowledge, InformationWeek, ITPro Today and Network Computing) to deliver to you a look at the trends, technologies, and threats that are emerging in the coming year. Download it today!
Flash Poll
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-3154
PUBLISHED: 2020-01-27
CRLF injection vulnerability in Zend\Mail (Zend_Mail) in Zend Framework before 1.12.12, 2.x before 2.3.8, and 2.4.x before 2.4.1 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via CRLF sequences in the header of an email.
CVE-2019-17190
PUBLISHED: 2020-01-27
A Local Privilege Escalation issue was discovered in Avast Secure Browser 76.0.1659.101. The vulnerability is due to an insecure ACL set by the AvastBrowserUpdate.exe (which is running as NT AUTHORITY\SYSTEM) when AvastSecureBrowser.exe checks for new updates. When the update check is triggered, the...
CVE-2014-8161
PUBLISHED: 2020-01-27
PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to obtain sensitive column values by triggering constraint violation and then reading the error message.
CVE-2014-9481
PUBLISHED: 2020-01-27
The Scribunto extension for MediaWiki allows remote attackers to obtain the rollback token and possibly other sensitive information via a crafted module, related to unstripping special page HTML.
CVE-2015-0241
PUBLISHED: 2020-01-27
The to_char function in PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to cause a denial of service (crash) or possibly execute arbitrary code via a (1) large number of digits when processing a numeric ...