vulnerabilities
43 TopicsDeploy Microsoft Defender for Cloud via Terraform
Terraform is an Infrastructure as a Code tool created by Hashicorp. It’s used to manage your infrastructure in Azure, as well as other clouds. In this article, we’ll be showing you how to deploy Microsoft Defender for Cloud (MDC) using Terraform from scratch.How Defender for Cloud displays machines affected by Log4j vulnerabilities
Microsoft Defender for Cloud's inventory filters can easily and quickly help you find all machines with a specific piece of software, or that are vulnerable to a specific CVE. In this case, we show how to find machines running Log4j or with the security finding CVE-2021-44228.Defender for Cloud unified Vulnerability Assessment powered by Defender Vulnerability Management
We are thrilled to announce that Defender for Cloud is unifying our vulnerability assessment engine to Microsoft Defender Vulnerability Management (MDVM) across servers and containers. Security admins will benefit from Microsoft’s unmatched threat intelligence, breach likelihood predictions and business contexts to identify, assess, prioritize, and remediate vulnerabilities - making it an ideal tool for managing an expanded attack surface and reducing overall cloud risk posture.30KViews4likes15CommentsDevOps 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 DevOpsAutomate 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 GitHub