What are AWS’s Security Responsibilities, Anyway?
ACM.144 A deeper dive into the shared responsibility model
Part of my series on Automating Cybersecurity Metrics. The Code.
Free Content on Jobs in Cybersecurity | Sign up for the Email List
In my last post I covered how to potentially prevent CreateUser privilege abuse in an AWS environment.
There are some potential pitfalls that we’ll want to consider but first, I’m going to write up a post on how to figure out how AWS secures their side of the AWS Responsibility Model. We need to understand this when evaluating threats in our AWS account and what to do about them.
The AWS Shared Responsibility Model
When you work in a cloud environment, it is your responsibility to secure certain things and the cloud provider is responsible for securing some things on their side. I wrote about that here in more detail in my post What is Cloud:
So what are your responsibilities on AWS? AWS defines this in their documentation of the Shared Responsibility Model. The first time I saw this I thought it was brilliant, having tried to implement a SAAS platform before the term existed and along with that experienced the challenge of explaining it to customers.
Me back then: No, you do not get to FTP into your website. I’m managing everything for you, and by the way, it’s much more secure that way. No there’s no Plesk access. Not all web hosting providers are the same or give you the same tools. Yes, I can get you your data out for a fee (because I had not implemented any automated way to get that yet) and no, you cannot have the source code. You didn’t pay enough for that.
Some customers couldn’t understand it, but today it’s obvious — it would be like demanding that AWS give you all the source code that runs AWS when you move your systems to Azure, and demanding that they help you move all your systems to the new provider — for free.
What about detailed security threat questions?
Alright that image is great, and it kind of shows you where the line is drawn, but not exactly. I’ll get to that more precisely at the end, but first, I like to say: If you can see it, touch it, and change it, you likely own it. If you use that line in the future, please give me some kudos and direct people to my blog. Thank you. :)
That diagram doesn’t answer all the questions companies may and should have about security and data protection.
Some potential questions might be:
- How do you prevent rogue code from getting into AWS systems such as happened in the Solar Winds attack?
- How do you help prevent phishing attacks for my employee’s AWS credentials such occurred in the Oktapus attacks? Or is that all on me?
I wrote about a potential similar threat here:
- What happens to my data when I terminate an EC2 instance, Lambda function, Fargate or Batch container? Is this compliant with the regulations and standards my company has to follow?
- What happens when I delete files from S3? Databases? Queues? User information and credentials? Secrets? Parameters? etc. etc. etc.
- How do you prevent insiders from sniffing my traffic as it traverses the AWS network?
- How do you prevent DNS exfiltration on AWS-managed DNS servers?
- How exactly do you segregate virtual machines running on the same hypervisor to prevent another customer or insider from seeing that data?
- What about containers (Fargate, Lambda, Batch) running on the same host?
- How do you prevent an insider from accessing my user credentials and using them in my AWS accounts?
- Can your employees see my data in S3? In EC2 instances? The AWS console? Or anywhere else in AWS? And can they alter it?
- Could an insider obtain temporary or session credentials? This is related to the topic of my next post, and why I have to stop to write this one — because this one point is a bit complicated.
AWS cloud security and data protection documentation
AWS used to have white papers that went into a fair amount of detail on how they secured their services. I imagine they probably had a more centralized approach, such as the one I’m proposing in this blog series. Perhaps as they acquired more companies and the services expanded this changed. I can only speculate. I don’t really know and you’ll have to ask Amazon, because now they don’t seem to have a single, clearly defined white paper on security processes.
When I wanted to get onto AWS I read all the white papers as I mentioned in my What is Cloud? post. Now there are too many. In fact, there are too many white papers on security alone. Back then reading a single paper helped convince me that maybe the cloud’s time had come. It answered some of the above questions. Maybe not all to the extent some organizations will require, but it was pretty good.
You can find the old version of this paper on the Wayback Machine.
This seems like an updated version because it mentions the Nitro hypervisor:
Well, these white papers are now archived and they provide a link to updated information. The problem is that this link goes to a portal with a zillion documents. You might have time to find the answers to all the above questions and others here but I don’t right now. I only have so much time in a day and I am counting on the big companies who have more staff and resources to keep AWS honest in their security practices. There are enough large companies with a vested interest in AWS security that their teams can and should be asking and re-asking assessment questions periodically.
Cloud Security Alliance (CSA) STAR registry
Probably an easier to digest source which may answer your questions is the CSA STAR registry documentation. The Cloud Security Alliance (CSA) has come up with a questionnaire I actually like better than SOC 2 compliance. I use it when I help companies with internal assessments, but I modify the questions and add to it in some areas where I think it could have more detail, and when cloud-platform-specific questions are applicable.
Note that CircleCI, who unfortunately recently experienced a breach, was both FedRamp compliant and had SOC2 compliance. They are currently not in the CSA STAR registry:
A visit to the Wayback Machine shows they used to be in the registry, but the document the registry links to is no longer available:
https://web.archive.org/web/20201204081736/https://cloudsecurityalliance.org/star/registry/circleci/
Also, even if they were in the registry in the past, the CSA questionnaire has had improvements over time, some of which I really like. They are related to development practices and separation of duties, some of which may have helped CircleCI but we can’t really know for sure.
I still tend to modify the questionnaire to meet my needs and cover any threats that do not fall into their categories, and some parts of assessments are better handled by tools. Although certain penetration testers rage against tools and automation, I write my own scripts and tools in addition to commercial tools and I can find certain key risks in cloud accounts many times faster than I would through manual evaluation. Of course, I perform manual tasks as well, but I can get a lot more coverage and have more time for the manual part because the tools do some of things I used to do manual faster for me.
I can also create my reports much faster, including incorporating the manual documentation of findings and remediation which I add in when necessary. To rewrite standard responses and documentation over and over again for common findings is just costing customers more money with no associated value.
SOC2 vs. CSA Cloud Controls Matrix (CCM)
On that note, I’ve looked at SOC2 in the past and it seems to be a lot of repetitive paperwork compared to the CSA questionnaire which is now part of the CSA Cloud Controls Matrix (CCM). The latter is a succinct list of questions with a mapping to many different security frameworks and different types of compliance an organization may need to obtain (NIST Cybersecurity Framework, HIPAA, PCI, etc.)
I asked an auditor I worked with about this difference and the repetitive nature of a book I read on SOC2 compliance and she said something like this:
Yeah, I freaked out when I saw we were going to have to write a 350 page report. But one of the other auditors told me, don’t worry, it’s mostly cut and paste. We don’t actually write that much.
Now before you read the next section I want to stop and tell you that I think auditors are a massively important part of the cybersecurity industry. As much as I have heard people on the technical implementation side mock auditors at times, they are invaluable because we need an external party to verify the security processes and controls companies claim to have. So I’m writing here about the process and documentation, not the job function or the people. I worked with some amazing auditors I really liked, and they were simply following the industry standard process.
Auditors are one of the jobs that can really make a difference by calling companies out on things they are not doing correctly — when they are enabled to freely do so and have a balanced (fair) approach.
My experience as a subject matter expert (SME) on an audit was similar to what I read in the book on SOC2 compliance in some ways. That’s why I don’t do that type of work anymore. I was getting paid a substantial amount per hour to move data around in spreadsheets. This is not the fault of the auditors, because that is a standard process and what they are trained to do. It is industry standard.
Perhaps the industry standard needs to change. As you can tell by this and other facts in my recent blog posts, money is not my sole motivation. I actually want to help people with security the best way I possibly can. I want to provide them a list of security problems to fix as quickly and succinctly as possible. I want to get as much coverage as possible in a penetration test or assessment.
CSA Star is a worthwhile alternative — until someone gets involved and starts over-complicating it to make more money. The way “consultants” got involved with Scrum. Don’t do that, please. Keep it a simple, straightforward, questionnaire that is easy to digest for people who don’t have time to read 350 page audit reports.
By the way, if you want a simple version of Scrum that works, you can find it here:
AWS in the CSA Star Registry
CSA has three levels that a company can achieve.
- Level 1: The first is a self-assessment questionnaire. The company tells you what it is doing.
- Level 2: The second is where auditors and assessors come in and why they are so important — they tell us if the company is really doing what they claim to be doing through a third-party attestation. Now the question is, what is the quality and trustworthiness of the company performing the attestation? Good auditors and assessors are vital in cybersecurity!
- Level 3: The last level is continuous monitoring. An assessment and an attestation is a point in time. How do you ensure that you maintain this high level of security? That’s what level three is all about.
Amazon published their CSA documentation for each level here and is helpful for companies performing a third-party vendor assessment and may have answers to some of the above questions.
Business Contracts
People complain that the line of where AWS’s responsibility ends and the customers begins in the shared responsibility model is fuzzy. They say it’s not clear who is responsible for what.
If that is the case, the customer has not performed a proper upfront assessment and asked those questions in advance. If any of the answers are vital to the customer’s choice to use AWS, then they need to be clearly documented in the customer contract. If you do not want to do that or pay a lawyer to help you evaluate who is responsible for what and get clearly defined terms in your contract then you’re stuck with trying to interpret whatever the documentation the cloud provider gives you — which their contract may say they can change at any time.
When you do business with another company, you sign a contract. That contract governs any future disputes. Small businesses will not have a lot of clout to change the AWS contract. In the past, some reported that AWS will never change their contract. I happen to know a lawyer who did get a change in an AWS contract. He wrote this book, which you might want to read if you are not familiar with how business law and contracts work. It’s been one of the best selling contract law books on Amazon for a while:
If enough people make a similar request to AWS for a contract change, it could possibly make its way into the AWS standard contract because it will make it easier to do business, as fair contracts usually do. If you are not comfortable with the definition of the shared responsibility model, then you should not be doing business with AWS in the first place. However, I think Amazon provides a very valuable service and for me so far, it has been an amazing place to host applications and tools that I use in my work.
Some of those relate to cybersecurity metrics automation…which I’ll get to eventually.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
