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 Security

// // //

Cloud Security Is a Shared Responsibility

In the answer to a question from a recent webinar, editor Curtis Franklin looks at who's responsible for data security in the cloud.

Here at Security Now, webinars are interactive affairs. In our most recent webinar, we had some great questions, including a couple that we couldn't answer in the time allowed. Here's the first of the questions along with our answer for everyone in the community to see.

In our Look Forward to CyberSecurity in 2018, Gary asked:

If we are going to move more critical applications and the data accessed, produced and stored -- will encryption capabilities become critical? And would anyone really outsource this function to AWS? Many people think AWS and Azure are taking responsibility for your apps and data when you move them to the cloud -- are they really going to "add this" via their service offerings?

The question of who takes responsibility for your applications and data is a critical issue when moving to a cloud infrastructure. Cloud providers have tried to bring some discipline to the question of who's responsible for what through the shared responsibility model of security. Stated most succinctly, this states that the cloud provider is responsible for the security of the cloud infrastructure (including the services and applications they're contracted to provide) while the customer is responsible for the security of the data that runs through the infrastructure.

Amazon was the first major cloud provider to publish a formal statement of their policy on AWS. Their language draws a distinction between the security of the cloud and the security of what's in the cloud. It's a useful distinction that helps clarify the pieces that fall under each definition.

Image: Amazon AWS
Image: Amazon AWS

Of course, Amazon has not been alone in drawing the distinction: Microsoft has also released information on the shared security model as applied to Azure. Google also has a paper explaining their security model, though it goes into more detail on the tools they provide to help customers with their responsibilities.

When you strip away all the explanations and jargon, the lesson to be learned in all of these papers and posts is that going to the cloud doesn't mean that you can forget about security. No cloud provider is stepping up to assume responsibility for your data's security -- that's still your job.

The fact that it's your job means that you may need to bring new tools and strategies to bear on data that no longer lives within the cozy confines of your network boundary. These tools, which range from micro-segmentation to CASB, should be deployed in consultation with your cloud provider so that you're certain neither of you is stepping on the other's toes in the name of security.

If you're interested in the other questions and answers from the webinar, as well as the editors' takes on the stories we're likely to be talking about in 2018, it's not too late to listen to the webinar. You've got time to ask your own questions, too -- just leave them as comments to this article or the next article answering questions from the event. And keep your eyes open for our next editorial webinar, coming to Security Now in January 2018!

Related posts:

— Curtis Franklin is the editor of SecurityNow.com. Follow him on Twitter @kg4gwa.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Machine Learning, AI & Deep Learning Improve Cybersecurity
Machine intelligence is influencing all aspects of cybersecurity. Organizations are implementing AI-based security to analyze event data using ML models that identify attack patterns and increase automation. Before security teams can take advantage of AI and ML tools, they need to know what is possible. This report covers: -How to assess the vendor's AI/ML claims -Defining success criteria for AI/ML implementations -Challenges when implementing AI
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2022-2529
PUBLISHED: 2022-09-30
sflow decode package does not employ sufficient packet sanitisation which can lead to a denial of service attack. Attackers can craft malformed packets causing the process to consume large amounts of memory resulting in a denial of service.
CVE-2022-2922
PUBLISHED: 2022-09-30
Relative Path Traversal in GitHub repository dnnsoftware/dnn.platform prior to 9.11.0.
CVE-2022-41849
PUBLISHED: 2022-09-30
drivers/video/fbdev/smscufx.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free if a physically proximate attacker removes a USB device while calling open(), aka a race condition between ufx_ops_open and ufx_usb_disconnect.
CVE-2022-41850
PUBLISHED: 2022-09-30
roccat_report_event in drivers/hid/hid-roccat.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free in certain situations where a report is received while copying a report->value is in progress.
CVE-2022-41848
PUBLISHED: 2022-09-30
drivers/char/pcmcia/synclink_cs.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling ioctl, aka a race condition between mgslpc_ioctl and mgslpc_detach.