Azure Security posture management using Azure security Center polices.

We all know assigning Azure policies are one of the best ways to have cloud governance and a lot of organizations use the built in Azure security center initiatives or the custom created policies for securing their infrastructure/ workloads.

The article below is to throw some light on how to use Azure polices and Azure security center monitoring capabilities together to create security guardrails around network security and how the Cyber security team/ operations team can have a single pane of glass for monitoring drifts.

Before we dive in, lets quickly see what Azure security center offering are :

Azure Security Centre features cover the two broad pillars of cloud security:

Cloud security posture management (CSPM) — Security Center is available for free to all Azure users. The free experience includes CSPM features such as secure score, detection of security misconfigurations in your Azure machines, asset inventory, and more. Use these CSPM features to strengthen your hybrid cloud posture and track compliance with the built-in policies.

Cloud workload protection (CWP) — Security Centre’s integrated cloud workload protection platform (CWPP), Azure Defender, brings advanced, intelligent, protection of your Azure and hybrid resources and workloads. Enabling Azure Defender brings a range of additional security features.

Azure Defender is a CWP product with ML and AI powered threat detection capabilities that not only includes Virtual machines but also other Azure services like App service, Storage, SQL servers, Keyvault etc. Dashboard for AzD can be accessed from ( https://portal.azure.com > Security center > Azure defender ) . This comes with additional cost and customers can choose to opt for the service by selecting the AzD plan and enabling the required services

Credit : Microsoft webinars

Here we are going to use the CSPM capability of Azure security center for our use case, which comes free of cost along with Azure subscription.

The security policies enabled in Azure Security Center drive security recommendations and monitoring.

A security policy defines the set of controls that are recommended for resources within the specified subscription. In Azure Security Center, you define policies for your Azure subscriptions according to your company’s security requirements and the type of applications or sensitivity of the data in each subscription.

We can write very simple statements in JSON using the Azure policy editor to create these templates and publish them as policies ‘scoping’ to a management group, or a subscription or even a resource group based on the requirement. We could group multiple policies to an initiative which serves common goal ( like one initiative for NIST related polices, another for CIS related standards)

Before we get right into the policies, let us discuss about how some of the basics about Azure Virtual network setup and outbound internet connectivity for Azure, because the policies we are trying to create are going to address very specific network security use cases.

In general, we setup a virtual network first and then create a subnet to deploy virtual machines or other resources in Azure environment. By default all subnets are directly connected and can communicate with each other, within the same VNET.

For a given subnet, 5 IPs will be reserved for Azure internal requirements . All VNETs behind the scenes have a unique public IP assigned, which enables the workloads to communicate with the Internet, without having assigned any Public IP addresses or NAT Gateway.

We have many ways to control or alter this default behavior of the Azure outbound traffic to internet — by creating a NAT gateway, assigning public IP to a virtual machine , associating VM with a standard load balancer or finally use an NVA ( Network Virtual Appliance ) or Azure native Firewall as a Service .

For most organizations, a common approach will be to use a NVA ( Network virtual appliance) or an Azure firewall ( Microsoft Cloud firewall) and create UDR ( User Defined Route) to force tunnel the traffic, since this allows us to route the outbound traffic to an on- premises firewall or a cloud firewall to do filtering/ traffic inspection for security. There are many well-known firewall vendors providing NVAs through the marketplace, like Barracuda, Checkpoint, Palo Alto etc.

It is also a common practice for organizations to employ policies to ensure the ILPIP ( Instance level public IPs) are not associated directly to the Virtual machine and they are either on the Firewall or on the external Load balancer so it is most scalable and easy to troubleshoot for issues. We can also assign network security groups (NSG) to either a NIC or a subnet level. These NSG can be used to define five-tuple rules which can apply either for outbound or inbound traffic flow

Below picture depicts a very common model for outbound internet connectivity for Azure workloads, where the firewalls are deployed in a NVA subnet , web servers on another subnet within the Vnet , with subnet level NSGs to control east- west traffic. This could be easily extended to a HUB and SPOKE model as well where the NVA sits in a HUB Vnet and web severs deployed in a SPOKE VNet , peered to enable communication between both Vnets.

For simplicity the former scenario is depicted below. Notice the UDR on the webserver subnet to route all internet outbound traffic to NVA’s frontend LB for inspection/ firewalling and another UDR on the NVA subnet to directly route the traffic to internet.

User defined Route creation for subnets for outbound access

We are going to discuss about four different security policies which will help organizations to audit/ prevent ( based on the ‘effect’ you choose in the policy ) bypassing different security controls around the assignment of UDR, the next hop used and the usage of Internet as next hop type on the UDR and finally NSG applied on the subnet etc.

Below are the list of security guardrails we are going to discuss here ( can be used as both preventive and detective ,based on the company policies) . Here i’ am showing a mix of both.

1. Audit UDR on Subnets
2. Enforce NVA’s IP address as ‘NextHop IP’ on the UDR.
3. Enforce Next hop type is not set to ‘Internet’ for subnets created in SPOKE Vnets.
4. Audit NSG X on Subnets

For the working policy statements , check out the GitHub location here https://github.com/mmkmur/mmkmur/find/main

Caution : These are created and tested by me, but should be used only as reference. Please adjust it accordingly to your requirement and test it before applying them for your environment )

