To collect events in Azure Sentinel from VMs and servers, we use the Microsoft Monitoring Agent. The MMA supports both Windows and Linux operating systems independently of where they run: on-premise, Azure or other clouds. The agent may be installed on Windows or Linux VMs by using one of the following methods:
There is a very convenient and fast approach for making sure all of your Azure VMs are onboarded into Azure Sentinel, using an Azure Policy that can audit settings inside the machine and then using the VM extensions installation as a remediation task if the agent is not present. However, it was only available for Azure VMs ; for non-Azure deployments, we had to do a manual installation, what if we could have a similar experience for those servers as well?
Azure Arc for servers allows us to extend Azure Policies and extensions outside the boundaries of Azure, this makes non-Azure VMs first class citizens in Azure management plane. On this article we will focus on how you can not only automate the MMA installation using extensions but also leveraging Azure Policies to warrantee all servers are reporting events to Azure Sentinel.
To apply policies to non-Azure VMs you must first deploy the Azure Arc agent, so it is registered into ARM. Having this agent and using Azure as the management control plane will also come with a set of new benefits:
You could deploy this agent manually or automate the installation with tools like:
Now that external resources are connected to Azure, you can start managing them in a similar way you’d do in Azure. A very common way to make sure all of your VMs are reporting events to Sentinel would be to set up an Azure Policy at subscription or Resource Group level so, why not do the same for non-Azure Linux and Windows systems?
This article, shows the steps needed to set up a policy that will act as built-in control to make sure all your servers are reporting to you Azure Sentinel Log Analytics Workspace.
We will set up an initiative at resource group level to make sure that all Azure Arc enabled servers are reporting to Azure Sentinel, including on-prem and other cloud servers. Since we can install extensions on Azure Arc enabled VMs, we can use deployIfNotExist policies to automatically remediate non-compliant resources and install the MMA as an extension.
First, I created a Linux Virtual machine in Google Cloud Platform and installed the Azure Arc agent. As a result, you will be able to see this GCP VM on Azure as an Azure Arc connected VM that is now mapped to a Resource Group, Subscription and Region.
Now we can set up an Initiative to the Resource Group, In this case we will set up the initiative called “Enable Azure Monitor” and the scope will be the Resource Group (you could also apply it to the entire subscription).
As part of the initiative, we need to provide the Log Analytics workspace we want to use to configure the agent to connect to. In this case, we will provide the information of the Log Analytics workspace where we have enabled Azure Sentinel.
Then we also have the option to define how the policy should act in case it finds resources that are non-compliant, using a remediation task. The initiative we are using is of the type deployIfNotExists, therefore it has the option to modify the not compliant resource so it can be put into a compliant state. The remediation task we will use is “Deploy Log Analytics agent to Linux Arc machines”, the task will leverage the Azure Arc agent to deploy MMA as an extension.
Once you have assigned the initiative, you will see that it will be evaluated (it may take 30 minutes to run the scan) and show that the server on GCP is not compliant.
After we run the remediation task, we will see that the extension is deployed to the VM and we have a compliant Azure Policy report, with a Linux VM reporting to our Sentinel Log Analytics workspace.
We can also verify that we are collecting hearbeats and security events from the VM.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.