Azure Sentinel team has developed a great connector for Azure Sentinel, which you can use to automate your Logic App. The Azure Sentinel Connector currently contains the following actions:
In this blog we will focus on how to deploy a logic App configured with the correct Connection credentials for the Azure Sentinel connector through ARM template.
When adding the Azure Sentinel trigger step or an action to the logic App, we need to provide a connection which will be used to authenticate the Azure Sentinel environment:
Most of the time this is automatically created through the Azure Portal, with your current user credentials if you have the right permissions. But that’s not what we are looking for 😛 So the other option is to select “Connect with Service Principal” and provide a Client ID and secret, which will be used to access the Azure Sentinel resource:
Reader permission is enough if you only want to read data. However, if you for example want to use the “Update Accident” action from the Azure Sentinel connector suit, the SPN needs to have higher privilege’s.
Now we know that we can use a Client ID and secret to authenticate, it’s time to create the “Managed API” connection resource with the correct properties. You can achieve this with the configuration below:
So next we need to combine all the configuration and link all the resources together in the ARM template to deploy our solution. Below a simple Logic App, which contains Azure Sentinel trigger step and a “Get Incident” action:
The Logic App must always start with “When a response to an Azure Sentinel alert is triggered” step.
After deploying the above ARM template the resources below will be created:
Here you see how the Azure Sentinel actions in the Logic App are automaticity configured to use the azureSentinel connection:
Today I got a question about how to enable Azure Sentinel through ARM templates and surprisingly there was no documentation or blog about this subject online. Below the ARM template that I have used to enable Azure Sentinel trough ARM templates:
“Azure Sentinel is a cloud-native SIEM that provides intelligent security analytics for your entire enterprise at cloud scale. Get limitless cloud speed and scale to help focus on what really matters. Easily collect data from all your cloud or on-premises assets, Office 365, Azure resources, and other clouds. Effectively detect threats with built-in machine learning from Microsoft’s security analytics experts. Automate threat response, using built-in orchestration and automation playbooks.” read more
Rules in Azure Sentinel create the basic logic on which Incidents get created. Currently the only way to add, change or delete rules is through the Azure portal. As we’re running a cloud Security Operations Center at Wortell with many customers connected, doing this manually is no option for us.
At the moment there is no documented API, ARM or PowerShell module to configure Azure Sentinel. After doing some research we were able to find the API’s that are currently being used by the Azure Portal and based on that we’ve written a PowerShell module to manage Azure Sentinel through PowerShell. Continue reading Azure Sentinel PowerShell Module
A frequently asked question about rolling out Azure VNet with different subnets in a infrastructure as code environment is where and how to define the subnets in your Azure ARM template. In the most examples online the number of subnets is configured in the template and the name and addressPrefix is configured in the parameter file. The big disadvantage with this scenario is that when you deploy a VNet with for example two subnets and later you decide to add more subnets you have two choices both of which are uncomfortable for an Infrastructure as code release pipeline. Continue reading Infrastructure as Code – Deploy Azure VNet with dynamic subnets
At the moment of writing this blog it’s unfortunately not possible to move an Azure VM with Managed disk to another Resource Group or to another Description. However, Microsoft says on the Azure Portal that this will be possible in the near feature. For the time being, I have chosen to write a small PowerShell script that will do the move fully automated for you. At the moment the only way to move an Azure VM with Managed Disk to another resource group is redeploying the VM. To achieve this you need to perform the following steps (some from the portal and some from PowerShell) manually:
- Shutdown VM
- Collect the required information like Networking, VM size, Storage etc.
- Create a Snapshot
- Create or use an existing Azure Storage Account to copy the Snapshot to
- Remove the VM
- Create a new Azure VM in the new Resource Group with the collected information and Snapshot disk from the Azure Blob
- The Azure VM will start automatically, check if the VM functions as it should and remove the Snapshot and Azure Storage Account.
As you can see there are about 7 steps needed to move an Azure VM with a Managed Disk. The script that I have written will do all the steps automatically with only 3 variables that you need to define while running the script. Continue reading Move Azure VM with Managed Disk to another Resource Group