Now let’s look at these policies in detail and what they help us achieve.

1. Audit UDR on Subnets

This policy audits, if a Route table ( UDR ) is attached to the Subnet. This will help to identify any misconfigurations ( could be accidental or someone with malicious intent trying to circumvent security controls ) on UDR while creating subnets which sometimes will be difficult to identity, since workloads will take default route and connect to internet . With this policy on, we can either do an audit and report compliance or add an effect to deny the creation of subnets without having the specific UDR attached. Putting the policy and audit to begin with and later moving it to deny effect is the ideal practice to assess the risk and ensure you don’t break anything. Also by default these policy has no effect on the already existing resources even with deny effect. ( Policy enforcement will be only done for future resources)

2. Enforce NVA’s IP address as NextHop IP

This is to enforce the Next hop IPs ( NVA IPs) on a UDR rule. This policy will prevent miss configurations and enable admins to only use the specified IPs in the policy of NextHop. Azure accepts any appliance IP address which has port forwarding enabled in the NextHop field, so having this policy ensure no one can either accidently or maliciously configure the rule incorrectly, which may lead to noncompliance / data exfiltration bypassing organizational perimeter devices.

You can also tweak this policy to either use ‘Audit’ or “deny’ effects based on the requirement

3. Enforce Next hop type is not set to ‘Internet’ for subnets created in SPOKE Vnets.

It is equally important, not to allow NextHop type as ‘Internet’ for the Spoke VNETs since this will enable workloads deployed in a subnet to go directly to internet, bypassing the NVA

This addresses, a slightly different risk — but at a different configuration level as you can imagine.

4. Audit NSG X on Subnets

This policy assignment audits if a given subnet is having a specific NSG attached. If your organization has policies around ensuring all subnets must have a NSG applied, to control the east-west or north -south traffic , to achieve segmentation, this policy will help us to check compliance of your environment. You can either specify the NSG ID or tweak the policy to report if subnet is missing the NSG , and project it for noncompliance.

Once applied, the policy will provide us the compliance view from the Policy > compliance blade as below.

Note : You could group all these policies into one initiative so that it can be easily attached to the Security center custom initiate later

Azure policy compliance dashboard

Note: If you notice the compliance state as Not started, it means the Policy has been assigned, but yet to be evaluated by Azure policy against the resources. You will have to wait to get the compliance state reports.

Now comes the actual Azure security center use case to monitor them and show the ‘unhealthy’ resources in the recommendations . This will aid the security team or the infrastructure team to monitor the drift , triage or report compliance on a periodic manner.

All we need to do is to create a policy initiatives ( you may call it Network security compliance policy, for example) as mentioned earlier from these policies and then add it as a custom initiative in the Azure security center.

Navigate to Security center > Security policy > Your custom initiatives > Add a custom initiative and select the policy initiative you created

Note : This doesn’t require any license, available as a part of the free offering of ASC.

Once done you will see them under the recommendation tab as below

Azure security center recommendation window

These recommendation’s will have a ‘Custom’ flag on it so can be distinguished from other recommendations.

Also it is important to note, none of these will attract any cost on your Azure Bill ( i.e. creating Azure polices + ASC monitoring ). If you were to send this data to a 3rd party SIEM for monitoring or store the recommendations in Log analytics workspace , that will attract some cost based on the volume of alerts. )

We can define a lot of similar polices to address general misconfigurations which will act of guardrails for security enforcement and enhance the CSPM ( Cloud security Posture Management) for organizations and utilize the power of Azure security center policies to report and monitor compliance !!

Thats all for now !!. See you in the next article !