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?
A Realistic Threat Model for the Masses
Lysa Myers, Security Researcher, ESET,  10/9/2019
USB Drive Security Still Lags
Dark Reading Staff 10/9/2019
Virginia a Hot Spot For Cybersecurity Jobs
Jai Vijayan, Contributing Writer,  10/9/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-14832
PUBLISHED: 2019-10-15
A flaw was found in the Keycloak REST API before version 8.0.0 where it would permit user access from a realm the user was not configured. An authenticated attacker with knowledge of a user id could use this flaw to access unauthorized information or to carry out further attacks.
CVE-2017-10022
PUBLISHED: 2019-10-15
In haml versions prior to version 5.0.0.beta.2, when using user input to perform tasks on the server, characters like < > " ' must be escaped properly. In this case, the ' character was missed. An attacker can manipulate the input to introduce additional attributes, potentially executing ...
CVE-2019-10759
PUBLISHED: 2019-10-15
safer-eval before 1.3.4 are vulnerable to Arbitrary Code Execution. A payload using constructor properties can escape the sandbox and execute arbitrary code.
CVE-2019-10760
PUBLISHED: 2019-10-15
safer-eval before 1.3.2 are vulnerable to Arbitrary Code Execution. A payload using constructor properties can escape the sandbox and execute arbitrary code.
CVE-2019-17397
PUBLISHED: 2019-10-15
In the DoorDash application through 11.5.2 for Android, the username and password are stored in the log during authentication, and may be available to attackers via logcat.