To celebrate the new year, we have released the ThreatModel for Azure Storage, free and open source, to help everyone identify and mitigate security risks when using this service. You can interact with the data via ControlCatalog or download the document via GitHub.
TrustOnCloud helps customers make sense of the shared responsibility model and accelerates the secure adoption of each Cloud Service. We use threat modeling to ensure that Security Architects, DevOps, and Security Governance teams can make well-informed and bias-free security decisions.
With over 120 ThreatModels published for our customers. The ThreatModel empowers organizations to take a proactive approach to secure their data and applications in Azure.
How to use the ThreatModel for Azure Storage
Using ControlCatalog: To help our customers navigate the information in our ThreatModels, we have ControlCatalog, a reactive UI to navigate our ThreatModels. With ControlCatalog, we want to help anyone take advantage of the data from our ThreatModels. It allows the reader to pivot between threats and controls, set the MITRE ATT&CK®, see the top threats and controls, understand a particular flow, etc.
Reading the document: The document might feel overwhelming with its 130+ pages. All pages of the ThreatModel are relevant for at least one-use case; your use case might only need some of the pages.
Everyday use cases we see from our customers are:
1. Covering the “best practices” (e.g., best security/effort ratio)
Who for: DevOps team and/or not-too-sensitive workloads (or what we like to call it, “if it gets owned, we will have a bad week, not a bad year”)
What do you get out of it: You will have a list of all the controls ordered by priority. It is risk-based, without the hassle of going 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.
Where to look in the ThreatModel: Go to page 106 [Appendix 1 – Prioritized list for control implementation].
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.
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)
Who for: Security Architects and/or for sensitive workloads (typically having reputational risks or regulatory risks)
What do you get out of it: 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. This enables you to secure the parts of the service you are using without the need to waste cycles on securing parts of the services which aren’t in use.
Where to look in the ThreatModel: Go to page 5 [Feature Classes].
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.
3. Technology onboarding for large enterprises/agencies
Who for: Cloud Enterprise Security and GRC, for mass adoption of Cloud Services.
What do you get out of it: A complete overview of the service, its features, threats, and controls.
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 (e.g., Blob SFTP support and its local users), or take an exception-based approach. In 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 IOC events and in your CSPM (e.g., Azure Policy).
Staying Secure and Azure Preview Features
Like most cloud services, Azure Storage is not ‘static’. In 2022 alone, significant features such as SFTP support, immutable storage, and Azure Monitor diagnostic settings for Azure Storage all reached General Availability, to name but a few.
Anyone familiar with Azure will know about the use of ‘Preview’ features. At TrustOnCloud, we stay abreast of the items in Public and Private previews; however, due to the rate of change in such features, we do not include them in our ThreatModels. The exception is if it’s a control that addresses a threat in a service feature that is generally available. In these circumstances, we refer to the specific control as being in Preview mode. Rest assured, once these preview features reach General Availability as part of our OverWatch service; our customers will receive a summary update of the threat and control implications of the new feature and access to the updated ThreatModel.
The ThreatModel for Azure Storage is a powerful tool for organizations looking to secure their data and applications in the cloud. With its ability to cover best practices, review services based on application and risk tolerance, and facilitate technology onboarding for large enterprises, the ThreatModel empowers security teams to make informed, proactive decisions about their cloud security. Download it now for free on GitHub and take the first step towards a more secure cloud journey.