Workflow Automation is a new Azure Security Center feature (preview) that can trigger Logic Apps on security alerts and recommendations.
In this blog post, we will demonstrate how we can use API to build and answer more unique triggering scenarios.
Scenario
Contoso organizations leverages Azure Security Center in a large scale. One of the security departments uses Azure Security Center to manage the Protection and specifically responsible for Defender antimalware alerts and findings. This department wants to receive email’s only on alerts that are related to Defender antimalware.
Before implementing this scenario via API, let’s review the experience in the Azure Security Center dashboard. Follow the steps below to get started:
- Open Azure Security Center, and on the left navigation pane, click on Workflow automation (Preview)
- On the Workflow automation blade, click the + Add workflow automation button. The blade below appears:
3. Under Triggers conditions, you can see that the automation can be triggered by alerts or recommendations. Under Alert severity, you can also select the severity level that you want to target.
As you could see, the options available via Azure Security Center dashboard are very straight forward. Now let’s see how to create a workflow automation via API.
Workflow Automation via API
Workflow Automation feature is currently in public preview stages, it will be become GA in the coming months, and part of it we'll release a full API interface that will include PowerShell, Azure CLI.
As mentioned earlier, for this scenario we need to build a workflow automation that will trigger only when Antimalware detection arrives in ASC. To accomplish this task via API, we will leverage the workflow automation API.
The advantage of using this API is that we have more granular filtering options.
The filtering options that will be used for this scenario are:
- Filter on ASC alerts only
- Filter on AlertVendor = Microsoft Antimalware
Although we will leverage only those two filtering options, there are much more available, as shown in the list below (list reference can be found in our GitHub Repo)
- AlertName - Alert display name
- Severity - The alert severity (High/Medium/Low/Informational)
- AlertType - unique alert identifier
- ConfidenceLevel - (Optional) The confidence level of this alert (High/Low)
- ConfidenceScore - (Optional) Numeric confidence indicator of the security alert
- Description - Description text for the alert
- DisplayName - The alert's display name
- EndTime - The impact end time of the alert (the time of the last event contributing to the alert)
- Entities - A list of entities related to the alert. This list can hold a mixture of entities of diverse types
- ExtendedLinks - (Optional) A bag for all links related to the alert. This bag can hold a mixture of links for diverse types
- ExtendedProperties - A bag of additional fields which are relevant to the alert
- IsIncident - Determines if the alert is an incident or a regular alert. An incident is a security alert that aggregates multiple alerts into one security incident
- ProcessingEndTime - UTC timestamp in which the alert was created
- ProductComponentName - (Optional) The name of a component inside the product which generated the alert.
- ProductName - constant ('Azure Security Center')
- ProviderName - unused
- RemediationSteps - Manual action items to take to remediate the security threat
- ResourceId - Full identifier of the affected resource
- SourceComputerId - a unique GUID for the affected server (if the alert is generated on the server)
- SourceSystem - unused
- StartTime - The impact start time of the alert (the time of the first event contributing to the alert)
- SystemAlertId - Unique identifier of this security alert instance
- TenantId - the identifier of the parent Azure Active directory tenant of the subscription under which the scanned resource resides
- TimeGenerated - UTC timestamp on which the assessment took place (Security Center's scan time) (identical to DiscoveredTimeUTC)
- Type - constant ('SecurityAlert')
- VendorName - The name of the vendor that provided the alert (e.g. 'Microsoft')
- VendorOriginalId - unused
- WorkspaceResourceGroup - in case the alert is generated on a VM, Server, VMSS or App Service instance that reports to a workspace, contains that workspace resource group name
- WorkspaceSubscriptionId - in case the alert is generated on a VM, Server, VMSS or App Service instance that reports to a workspace, contains that workspace subscriptionIdThe first step to configure this workflow automation via API is to build the Rest API payload. Follow this documentation Create or update API. In the request body enter this relevant information
|
{ "properties": { "description": "Send Email only on Antimalware", "isEnabled": true, "metadata": { }, "scopes": [ { "description": "Send email on Alerts from the Anti malware detection", "scopePath": "/subscriptions/6b1ceacd-5731-xxxx-8f96-2078dd96fd96" } ], "sources": [ { "eventSource": "Alerts", "ruleSets": [ { "rules": [ { "propertyJPath": "VendorName", "propertyType": "String", "expectedValue": "Microsoft Antimalware", "operator": "Equals" } ] } ] } ], "actions": [ { "logicAppResourceId": "/subscriptions/6b1ceacd-xxx-xxxx96-2078dd96fd96/resourceGroups/ASC-Playbook/providers/Microsoft.Logic/workflows/ASC-Alert-To-ServiceNow/logicApp", "uri": "https://exampleTriggerUri1.com", "actionType": "LogicApp"
} ] }, "id": "/subscriptions/6b1ceacd-5731-xxxx-xxxx-2078dd96fd96/resourcegroups/cxe-yanivsh/providers/Microsoft.Security/automations/AntiMalwareAlerts", "name": "AntiMalwareAlerts", "type": "Microsoft.Security/automations", "location": "West Europe" } |
After the successful put request, open ASC portal and navigate to the Workflow automation blade and notice to the newly automation item.
It is important to mention that once a specific automation item created through an API request, you will have some editing limitation in the UI, so our recommendation is that if we need to edit this specific item, it should be done via the API.
Happy automation 
Reviewers:
@Yoav Francis