Security Posture for Azure Key Vault Managed HSM with Azure Policies

In my previous blog post I described how to monitor, from a security perspective, the events occurring on an Azure Key Vault Managed HSM (Hardware Security Module) - in the rest of this post abbreviated as “MHSM” - by using Microsoft Sentinel. This security monitoring allows to identify suspicious activities and to react accordingly.

In this blog post I’ll describe how to proactively monitor, always from a security perspective, the configuration of a MHSM in order to identify and possibly correct any deviation from the Microsoft recommendations and known security best practices.

Typically, in the Microsoft Azure cloud environment, this kind of “security posture” monitoring is done by Microsoft Defender for Cloud - in the rest of this post abbreviated as “MDC”: the Cloud Security Posture Management, also here abbreviated as “CSPM”, is a key MDC’s feature. To do this continuous security assessment, MDC relies on the Azure Policies; specifically, it uses the definition of the Azure “initiative” (group of policies) named Azure Security Benchmark (ASB), which is “assigned” (with assignment name “ASC Default”) at subscription or management group level and then which covers any Azure resource. CSPM is a “free of charge” capability of MDC. MDC has also Cloud Platform Workload Protection (CWPP) capabilities to protect against security threats different workloads running in hybrid and multi-cloud environment.

Unfortunately, at the time of this writing (July 30, 2022), the MDC protection capabilities (CSPM and CWPP) do not cover yet MHSM instances, though they fully cover simple Azure Key Vault instances. I’m sure that the coverage extension to MHSM will be added very soon in the future.

Today we can easily assess the known deviations of the MHSM configuration from the security best practices by directly relying on the Azure Policies. Different polices already exists with the words “Managed HSM” in their title, some of them also with the “Preview” tag in the title.

Recommendation: To better visualize the images shown in this blog post, I recommend to right-click on them and open it in a new tab or window

In the above screenshot I’m highlighting the evidence that these polices are “built-in” in Azure.

Info Notice: At the time of this writing, I could not find the existence of these policies mentioned in the official Microsoft documentation for the MHSM. Nevertheless, each of these policy has a very clear name and description.

As already clarified, at the time of this writing these individual policies are not included in the Azure Security Benchmark initiative so they are not part of its default assignment: they must be assigned individually at the desired scope (subscription, resource group)

Additional “custom policies” can be created to further protect MHSMs.

When all policies are assigned at the desired scope, it is possible to have a view of their effect by using the “Compliance” page of the Azure Policy blade.

For example, this the detailed view of a policy with a non-compliance…:

…while this the detailed view of a policy with full compliance:

As always, I hope that the information provided in this blog post may be useful.

PS. Feedback on this blog post can be added in this related LinkedIn post

A final note. When I started investigating on how to assess the security configuration of MHSMs I was not aware of the existence of the (yet undocumented) built-in policies in Azure. Because of that, I started by cloning the policies existing for simple Key Vault instances. For the sake of completeness, this is how I did it: open the “Azure Security Benchmark” initiative, search for the included polices with the word “Key Vault” in their title, duplicate them, replacing the word “vaults” with the word “managedhsms” on their JSON definitions, and assign them individually to the desired scope including the MHSM(s) to be protected. Only a few of the individual policies created for simple Key Vault instances could not be applied to MHSM (e.g., those referring to the protection of “secrets”, which do not exist in MHSMs).