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 DevOpsDevOps Security Workbook
DevOps Security Workbook Workbooks provide a flexible, customizable canvas for data analysis and the creation of rich visual reports. The new DevOps Security workbook in Microsoft Defender for Cloud (MDC) provides you with a unified interactive experience enabling you to quickly gain visibility and insights into your DevOps security posture in coordination with the newest MDC service Defender for DevOps. The DevOps Security workbook provides you with a customizable foundation that helps you visualize the state of your DevOps posture for the connectors you have configured. You can investigate credential exposure, including types of credentials and repo locations. Then you can do the same for code, dependencies, and hardening. Objectives: Create a centralized view of DevOps security to inform investigations and enable reporting capabilities for your organization Overview - summary view of code, secrets, OSS vulnerabilities, and posture scan results Secrets - view of exposed secrets in repositories Code - view of code scanning results in repositories OSS Vulnerabilities - view of OSS vulnerabilities in repositories Infrastructure as Code - view of IaC misconfigurations in repositories Posture - consolidated view of security posture across connected DevOps environments Threats & Tactics - summarized view of attack exposure across connected DevOps environments Prerequisite: To leverage the DevOps Security Workbook you must have a connector provisioned in MDC to your Source Code Management System (such as Azure DevOps or GitHub) Access the Workbook Navigate to Defender for Cloud, click on Workbooks, then click on DevOps Security (Preview) to launch the Workbook. Overview Page The Overview page is the aggregated information for the DevOps Security Workbook. The Help button shows a description for each tab and links to each DevOps Recommendation in Defender for Cloud. The Overview graphs show overall secrets exposure, cumulative code scanning findings, and all DevOps Recommendations by severity. The top repositories requiring attention, ordered by discovered security issues, are listed below each graph. Secrets Page The Secrets page shows the repositories and the exact location—down to the line of code—where a secret has been found in a source file. Data also includes the type of secrets found across repositories. This enables Security Operators to know what types of secrets are commonly exposed in your organization and where to go to immediately disable compromised secrets in cloud resources and workloads. Code Page The Code page shows code scanning findings aggregated by tool (such as TemplateAnalyzer, Trivy, etc.) and by repository. The threshold is set to 10 but can be changed to match your organization’s tolerable risk level for code security issues. You’ll know which repositories have a high number of security findings so that Security Operators can focus efforts with those Development Teams needing security awareness training. Additional information available in the Properties column includes details on the analysis performed and data collected during code scanning including description, deep link to the file with the security issue, tools, rules, branches, line number, severity, and more. You can use this rich data to further customize the Workbook’s analysis for your organization’s needs using Kusto Query Language (KQL). OSS Vulnerabilities Page The OSS Vulnerabilities page shows vulnerable open source dependencies used in a workload. Results are grouped by repository in the grid view and, again, you can drill down in the Properties column to see supplementary information such as CVE, CWE, CVSS score, and more. This data is useful for focusing remediation efforts on specific vulnerable repositories and workloads. Infrastructure as Code Page The Infrastructure as Code page contains IaC misconfiguration findings by tool and by repository. This data is useful for proactively identifying repositories with misconfigured IaC templates that could lead to deploying vulnerable workloads. Posture Page The Posture page consolidates the view of security posture of DevOps repositories. The issues surfaced on this page are related to good code hygiene practices and security configuration of DevOps environments. Some examples include seeing whether code, secret, and OSS vulnerability scanning is enabled on a repository. Threats & Tactics Page This page is a view of repositories and all their issues with the corresponding threats and tactics that could be used to exploit the discovered vulnerabilities. Security Operators can use this date to proactively work with Development Teams to reduce attack surface. This data also allows your Threat Hunters to prioritize hunting and response based on the types of attacks that are high priority to your organization. Conclusion To review, we’ve walked through the new DevOps Security Workbook and explored how you can gain new visibility into the security posture of your Source Code Management Systems (SCMS) in Microsoft Defender for Cloud. Once you’ve onboarded your SCMS—whether GitHub, Azure DevOps, or even future integrations—to Defender for DevOps, you can visualize the security of your development lifecycle across any cloud—Azure, AWS, GCP—and build rich, customized dashboard experiences with KQL to enable the centralized view of DevOps Security that empowers and informs your organization. Additional Resources To learn more about Defender for DevOps, read this documentation Download (free) a special Appendix about Defender for DevOps from the latest Microsoft Defender for Cloud book published by Microsoft Press To learn how to onboard your Source Code Management System to Defender for Cloud, read this documentation for GitHub and this documentation for Azure DevOps To learn more about the Microsoft Security DevOps (MSDO) tools, read this documentation for GitHub and this documentation for Azure DevOpsEnhance your CI/CD deployment by using Vulnerability Assessments from Microsoft Defender for ACR
By embedding Microsoft Defender for container registries assessments into your CI/CD pipeline, you can address this need and have a more secure automation and deployment processes in enterprise environments. This blog will take you through a few simple steps to take your CI/CD pipeline to the next security level.Compliance for Exposed Secrets Discovered by DevOps Security in Defender for Cloud
Compliance for Exposed Secrets Discovered by DevOps Security in Defender for Cloud Azure Policy helps enforce organizational standards and assess compliance at-scale. You can now create a custom Azure Policy to add DevOps security to your centralized compliance dashboards. This blog walks through creating a custom Azure Policy that leverages the DevOps security recommendations in Defender for Cloud called “Azure DevOps repositories should have secret scanning findings should be resolved", "GitHub repositories should have secret scanning findings resolved", and "GitLab projects should have secret scanning findings resolved". This policy gives Security and Compliance Teams visibility into discovered secrets found in Azure DevOps, GitHub, and GitLab that have been onboarded to Microsoft Defender for Cloud. Objectives: Create a custom AuditIfNotExist Azure Policy Visualize the custom policy in the Compliance view in Azure Policy Prerequisites: Connector provisioned in Defender for Cloud to your Source Code Management System (such as Azure DevOps, GitHub, or GitLab) For Azure DevOps: enable secret scanning in GitHub Advanced Security for Azure DevOps For GitHub: enable secret scanning in GitHub Advanced Security For GitLab: enable secret scanning in GitLab Ultimate Create a Custom Azure Compliance Policy for Exposed Secrets Navigate to Azure Policy Click Definitions Click + Policy definition For Definition location, choose a subscription or management group For Name, type code repositories should have secret scanning findings resolved Type a Description, such as: DevOps security in Defender for Cloud has found a secret in code repositories. This should be remediated immediately to prevent a security breach. For Category, click Create new, then type DevOps Security For Policy Rule, cut and paste the following JSON: { "parameters": { "effect": { "type": "String", "metadata": { "displayName": "Effect", "description": "Enable or disable the execution of the policy" }, "allowedValues": [ "AuditIfNotExists", "Disabled" ], "defaultValue": "AuditIfNotExists" } }, "policyRule": { "if": { "field": "type", "in": [ "microsoft.security/securityconnectors/devops/azuredevopsorgs/projects/repos" ] }, "then": { "effect": "[parameters('effect')]", "details": { "type": "Microsoft.Security/assessments", "name": "b5ef903f-8655-473b-9784-4f749eeb25c6", "existenceCondition": { "field": "Microsoft.Security/assessments/status.code", "in": [ "NotApplicable", "Healthy" ] } } } } } Note: The example above is for Azure DevOps. To replicate the same policy for GitHub or GitLab: GitHub Change "microsoft.security/securityconnectors/devops/azuredevopsorgs/projects/repos" to "microsoft.security/securityconnectors/devops/githubowners/repos" Change assessment key name "b5ef903f-8655-473b-9784-4f749eeb25c6" to "dd98425c-1407-40cc-8a2c-da5d0a2f80da" GitLab Change "microsoft.security/securityconnectors/devops/azuredevopsorgs/projects/repos" to "microsoft.security/securityconnectors/devops/gitlabgroups/projects" Change assessment key name "b5ef903f-8655-473b-9784-4f749eeb25c6" to "867001c3-2d01-4db7-b513-5cb97638f23d" For more information on Azure Policy definition structure, effects, scope, and more, review this documentation. The policy we just created uses the assessment ID for the Defender for Cloud DevOps securirty recommendation called “Code repositories should have secret scanning findings resolved” to determine whether there are any resources that are not NotApplicable or Healthy. If the policy finds an Unhealthy status code, that repository will be flagged as non-compliant because a secret was discovered. Click Save Navigate to Azure Policy Click Assignments Click Assign Policy For Scope, choose the subscription that has your connector or a top-level management group For Policy definition, choose code repositories should have secret scanning findings resolved Click Review + create Click Create Click Compliance Find the policy and click on it to view details The custom Policy gives you reporting capabilities on both compliant and non-compliant repositories. It should look like the following in the Policy Compliance details: Conclusion To review, we’ve walked through setting up a custom Azure Policy to audit repositories against a Defender for Cloud assessment that finds exposed secrets. We assigned the policy to a subscription and visualized the results in Azure Policy’s centralized Compliance view. This helps Compliance Managers, Security Operators, and Governance Teams identify non-compliant repositories across connected DevOps environments. You can then use Azure Policy reporting on these discovered secrets to implement governance for resource consistency, regulatory compliance, security, and management. 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 Source Code Management System to Defender for Cloud, read this documentation for GitHub and this documentation for Azure DevOps To learn more about the Microsoft Security DevOps (MSDO) tools, read this documentation for GitHub and this documentation for Azure DevOpsPre-Deployment Protection for Infrastructure as Code
Pre-Deployment Protection for Infrastructure as Code Security Operators are inundated with security misconfigurations in their cloud resources. To reduce the number of security misconfigurations, identification and remediation can be shifted left so Developers can find and fix security misconfigurations earlier in the development lifecycle, reducing the burden on SecOps. Let's see how the newest service in Microsoft Defender for Cloud, Defender for DevOps, can help with pre-deployment protections. This blog walks Security Operators through setting up security tools in development workflows and integrated developer environments (IDE)—enabling SecOps to empower their Developers to fix security misconfigurations in pre-deployment, before the issues are deployed to production. Objectives: Configure the Defender for DevOps Microsoft Security DevOps (MSDO) tools to scan for Infrastructure as Code (IaC) templates Leverage GitHub branch protection to require Checks for TemplateAnalyzer and Terrascan rules Use a GitHub extension to manage pull requests and visualize Checks from the MSDO tools and indicate the exact lines of code that are misconfigured Prerequisites: Connector provisioned in MDC to your Source Code Management System (such as Azure DevOps or GitHub) If your SCMS is GitHub: GitHub Advanced Security VS Code GitHub Extension The GitHub Pull Requests and Issues extension allows you to review and manage GitHub pull requests and issues in Visual Studio Code. It allows you to manage pull requests and finds issues with checks annotated in IaC templates. The extension can be found at this link: https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github Defender for DevOps IaC Tools The Microsoft Security DevOps (MSDO) tools are a set of static code analysis tools that help you secure workloads in your CI/CD pipelines. The tool configuration supports enabling only Infrastructure as Code, without the other tools, to shorten runtime and concentrate on securing ARM, Cloud Formation, Terraform templates. Configure the MSDO tools for only IaC scanning, follow the tutorial at this link: https://docs.microsoft.com/en-us/azure/defender-for-cloud/iac-vulnerabilities GitHub Branch Protection Rule This section assumes you followed the steps in the previous section to configure the MSDO tools. Next, navigate to the repository you used to setup the MSDO tools. 1. On GitHub.com, navigate to the main page of the repository 2. Under your repository name, click Settings 3. In the "Code and automation" section of the sidebar, click Branches 4. Next to "Branch protection rules," click Add rule 5. Under "Branch name pattern," type the branch name or pattern you want to protect If you want to support all branches, type * or enter your default branch name 6. Under "Protect matching branches," select Require a pull request before merging 7. Select Require status checks to pass before merging 8. In the Search for status checks box, type Terrascan and TemplateAnalyzer 9. Optional: select Include administrators to apply the rules above to administrators 10. Click Save Upload and Test an ARM Template 11. In the IaC tutorial, you downloaded an ARM template to get started Make a change to the template and commit it to a new branch 12. Create a pull request 13. Check the pull request results of the MSDO workflow 14. Verify that Checks show up in VS Code Conclusion To review, we’ve walked through creating a branch protection rule to force the Infrastructure as Code MSDO tools to run when a pull request is submitted. The tools found misconfigurations in templates and did not allow the pull request to merge into the main branch because of the security findings in the templates. This not only helps reduce the fatigue of Security Operators, but also empowers Developers to find and fix security misconfigurations before they ship to production. Additional Resources To learn more about Defender for DevOps, read this documentation Download (free) a special Appendix about Defender for DevOps from the latest Microsoft Defender for Cloud book published by Microsoft Press To learn how to onboard your Source Code Management System to Defender for Cloud, read this documentation for GitHub and this documentation for Azure DevOps To learn more about the Microsoft Security DevOps (MSDO) tools, read this documentation for GitHub and this documentation for Azure DevOps
