Partner Perspectives  Connecting marketers to our tech communities.
SPONSORED BY
6/20/2017
11:00 AM
Tim Prendergast
Tim Prendergast
Partner Perspectives
Connect Directly
Twitter
LinkedIn
RSS
50%
50%

Cloud Security & the Power of Shared Responsibility

When you and your CSP jointly embrace the shared security responsibility model you can achieve greater success than you or your provider can achieve alone.

When you're a toddler, you think the world revolves around you, and your personal constitution has one word in it: "mine!" As you grow and develop some wisdom, you recognize that the world is complex, there are systems governing everything, and without the ability to share, you're likely destined to a lonely, off-the-grid existence in a van down by the river.

The cloud, itself, is a great example of the power of what sharing can provide. You have data, and you want to transact with that data. But a cloud provider owns the means by which you can do those things, so there has to be an agreement about responsibility – that is how, when, and where it can happen. It’s all dependent upon the two parties agreeing to specific responsibilities. Because it's shared responsibility, there also has to be a security model that ensures that the security of your data, transactions, and operations is being handled adequately within this framework.

For enterprises using public cloud infrastructures like Amazon Web Services (AWS) or Microsoft Azure, that shared responsibility is critical to getting any benefit from these incredibly innovative and lucrative compute platforms. Each Cloud Service Provider (CSP) makes very clear what it is they will secure, and what the expectations are for customers. This codified model helps customers prepare to provide the resources and acquire the necessary tools to monitor and fix security issues as they come into their purview.

For public cloud customers, there's something very easy about adhering to the shared model, because the rules of assigning and managing governance is quite apparent from the onset. In fact, Amazon makes it very clear, as evidenced by this statement from the AWS security page: "AWS has secured the underlying infrastructure and you must secure anything you put on the infrastructure." 

Breaking it down, this means that the CSP will maintain the strong security and compliance controls across their entire infrastructure platform for things like datacenter, core network/hardware, operational security practices like data disposal and change control, and others. Your job is to manage anything you manipulate on their platform.

Let's say you want to launch some scalable compute services like EC2 or Azure Virtual Machines. According to the shared responsibility model, you’re on the hook for the security groups, patching of the servers, application-level security, and anything else related to how you use/manage the virtualized servers you created.

Perhaps you're creating objects in a storage service like Amazon S3 or Azure Storage. You, as the customer, will need to manage the encryption status of those files, access policies, geographic containment, and all other aspects of data security and integrity.

With each and every service you can engage in the public cloud, there is a strong suite of security controls that are available to you. The CSPs give you hundreds of ways to configure and misconfigure your infrastructure. You have to ensure you are using them effectively and consistently.

What's compelling about this approach is that when you and your CSP jointly embrace the shared security responsibility model you can achieve greater security success than you or your provider can achieve alone. When a single party tries to deliver comprehensive security throughout an environment, the workload often overwhelms the engaged teams, especially at a time when the surface area your infrastructure touches is growing larger. This stems from the limitation of security resources that any single entity can experience; few organizations have enough security staff and resources to achieve all key project goals PLUS continuous deep security engagement of every environment.

This means any single entity cannot achieve total security nirvana because technical inertia or some impediment prevents it. However, if you partition the responsibility for security, the workload is divided between you and your CSP, not to mention their entire customer base.

This puts market forces to work. If you have a million customers each with one security professional, you now have a million security professionals working to secure a subset of your platform’s resources. This force multiplier is powerful, and is part of the reason cloud platforms like AWS and Azure are some of the most secure compute platforms created to date.

Tim Prendergast co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level.  After years of building, operating, and securing services in Amazon Web Services, he set out to make security approachable and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Microsoft President: Governments Must Cooperate on Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/8/2018
5 Reasons Why Threat Intelligence Doesn't Work
Jonathan Zhang, CEO/Founder of WhoisXML API and TIP,  11/7/2018
Why Password Management and Security Strategies Fall Short
Steve Zurier, Freelance Writer,  11/7/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-16470
PUBLISHED: 2018-11-13
There is a possible DoS vulnerability in the multipart parser in Rack before 2.0.6. Specially crafted requests can cause the multipart parser to enter a pathological state, causing the parser to use CPU resources disproportionate to the request size.
CVE-2018-16471
PUBLISHED: 2018-11-13
There is a possible XSS vulnerability in Rack before 2.0.6 and 1.6.11. Carefully crafted requests can impact the data returned by the `scheme` method on `Rack::Request`. Applications that expect the scheme to be limited to 'http' or 'https' and do not escape the return value could be vulnerable to a...
CVE-2018-6980
PUBLISHED: 2018-11-13
VMware vRealize Log Insight (4.7.x before 4.7.1 and 4.6.x before 4.6.2) contains a vulnerability due to improper authorization in the user registration method. Successful exploitation of this issue may allow Admin users with view only permission to perform certain administrative functions which they...
CVE-2018-17614
PUBLISHED: 2018-11-13
This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Losant Arduino MQTT Client prior to V2.7. User interaction is not required to exploit this vulnerability. The specific flaw exists within the parsing of MQTT PUBLISH packets. The issue results from th...
CVE-2018-8009
PUBLISHED: 2018-11-13
Apache Hadoop 3.1.0, 3.0.0-alpha to 3.0.2, 2.9.0 to 2.9.1, 2.8.0 to 2.8.4, 2.0.0-alpha to 2.7.6, 0.23.0 to 0.23.11 is exploitable via the zip slip vulnerability in places that accept a zip file.