Managing 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:Using 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.Automate Azure Security Center actions with Playbooks and ServiceNow
Logic Apps provides an excellent way to automate Azure Security Center actions like responding to alerts or recommendations. In this blogpost, we will create a Logic Apps playbook that will create a record in ServiceNow. This prevents you from manually creating a ticket in ServiceNow and populate the fields that the playbook can automatically fill in for you. Add a Security Center playbook to integrate ServiceNow Logic Apps has out of the box integrations with third party vendors like ServiceNow, this makes it very easy to integrate Azure Security Center. We can leverage ServiceNow Record actions like Create, Delete, Get, Update, etc. Navigate to the Azure Security Center portal and under Automation and Orchestration, select Playbooks Click on Add Playbook Provide a name for your new playbook like “ASC-Alert-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 In the Logic Apps Designer select the Blank Logic App template Search for Azure Security Center and select When a response to an Azure Security Center alert is triggered as the trigger Note: adding the Azure Security Center trigger makes your playbook visible in the Azure Security Center alerts blade 6. Click on + New Step and search for ServiceNow 7. Select Create Record as the action 8. To continue, you need to create a ServiceNow connection Note: if you don’t have a ServiceNow environment you can sign up here for a developer instance 9. Fill in the required fields to create the connection 10. Now you need to pass values from the Security Center alert trigger so that we can automatically populate the ServiceNow record. For creating a new incident record, we need to populate at least the Caller and Short description field as shown in the ServiceNow Incident New Record screen: 11. Back to your Logic Apps Playbook ServiceNow action, select Incident as your Record Type: 12. Fill in the values for at least Caller and Short Description, but you can add any alert fields which are of interest: 13. Save your Logic Apps playbook, your playbook should look like this: 14. Switch to Security Alerts in Azure Security Center (under Threat Protection). 15. Click on the security alert, you should see something similar like this: 16. Click on the alert one more time, which reveals the alert details, and the View playbooks button becomes available: 17. Click on the View playbooks This shows which playbooks are available in Azure Security Center 18. Click on the Run button to start the playbook you have created. This will pass the alert information and context. Note: The Run history tab shows previously invoked playbooks and status 19. After the playbook has ran successfully, you can see the record created in ServiceNow: How to automate this end to end? Look at this blogpostAutomation to block compromised identity detected by Microsoft Defender for Resource Manager
If an account is compromised you would disable the account temporarily, revoke all the associated authentication token, and reset the password. To automate this process, you can use the Azure Logic App we have developed to disable the account, revoke all the active tokens and notify the account’s manager if it exists or simply to a designated email address.
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 GitHubAutomate 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 DevOpsPolicy 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.
