The Security Stack Mappings for Azure research project was published today, introducing a library of mappings that link built-in Azure security controls to the MITRE ATT&CK® techniques they mitigate against. Microsoft once again worked with the Center for Threat-Informed Defense and other Center members to publish the mappings, which pair the familiar language of the ATT&CK framework with the concrete coverage Azure provides to protect organizations’ attack surfaces. Microsoft is pleased that community interest in seeing such mappings for Azure led to its use as the pilot cloud platform for this endeavor.
The project aims to fill an information gap for organizations seeking proactive security awareness about the scope of coverage available natively in Azure. The project does this by creating independent data showing how built-in security controls for a given technology platform, in this case Azure, secure their assets against the adversary tactics, techniques, and procedures (TTPs) most likely to target them.
Microsoft has worked to expand the suite of built-in security controls in Azure which, while highly effective for protecting customer environments, can feel overwhelming to understand across an organization’s entire Azure estate. MITRE has developed the ATT&CK framework into a highly respected, community-supported tool for clarifying adversary TTPs. Pairing the two together provides a helpful view for organizations to understand their readiness against today’s threats in a familiar vocabulary that enables easy communication to their stakeholders.
Aside from the mapping files, key project deliverables include a methodology that describes how the project team assessed the mappings and a scoring rubric to explain how the mapping scores were decided. Accompanying the methodology and scoring rubric are a YAML data format that houses each mapping and a mapping tool that validates and produces corresponding ATT&CK Navigator layer files for easy visualization. The ATT&CK Navigator view is particularly useful for assessing multiple security controls concurrently to identify similarities or differences in coverage capabilities.
Azure’s built-in security controls map to broad ATT&CK technique coverage
The Security Stack Mappings research project was undertaken in response to the lack of data available to explain how a technology platform’s built-in security controls mitigate against adversary TTPs as described by ATT&CK techniques. Azure was chosen for the inaugural iteration of this research, with plans for the Center to repeat the process for other technology platforms in the future.
The methodology distinguishes between security controls that function independently and features that can be enabled as part of another product or service, choosing only the former as candidates for mappings.
The scoring rubric is comprised of three main factors:
- The intended function of the security control—whether it is meant to protect, detect, or respond to an adversary behavior.
- The coverage level of the control for the mapped ATT&CK technique—minimal, partial, or significant.
- Factors found to be useful considerations for assessing a mapping—coverage, temporal (real-time, periodic, or externally triggered), and accuracy (such as false positive or false negative rates).
The list of Azure security controls that were mapped was compiled by the Center, with input from Microsoft and other Center members. Part of the list was based on the Azure Security Benchmark (v2), previously published by Microsoft, which provides guidance on best practices and recommendations for improving the security of workloads, data, and services on Azure. As many organizations are now using ATT&CK to keep track of their overall security posture, Microsoft is pleased to be able to support them through the ready-made mappings produced through this project.
For a list of the Azure security controls that were mapped, see the Center’s list of Azure controls.
Each control was mapped to one or more techniques and categorized using thematic tags for an alternate coverage view. For example, the “Analytics” tag returns the following set of controls:
- Azure Alerts for Network Layer
- Azure Network Traffic Analytics
- Azure Sentinel
Whereas the “Containers” tag returns this set:
- Azure Defender for Container Registries
- Azure Defender for Kubernetes
- Docker Host Hardening
Microsoft previously partnered with the Center and other Center members to develop the ATT&CK for Containers matrix, which used the threat matrix for Kubernetes developed by the Azure Security Center team for Azure Defender for Kubernetes, as a starting point to expand on. You may notice that the mapped techniques for the container security controls above don’t reference some of those newly added in the ATT&CK for Containers matrix as part of the release of ATT&CK v9 in April 2021. As this ATT&CK version was released mid-project, the team chose to focus on ATT&CK v8 instead, with plans to update mappings to ATT&CK v9 already in the works.
Just the beginning for technology platform mappings
With the successful completion of the Security Stack Mappings for Azure research project, Microsoft and the rest of the industry now have a consistent, repeatable approach available to use for mapping built-in security controls to ATT&CK techniques. As Microsoft continues to expand the built-in tools available to protect customer workloads, data, and services in Azure, and as MITRE continues to expand the number of adversary TTPs described by the ATT&CK matrices, there will be new mappings available to help organizations make sense of their security coverage level. Microsoft will continue to support community efforts such as this to enable easier understanding and communication of security coverage wherever we can.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.
The post MITRE ATT&CK® mappings released for built-in Azure security controls appeared first on Microsoft Security Blog.