Automate SecOps to Developer Communication with DevOps Security in Defender for Cloud
Automate SecOps to Developer Communication with DevOps Security in Defender for Cloud Logic Apps are a workflow automation feature of Microsoft Defender for Cloud (MDC) in which you can create and run automated workflows that integrate your apps, data, services, and systems. Customer feedback has been loud and clear—Security Teams need more efficient and effective ways to communicate directly with Development Teams about discovered security findings. This blog walks through creating a Logic App that Security Teams can use to automate communication of discovered security issues to Development Teams. The Logic App creates a Work Item in Azure DevOps (ADO) containing repository location, description, and remediation information from DevOps security in Defender for Cloud Recommendations that Developers can use to remediate the discovered security issue. Security Operators will find this Logic App particularly useful because they do not need to be familiar with Azure DevOps or even to login to Azure DevOps to create a Work Item for their Developers. Instead, SecOps can trigger a Logic App on an affected repository and create a Work Item for a Development Team to triage and remediate. Objectives: Create a Logic App to create an Azure DevOps work item from an MDC Recommendation Test the Logic App Prerequisite: Connector provisioned in MDC to your Source Code Management System (such as Azure DevOps or GitHub) Create a Logic App to Create an ADO Work Item Login to Azure and search for or click Logic Apps Click + Add Choose a Subscription and Resource group Enter a name for your Logic App Under Plan, choose Consumption Click Review + create Click Create Go to the Logic App you created and click Logic app designer in the left menu Click Blank Logic App In the search box, type Recommendation Choose When a Microsoft Defender for Cloud Recommendation is created or triggered Click + New step Type variable in the search box Choose Initialize variable For Name, type org_name For Type, choose String Click + New step Type variable in the search box Choose Initialize variable For Name, type project_name For Type, choose String Click + New step Type variable in the search box Choose Initialize variable For Name, type repo_name For Type, choose String Click + New step Type variable in the search box Choose Set variable For Name, choose org_name from the dropdown menu For Value, click in the empty box In the Add dynamic content flyout, click Expression and type the following: first(skip(split(triggerBody()?['properties']?['resourceDetails']?['id'],'/'),10)) and click OK Click + New step Type variable in the search box Choose Set variable For Name, choose project_name from the dropdown menu For Value, click in the empty box In the Add dynamic content flyout, click Expression and type the following: first(skip(split(triggerBody()?['properties']?['resourceDetails']?['id'],'/'),12)) and click OK Click + New step Type variable in the search box Choose Set variable For Name, choose repo_name from the dropdown menu For Value, click in the empty box In the Add dynamic content flyout, click Expression and type the following: first(skip(split(triggerBody()?['properties']?['resourceDetails']?['id'],'/'),14)) and click OK Click + New step Type azure devops in the search box Click Create a work item Click Sign in Click Accept to allow the App request for the Logic App to write to Azure DevOps For Organization Name, click in the box, click Enter custom value In the Add dynamic content flyout, click org_name For Project name, click Enter custom value In the Add dynamic content flyout, click project_name For Work Item Type, type task For Title, click in the box, type the title of the work item you want to create for your Developers, such as: A security issue needs to be remediated from the following repo: In the Add dynamic content flyout, click repo_name For Description, type Description: In the Add dynamic content flyout, click Properties Metadata Description, then hit enter twice Type Remediation steps: then hit enter In the Add dynamic content flyout, click Properties Metadata Remediation Description Your Logic App should now look like the following: Your no code Logic App is now complete and needs to be tested. Test the Logic App Navigate to Microsoft Defender for Cloud Click Recommendations Expand Remediate vulnerabilities, click Code repositories should have secret scanning findings resolved Expand Affected resources, tick an Azure DevOps repository Click Trigger logic app In the Selected subscription dropdown, choose the Subscription that contains the Logic App Tick the box next to the Logic app Click Trigger Now let’s verify that your work item has been created Login to Azure DevOps and navigate to the Project with the repository you tested Click Boards, then click Work items to see the work item that you created Your work item should look similar to the following work item: Conclusion To review, we’ve walked through creating a Logic App that creates a Work Item in Azure DevOps to communicate with Developers so they can remediate security findings discovered by Microsoft Defender for Cloud. This Logic App can be executed on any Azure DevOps repository. It injects the location, description, and remediation steps in the Work Item description body so that Developers can quickly find and fix the security issue. This helps Security Operators automate communication with Developers by creating a Work Item that the Development Team can then prioritize in their Sprint Planning sessions. Additional Resources To learn more about DevOps security in Defender for Cloud, read this documentation Download (free) a special Appendix about DevOps security in Defender for Cloud from the latest Microsoft Defender for Cloud book published by Microsoft Press To learn how to onboard your Azure DevOps Source Code Management System to Defender for Cloud, read this documentation for Azure DevOpsManaging Security Center at scale using ARM templates and Azure Policy
*** Update: This blogpost has been updated with a new ARM template and new Azure Policy definitions which covers the new Security Center bundle pricings. The new ARM template can be found here, the new Azure Policy definitions can be found here *** Recently we have been receiving several customer questions on how to manage Security Center at scale in a continuous integration (CI) and continuous delivery (CD) scenario, better known as CI/CD. How do you make sure that when a new subscription is instantiated, Security Center is configured correctly and is enabled to monitor new and existing resources? How do you manage hundreds of subscriptions within your organizattion? How do you enforce your security policies? This blogpost covers two scenarios: Configure Security Center using an ARM template to support a CI/CD scenario and management at scale Enforce a Security Center configuration within your organization, using Azure Policy Since both ARM templates and Azure Policy talk to the Resource Manager API in Azure, by making a JSON formatted request, you can re-use the deployment section of an ARM template to author an Azure Policy definition. If you are new to ARM templates and are looking for guidance on authoring, go here. In case you want to leverage PowerShell for configuring ASC, go here. The Security Center ARM Template Every ARM template consists of these 7 elements (not all of them have to be used): It’s the “resources” element that we are interested in since the ARM template reference for Security Center hasn’t been documented yet. We are in the process of publishing which makes it easier to find which types and values are allowed and will also provide IntelliSense. I will update this post when that becomes available. In this blogpost I will cover the two most asked questions: How can I make sure that Security Center is configured for the Standard pricing tier, which unlocks all the Security Center features How can I enable auto provisioning, which enables automatic installation of the Microsoft Management Agent (MMA) VM extension for new resources. Please refer to the pricing tier documentation for the difference between the Free and Standard tier. Set the ASC pricing tier in an ARM template The new pricing tier API is fast and efficient to use. We are using the Microsoft.Security/pricings type to set our pricing tier. How does that look in a template? The ARM template can be found here. If you want to deploy this template, please make sure you target the subscription instead of a resource group. This is a common made mistake, since ASC lives at the subscription level, not at the resource group level. A deployment would look like this (using PowerShell): New-AzDeployment -Name myAscDeploy -Location <yourLocation> -TemplateFile ‘<yourTemplateFileAndPathHere>' -Verbose Since you have probably noticed the usage of a parameter, so you can flip it from “Free” to “Standard” or the other way around, you will be prompted for this value. Please note that we are only allowing the two values specified and it is case sensitive. You can verify the deployment in the activity log: Leveraging the ARM template to create an Azure Policy Now that you have a working ARM template, you can use it to create a deployIfNotExists type of Azure policy which allows you to remediate if the policy definition is non-compliant. If you are just starting with Azure Policy, I would recommend to explore our documentation for guidance on different policy definitions. Leveraging the ARM template we just created, you can construct a deployIfNotExists Azure Policy. You first need to create the section that allows you to find the pricingTier field and value (Standard). For this to work, you need to target your Policy at the right scope (subscriptions or higher), then you define the “effect” (deployIfNotExists) and you set the type to Microsoft.Security/pricings, where the field and value lives which we are looking for. If the existenceCondition returns false and you want to remediate it, you need to define a deployment section under the resources section, where you define your target type and properties. You can find the Azure Policy shown above here. Having your ARM Policy defined, you can now create and assign your new Azure Policy. Please note that you need the appropriate permissions to create a managed identity. This ensures that the policy has the appropriate permissions to change the Security Center configuration at the subscription level. It takes around 30 minutes for the policy to take effect as mentioned in the confirmation. Your policy will remain in this state for a while: Then after around 30 minutes, you will notice a non-compliant assignment, as shown below. If you click on the assignment, you can explore which resource is non-compliant. You can click on Create Remediation Task to remediate it. Automatically create a remediation task In case you want to use automation, you can leverage the Policy Insights API to create a remediation task. One of the options you have is to invoke the API using PowerShell. The script below shows an example how to accomplish that. Please note that besides the subscriptionId, you need to pass a remediationName and policyID: You can find the script to create a remediation task here. If you have succesfully executed the script, you should see something similar in your activity log: Your ASC pricing tier should be changed to Standard and after a policy refresh cycle, your compliance state should be updated to compliant. Configure Security Center auto provisioning using a custom workspace The following ARM template enables auto provisioning so that the Microsoft Management Agent VM extension will be deployed automatically to new created virtual machines. You will also configure a custom Log Analytics workspace instead of the default Security Center one. The ARM template for enabling auto provisioning can be found here. Please note that you need to pass specific parameters values for configuring the Log Analytics workspace like workspace name, the resource group of the workspace and the Azure subscriptionID of where the workspace is created. Deployment of the ARM template is straightforward as you have seen before while deploying the pricing tier template and should look like this:Policy Distribution Dashboard for Microsoft Defender for Cloud
Understanding the current state of your environment is the first step towards improving its security posture. Microsoft Defender for Cloud is designed to strengthen the three pillars every enterprise relies on which is Protection, Detection & Response providing you CSPM & CWPP functionalities. In Defender for Cloud, the posture management features provide Visibility and hardening guidance and the central feature that enables you to achieve these goals is Secure Score. Defender for Cloud continually assesses your resources, subscriptions and organization for security issues, and it aggregates all the findings into a single score by providing you list of recommendations. Typically, these are gaping holes that need to be fixed ASAP, while some recommendations are more long-term or just less critical and some more critical. Current Challenge One of the questions we constantly get asked is, How do I ensure that the Security posture will not start deteriorating again after the fixes have been made (or) how do I ensure I apply guardrails at the beginning of deployment phase for every service in Azure. It is often the case that development teams have full control of their subscriptions/resources. As a result, the configurations start to drift. The cure is simple, we need to have a security baseline defined. Before you start reading about the proposed solution, it is important to understand, Defender for Cloud and Azure policies work together to help monitor and report on compliance in your environment. Like security policies, Defender for Cloud initiatives are also created in Azure Policy. You can use Azure policy to manage your policies, build initiatives, and assign initiatives to multiple subscriptions or for entire management groups. The default initiative automatically gets assigned to every subscription in Defender for Cloud and that is Azure Security Benchmark. Azure Security Benchmark (ASB) consolidates Microsoft security best practices in Azure. It’s a great resource for design decisions, and the controls are mapped to industry standards. We have also created a policy set in Azure which can be used for monitoring resource compliance against the baseline. This widely respected benchmark builds on the controls from the Center for Internet Security (CIS) and National Institute of Standards and Technology (NIST) with a focus on cloud-centric security. Almost every recommendation from Defender for Cloud has an underlying policy that is derived from a requirement in the benchmark. To learn about the built-in policies that are monitored by Defender for Cloud, check this out. Here you can find all the Azure Policy definitions in the Defender for Cloud category. Proposed Solution Up until now, there was no single view with which you could visualize all the policies you have assigned to monitor compliance of your environment. You had to browse through many different blades in Azure to assess and obtain this information. With this blog, I’m introducing you to a workbook that acts as a single pane of glass representing the policies and baselines across multiple subscriptions in Azure, in your environment as the first crucial step is to inventory and gain visibility. What’s in the Dashboard The new Policy Distribution Dashboard for Microsoft Defender for Cloud provides a unified view and deep visibility into the configuration of your overall policy structure in Azure. The dashboard is powered by Azure Resource Graph (ARG) queries and divided into different sections. The workbook can be edited, and all queries can be modified to meet your needs. The workbook provides different sections like: Initiatives that’s assigned to the subscriptions The recommendations that are exempted and that are policy disabled List of Custom policies Regulatory Compliance Assessment State Policies by effect Compliance by policy assignment How to Deploy The Policy Distribution Dashboard is available in the Microsoft Defender for Cloud GitHub Repo page, under Workbooks and can be accessed directly with its direct URL The workbook can be deployed quickly in the Azure Commercial and Gov cloud environments by clicking the respective “Deploy to Azure” buttons on the workbook page. How to Use To use this dashboard, you need at least Reader permission at the subscription level. Assuming you have the required permissions, watch the screen capture below to learn about how to navigate through and use the dashboard. Conclusion The Policy Distribution dashboard provides valuable information about your policy assignments and it’s status. The workbook is available to all customers free of charge and does not require you to be a paid customer of Microsoft Defender for Cloud. Additional Resources To learn more about Microsoft Defender for Cloud, visit: https://aka.ms/ascninja To learn about Microsoft Defender for Cloud workbooks, visit: https://docs.microsoft.com/en-us/azure/security-center/custom-dashboards-azure-workbooks Acknowledgements Special thanks to Lior Arviv for the partnership in reviewing and providing feedbacks on the artifact and reviewing article. Many thanks to @Rebecca Halla & YuriDiogenes in supporting this initiative and suggesting feedbacks.Automate DevOps Security in Defender for Cloud Recommendation Remediation
Automate DevOps Security in Defender for Cloud Recommendation Remediation Logic Apps are a workflow automation feature of Microsoft Defender for Cloud in which you can create and run automated workflows that integrate your apps, data, services, and systems. This blog walks through creating a Logic App that you can use to auto-remediate the DevOps security recommendation in Defender for Cloud called “GitHub repositories should have Dependabot scanning enabled” by enabling Dependabot on a GitHub repo. Security Operators will find this Logic App particularly useful because they do not need to be familiar with GitHub or login to GitHub to enable Dependabot scanning. Instead, SecOps can enable Dependabot open source dependency scanning remotely and on numerous repositories by using Logic App automation. Objectives: Create a Logic App to enable Dependabot in GitHub Create a PAT Token and secure it in Azure Key Vault Test the Logic App Prerequisites: Key Vault – for Personal Access Token secret Connector provisioned in MDC to your GitHub Source Code Management System Sample GitHub repository – with Dependabot disabled Create a Logic App to enable Dependabot on a GitHub repo Login to Azure and search for or click Logic Apps Click + Add Choose a Subscription and Resource group Enter a name for your Logic App Under Plan, choose Consumption Click Review + create Click Create Go to the Logic App you created and click Logic app designer in the left menu Click Blank Logic App In the search box, type Recommendation Choose When a Microsoft Defender for Cloud Recommendation is created or triggered Click + New step Type variable in the search box Choose Initialize variable For Name, type repo_name For Type, choose String Click + New step Type variable in the search box Choose Initialize variable For Name, type owner For Type, choose String Click + New step Type variable in the search box Choose Set variable For Name, choose repo_name from the dropdown menu For Value, click in the empty box In the Add dynamic content flyout, click Expression and type the following: first(skip(split(triggerBody()?['properties']?['resourceDetails']?['id'],'/'),12)) and click OK Click + New step Type variable in the search box Choose Set variable For Name, choose owner from the dropdown menu For Value, click in the empty box In the Add dynamic content flyout, click Expression and type the following: first(skip(split(triggerBody()?['properties']?['resourceDetails']?['id'],'/'),10)) and click OK For this Logic App to execute securely, you need a Personal Access Token (PAT) to use in the API request. Follow the steps here in the GitHub documentation to create a PAT: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token Important: The PAT needs permissions to enable Dependabot—which requires Full control of private repositories After you create a PAT, this should be stored in a Key Vault to keep it secure and accessible by the Logic App. Add the PAT as a secret to your Key Vault. Click Save on the Logic App canvas. Navigate back to the Logic App Click Identity On the System assigned tab, set status to On Click Save, then Yes Click Azure role assignments Click + Add role assignment In Scope, choose Key Vault. In Subscription, choose the subscription with your Key Vault. In Resource, select the Key Vault. In Role, choose Key Vault Reader Click Save Navigate back to the Logic App Click Identity On the System assigned tab, copy the Object (principal) ID Navigate to your Key Vault Click Access policies Click + Create In the Secret permissions list, tick Get and List Click Next Paste the Object (principal) ID that you copied earlier in the Search by box Click the Identity and click Next Click Next, then click Create Click Add, then click Save Navigate back to the Logic App Click Edit to go to the Logic Apps Designer Click + New step Type key vault in the search box Choose Azure Key Vault, click Get secret Click Connect with managed identity Type a Connection name, then type your Key Vault name in the Vault name box Click Create Choose your secret from the Name of the secret dropdown list Click + New step Type HTTP in the search box and click HTTP In Method, choose PUT. In URI, type https://api.github.com/repos///vulnerability-alerts. Put your cursor after repos/ and in the dynamic content click owner Move after the next / and click repo_name from the dynamic content In Headers, for Enter key type Accept and for Enter value type application/vnd.github+json In Headers, for Enter key type Authorization and for Enter value type token <space> click Value in the dynamic content Your HTTP step should now look like the following: Click Save to save the workflow Your no code Logic App is now complete and needs to be tested. Test the Logic App Navigate to Microsoft Defender for Cloud Click Recommendations Expand Enable enhanced security features, click GitHub repositories should have Dependabot enabled Expand Affected resources, tick a GitHub repository Click Trigger logic app In the Selected subscription dropdown, choose the Subscription that contains the Logic App Tick the box next to the Logic app Click Trigger Now let’s verify that Dependabot has been enabled Navigate to the GitHub repository that did not have Dependabot enabled Click Settings Click Code security and analysis You should now see that Dependabot alerts is enabled Conclusion To review, we’ve walked through creating a Logic App to auto-remediate the MDC recommendation: “GitHub repositories should have Dependabot scanning enabled” by enabling Dependabot on a GitHub repo. This helps harden the security on your organization’s GitHub repositories and provides Security Operators with visibility into your organization’s open source dependencies via Dependabot scanning findings. Additional Resources To learn more about DevOps security, read this documentation Download (free) a special Appendix about DevOps security from the latest Microsoft Defender for Cloud book published by Microsoft Press To learn how to onboard your GitHub Source Code Management System to Defender for Cloud, read this documentation for GitHubUsing Azure Security Center API for Workflow Automation
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.Automation to Block Outgoing Traffic to Malicious Websites detected by Microsoft Defender for DNS
One common type of security attack that occurs when an attacker has gained access to a virtual machine is that they will attempt to go to suspicious IP addresses. Attackers may do this for any number of reasons, including to perform data exfiltration from your Azure resources using DNS tunnelling, download malware to communicate with command and control servers, perform DNS attacks which is communication with malicious DNS resolvers, and to communicate with domains used for malicious activities such as phishing and crypto mining. All of these activities can be detected by Microsoft Defender for DNS, which is part of Microsoft Defender for Cloud. When the outgoing traffic has been detected to be to suspicious IP addresses by the Microsoft Defender for DNS plan, Microsoft Defender for DNS will trigger an alert. Some ways to investigate the alert can be found in the Take Action tab of the alert: In this case, we recommend that you set up the following workflow automation, which will automatically block this attack from occurring by creating a network security rule in the virtual machine's network security group to block outgoing traffic to this malicious IP address. What are the prerequisites for this automation? The Microsoft Defender for DNS plan should be enabled, as per here. You should have deployed a VM the standard way with any operating system. Note: It’s not guaranteed for this automation to succeed correctly if the VM is using a domain controller or if the DNS is sent through a DNS server in the VNET. This automation can be utilised for the alerts that come from Defender for DNS that contain the malicious IP address that the attacker is attempting to go to. You can validate this by creating these alerts yourself on the VM by following the instructions here. This automation can be used on the following alerts: Attempted communication with suspicious sinkholed domain Network intrusion detection signature activation Communication with suspicious random domain name Communication with possible phishing domain Anonymity network activity Anonymity network activity using web proxy How does the automation work? When Microsoft Defender for Cloud detects someone is attempting to go to a malicious IP address from your virtual machine, it triggers an alert to bring you awareness about this potential attack. The automation uses this alert as a trigger to block the outgoing traffic of the IP by creating a security rule in the NSG attached to the VM to deny outbound traffic to the IP address attached to the alert. In the alerts of this type, you can find the outbound IP address appearing in the 'address' field of the alert. The Logic App uses a system-assigned Managed Identity. You need to assign Contributor permissions or Security Reader and Network Contributor permissions to the Logic App's Managed Identity so it is able to create an NSG rule once there is an attack detected. You need to assign these roles on all subscriptions or management groups you want to monitor and manage resources in using this playbook. Note: You can assign permissions only if your account has been assigned Owner or User Access Administrator roles, and make sure all selected subscriptions registered to Microsoft Defender for Cloud. Refer to the Readme file in our GitHub Repository for detailed procedure. Deployment process and details Navigate to Microsoft Defender for Cloud GitHub repository and select “Deploy to Azure” as shown in Image 1: Image 1: Git Hub repository Once you have clicked on ‘Deploy’ option in the screen above, you should automatically be redirected to the Azure portal Custom deployment page where you can fill in the details of requirement as shown in Image 2, as shown below: Image 2: Azure portal, Custom Deployment The ARM template will create the Logic App Playbook and an API connection to Office 365, and ascalert. You need to authorize the Office 365 API connection so it can access the sender mailbox and send the email notification from there. Once you review and create from Image 2, you would notice below resources created from the ARM template (Refer Image 3) Image 3: Summary of the resources created from the ARM template Define when the Logic App should automatically run: Workflow automation feature of Microsoft Defender for Cloud can trigger Logic Apps on security alerts and recommendations. For example, you might want Microsoft Defender for Cloud to email a specific user when an alert occurs. When you add the workflow automation and trigger conditions, the triggers will initiate this automatic workflow. In this example, you want the Logic App to run when a security alert that contains "domain" is generated. Note: Read more about workflow automation here When an attempt to go to a suspicious domain is detected by Microsoft Defender for Cloud as shown in Image 4, this would automatically apply the automation and blocks the traffic of the IP by creating a security rule in the NSG attached to the VM to deny outbound traffic to the IP address associated with the json of the alert as shown in Image 4. Image 4: IP blocked by Microsoft Defender for Cloud You would receive an email notification on the alert details as shown in Image 5: Image 5: Email received to show automation has been triggered This logic app as well as many other can be found here: Direct Link to GitHub sample Microsoft Defender for Cloud GitHub Repo Most organizations lack the time and expertise required to respond to these alerts so many go unaddressed. Having this type of automation can address the threat immediately. I hope you enjoyed reading this article and implementing it! Special thanks to: Tom Janetscheck, Senior Program Manager, Microsoft Defender for Cloud, Microsoft Safeena Begum Lepakshi, Senior Program Manager, Microsoft Defender for Cloud, Microsoft Ido Keshet, Senior Program Manager, Microsoft Defender for Cloud, Microsoft Thomas Vuylsteke, Senior Customer Engineer, Microsoft YuriDiogenes, Principal PM Manager, Microsoft Defender for CloudAzure Security Center & automatic creation of an incident in ServiceNow
In my previous blogpost I talked about how to create a Logic Apps playbook which creates a ticket in ServiceNow. In this blogpost we will look at how to automatically create a ticket in ServiceNow when a Security Center alert is raised. Note: Automatic triggers for Logic App with Azure Security Center will be released in the future Now that you can create a ServiceNow record by selecting and starting the playbook in Azure Security Center, you are going to explore how to automate this end-to-end. The benefit of this approach is that there’s no human action necessary to run the playbook. If Azure Security Center generates an alert, a record will be created automatically. For this to work you are going to leverage the following: A classic Azure alert, which is part of Azure Monitor An Action Group which serves as what to do if an alert is raised, in this case start the playbook automatically for you A second playbook which will be started by the Action Group To avoid duplicate records being created based on the same Azure Security Center alertID, you are going to add a custom field in ServiceNow which will be populated with the Azure Security Center alertID. Leveraging this field, we can validate if a new record should be created. Please refer to the ServiceNow documentation for more information about how to add a custom field. Open an existing incident in ServiceNow and right click in the top for the form Select Configure, Form Layout and under Create new field enter ASC_AlertID as the Name and select Medium (100) as the Field length. Click on Add and then Save the new field. 3. Navigate to the Azure Security Center portal and under Automation and Orchestration, select Playbooks 4. Click on Add Playbook 5. Provide a name for your new playbook like “ASC-Automatic-Ticket-To-ServiceNow” and fill in the resource group and location fields. The Log Analytics integration offers capabilities like using search to query the status and history of your playbooks. Click on Create 6. In the Logic Apps Designer select the Blank Logic App template 7. Select When a HTTP request is received as the trigger 8. In the Request Body JSON Schema box you need to add the Azure Monitor schema which can be found here. Refer to step 8 in the article and copy the Azure Monitor JSON schema 9. Click on the Use sample payload to generate schema link 10. Paste in the JSON schema you just have copied 11. Since Azure Monitor provides you with a JSON formatted input, you need to parse it so that you can use it in a more structured way for our purpose. Click on + New Step and search for parse json and select it 12. Select the Body as Content 13. For efficiently using the Azure Security Center alert information, you need to provide a schema. 14. Navigate to this link and copy the Azure Security Center alert schema 15. Paste the copied schema into the Schema body 16. Now you are going to add a new step which will check if a record already has been created based on the Azure Security Center alertID. If not, we will create a new record. Click on + New Step, search for ServiceNow and add a List Records step 17. Select Incident as the Record Type 18. Under Query add u_asc_alertid= and the correlationId field from the previous step. Fill in the other fields as shown below. Your List Records configuration should look like this: 19. To check the existence of a ServicNow record based on the Azure Security Center alertID, you are going to add a Condition as a new step. Leverage the Expression field to validate if a record has been returned by entering this expression: empty(body('List_Records')['result']) 20. Enter true in the field next to is equal to. Your Condition configuration should look like this: 21. If your statement is “true”, then no records have been found with the same Azure Security Center alertID and we need to create a new record 22. Within the If true block, click on + New Step and search for ServiceNow 23. Select Create Record as the action Note: Since we have already created a connection previously, we are going to re-use that connection. Logic Apps automatically selects that connection for you 24. Select Incident as your Record Type: 25. Now add the Azure Security Center alertID field by adding correlationId in the ASC_AlertID field of the ServiceNow incident properties. This value comes from the Parse JSON step and should look like this: 26. Add values to the remaining fields like Short description, Description and Resolution notes: 27. Add any additional steps like Send an email: 28. Save the playbook Creating an Action Group For invoking a Logic Apps playbook automatically based on an Azure Security Center alert being generated, you are going to leverage Azure Action Groups in Azure Monitor. Navigate to the Azure portal and click on Azure Monitor Under Settings, click on Action Groups and click on Add action group 3. Give you new action group a name like “ASC-Alert-ActionGroup” and fill in the remaining required fields 4. Under Actions, provide an Action Name and under Action Type, select your “ASC-Automatic-Ticket-To-ServiceNow” Logic Apps playbook and click on OK to save it Creating an Azure Classic Alert Navigate to Azure Monitor -> Alerts (classic) -> Add activity log alert Under Event Category, select Security Under Operation name, select Activate Alert (locations/alerts) Under Alert via make sure to select the action group we have created earlier: 5. Save the alert Test driving the playbook Every Security Operations Center (SOC) wants to ensure that that any automation, specifically creating tickets based on security alerts, works as expected. To test if your playbook automatically starts when an alert is generated, you need an Azure Security Center alert. One option to safely generate an Azure Security Center test alerts is described here. Verify that you have a new alert in Azure Security Center, like the one below: Switch over to ServiceNow and you can see that an automatic alert has been generated: In case you have configured an email notification step, you should receive an email like the example : Start automating Security Center actions with playbooks and ServiceNow today. For more information on Azure Security Center, playbooks, and ServiceNow, visit our documentation below. Azure Security Center documentation Azure Security Center playbooks ServiceNow ITSM solution ServiceNow developer instance
