The last S3 security document that we’ll ever need, and how to use it
We have released the ThreatModel for Amazon S3, free and open source. You can download it via GitHub.
The Shared Responsibility Model is an easy-to-understand diagram by Cloud Providers. The reality is that:
1) The Shared Responsibility Model is the customers’ responsibility, and
2) It is difficult to execute as the line between responsibilities is not clearly defined.
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 can make excellent and bias-free security decisions.
With over 120 ThreatModels published for our customers, we decided to open source the ThreatModel for Amazon S3 to clearly define customer responsibilities and reduce bad security 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
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.
Everyday use cases we see from our customers are:
- Covering the “best practices” (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 your controls, starting with the “Very High” priority (using the implementation column). Test your controls work (using the testing column). Feel free to skip controls not relevant to your usage of the service.
Typically for: DevOps team and/or not-too-sensitive workloads (or what I like to call it “if it gets owned, we will have 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 go deeper with each feature class page with its Data Flow Diagram and 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 its mitigating controls. Decide what controls (or mitigation impact levels) are required for each threat to satisfy your risk tolerance.
Typically for: Security Architects and/or for sensitive workloads (typically having reputational risks or regulatory risks)
3. Technology onboarding for large enterprises/agencies (if you are required (or enjoy diving deep as if it were the Mariana Trench)
Where to look in the ThreatModel: Everywhere. Typically, there is a decision from the enterprise/agency to use the service or not. We usually walk our customers through the relevant sections with our Cloud Threat Researchers.
What to do: Review the whole document. After review, some of our customers decide not to use a service for their highest application criticality, block certain features (looking at you, Torrent S3 Object), or take an exception-based approach. For other cases, the service can progress to its 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 control objectives and their underlying controls. These underlying controls 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.
Conclusion
To be the last S3 security document we’ll ever need, there is a caveat: it needs to be updated (very) regularly due to the rapid pace of AWS innovation.
In 2021, 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 update this ThreatModel for Amazon S3 regularly and welcome any contribution from the community.
If you are interested in having access to any of our 120+ other ThreatModels, please reach out to contact@trustoncloud.com.
