The Shared Responsibility Model is an easy-to-understand diagram by Cloud Providers. The reality is that: 1) the Shared Responsibility Model is the responsibility of the customer, and 2) it is difficult to execute as the line between responsibilities is not clearly mapped out.
TrustOnCloud helps customers make sense of the shared responsibility model, and accelerates secure adoption of each Cloud Service. We use threat modeling to ensure that Security Architects, DevOps, and Security Governance teams are able to make good and bias-free security decisions.
With 70+ ThreatModels published for our customers, we decided to release the ThreatModel for Amazon S3 to all, in order to clearly define customer responsibilities and reduce security bad days for the AWS community, now and in the future.
We will use this blog post to walk you through how you can use this ThreatModel effectively.
How to use the ThreatModel for Amazon S3
To get started, the document might feel overwhelming with its 160+ pages. With its 32 distinct features, Amazon S3, the Simple Storage Service, is no longer “Simple”, but I digress. All pages of the ThreatModel are relevant for at least a use case; your use case might not need all the pages.
Common use cases we see from our customers are:
- Covering the “best practices” (e.g. best security/effort ratio)
- Reviewing the service depending on your application(s), and implementing the controls based on your risk tolerance
- Technology onboarding for large enterprises/agencies
- Compliance mapping to demonstrate a risk-based approach and formulate an action plan
For each use case, you will find below where to look, what to do, and for whom it typically makes sense.
1. Covering the “best practices” (e.g. best security/effort ratio)
Where to look in the ThreatModel: Go to page 139 [Appendix 1 – Prioritized list for control implementation]. You will have a list of all the controls ordered by priority. It is risk-based, without the hassle to go through all the risks. We built this priority using our list of threats, the impact of the controls on the threats, and the effort it takes to implement the controls.
What to do: review that you implemented the controls starting with the “Very High” priority (using the implementation column). Test your controls actually work (using the testing column). Note that some controls might not be relevant for your usage of the service, feel free to skip them.
Typically for: DevOps team, and/or not-too-sensitive workloads (or what I like to call it “if it gets owned, we will get a bad week, not a bad year”)
2. Reviewing the service depending on your application(s), and implementing the controls based on your risk tolerance (e.g. high security but ad hoc)
Where to look in the ThreatModel: Go to page 5 [Feature Classes]. We call feature classes, the portion of the service you can enable (exposing you to risk on those APIs) while being able to disable the rest. You can then go deeper with each feature class page with its Data Flow Diagram, and its associated threats and controls.
What to do: Identify the feature classes you intend to use during a threat modeling session with the DevOps team. Review each threat (at least Medium and above) and their mitigating controls. Decide what controls (or levels of mitigation impact) is required for each threat to satisfy your risk tolerance.
Typically for: Security Architect, and/or for sensitive workloads (typically having reputational risks or regulatory risks)
3. Technology onboarding for large enterprises/agencies (if you are required to dive deep – or enjoying – like as if it were the Mariana Trench)
Where to look in the ThreatModel: Everywhere. Typically at this point, there is a decision from the enterprise/agency to use the service or not. We typically walk our customers through the relevant sections with our Cloud Threat Researchers.
What to do: Once the whole document is reviewed, some of our customers decided not to use a service for the highest application criticality or block certain features (looking at you Torrent S3 Object); or to take an exception-based approach. For other cases, the service can progress to their internal next steps. For example, building infrastructure-as-code templates that application owners must use, or defining the use cases to configure as IOCIndicator of compromise events and in your CSPMCloud Security Posture Management (e.g. Config Rules).
Typically for: Cloud Enterprise Security and GRC, for mass adoption of Cloud Services
4. Compliance mapping to demonstrate a risk-based approach, gap analysis and formulating an action plan (where compliance comes in handy)
Where to look in the ThreatModel: Go to page 132 [Compliance Mapping]. You will find a mapping from S3 controls to PCI DSS v3.2. The document supports over 100 Compliance frameworks and standards using the Secure Control Framework. Our mappings are based on compliance requirements mapped to security objectives and their underlying security activities. The activities are prioritized using our risk-based approach anchored in identifying threats on the service.
What to do: Review how you address the compliance requirements that you are subject to. Request evidence of the implementation and testing of the controls. Track the completion of any gaps.
Typically for: Compliance specialists, auditors, regulators
To be the last S3 security document we’ll ever need, there is a caveat: it needs to be updated (very) regularly, due to AWS rapid pace of innovation.
In the last year alone, we tracked and analyzed over 3,500 events from new features, changes, bugs, etc. New attack techniques are discovered regularly by our researchers, our customers or the community. For that reason, we will keep updating this ThreatModel for Amazon S3 on a regular basis, and welcome any contribution from the community.
If you are interested in having access to any of our 70+ other ThreatModel™, please reach out to email@example.com.