The following excerpt regarding who is responsible when it comes to security in the cloud is taken from a live panel discussion titled Cloud Security 2021: Emerging Trends, Threats, and Responses. The cloud provider, auditing, managed service provider and enterprise communities were represented by Tim Sandage of AWS, Mike Hughes of Prism RA, Jeff Collins of Lightstream and Tyler Kennedy of Rewind. The session was moderated by Aaron Klein of SecureCloudDB.
Aaron Klein, Co-Founder & CEO, SecureCloudDB
We all hear about cloud security and the shared responsibility model. Let's start with Tim explaining what AWS [Amazon Web Services] provides out of the box, and then hear about how everyone on the panel applies this model in their own and customer environments.
Specifically, we're going to focus on how cloud security demands that we think about things in different ways; about how we implement different security practice versus on prem. So let's get very specific in how the cloud is different and what does successful security entail.
Tim, can you start us off? And then we'll go around.
Timothy Sandage, Senior Manager, AWS
Thanks, Aaron. So, first and foremost, the key thing about AWS is our priority zero is security. So everything that we do, everything that's within our DNA, is around how do we make sure that our global infrastructure is secure for whatever workload that our customers need to host or put into the cloud.
The idea of security of the cloud is what AWS does, and what we do really really well is take care of those physical security aspects of data center security - visitor logs, service delivery, all of the pieces that actually make compute capable. From an infrastructure standpoint, we do all of the things to allow for basic compute, basic database service utilization, application awareness, and so forth within the cloud.
Now, the customer then has to look at it from the perspective from the operating system, or the guest operating system; they need to secure that use of the operating system; they need to secure that use of data, databases, and so forth. And whether that's individually throughout the different services that we offer, or if it's their partner services that can enhance the security such as yourselves [SecureCloudDB] with database security and so forth. So those are really the key aspects.
But then the other piece that's important to understand is that there are services such as RDS and some other services that are a little bit higher in the stack, where we lean in a little bit more and do some of the security pieces. But the key element of the shared responsibility model is to know what is the service responsibility per service for the customer aspect. Is AWS patching and doing vulnerability scanning of the operating system like we are within RDS? Or is it an independent operating system like EC2, where you as a customer are 100% responsible for securing and patching and managing that operating system.
So the key piece is making sure, as you're deploying services in the cloud, to understand the key resource constraints that you're obligated to as a customer, and then the things that we do on your behalf, and then obviously, as we'll talk through, partner solutions that can really help enhance that security capability.
So Aaron, I hope that hits the mark for you.
Yeah, I think so. I look for other folks to weigh in as to how they're applying it. Maybe we'll start with Tyler and how he's applying it in his environment and what he's looking for in terms of shared security?
Tyler Kennedy, Application Security Engineer, Rewind
Sure. So, as with all cloud providers, it's a shared security model, which means the responsibility for keeping things secure is on two parties, yourself and your provider.
One of the great benefits of very in depth and expansive providers like Amazon AWS, is that it has every bell and whistle you could possibly imagine. I think under the security category, there's 25 different tools in the AWS dashboard. But of course, it still ends up being on the user to actually configure and use these things in a way that keeps what they're running secure.
Some of the most recent major private information leaks have simply been unsecured databases where someone has put something on RDS and misconfigured it so that it was unfortunately available to the public.
So it's always on both parties just because you know, we trust Amazon AWS, and we trust Google Cloud, we trust all these hosting providers to do a pretty good job at security and keep things secure. It's still on you to ensure that the infrastructure you have running on top of a platform like this is actually safe for your users.
Shared responsibility doesn't mean you can just say, “Well, Amazon's got people like Tim, and they're pretty good. We can just ignore security.”
Cool. Jeff, do you want to weigh in on how you guys take care of your customers and what you look for and where you see the lines being drawn?
Jeff Collins, Chief Strategy Officer, Lightstream
Sure, definitely. So you know, the biggest thing when we're talking to customers - whether you're large or small, inside of AWS - really, the idea is the same. And Tim hit on this - the shared responsibility model defines where Amazon starts and where Amazon stops.
And within Amazon, Amazon provides a whole set of native controls that provide security for customers. But those controls won't necessarily secure your environment. And what I mean by that is they secure the infrastructure, they secure the services, they secure everything that Amazon provides. But as a customer, you have to go in and still secure your applications, you still have to secure anything inside of your environment, whether that's a database, in the case of what we're talking about today, or it's an application, maybe it's a monolithic application, or a micro service based application, whatever it may be, you still have to leverage that.
And that's where the whole ecosystem of third party technologies comes in. There's a whole multitude of third party technologies that exist on top of AWS, just like SecureCloudDB, wherein they provide that capability, and they provide that support for those applications, databases, etc.
And so, as customers go down this path, that's the big area that we always push is number one, leverage every native control. But then number two, leverage those third party controls as necessary and as applicable to your environment. And that will change over time; if you go into AWS and you're very monolithic, your controls and your capabilities will be very different than if you transform and are very much microservices based or services based inside of your environment. And so, always think about those things and always leverage technologies as applicable and necessary for your environment.
Excellent. And, Mike, you come in, and you look at this from an auditor's perspective.
Mike Hughes, Director, Prism RA
I do and I'm getting in and looking at our clients environments. And we've had the concept of any vulnerability anytime, anywhere, for many years. At least we had an on premise server, so we knew where our data was, we’re in the cloud now we don't know where that data is.
And yeah, this thing about shared responsibility, Yes, there is. But I wish I had a pound or a dollar for every time a client has said to me, “We don’t have to worry about security, that is the provider's responsibility.” No, it's not. You're still accountable for that data. Yes, there are tools in place that you can help configure security. But it's down to you, you need to configure that.
And when we're talking about baselines is when we get these concepts in, and the client understands their data, where it is and what level security they need, and baseline beyond those controls. Do they ever go back and revisit that from time to time? Or is that baseline still valid? Has it been changed, because we had to reconfigure to open something up to do some tests or something - did we close it again? And unless we do that ongoing, reaffirmance of the baseline we're placing undue reliance on these top controls. So this is a never ending story.
I think I think that's a super valid point. Right? And I'm sure everyone else would agree that security is not a set it and forget it, it is a constantly review it. I think maybe that's one of the things we take out of this.