Category: Cybersecurity

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 enhancement 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 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..."
}

What’s an Azure Service Principal and Managed Service Identity?

One of the general recommendations I always suggest to customers and their environments it leverage Azure Managed Service Identities (or MSI) over the traditional Service Principal (SP). Of course, the question then becomes, well what is the difference? When should I use a Service Principal and when should I use a Managed Service Identity?

In short, the difference is pretty clear. However, let’s make sure we understand what a Service Principal is, and what are they intended for…

What is a Service Principal (SP)?

In Azure, and many cloud environments, Service Principals carry the most weight with regards to access to the environment. Service Principals are an identity created for the use of applications, hosted services and automated tools to access Azure resources. This access is and can be restricted by assigning roles to the service principal(s).

What is a Managed Service Identity (MSI)?

With Managed Identities, there are two types of identities, system-assigned managed identity and user-assigned managed identity.

  1. System-assigned Managed Identity: is created and enabled directly on an Azure service. When enabled, Azure will automatically create the identity for the instance within Azure AD and will ensure it is trusted by the subscription where the instance resides. After the Azure resource/instance is created, the system-assigned managed identity credentials are provisioned onto the instance. The lifecycle is also directly attached to the Azure instance/resource and cannot be shared with other resources. In other words, the managed identity is created within Azure AD when the resource is created, and similarly the managed identity is deleted from Azure AD when the associated resource is deleted.
  1. User-assigned Managed Identity: is created as a standalone Azure resource, where the managed identity is created by the Azure AD administrator. The managed identity is trusted within the subscription and can also be assigned and shared with multiple Azure resources. The lifecycle is not dependent on the Azure resource, in other words, when the Azure resource is deleted, the managed identity is not deleted until the Azure AD administrator manually deletes the identity.

With MSI’s Azure automatically rotates/rolls the credentials every 46 days, Microsoft provides a workflow diagram on how MSIs work with Azure VM’s and other various Azure resources. See the diagram below to understand the credential rotation workflow.

Source: https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview

What is the difference?

In short, when considering to use an MSI (Managed Service Identity) or a SP (Service Principal), also consider using a MSI for the reasons below.

MSI’s, managed the creation and automatically roll over the service principal for you. This is done by Azure in the background and requires no human/customer intervention. These credentials are rotated/rolled over every 46 days, this is a default behaviour/policy.

Use an MSI when and where available. Azure continues to grow their list of MSI’s and which resources can work with MSI’s, you can find the list HERE.

 

 

For a complete overview on MSI’s please visit Microsoft’s documentation HERE.