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?
5 Reasons the Cybersecurity Labor Shortfall Won't End Soon
Steve Morgan, Founder & CEO, Cybersecurity Ventures,  12/11/2017
BlueBorne Attack Highlights Flaws in Linux, IoT Security
Kelly Sheridan, Associate Editor, Dark Reading,  12/14/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
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.