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?
White House Cybersecurity Strategy at a Crossroads
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/17/2018
Mueller Probe Yields Hacking Indictments for 12 Russian Military Officers
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/13/2018
10 Ways to Protect Protocols That Aren't DNS
Curtis Franklin Jr., Senior Editor at Dark Reading,  7/16/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Who were you expecting?  Robin Williams?
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2016-10727
PUBLISHED: 2018-07-20
camel/providers/imapx/camel-imapx-server.c in the IMAPx component in GNOME evolution-data-server before 3.21.2 proceeds with cleartext data containing a password if the client wishes to use STARTTLS but the server will not use STARTTLS, which makes it easier for remote attackers to obtain sensitive ...
CVE-2018-8018
PUBLISHED: 2018-07-20
Apache Ignite 2.5 and earlier serialization mechanism does not have a list of classes allowed for serialization/deserialization, which makes it possible to run arbitrary code when 3-rd party vulnerable classes are present in Ignite classpath. The vulnerability can be exploited if the one sends a spe...
CVE-2018-14415
PUBLISHED: 2018-07-20
An issue was discovered in idreamsoft iCMS before 7.0.10. XSS exists via the fourth and fifth input elements on the admincp.php?app=prop&do=add screen.
CVE-2018-14418
PUBLISHED: 2018-07-20
In Msvod Cms v10, SQL Injection exists via an images/lists?cid= URI.
CVE-2018-14419
PUBLISHED: 2018-07-20
MetInfo 6.0.0 allows XSS via a modified name of the navigation bar on the home page.