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 DevOps
Introducing the new File Integrity Monitoring with Defender for Endpoint integration
As the final and most complex piece of this puzzle is the release of File Integrity Monitoring (FIM) powered by Defender for Endpoint, marks a significant milestone in the Defender for Servers simplification journey. The new FIM solution based on Defender for Endpoint offers real-time monitoring on critical file paths and system files, ensuring that any changes indicating a potential attack are detected immediately. In addition, FIM offers built-in support for relevant security regulatory compliance standards, such as PCI-DSS, CIS, NIST, and others, allowing you to maintain compliance.Leveraging Defender for Containers to simplify policy management in your Kubernetes Clusters
Introduction A key part of Kubernetes security includes making sure the cluster is configured to industry and company best practices. This entails controlling what users can do on the cluster and blocking actions that don’t comply with pre-defined best practices. Out of the box, Kubernetes does not provide a mechanism to write and deploy fine grained policies required per your security and compliance mandates. As a result, you will probably leverage something like Gatekeeper along with Open Policy Agent (OPA). Defender for Containers protects your Kubernetes clusters by continuously assessing them to get visibility into misconfigurations and help mitigate identified threats. To get insight into the workload configuration on the cluster, the Azure Policy for Kubernetes is deployed as part of the Defender for Containers plan. The Azure Policy for Kubernetes extends the Gatekeeper v3 admission controller webhook for OPA. Gatekeeper is needed to check if the policy is correct before enforcing it. On Azure Kubernetes Service (AKS), it is deployed as an add-on. For Arc Enabled Kubernetes, which includes on-premises clusters and clusters hosted in Google Cloud or Amazon Web Services, it is deployed as an extension. In this blog, we will go more into detail about how Azure Policy for Kubernetes, uses Gatekeeper with OPA in the Defender for Containers plan. How does the policy deployment work? The Azure Policy for Kubernetes checks with the Azure Policy service for policy assignments to the cluster, deploys policy definitions into the cluster as constraints and constraint templates and reports details back to the Azure Policy service. Figure 1 shows at a high level how the Gatekeeper works with policy and responds to admission requests. When a user makes a request to the API server, the API server will send an admission request to the Gatekeeper validating Webhook and asks if this request should be allowed to proceed. To make a decision, the Gatekeeper will consult the Policy CRs(Core Rules). The constraint shows the gatekeeper what requirement needs to be met to make the request from the API server while the template shows exactly how to make those requests. When enabling Defender for Containers on your subscriptions, it recommends deploying the Azure Policy agent on your Kubernetes clusters. Once the agent is deployed, Defender for Containers provides best practices via recommendations across all Kubernetes clusters. Some recommendations have parameters that must be configured before they can be used effectively. The only action required by the customer is to adjust policy parameters of those recommendations to the organizational policy. For example, in the recommendation "Container images should be deployed only from trusted registries", customers must define known and trusted registries. Additionally, with “Container CPU and memory limits should be enforced”, customers must define the max allowed CPU units and memory bytes in the cluster in order for Defender for Containers to report non-compliant clusters. Organizations can also leverage the “Additional Information” section of the recommendation to view parameters that need to be configured. Another parameter organizations may consider are exclusions. Organizations may have components on the cluster such as an image or container that they want to be excluded from being monitored in relevant recommendations. Where applicable, the “Additional Information” section of the recommendation would highlight the option to configure exclusions. The exclusion would apply to all relevant data plane recommendations and are not customizable per recommendation. In the recommendation “Privileged containers should be avoided”, organizations can configure exclusions based on container images. Once configured, the exclusion would apply across all data plane recommendations where an image is relevant. To be more proactive towards Kubernetes security, consider changing the recommendation from “audit” mode to “deny”. The deny effect would prevent the creation of resources that don’t satisfy the recommendation. Exporting Affected Components Once the parameters have been configured for the recommendations, you can view the affected components by navigating to the unhealthy resources tab and clicking on the unhealthy cluster. The affected components will pop up on the left blade. This information is retrieved via API calls and can be exported using a PowerShell script. Limitations Before deploying the Azure Policy Add-on please be aware of existing limitations and recommendations. Summary In this article, we demonstrated an easy way to deploy and manage the policies for your Kubernetes clusters. Through the Azure Policy for Kubernetes, which is deployed as part of the Defender for Containers plan, organizations can leverage several built-in recommendations to monitor compliance on the Kubernetes data plane. We also showed you how to view the affected components for each recommendation, export them and apply exclusions. More Information: Container security with Microsoft Defender for Cloud | Microsoft Learn Secure your Containers from Build to Runtime - YouTube Learn Azure Policy for Kubernetes - Azure Policy | Microsoft Learn Reviewers Tomer Spivak, Senior PM(Defender for Cloud) Maya Herskovic, Senior PM(Defender for Cloud Mekonnen Kassa, Principal GPM (CxE, Defender for Cloud)
Unleashing the Power of Microsoft Defender for Cloud – Unique Capabilities for Robust Protection
So you have implemented a non-native Cloud Security Posture Management solution but there are security gaps that you might not have considered. How Defender for Cloud is uniquely positioned to secure your cloud attack surface.
