Azure Policy – Approved VM Extensions

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 (seperated 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

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 Security Center – Continuous Export

Azure Security Center (ASC) is a great 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, so they don’t have all of their eggs in one basket (sort of speak) with a single vendor. Azure Sentinel is a great solution, but still lacks maturity in comparison to other products like IBM’s QRadar, Splunk and some others.

ASC also 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, Azure’s Event Hubs is a great middleman solution.

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. Choosing the latter, we can also configure ASC to Continuously Export the data being collected in ASC to be forwarded to Event Hubs. Which in turn will allow the third party SIEM to ingest the data within Event Hubs.

Once you have enabled ASC, enrolled your resources, (assuming you have already configured Event Hubs and a third party SIEM) you can then setup Continuous Export within the ASC console as shown below.

Setting up ASC Continuous Export is pretty straightforward, provided you have already configured Event Hubs, and your SIEM to ingest from Event Hubs. Within ASC, select Continuous Export. Enable which workspace to send the data to, either Event Hubs, or Log Analytics (Sentinel). Select the type of alerts and recommendations (All, Low, Medium, High). Specify the Subscription where Event Hubs lives, the Event Hub Namespace, Name, and Policy Name. Hit Save, and that is it!

That is, pretty simple. Definitely a much easier solution than deploying Linux and Windows Agent Diagnostic (LAD/WAD) — another post for another day 🙂

Azure Security Center – Secure Score Enhancements

Over the last few days, Azure Security Center (ASC) made an update to how Secure Score is calculated. This new enachangement simplifies how the Secure Score is calculated, and in this post I would like to show how this is done.

As previously mentioned, Azure Security Center is a high-level, holistic assessment of your Azure environment. Azure Security Center can also be extended to your on-premises environment as well. Nevertheless, one of the key functionalities ASC provides is a Secure Score. Secure Score is a calculation based on your specific environment, and the resources deployed within your environment. The Secure Score  provides a ratio between your healthy resources and total resources deployed within your environment as per recommendation for each security/vulnerability.

To see your Secure Score, go to Azure Security Center, and looked for your score within the Policy & Compliance blade:

Now let’s take a look at how the Secure Score is calculated.

If you drill down to your recommendations section, you can see how each control and its potential score. You can also review how you can achieve a higher score by implementing the suggested recommendations.

If we select one of the many recommendations, we can see by implementing MFA in the environment, our overall Secure Score has the potential to increase by 10 points, or 18%.

 

To get the full list of Security Controls and each recommendations, please see Microsoft’s documentation HERE.

 

Automate and Deploy Microsoft Defender Advanced Threat Protection (MDATP) via PowerShell

A few days ago, I needed to on-board Azure Windows Server VMs with Microsoft Windows Defender Advanced Threat Protection, or in short, MDATP. Sometimes Azure Security Center (ASC) has issues with on-boarding VMs and deploying the MDATP agent. As a result, I wrote the following PowerShell script that will download the MDATP.cmd file from my Azure Blob container and install it locally to the VM. This script allows you to automate it for many VMs to the scope of a Resource Group.

Now there are a few assumptions here…

  1. Download the MDATP.cmd file from the Defender Security Center portal
  2. Remove the requirement for user consent for the MDATP execution
  3. Upload the modified MDATP file to an Azure Blob container
  4. Generated a SAS URI for the MDATP file

There are many examples on the Internet on how to go step #4. Maybe in time I will do another post.

To remove the requirement of the MDATP agent to execute based on user interaction/consent can be done by removing, or commenting out the following lines of code. Launch the MDATP.cmd file within Notepad, and add a “:” before each line of code from lines 9 through 19, except line 14. Should look something like this.

Now, update and run the following PowerShell code. You can validate the VM is calling back to the Defender Security Center portal or by running the MDATPClientAnalyzer on the VM.

#update resource as needed
$resourcegroup = "YOUR_RESOURCE_GROUP"
#get only Windows Server VMs
$vms = Get-AzVM -ResourceGroupName $resourcegroup | Where-Object {$_.StorageProfile.OSDisk.OSType -eq "Windows"} | Select-Object Name
foreach ($vm in $vms)
{
    #friendly start message to indicate which server has started
    Write-Host "Server $vm has started..."
    #create folder, do not display error if folder already exists
    New-Item -Path "C:\" -Name "MDATP" -ItemType "directory" -ErrorAction SilentlyContinue
    #download MDATP.cmd file from Storage Account with SAS URI. Execute the cmd file. Passing "Y" to continue with installation.
    Invoke-WebRequest -Uri "YOUR_URI_SAS" -OutFile WindowsDefenderATPLocalOnboardingScript.cmd; Start-Process -FilePath "C:\MDATP\WindowsDefenderATPLocalOnboardingScript.cmd" -Verb RunAs
    #sleep for 5 seconds
    Start-Sleep -Seconds 5
    #restart-server
    Restart-Computer -ComputerName $vm
    #friendly finished message to indicate which server has completed and will now reboot
    Write-Host "Server $vm has completed, reboot initiated..."
}

Azure Conditional Access – Report-Only Mode

What is Conditional Access Report-Only mode?

Not too long ago, Azure Conditional Access introduced a new feature that allows Azure Active Directory administrators to test conditional access policies and its impact without actually enforcing the policy — ie. Report-Only mode.

For starters, Azure Conditional Access allows Azure Active Directory (Azure AD) administrators to enforce a specific set of conditions to be satisfied before a user (or group) can access specific resources within Azure. For example, a policy could be something simple as, ‘Enforce all users to go through MFA in order to gain access to the Azure portal“. Or, “Only users connected to the On-Premises network can gain access to the Azure portal.

Conditional Access is one of the many layers of implementing a Zero-trust network/environment. More on that in another post…

Implementing Conditional Access policies introduces a lot of challenges to end-users as sometimes it is difficult to determine the level of impact to the end-user(s). Report-Only mode allows for a Conditional Access administrators and the policy to determine the level of impact to users before actually enforcing the policy.

In the example below, I have created a Conditional Access policy with the following conditions and controls before a user can gain access to an Azure application. In this example, that application is Azure Portal.

Overview:

All Guest Users, must go through MFA in order to be granted access to Azure Management Portal. — pretty simple. Let’s see how this is setup, and the effects of Report-Only mode.

To begin, navigate to the Azure Active Directory service within the Azure Portal. Some base requirements, you need to have an Azure AD P1 or P2 license, and you the administrator must have Conditional Access Administrator (Azure AD role) as a minimum.

Create a policy, and give it some name followed by providing various requirements/conditions/controls.

Next we need to specify the user/users/group that this policy will be applicable to (or not, see the Exclude function).

 

Next, we need to specify the application this policy will be applicable to. Here I have selected the Azure Management Portal (Microsoft Azure Management) as the Cloud app.

 

Next, we need to either block or grant access to the users and the application once they pass the controls. In this case, the user must go through MFA in order to gain access to the Cloud app.

 

Finally we will save our configuration and leave the policy as Report-Only.

 

Now we can navigate to the Sign-In logs, and audit and validate our policy. Again, since this is a Report-Only policy, we can see the level of impact it would have caused to our end-users.

For more on Azure AD Conditional Access, please feel free to visit the following Microsoft URL, https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/.