Announcing Microsoft Defender Vulnerability Management in public preview
Today, we are thrilled to announce the public preview of Microsoft Defender Vulnerability Management, a single solution offering the full set of Microsoft’s vulnerability management capabilities to help take your threat protection to the next level.What is Zero Trust and is it the Future of Cybersecurity?
Zero Trust is a security architecture that assumes the network is already infiltrated and implements multi-factor authentication, least privilege access, and real-time monitoring and analytics to secure digital assets. The Zero Trust model goes beyond the traditional perimeter-based security method and focuses on protecting identities, endpoints, applications, data, infrastructure, and networks. By using a Zero Trust model, organizations can better protect themselves from cyber-attacks and data breaches while still making sure they are compliant and staying productive. Zero Trust is the future of cybersecurity because it focuses on visibility, automation, and orchestration. It is also the key to securing your digital estate.New identity security posture assessments: Riskiest LMPs and Unsecure Account Attributes
We are happy to announce two new Azure ATP identity security posture assessments for riskiest Lateral Movement Paths (LMP) and unsecure account attributes. What are risky lateral movement paths? Azure ATP continuously monitors your environment to identify sensitive accounts with the riskiest lateral movement paths that expose a security risk, and reports on these accounts to assist you in managing your environment. Paths are considered risky if they have three or more non-sensitive accounts that can expose the sensitive account to credential theft by malicious actors. Why should I be concerned about lateral movement paths? Malicious actors, much like thieves, often look for the easiest and quietest way into any environment. Sensitive accounts with risky lateral movement paths are windows of opportunities for attackers and can expose risks. For example, the riskiest paths are more readily visible to attackers and, if compromised, can give an attacker access to your organization's most sensitive entities. How do I use this security assessment? Use the report table to discover which of your sensitive accounts have risky LMPs. Take appropriate action: Remove the entity from the group as specified in the recommendation. Remove the local administrator permissions for the entity from the device specified in the recommendation. What are unsecure account attributes? Azure ATP continuously monitors your environment to identify accounts with attribute values that expose a security risk, and reports on these accounts to assist you in protecting your environment. What risk do unsecure account attributes pose? Organizations that fail to secure their account attributes leave the door unlocked for malicious actors. Malicious actors, much like thieves, often look for the easiest and quietest way into any environment. Accounts configured with unsecure attributes are windows of opportunities for attackers and can expose risks. For example, if the attribute PasswordNotRequired is enabled, an attacker can easy access to the account. This is especially risky if the account has privileged access to other resources. How do I use this security assessment? Use the report table to discover which of your accounts have unsecure attributes. Take appropriate action on those user accounts by modifying or removing the relevant attributes. You can find these new assessments under the Identity Security Posture in the Cloud App Security portal (Azure ATP integration must be enabled). Please let us know what you think about these assessments in the comments!From Healthy to Unhealthy: Alerting on Defender for Cloud Recommendations with Logic Apps
In today's cloud-first environments, maintaining strong security posture requires not just visibility but real-time awareness of changes. This blog walks you through a practical solution to monitor and alert on Microsoft Defender for Cloud recommendations that transition from Healthy to Unhealthy status. By combining the power of Kusto Query Language (KQL) with the automation capabilities of Azure Logic Apps, you’ll learn how to: Query historical and current security recommendation states using KQL Detect resources that have degraded in compliance over the past 14 days Send automatic email alerts when issues are detected Customize the email content with HTML tables for easy readability Handle edge cases, like sending a “no issues found” email when nothing changes Whether you're a security engineer, cloud architect, or DevOps practitioner, this solution helps you close the gap between detection and response and ensure that no security regressions go unnoticed. Prerequisites Before implementing the monitoring and alerting solution described in this blog, ensure the following prerequisites are met: Microsoft Defender for Cloud is Enabled Defender for Cloud must be enabled on the target Azure subscriptions/management group. It should be actively monitoring your resources (VMs, SQL, App Services, etc.). Make sure the recommendations are getting generated. Continuous Export is Enabled for Security Recommendations Continuous export should be configured to send security recommendations to a Log Analytics workspace. This enables you to query historical recommendation state using KQL. You can configure continuous export by going to: Defender for Cloud → Environment settings → Select Subscription → Continuous Export Then enable export for Security Recommendations to your chosen Log Analytics workspace. Detailed guidance on setting up continuous export can be found here: Set up continuous export in the Azure portal - Microsoft Defender for Cloud | Microsoft Learn High-Level Summary of the Automation Flow This solution provides a fully automated way to track and alert on security posture regressions in Microsoft Defender for Cloud. By integrating KQL queries with Azure Logic Apps, you can stay informed whenever a resource's security recommendation changes from Healthy to Unhealthy. Here's how the flow works: Microsoft Defender for Cloud evaluates Azure resources and generates security recommendations based on best practices and potential vulnerabilities. These recommendations are continuously exported to a Log Analytics workspace, enabling historical analysis over time. A scheduled Logic App runs a KQL query that compares: Recommendations from ~14 days ago (baseline), With those from the last 7 days (current state). If any resources are found to have shifted from Healthy to Unhealthy, the Logic App: Formats the data into an HTML table, and Sends an email alert with the affected resource details and recommendation metadata. If no such changes are found, an optional email can be sent stating that all monitored resources remain compliant — providing peace of mind and audit trail coverage. This approach enables teams to proactively monitor security drift, reduce manual oversight, and ensure timely remediation of emerging security issues. Logic Apps Flow This Logic App is scheduled to trigger daily. It runs a KQL query against a Log Analytics workspace to identify resources that have changed from Healthy to Unhealthy status over the past two weeks. If such changes are detected, the results are formatted into an HTML table and emailed to the security team for review and action. KQL Query used here: // Get resources that are currently unhealthy within the last 7 days let now_unhealthy = SecurityRecommendation | where TimeGenerated > ago(7d) | where RecommendationState == "Unhealthy" // For each resource and recommendation, get the latest record | summarize arg_max(TimeGenerated, *) by AssessedResourceId, RecommendationDisplayName; // Get resources that were healthy approximately 14 days ago (between 12 and 14 days ago) let past_healthy = SecurityRecommendation | where TimeGenerated between (ago(14d) .. ago(12d)) | where RecommendationState == "Healthy" // For each resource and recommendation, get the latest record in that time window | summarize arg_max(TimeGenerated, *) by AssessedResourceId, RecommendationDisplayName; // Join current unhealthy resources with their healthy state 14 days ago now_unhealthy | join kind=inner past_healthy on AssessedResourceId, RecommendationDisplayName | project AssessedResourceId, // Unique ID of the assessed resource RecommendationDisplayName, // Name of the security recommendation RecommendationSeverity, // Severity level of the recommendation Description, // Description explaining the recommendation State_14DaysAgo = RecommendationState1,// Resource state about 14 days ago (should be "Healthy") State_Recent = RecommendationState, // Current resource state (should be "Unhealthy") Timestamp_14DaysAgo = TimeGenerated1, // Timestamp from ~14 days ago Timestamp_Recent = TimeGenerated // Most recent timestamp Once this logic app executes successfully, you’ll get an email as per your configuration. This email includes: A brief introduction explaining the situation. The number of affected recommendations. A formatted HTML table with detailed information: AssessedResourceId: The full Azure resource ID. RecommendationDisplayName: What Defender recommends (e.g., “Enable MFA”). Severity: Low, Medium, High. Description: What the recommendation means and why it matters. State_14DaysAgo: The previous (Healthy) state. State_Recent: The current (Unhealthy) state. Timestamps: When the states were recorded. Sample Email for reference: What the Security Team Can Do with It? Review the Impact Quickly identify which resources have degraded in security posture. Assess if the changes are critical (e.g., exposed VMs, missing patching). Prioritize Remediation Use the severity level to triage what needs immediate attention. Assign tasks to the right teams — infrastructure, app owners, etc. Correlate with Other Alerts Cross-check with Microsoft Sentinel, vulnerability scanners, or SIEM rules. Investigate whether these changes are expected, neglected, or malicious. Track and Document Use the email as a record of change in security posture. Log it in ticketing systems (like Jira or ServiceNow) manually or via integration. Optional Step: Initiate Remediation Playbooks Based on the resource type and issue, teams may: Enable security agents, Update configurations, Apply missing patches, Isolate the resource (if necessary). Automating alerts for resources that go from Healthy to Unhealthy in Defender for Cloud makes life a lot easier for security teams. It helps you catch issues early, act faster, and keep your cloud environment safe without constantly watching dashboards. Give this Logic App a try and see how much smoother your security monitoring and response can be! Access the JSON deployment file for this Logic App here: Microsoft-Unified-Security-Operations-Platform/Microsoft Defender for Cloud/ResourcesMovingFromHealthytoUnhealthyState/ARMTemplate-HealthytoUnhealthyResources(MDC).json at main · Abhishek-Sharan/Microsoft-Unified-Security-Operations-Platform
New Kerberos delegation types and columns in our identity security posture assessments
Two new enhancements are coming to Azure ATP's Identity security posture assessments: First, we are rolling out new types of Kerberos delegation into Azure ATP's Unsecure Kerberos delegation assessments: Constrained and Resource Based The new delegation types will show cases when a non-sensitive entity has been configured with constrained Kerberos delegation that points to a sensitive entity and when a sensitive entity has resource based constrained delegation configured for it, both allowing a malicious actor with a potential privilege escalation path if abused. to make things easier to configure, we will surface the exact delegation details that needs to be removed Furthermore, we are adding the much-requested Tags and Recommended action columns, where applicable, to show both the associated Tags (e.g. Sensitive) and the Recommend action per entity Or.New identity security posture assessments: Unsecure SID-History attributes and Microsoft LAPS Usage
We are happy to announce two new Azure ATP identity security posture assessments for unsecure SID-History attributes and Microsoft LAPS usage. What is the SID-History attribute? SID History is an attribute that supports migration scenarios. Every user account has an associated Security Identifier (SID) which is used to track the security principal and the access the account has when connecting to resources. SID History enables access for another account to effectively be cloned to another and is extremely useful to ensure users retain access when moved (migrated) from one domain to another. What risk does unsecure SID History attribute pose? Organizations that fail to secure their account attributes leave the door unlocked for malicious actors. Malicious actors, much like thieves, often look for the easiest and quietest way into any environment. Accounts configured with an unsecure SID History attribute are windows of opportunities for attackers and can expose risks. For example, a non-sensitive account in a domain can contain the Enterprise Admin SID in its SID History from another domain in the Active Directory forest, thus “elevating” access for the user account to effective Admin in all domains in the forest. Also, if you have a forest trust without SID Filtering enabled (also called Quarantine), it’s possible to inject a SID from another forest and it will be added to the user token when authenticated and used for elevated access. How do I use this security assessment? Use the report table to discover which of your accounts have an unsecure SID History attribute. Take appropriate action to remove SID History attribute from the accounts using PowerShell using the following command: Identify the SID in the SIDHistory attribute on the account. Get-ADUser -Identity <account> -Properties SIDHistory | Select-Object -ExpandProperty SIDHistory 2. Remove the SIDHistory attribute using the SID identified earlier. Set-ADUser -Identity <account> -Remove @{SIDHistory='S-1-5-21-...'} What is Microsoft LAPS? Microsoft LAPS (Local Administrator Password Solution) provide a solution to the issue of using a common local account with an identical password on every computer in a domain. LAPS resolve this issue by setting a different, rotated random password for the common local administrator account on every computer in the domain. Why should I use Microsoft LAPS? LAPS simplify password management while helping customers implement additional recommended defenses against cyberattacks. In particular, the solution mitigates the risk of lateral escalation that results when customers use the same administrative local account and password combination on their computers. LAPS store the password for each computer’s local administrator account in Active directory, secured in a confidential attribute in the computer’s corresponding AD object. The computer can update its own password data in Active directory, and domain administrators can grant read access to authorized users or groups, such as workstation helpdesk administrators. How do I use this security assessment? Use the report table to discover which of your domains have some (or all) compatible windows devices that are not protected by LAPS, or that have not had their LAPS managed password changed in the last 60 days. For domains that are partially protected, select the relevant row to view the list of devices not protected by LAPS in that domain. Take appropriate action on those devices by downloading, installing, and configuring or troubleshooting Microsoft LAPS using the documentation provided in the LAPS download. You can find these new assessments under the Identity Security Posture in the Cloud App Security portal (Azure ATP integration must be enabled). We would love to get your insights!
