Tag: Policy

Azure MSI & Policy Governance

· Leave a comment ·

Last few weeks I have been really pushing customers to use Azure Managed Service Identity (MSI) as much as possible, assuming the MSI capability exists with the Azure service. Note, not all Azure services support MSI’s today, however for the most part all services do support the traditional Service Principal (SP).

If are are unclear what the difference is between an SP and MSI is, I would welcome you to visit the following link HERE.

With that said, how do we ensure as services are deployed and are leveraging MSIs and not SPs? Azure Policy! Simple right? Yes, it really is. Below is a list of policies that exist today, however this list will continue to grow as more Azure services incorporate MSIs. And of course, if you’re willing, you can always create your own custom policy to ensure the Azure service is using an MSI. Note, the policies availability and the Azure services that support MSIs, is not 1:1. There are more services that support MSIs, than the out of the box policies that support MSIs today. If you are not willing to wait for Microsoft to push out new policies, then you should go ahead and create your own.

Once you have selected the policy, enabled/enforced it, you can now track to see if (for example, Azure Function), if a new Function is deployed and it is not using an MSI, it will be flagged, or you can go further and reject the deployment if it is not using an MSI.

Below is a link that provides which Azure services support MSI’s as of today. Note, this list will only continue to grow. https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities

Azure Policy – Approved VM Extensions

· 1 Comment ·

I work with many customers where Security is no longer a second-thought, but the key driver for any conversation/engagement. One of the many Governance standards and policies that typically comes up during these conversations, is to ensure their Azure environment resources can only have approved extensions deployed. The policy also falls under the highly recommended CIS benchmarks. Ensuring your environment is following CIS benchmarks and controls is a very good starting point.

First, you need to understand which extensions are available. To get the list of all extensions available, within your Azure region, and dump it to a file, you can use the following PowerShell code:

Get-AzVmImagePublisher -Location "canadacentral" | Get-AzVMExtensionImageType | Get-AzVMExtensionImage | Select Type, PublisherName, Version | Format-Table -AutoSize | Out-File -FilePath .\VMextensionsCanadaCentral.txt


Next, now that we know which extensions are available, we need to understand which extensions we want to allow. Once we have that list, it is simply adding the list of extensions (separated with a semicolon; ensure no whitespace exists!!).


Once you have the list, deploy the Policy “Only approved VM extensions should be installed” and set it to ‘Deny‘. Or on the flipside, you can set the Policy to ‘Disabled’, which would allow the Policy to allow extensions, but the following within the list. Depending on your security stance, you can either allow explicit extensions and deny all by default. Or, allow any extension by default, however disable only the following extensions based on your list. I would think the former provides more control.


Once you have the policy deployed, configured and enabled, your users will get an error something like this, if the extension the VM is requesting is not a part of the approved list…




To get this policy in your environment, you can either go to the Azure Policy service and look up the definition, or visit the following link HERE, and access the JSON/Policy from Azure’s GitHub repo.

Azure Security Center – Continuous Export via Azure Policy

· Leave a comment ·

Earlier this week, I highlighted how you can use Azure Security Center (ASC) and its Continuous Export feature to send Security Alerts and Recommendations to Event Hubs (and/or Log Analytics) — you can find that post HERE. Today I want to show you how to can use Governance best practices, and leverage Azure Policy to ensure ASC is configured to forward to either Event Hubs and/or Log Analytics.

As a quick intro, Azure Security Center (ASC) is a holistic solution provided by Microsoft to not only assess your Azure resources, but can also be extended to your On-Premises infrastructure as well. ASC is a security management solution that improves your overall security posture within your Azure environment and on-premises infrastructure. I work with a lot of customers where they require an “agnostic” SIEM solution. ASC generates detailed security recommendations and alerts that can be viewed through the ASC portal. However when customers have a requirement to send this telemetry to some third party SIEM, such as QRadar, Splunk, etc. In short, your Azure resources can send their security events directly to Event Hubs (via Diagnostic Agents) or can be configured (the easier approach) with ASC.

To get these policies, go HERE to the Azure GitHub repo. Next post, I will walk you through the setup and all the necessary parameters that are required to get this policy up and ‘governing’.

Azure Policy – Audit for Network UDR Changes

· Leave a comment ·

Azure Policy has been available for some time now, but for folks getting start with Cloud Governance, Azure Policy is a service in Azure that allows you to manage, assign, and create custom policies. These policies can be used to enforce a global set of rules or specific set of controls for a specific environments, ie. less control and governance in a “development” environment. This allows resources to stay compliant with you enterprise standards. Azure policies can enforce different rules, from Denying specific services, for example, ensuring only resources are built within a specific region, ie. resources can only be built within the Canadian regions. Conversely, rather than enforcing, policies can also be configured to Audit, where resources will be marked if they are not compliant, for example, a Storage Account is not configured with secure transfer.

Before diving into the policy itself, I want to quick go over the types of conditions that are available, and that can be used to enforce different compliance rules. The following table shows how different policy effects work with the condition evaluation for the resulting compliance state. Although you don’t see the evaluation logic in the Azure portal, the compliance state results are shown. The compliance state result is either compliant or non-compliant.

Resource StateEffectPolicy EvaluationCompliance State
ExistsDeny, Audit, Append, DeployIfNotExist, AuditIfNotExist*TrueNon-Compliant
ExistsDeny, Audit, Append, DeployIfNotExist, AuditIfNotExist*FalseCompliant
NewAudit, AuditIfNotExist*TrueNon-Compliant
NewAudit, AuditIfNotExist*FalseCompliant
  • *The Append, DeployIfNotExist, and AuditIfNotExist effects require the IF statement to be TRUE. The effects also require the existence condition to be FALSE to be non-compliant. When TRUE, the IF condition triggers evaluation of the existence condition for the related resources.

Source: https://docs.microsoft.com/en-us/azure/governance/policy/assign-policy-portal

In this example today, I want to show a real world example, where a customer recently asked to monitor any changes being made to their UDRs (User Defined Routes/Routing).

The following will continuously monitor all UDRs in the environment. If any changes are made to a single UDR table, it will be audited and its changes will be tracked. Once the policy is enabled, you can see it in action by creating/modifying a UDR.

“policyRule”: {
   “if”: {
      “anyOf”: [
       {
            “source”: “action”,
            “like”: “Microsoft.Network/routeTables/*”
       }
    ]
    },
   “then”: {
   “effect”: “audit”
    }
}

See below for the compliance once a change has been made to a UDR. Once you drill down to the event, the user, the activity log, you can then see the exact changes that were made to the UDR.

I hope this was helpful!