rss.livelink.threads-in-node

Organize your multitenant view with Tenant Groups in Microsoft Defender

Simaya_Ouli — Wed, 27 May 2026 16:00:00 GMT

Managing security across many tenants shouldn’t mean drowning in a single, flat list. We’re excited to share a new capability, now in public preview in the Microsoft Defender multitenant (MTO) portal: Tenant Groups—a flexible way to organize the tenants you manage and switch your view between them with a single click.

If you’re a managed security service provider (MSSP), a cloud service provider (CSP), or a security team operating across multiple Entra ID tenants, this one’s for you.

What’s new

Tenant Groups let you create logical groupings of tenants (by customer segment, geography, criticality, onboarding stage—whatever fits how you work) and seamlessly switch the Defender MTO view to show data from only the tenants in that group.

NOTICE: The feature previously called Tenant groups—used for content distribution—has been renamed to Deployment profiles. The name “Tenant Groups” now refers to this new grouping experience.

Why it matters

Focus, faster – Investigate incidents, hunt threats, and review posture against just the tenants you care about right now—without noise from the rest.
Operational clarity – Group tenants the way your team actually works (e.g., Tier 1 customers, EMEA, Pilot rollout).
Permissions-aware – Even if a Tenant Group contains more tenants, you’ll only see the ones where you have B2B/GDAP (granular delegated admin privileges) access. Your existing access controls stay in charge.

Permissions you’ll need

To work with Tenant Groups, your account needs one of the following:

Entra ID roles

Security Administrator
Security Operator
Global Administrator

Product-specific (MDE, MDI, etc.) role-based access control (RBAC)

Global Administrator
Security Administrator
Plus, any custom RBAC roles required to see data across products

Unified RBAC (URBAC)

Security/read—to view Tenant Groups
Security/manage—to create Tenant Groups

Remember: A Tenant Group can include tenants you don’t have access to. You’ll only ever see the ones your permissions allow.

Getting started

1. Open Tenant Groups

Sign in to the Microsoft Defender portal with administrative credentials, then navigate to Multitenant Management > Tenant Groups.

You’ll find a built-in group called My private group that contains all the tenants from your previous setup. You can add or remove tenants from it, but it can’t be deleted.

2. Create a Tenant Group

Select + Create tenant group.
Give it a descriptive name (e.g., Healthcare customers, EMEA Tier 1).
Optionally, add a description so teammates know the group’s intent.
Select the tenants you want to include.

That’s it—your group is ready.

3. Switch between Tenant Groups

In the top-left corner of the portal, select Open multitenant management.
Choose the group you just created.

Navigate around the Defender MTO portal—incidents, alerts, devices, hunting—and you’ll see only data from the tenants in that group. Switch groups anytime to refocus.

Live change detection: If a teammate edits a Tenant Group (adds or removes tenants) while you’re viewing it, the portal surfaces a notification so you know the underlying scope has changed. No stale views, no surprises.

4. Edit a Tenant Group

Go back to Multitenant Management > Tenant Groups.
Select the group and choose Edit.
Add or remove tenants as your environment evolves, then re-test your views.

Tips for getting the most out of Tenant Groups

Start with how your team triages – Name groups after the workflows you actually run (On-call queue, Customer A—production).
Keep groups small and purposeful – Overlapping, focused groups beat one giant catch-all.
Pair with Deployment profiles – Use Tenant Groups for viewing, and Deployment profiles for distributing content—two clean, complementary concepts.
Audit access regularly – Because group membership is independent of B2B/GDAP access, periodic reviews keep expectations aligned.

We want your feedback

Tenant Groups are designed around real multitenant operations work—and we’d love to hear how you’re using them. Try it out in your environment, share what’s working (and what isn’t), and let us know what you’d like to see next.

Identity Attack Graph in Microsoft Sentinel

klianos — Wed, 06 May 2026 11:47:45 GMT

Identity is now one of the most important attack surfaces in cloud security. In many real-world incidents, attackers do not rely only on malware or network movement. Instead, they abuse identities, permissions, role assignments, group memberships, service principals, and misconfigured access paths to move from an initial compromise to high-value resources.

This is why the new Identity Attack Graph in Microsoft Sentinel is an important capability. It helps security teams visualize how identities are connected to Azure resources and how an attacker could potentially move from one identity to another resource through permissions and relationships.

What is the Identity Attack Graph?

The Identity Attack Graph in Microsoft Sentinel provides a visual way to understand how identities, permissions, groups, and Azure resources are connected.

Instead of manually checking multiple portals, logs, and role assignments, the graph helps analysts understand relationships such as:

Which identities have access to specific Azure resources
Which users or service principals are over-privileged
Which groups provide indirect access to sensitive resources
Which identities may have a path to critical assets
What the potential blast radius of a compromised identity could be
How attackers could move laterally through identity and permission relationships

This is especially useful because identity risk is often not obvious when looking at a single user, group, or role assignment in isolation. The real risk usually appears when these relationships are connected together.

A user may not directly have access to a sensitive resource, but the user may be a member of a group that has access to another resource, which then has permissions that create a path toward a high-value asset.

The Identity Attack Graph helps expose these hidden relationships.

Why this matters

In many Azure environments, permissions grow over time. Users change roles, groups are reused, emergency access is granted, service principals are created, and temporary permissions are not always removed.

As a result, organizations often end up with:

Too many privileged identities
Unused or stale permissions
Service principals with excessive access
Guest users with unnecessary permissions
Groups that provide indirect access to sensitive resources
Subscription-level roles that are broader than required
Lack of visibility into who can reach critical assets

Traditional investigation usually requires analysts to move between several places, including Microsoft Entra ID, Azure RBAC, Azure Activity logs, Sentinel queries, Defender XDR, and Azure Resource Graph.

The Identity Attack Graph reduces this complexity by presenting identity relationships as a connected graph.

This makes it easier to answer practical security questions such as:

“What can this identity access?”
“What happens if this user is compromised?”
“Which identities have a path to critical resources?”
“Which access path should we remediate first?”
“Which permissions create the highest risk?”
“Why does this identity have access to this asset?”

Key use cases

The feature can support several important identity security and cloud security scenarios.

1. Attack path discovery

Security teams can use the graph to identify how an attacker could move from a compromised identity to a sensitive Azure resource.

This is useful during both proactive assessments and active incident response.

For example, if a user account is suspected to be compromised, the graph can help identify which resources may be reachable through that identity’s direct or indirect permissions.

2. Blast-radius analysis

When an identity is compromised, one of the first questions is:

What could the attacker access with this identity?

The Identity Attack Graph can help analysts understand the potential impact of a compromised user, group, service principal, or managed identity.

This can help with containment, prioritization, and communication with stakeholders.

3. Over-privileged identity detection

The graph can help identify identities that have more permissions than they need.

Include:

Users with Owner or Contributor access at subscription level
Service principals with broad permissions
Guest users with privileged access
Groups that grant access to sensitive resources
Identities that have access to multiple critical assets

This is useful for enforcing least privilege and reducing identity attack surface.

4. Privileged access review

IAM and cloud security teams can use the graph to support access reviews.

Instead of only reviewing a list of role assignments, teams can understand the real impact of those permissions.

This helps answer:

Is this role assignment still required?
Does this group create unnecessary risk?
Does this identity have access to critical resources?
Is this access direct or inherited?
Is this path expected or suspicious?

5. Incident response and threat hunting

For SOC teams, the graph can support investigations involving:

Suspicious sign-ins
Compromised users
Privilege escalation
Suspicious role assignments
Lateral movement
Service principal abuse
Unusual access to sensitive resources

The graph does not replace logs or hunting queries, but it gives analysts a faster way to understand relationships and prioritize what to investigate next.

Important prerequisites and setup notes

During my evaluation, there were a few important setup requirements that should be clearly highlighted.

Microsoft Sentinel permissions

The environment must already be onboarded to Microsoft Sentinel, and the user testing or configuring the feature must have the appropriate Microsoft Sentinel permissions.

The documented role requirement includes Microsoft Sentinel Contributor.

However, in my experience, this is not always enough for the full onboarding and validation experience.

Subscription-level Owner permission

One important prerequisite that should be clearly mentioned is that Owner permissions at the Azure subscription level may be required.

This is especially important during onboarding and activation, because the graph depends on access to Azure resource and permission relationships.

If the user does not have sufficient subscription-level permissions, some setup steps or visibility into resources and relationships may not work as expected.

Recommended permission note:

In addition to Microsoft Sentinel permissions, ensure that the user configuring the preview has Owner permissions at the subscription level for the subscriptions that should be represented in the graph.

This should be made very clear in the onboarding documentation to avoid confusion during deployment.

Required data connector: Azure Resource Graph

Another very important setup step is the Azure Resource Graph data connector.

The Azure Resource Graph connector must be:

Installed manually

Activated manually

Connected to the relevant Sentinel workspace

This is a key point. The connector is not automatically enabled just because the Identity Attack Graph feature is available.

Without this connector, Sentinel may not have the required Azure resource relationship data needed to build a useful graph.

Why Azure Resource Graph is important

Azure Resource Graph provides visibility across Azure resources, subscriptions, and relationships. For an identity attack graph, this data is essential.

The graph needs to understand not only identities, but also the resources those identities can reach.

This may include:

Subscriptions
Resource groups
Storage accounts
Key Vaults
Virtual machines
Managed identities
Role assignments
Resource relationships
Resource hierarchy
Critical assets

Without Azure Resource Graph data, the attack graph may not provide the full picture of how identities connect to Azure resources.

For this reason, I believe the onboarding instructions should explicitly state:

The Azure Resource Graph data connector must be manually installed and activated before using the Identity Attack Graph.

Recommended onboarding checklist

Before using the Identity Attack Graph, I would recommend validating the following:

Requirement

Recommendation

Microsoft Sentinel workspace

Ensure the workspace is active and accessible

Sentinel role

Microsoft Sentinel Contributor or equivalent access

Subscription permissions

Owner permissions at subscription level

Azure Resource Graph connector

Manually install and activate the connector

Azure RBAC visibility

Ensure access to relevant role assignments

Microsoft Entra ID visibility

Ensure identity and group data is available

Resource visibility

Validate that relevant subscriptions and resources are visible

Data freshness

Allow enough time for data collection and graph population

This checklist can help avoid issues where the feature appears available but does not show the expected relationships.

How the Identity Attack Graph improves investigation

Before using a graph-based approach, an analyst often needs to manually collect and correlate data from multiple sources.

A typical investigation may include:

Checking the user in Microsoft Entra ID
Reviewing group memberships
Reviewing Azure RBAC assignments
Checking subscription-level access
Looking at resource-level permissions
Reviewing PIM activations
Searching Sentinel logs
Running KQL queries
Checking Azure Activity logs
Validating access with cloud or IAM teams

This process can be time-consuming.

The Identity Attack Graph helps reduce this effort by showing relationships visually. This allows the analyst to understand the possible path faster and decide where to focus.

For example, instead of manually asking:

“Does this user have access to this resource through any group, role, or inherited permission?”

The graph can help show the relationship directly.

This is valuable because many risky permissions are indirect. The user may not have direct access, but may inherit access through a group, role assignment, nested relationship, or service principal path.

Where validation is still needed

Although the graph provides strong visibility, I would still validate findings before taking remediation action.

This is especially important because removing access can affect business operations or production systems.

I would still validate with:

Microsoft Sentinel KQL queries
Microsoft Entra sign-in logs
Microsoft Entra audit logs
Azure Activity logs
Azure RBAC role assignments
PIM activation history
Defender XDR signals
Defender for Cloud recommendations
Azure Resource Graph queries
IAM team input
Cloud platform team input
Application owner confirmation

The graph is very useful for discovery and prioritization, but final remediation decisions should still be validated.

GQL and graph-based investigation

One of the interesting aspects of this feature is the use of graph-based thinking.

Security teams are already familiar with query languages such as KQL for log analytics. However, graph investigation is different.

KQL is excellent for searching and analyzing events over time, such as sign-ins, alerts, audit logs, and activity logs.

Graph Query Language, or GQL, is designed for querying connected data. Instead of only asking what happened at a specific time, graph queries help answer how entities are connected.

In identity security, this is very powerful because the risk often exists in the relationship between objects.

Graph entities include:

Users
Groups
Service principals
Managed identities
Roles
Subscriptions
Resource groups
Azure resources
Permissions
Sessions
Attack paths

Graph relationships include:

User is member of group
Group has role assignment
Identity has access to resource
Service principal owns application
Managed identity can access Key Vault
User can escalate privilege
Identity can reach critical asset

This allows analysts to ask more relationship-focused questions, such as:

Which identities can reach this resource?
What is the shortest path from this user to a critical asset?
Which groups create privileged access?
Which service principals have paths to sensitive resources?
Which identities have indirect access through nested relationships?
Which attack paths include subscription Owner or Contributor permissions?

KQL vs GQL: why both are useful

KQL and GQL serve different but complementary purposes.

Area

KQL

GQL / Graph Querying

Main purpose

Analyze logs and events

Analyze relationships and paths

Best for

Time-based investigation

Connected identity/resource investigation

question

“Did this user sign in from a risky location?”

“What resources can this user reach?”

Data model

Tables

Nodes and edges

Common use

Detection, hunting, analytics

Attack path discovery, relationship mapping

Strength

Event correlation

Path discovery

In practice, security teams need both.

KQL can identify a suspicious sign-in.
The Identity Attack Graph can show what the compromised identity could access.
KQL can then be used again to validate whether the attacker interacted with those resources.

This creates a strong workflow between event-based detection and relationship-based investigation.

Graph investigation scenarios

The following are conceptual are the types of graph questions that would be useful in identity attack path analysis.

Find paths from a user to critical resources

A useful graph query would help answer:

Show me all paths from this user to critical Azure resources.

This could help determine whether a compromised identity has a direct or indirect route to sensitive assets.

Find identities with paths to Key Vaults

Key Vaults often contain secrets, certificates, and keys.

A graph query could help identify:

Which users, groups, service principals, or managed identities have a path to Key Vault resources?

This would be useful for prioritizing access review and remediation.

Find subscription-level privileged identities

Subscription-level roles are high-impact because they can provide broad access.

A graph query could help find:

Which identities have Owner or Contributor access at subscription level?

This is especially important because subscription-level permissions can create wide attack paths.

Find indirect access through groups

Many access paths are created through group membership.

A graph query could help answer:

Which users have access to this resource through group membership?

This can help IAM teams clean up excessive or unnecessary group-based access.

Find service principals with broad access

Service principals are often used for automation and applications, but they can become high-risk if over-privileged.

A useful query would identify:

Which service principals have broad access to subscriptions or critical resources?

This is important because service principal compromise can lead to significant impact.

How GQL can improve analyst workflows

Adding strong GQL support to the graph explorer would make the feature more powerful for advanced users.

You could use graph queries to:

Search for specific paths
Filter by identity type
Filter by role
Filter by resource type
Find shortest paths
Find high-risk paths
Exclude known approved paths
Focus on critical assets
Query only privileged relationships
Identify unexpected permission chains

This would help both SOC analysts and cloud security engineers move from visual exploration to repeatable analysis.

A SOC analyst may want a quick visual graph during an incident, while a cloud security engineer

Scope filter (preview) has stopped working in Edge/Chrome

Pal Espen Bru — Wed, 06 May 2026 08:05:00 GMT

We have noticed that the Scope filter (preview) under Exposure Management -> Vulnerability Management has stopped working across all our desktops on the latest versions of Edge and Chrome. We see it across the board so guess it should be replicatable by you too.

Not critical enough that it warrants our time spent on an incident since it'll likely get reported anyhow, but putting it out here in case it's picked up by the Product Owners or Dev teams.

Monthly news - May 2026

HeikeRitter — Mon, 04 May 2026 15:24:34 GMT

Microsoft Defender
Monthly news - May 2026 Edition

This is our monthly "What's new" blog post, summarizing product updates and various new assets we released over the past month across our Defender products. In this edition, we are looking at all the goodness from April 2026. We are now including news related to Defender for Cloud in the Defender portal. For all other Defender for Cloud news, have a look at the dedicated Defender for Cloud Monthly News here.

🚀 New Virtual Ninja Show episode:

Weekly Security News: We publish a short 1ish minute video every week with updates across our Microsoft Security stack. Subscribe to our YouTube channel, so you don't miss the next episode.

Actionable threat insights

Microsoft Defender

Blog post: Containing a domain compromise: How predictive shielding shut down lateral movement
(Public Preview) You can now view the current status of automatic attack disruption and predictive shielding actions related to a specific incident. You view this data in the Activities tab of the incident page. Learn more
We made several enhancements across the Advanced hunting experience, read this blog post for all the details.
(Public Preview) The AIAgentsInfo table in advanced hunting now includes additional columns that provide deeper visibility into AI agents operating in your Microsoft 365 environment. These fields expand coverage beyond Copilot Studio to all agent types, including Microsoft Foundry, third-party marketplace, and custom line-of-business agents.
(Generally Available) Built-in alert tuning rules are now generally available. Built-in alert tuning rules suppress alerts from common benign activity in Defender for Endpoint and Defender for Office 365 without affecting Automated Investigation and Response (AIR) investigations and email notifications.
Microsoft Defender Experts for XDR customers can now see Defender Experts as a distinct entry in the Microsoft Defender portal navigation menu. This feature adds to the existing home page status card as in-portal experiences that provide consistent and predictable access to the service. Learn more
Blog post: Simplifying AWS defense with Microsoft Sentinel UEBA
Call to action: update automation by July 1, 2026 - Account Name is now consistently the UPN prefix for analytics rule alerts! Microsoft Sentinel is updating how the account entity's Account Name value is populated for analytics rule alerts when the full UPN is mapped into Account Name. This change improves consistency for downstream automation rules and Logic Apps playbooks. For more information, including before and after examples, read the blog article Update: Changing the Account Name Entity Mapping in Microsoft Sentinel.
For all other Sentinel News, have a look at the "What's new in Microsoft Sentinel blog post - April edition"

Microsoft Defender for Endpoint / Microsoft Defender Vulnerability Management

(Public Preview) You can now view the current status of automatic attack disruption and predictive shielding actions related to a specific incident. You view this data in the Activities tab of the incident page. Learn more
Microsoft Secure Score now includes the Ensure devices are updated to Secure Boot 2023 certificates and boot manager, which helps identify devices that haven't yet transitioned to the new Secure Boot 2023 certificates required ahead of the June 2026 expiration. To learn more about the recommendation, see Assess Secure Boot status with Microsoft Defender (blog).

Microsoft Defender for Identity

(Public Preview) Custom account correlation rules. Custom account correlation rules let you link accounts that belong to the same identity, such as privileged accounts with unique naming conventions. You can correlate accounts that don't share strong identifiers such as account ID, SID, object ID, or UPN by defining rules based on UPN prefix, UPN suffix, domain UPN, or employee ID. For more information, see Create custom account correlation rules.
(Generally Available) The Automatic Windows event-auditing configuration for sensors v3.x is now generally available. Automatic Windows event-auditing streamlines deployment by automatically applying the required auditing settings to new sensors and correcting misconfigurations on existing ones.

Microsoft Defender Incident – Handling incident severity change.

esanya2280 — Mon, 04 May 2026 12:06:36 GMT

I am polling incidents via Microsoft Graph API every 5 minutes, initially filtering out Low/Informational incidents.

Later, some low severity incidents are updated to High/Medium severity.

Is there any built-in mechanism in Defender for tracking severity transitions?

Microsoft Defender: New Advanced hunting enhancements

Noa_Nutkevitch — Tue, 28 Apr 2026 16:45:15 GMT

Co-author: Jeremy Tan

As a security analyst who actively hunts for critical threats, one of the most frustrating things that can happen is hitting a limit mid-query or encounter an experience that doesn’t behave as expected. The resulting friction and time spent troubleshooting or navigating takes valuable focus away from the investigation itself.

To address this, we’ve made several enhancements across the experience to ensure investigations can scale seamlessly so analysts can stay focused on finding and stopping threats without interruption. These updates are based on your feedback and our commitment to continually improve the experience for analysts and customers alike.

Scaling Investigations with Expanded Limits

We’ve made several enhancements across the experience to expand limits and better support large-scale investigations so analysts can query, explore, and act on more data with fewer constraints.

Results limitation increase (Preview)

We have heard your feedback on the need for larger data sets and are excited to announce that the results limitation in advanced hunting has been raised from 30,000 to 100,000 records. Now, queries returning up to 100,000 results will display all available data. If a query exceeds this threshold, results are truncated as before, but the increase allows for more comprehensive analysis and improved incident response.

Records limitation picker (Preview)

One common challenge in advanced hunting has been the risk of running queries that return overwhelming result sets, consuming excessive resources and potentially hitting system limits. The new records limitation picker addresses this by allowing you to explicitly set how many rows a query should return, directly from the editor toolbar.

Choose from predefined limits: 1,000, 5,000, or 10,000, 30,000 and 100,000 rows.
Select the maximum system limit (currently 100,000 records).
Define a custom value as needed.
The selected limit applies alongside any KQL-defined row limitations, with the lower value always taking precedence.
Your choice persists across page refreshes, navigation, and browser restarts.
By default, tenants start at the maximum row limit, but you can tailor your selection via page preferences.

This enhancement greatly improves performance and prevents unexpected limitations, making hunting safer and more efficient.

Partial results on size limit (GA)

Previously, queries that exceeded the 64 mb results size limit would fail outright, forcing analysts to modify their queries and rerun them. With the latest update, partial results are now provided when the size limit is reached:

Queries return the maximum records that fit within the 64 MB cap.
A clear message bar indicates when results are partial due to size constraints.
This allows you to act on available data immediately, without repeating query adjustments.

This improvement speeds up investigations and provides valuable data even in scenarios where limits are reached.

Enhanced UI for Faster, More Intuitive Investigations

We’ve made significant enhancements to the user experience delivering a more streamlined interface that helps analysts move through incidents with greater clarity, act with confidence, and spend less time searching and more time responding.

Hear from one of our customers:

“The recent updates to the Defender Advanced Hunting experience have gone a long way toward decluttering the interface and lowering the barrier for analysts and engineers who were previously more comfortable working exclusively in Microsoft Sentinel in the Azure portal.

By simplifying navigation, reducing unnecessary visual noise, and adding pinnable tabs, the XDR portal now feels more familiar. This usability improvement has helped shift long-standing Sentinel users toward the XDR experience without forcing a change in how teams think about their data or workflows.”

-Matt McCullogh, Senior SIEM Engineer, Best Buy

Query details side pane: enhanced visibility and troubleshooting (GA)

Understanding query execution and troubleshooting errors has often required tedious trial and error. The new query execution details side pane surfaces rich, actionable metadata for every query—successful or failed. With this feature, you can:

View execution time breakdowns, data sources, scopes, and resource utilization.
Examine response characteristics and detailed error information.
Navigate tabs such as overview, raw statistics, and errors for comprehensive diagnostics.
Access the side pane easily after running a query, or even from error messages in failure scenarios.

This transparency makes it far easier to investigate issues and optimize your hunting experience.

Improved error-handling for Advanced hunting queries (GA)

Advanced hunting now provides improved output messages, including clearer error messages that explain query failures and actionable suggestions for common issues. This update simplifies troubleshooting and helps reduce downtime with complex queries.

Simpler Navigation, More Powerful Hunting

Alongside these updates, the Advanced hunting UI has received several enhancements focused on usability and streamlined workflows. Users can now easily filter results with a single click, making data exploration more efficient and responsive and enhanced configuration of the schema tree now allows for collapsing or expanding all nodes with ease. Additionally, the page layout has been thoughtfully restructured, organizing components in a more intuitive manner for a modern, cohesive experience that makes advanced hunting both powerful and easy to use.

Rename tabs (GA)

Another notable usability enhancement is the ability for users to rename their working tabs within advanced hunting. This feature enables users to organize their work sessions more efficiently, allowing for clear identification of ongoing investigations and queries without requiring them to save their work as long-term functions or queries. By simply renaming tabs, users can quickly switch between tasks and keep their workspace well-structured, further improving workflow and productivity.

Saving KQL functions to log analytics workspace (GA)

In addition to the above enhancements, we are delighted to introduce the ability to save KQL functions directly from the advanced hunting page into your log analytics workspace. To utilize this feature:

Pick a folder under shared functions → Sentinel workspace functions.
Functions saved in this folder are available for use in workbooks, analytics rules, and for execution in advanced hunting.
Note: functions saved here are not available in custom detection rules.

This new capability empowers you to build reusable logic and streamline your security workflows across Microsoft Sentinel and advanced hunting.

Conclusion

These enhancements represent our continued commitment to supporting your security investigations with robust, flexible, and efficient tools. We look forward to your feedback and to bringing even more improvements in the future. Learn more about the new advanced hunting enhancements in our documentation.

Microsoft Sentinel MCP Entity Analyzer: Explainable risk analysis for URLs and identities

klianos — Wed, 15 Apr 2026 13:45:20 GMT

What makes this release important is not just that it adds another AI feature to Sentinel. It changes the implementation model for enrichment and triage. Instead of building and maintaining a chain of custom playbooks, KQL lookups, threat intel checks, and entity correlation logic, SOC teams can call a single analyzer that returns a reasoned verdict and supporting evidence. Microsoft positions the analyzer as available through Sentinel MCP server connections for agent platforms and through Logic Apps for SOAR workflows, which makes it useful both for interactive investigations and for automated response pipelines.

Why this matters

First, it formalizes Entity Analyzer as a production feature rather than a preview experiment. Second, it introduces a real cost model, which means organizations now need to govern usage instead of treating it as a free enrichment helper. Third, Microsoft’s documentation is now detailed enough to support repeatable implementation patterns, including prerequisites, limits, required tables, Logic Apps deployment, and cost behavior.

From a SOC engineering perspective, Entity Analyzer is interesting because it focuses on explainability. Microsoft describes the feature as generating clear, explainable verdicts for URLs and user identities by analyzing multiple modalities, including threat intelligence, prevalence, and organizational context. That is a much stronger operational model than simple point-enrichment because it aims to return an assessment that analysts can act on, not just more raw evidence

What Entity Analyzer actually does

The Entity Analyzer tools are described as AI-powered tools that analyze data in the Microsoft Sentinel data lake and provide a verdict plus detailed insights on URLs, domains, and user entities. Microsoft explicitly says these tools help eliminate the need for manual data collection and complex integrations usually required for investigation and enrichment

hat positioning is important. In practice, many SOC teams have built enrichment playbooks that fetch sign-in history, query TI feeds, inspect click data, read watchlists, and collect relevant alerts. Those workflows work, but they create maintenance overhead and produce inconsistent analyst experiences. Entity Analyzer centralizes that reasoning layer.

For user entities, Microsoft’s preview architecture explains that the analyzer retrieves sign-in logs, security alerts, behavior analytics, cloud app events, identity information, and Microsoft Threat Intelligence, then correlates those signals and applies AI-based reasoning to produce a verdict. Microsoft lists verdict examples such as Compromised, Suspicious activity found, and No evidence of compromise, and also warns that AI-generated content may be incorrect and should be checked for accuracy.

That warning matters. The right way to think about Entity Analyzer is not “automatic truth,” but “high-value, explainable triage acceleration.” It should reduce analyst effort and improve consistency, while still fitting into human review and response policy.

Under the hood: the implementation model

Technically, Entity Analyzer is delivered through the Microsoft Sentinel MCP data exploration tool collection. Microsoft documents that entity analysis is asynchronous: you start analysis, receive an identifier, and then poll for results. The docs note that analysis may take a few minutes and that the retrieval step may need to be run more than once if the internal timeout is not enough for long operations.

That design has two immediate implications for implementers.

First, this is not a lightweight synchronous enrichment call you should drop carelessly into every automation branch. Second, any production workflow should include retry logic, timeouts, and concurrency controls. If you ignore that, you will create fragile playbooks and unnecessary SCU burn.

The supported access path for the data exploration collection requires Microsoft Sentinel data lake and one of the supported MCP-capable platforms. Microsoft also states that access to the tools is supported for identities with at least Security Administrator, Security Operator, or Security Reader. The data exploration collection is hosted at the Sentinel MCP endpoint, and the same documentation notes additional Entity Analyzer roles related to Security Copilot usage.

The prerequisite many teams will miss

The most important prerequisite is easy to overlook: Microsoft Sentinel data lake is required.

This is more than a licensing footnote. It directly affects data quality, analyzer usefulness, and rollout success. If your organization has not onboarded the right tables into the data lake, Entity Analyzer will either fail or return reduced-confidence output.

For user analysis, the following tables are required to ensure accuracy: AlertEvidence, SigninLogs, CloudAppEvents, and IdentityInfo. also notes that IdentityInfo depends on Defender for Identity, Defender for Cloud Apps, or Defender for Endpoint P2 licensing. The analyzer works best with AADNonInteractiveUserSignInLogs and BehaviorAnalytics as well.

For URL analysis, the analyzer works best with EmailUrlInfo, UrlClickEvents, ThreatIntelIndicators, Watchlist, and DeviceNetworkEvents. If those tables are missing, the analyzer returns a disclaimer identifying the missing sources

A practical architecture view

An incident, hunting workflow, or analyst identifies a high-interest URL or user.
A Sentinel MCP client or Logic App calls Entity Analyzer.
Entity Analyzer queries relevant Sentinel data lake sources and correlates the findings.
AI reasoning produces a verdict, evidence narrative, and recommendations.
The result is returned to the analyst, incident record, or automation workflow for next-step action.

This model is especially valuable because it collapses a multi-query, multi-tool investigation pattern into a single explainable decisioning step.

Where it fits in real Sentinel operations

Entity Analyzer is not a replacement for analytics rules, UEBA, or threat intelligence. It is a force multiplier for them.

For identity triage, it fits naturally after incidents triggered by sign-in anomaly detections, UEBA signals, or Defender alerts because it already consumes sign-in logs, cloud app events, and behavior analytics as core evidence sources. For URL triage, it complements phishing and click-investigation workflows because it uses TI, URL activity, watchlists, and device/network context.

Implementation path 1: MCP clients and security agents

Microsoft states that Entity Analyzer integrates with agents through Sentinel MCP server connections to first-party and third-party AI runtime platforms. In practice, this makes it attractive for analyst copilots, engineering-side investigation agents, and guided triage experiences

The benefit of this model is speed. A security engineer or analyst can invoke the analyzer directly from an MCP-capable client without building a custom orchestration layer. The tradeoff is governance: once you make the tool widely accessible, you need a clear policy for who can run it, when it should be used, and how results are validated before action is taken.

Implementation path 2: Logic Apps and SOAR playbooks

For SOC teams, Logic Apps is likely the most immediately useful deployment model. Microsoft documents an entity analyzer action inside the Microsoft Sentinel MCP tools connector and provides the required parameters for adding it to an existing logic app. These include:

Workspace ID
Look Back Days
Properties payload for either URL or User

The documented payloads are straightforward:

{

"entityType": "Url",

"url": "[URL]"

}

And

{

"entityType": "User",

"userId": "[Microsoft Entra object ID or User Principal Name]"

}

Also states that the connector supports Microsoft Entra ID, service principals, and managed identities, and that the Logic App identity requires Security Reader to operate.

This makes playbook integration a strong pattern for incident enrichment. A high-severity incident can trigger a playbook, extract entities, invoke Entity Analyzer, and post the verdict back to the incident as a comment or decision artifact.

The concurrency lesson most people will learn the hard way

Unusually direct guidance on concurrency: to avoid timeouts and threshold issues, turn on Concurrency control in Logic Apps loops and start with a degree of parallelism of . The data exploration doc repeats the same guidance, stating that running multiple instances at once can increase latency and recommending starting with a maximum of five concurrent analyses.

This is a strong indicator that the correct implementation pattern is selective analysis, not blanket analysis. Do not analyze every entity in every incident. Analyze the entities that matter most:

external URLs in phishing or delivery chains
accounts tied to high-confidence alerts
entities associated with high-severity or high-impact incidents
suspicious users with multiple correlated signals

That keeps latency, quota pressure, and SCU consumption under control.

KQL still matters

Entity Analyzer does not eliminate KQL. It changes where KQL adds value.

Before running the analyzer, KQL is still useful for scoping and selecting the right entities. After the analyzer returns, KQL is useful for validation, deeper hunting, and building custom evidence views around the analyzer’s verdict.

For example, a simple sign-in baseline for a target user:

let TargetUpn = "email address removed for privacy reasons";

SigninLogs

| where TimeGenerated between (ago(7d) .. now())

| where UserPrincipalName == TargetUpn

| summarize

Total=count(),

Failures=countif(ResultType != "0"),

Successes=countif(ResultType == "0"),

DistinctIPs=dcount(IPAddress),

Apps=make_set(AppDisplayName, 20)

by bin(TimeGenerated, 1d)

| order by TimeGenerated desc

And a lightweight URL prevalence check:

let TargetUrl = "omicron-obl.com";

UrlClickEvents

| where TimeGenerated between (ago(7d) .. now())

| search TargetUrl

| take 50

Cost, billing, and governance

GA is where technical excitement meets budget reality.

Microsoft’s Sentinel billing documentation says there is no extra cost for the MCP server interface itself. However, for Entity Analyzer, customers are charged for the SCUs used for AI reasoning and also for the KQL queries executed against the Microsoft Sentinel data lake. Microsoft further states that existing Security Copilot entitlements apply

The April 2026 “What’s new” entry also explicitly says that starting April 1, 2026, customers are charged for the SCUs required when using Entity Analyzer.

That means every rollout should include a governance plan:

define who can invoke the analyzer
decide when playbooks are allowed to call it
monitor SCU consumption
limit unnecessary repeat runs
preserve results in incident records so you do not rerun the same analysis within a short period

Microsoft’s MCP billing documentation also defines service limits: 200 total runs per hour, 500 total runs per day, and around 15 concurrent runs every five minutes, with analysis results available for one hour.

Those are not just product limits. They are design requirements.

Limitations you should state clearly

The analyze_user_entity supports a maximum time window of seven days and only works for users with a Microsoft Entra object ID. On-premises Active Directory-only users are not supported for user analysis. Microsoft also says Entity Analyzer results expire after one hour and that the tool collection currently supports English prompts only.

Recommended rollout pattern

If I were implementing this in a production SOC, I would phase it like this:

Start with a narrow set of high-value use cases, such as suspicious user identities and phishing-related URLs. Confirm that the required tables are present in the data lake. Deploy a Logic App enrichment pattern for incident-triggered analysis. Add concurrency control and retry logic. Persist returned verdicts into incident comments or case notes. Then review SCU usage and analyst value before expanding coverage.

Monthly news - April 2026

HeikeRitter — Wed, 08 Apr 2026 08:18:07 GMT

Microsoft Defender
Monthly news - April 2026 Edition

This is our monthly "What's new" blog post, summarizing product updates and various new assets we released over the past month across our Defender products. In this edition, we are looking at all the goodness from March 2026. We are now including news related to Defender for Cloud in the Defender portal. For all other Defender for Cloud news, have a look at the dedicated Defender for Cloud Monthly News here.

🚀 New Virtual Ninja Show episode:

RSA blog posts:

Actionable threat insights

Microsoft Defender

We’re introducing a chat experience for Security Copilot directly within Microsoft Defender. Copilot is already embedded across Microsoft Defender experiences today, but now you can interact with it through an ongoing, two-way conversation. Ask questions, explore hypotheses, and follow your investigation threads across incidents, alerts, identities, devices, IPs, and other evidence. Read more about it in this blog post.
We are expanding agentic triage to identity and cloud alerts - bringing triage for phish, identity and cloud together within a single agent. The Security Alert Triage Agent helps you autonomously determine whether these alerts represent real threats or false alarms, delivering natural language findings and transparent, step-by-step decision analysis. Read more about it in this blog post.
Identity security enhancements: New identity security capabilities help you monitor and manage identity security for human and non-human identities:
- (Public Preview) Identity Security dashboard: The Identity Security dashboard provides summary cards for identity providers, on-premises identities, SaaS identities, PAM and IGA integrations, and non-human identities. For more information, see The Identity Security dashboard. The Identity Security dashboard is being rolled out gradually to customers, and might not yet be available in your organization.
- (Public Preview) Coverage and maturity page: The Coverage and maturity page shows your organization's identity security coverage with maturity levels, including Connected, Protected, Fortified, and Resilient, and prioritized setup tasks. For more information, see Coverage and maturity. The Coverage and maturity page is being rolled out gradually to customers, and might not yet be available in your organization. If you don't see this feature in your environment yet, check back soon.
- Identity inventory: The Identity inventory page now shows human and non-human identities in separate tabs. Insight cards help you classify critical assets, view highly privileged identities, identify critical Active Directory service accounts, and view cloud application accounts. For more information, see View the Identity inventory.
- (Preview) Non-human identities: The Non-human identities tab shows non-human identities, including Microsoft Entra ID apps, Active Directory service accounts, Google Workspace apps, and Salesforce apps. For more information, see Identity inventory and Investigate non-human identities.
- (Public Preview) Identity risk score: A new risk score for identities, ranging from 0 to 100, that indicates the likelihood of compromise and the potential impact based on criticality and privileged roles. The risk score is available in Microsoft Entra ID, where it can be used to inform conditional access policies and identity protection workflows. A new Risk score tab on the Identity page provides a detailed breakdown of the risk factors, including percentile comparison and risk trends. For more information, see Investigate an identity.
- (Public Preview) Domain investigation page: The Domain investigation page shows Active Directory domain security, including domain properties, deployment health, identity summary, service account breakdown, sensitive entities, active recommendations, group policies, and trust relationships. For more information, see Investigate a domain.
- (Public Preview)Identity security recommendations: View recommendations from Active Directory, Microsoft Entra ID, SaaS applications, and supported non-Microsoft identity providers. For more information, see Identity security recommendations.
Call to action: update older Microsoft Sentinel content as code (Sentinel repositories) API versions before June 15, 2026
(Public Preview) The following advanced hunting schema tables are now available for preview:
- The CloudDnsEvents table contains information about DNS activity events from cloud infrastructure environments.
- The CloudPolicyEnforcementEvents table contains policy enforcement evaluation decisions and metadata of security gating events for various cloud platforms protected by the organization's Microsoft Defender for Cloud.
To improve accuracy and better protect organizational identities, we've made updates to the Secure Score category calculations. Some security recommendations categorized as Cloud apps recommendations are now considered identity‑related and grouped under the Identity category. While the total Secure Score remains unchanged, individual identity and app scores may change.
(Public Preview) Customers can now use filters on very large incidents with many alerts and entities or hide specific entities to simplify complex incident graphs. By simplifying the graphs, they can focus their investigations on what matters most. Learn more
The proactive user containment (contain user) action as part of the predictive shielding feature is now generally available. This action infuses activity data with exposure data to identify exposed credentials at risk of being compromised and reused to conduct malicious activity.

Microsoft Defender for Endpoint / Microsoft Defender Vulnerability Management

Library management for live response is now generally available. This feature provides a centralized view for managing files and scripts used during live response sessions.
Microsoft Secure Score now includes new recommendations:
- Block outbound network connections from Microsoft HTML Application Host (mshta.exe): Helps mitigate attacks that leverage mshta.exe (a trusted Windows binary) to execute malicious scripts and communicate with external command-and-control (C2) infrastructure. Blocking outbound connections from mshta.exe disrupts common attack chains, prevents payload download and data exfiltration, and reduces the risk of living-off-the-land attacks. This is relevant for emerging attack campaigns, for example, ClickFix campaigns, where attackers abuse legitimate tools like mshta.exe to execute malicious content delivered through user interaction.
- Block file transfer over RDP: Restricts file transfer capabilities in Remote Desktop Protocol (RDP) sessions. This helps prevent attackers from using RDP sessions to transfer malicious files into the environment or exfiltrate sensitive data.
- SMB server security hardening against authentication relay attacks: Helps protect servers from credential relay attacks by strengthening Server Message Block (SMB) authentication protections, including enforcing Extended Protection for Authentication (EPA), SMB signing, and SMB encryption to ensure authentication integrity and protect SMB traffic from tampering or interception.
The proactive user containment (contain user) action as part of the predictive shielding feature is now generally available. This action infuses activity data with exposure data to identify exposed credentials at risk of being compromised and reused to conduct malicious activity.

Microsoft Defender for Identity

New identity security capabilities help you monitor and manage identity security for human and non-human identities:
- (Public Preview) Identity Security dashboard: The Identity Security dashboard provides summary cards for identity providers, on-premises identities, SaaS identities, PAM and IGA integrations, and non-human identities. Widgets show deployment status, highly privileged identities, users at risk, and domains with unsecured configurations. For more information, see The Identity Security dashboard. The Identity Security dashboard is being rolled out gradually to customers, and might not yet be available in your organization.
- (Public Preview) The Coverage and maturity page shows your organization's identity security coverage for identity providers, on-premises identities, SaaS identities, and PAM and IGA integrations. Each source displays a maturity level, including Connected, Protected, Fortified, and Resilient, with identity counts, coverage scores, and prioritized setup tasks. For more information, see Coverage and maturity. The Coverage and maturity page is being rolled out gradually to customers, and might not yet be available in your organization. If you don't see this feature in your environment yet, check back soon.
- The Identity inventory page now shows human and non-human identities in separate tabs. Insight cards help you classify critical assets, view highly privileged identities, identify critical Active Directory service accounts, and view cloud application accounts. For more information, see View the Identity inventory.
- (Public Preview) The Non-human identities tab on the Identity inventory page shows non-human identities, including Microsoft Entra ID apps, Active Directory service accounts, Google Workspace apps, and Salesforce apps. The tab includes statistics for risky, highly privileged, overprivileged, unused, and externally published identities. A separate investigation page lets you view details for each identity. For more information, see Identity inventory and Investigate non-human identities.
- (Public Preview) A new risk score for identities, ranging from 0 to 100, that indicates the likelihood of compromise and the potential impact based on criticality and privileged roles. The risk score is available in Microsoft Entra ID, where it can be used to inform conditional access policies and identity protection workflows. A new Risk score tab on the Identity page provides a detailed breakdown of the risk factors, including percentile comparison and risk trends. For more information, see Investigate an identity.
- (Public Preview) Identity security recommendations: View recommendations for Active Directory, Microsoft Entra ID, and SaaS applications such as Microsoft, Atlassian, GitHub, Google Workspace, Salesforce, and ServiceNow. Recommendations are also available for non-Microsoft identity providers such as Okta, PingOne, CyberArk, and SailPoint. For more information, see Identity security recommendations.
- (Public Preview) Domain investigation page: The Domain investigation page shows Active Directory domain security, including domain properties, deployment health, identity summary, service account breakdown, sensitive entities, active recommendations, group policies, and trust relationships. For more information, see Investigate a domain.
- (Public Preview) Password protection page: The Password protection page shows identity password risk from Active Directory, Microsoft Entra ID, and Okta, with tabs for password hygiene, password policies, leaked credentials, and exposed passwords. For more information, see Password protection.
- To improve accuracy and better protect organizational identities, we've made updates to the Secure Score category calculations. Some security recommendations categorized as Cloud apps recommendations are now considered identity‑related and grouped under the Identity category. While the total Secure Score remains unchanged, individual identity and app scores may change.
- The Suspected pass-the-ticket attack alert is now generally available. This alert was previously available in public preview as Pass-the-Ticket (PtT) attack. For more information, see Lateral movement alerts.
- These new alerts were added to the Defender for Identity security alerts:
  
  New alerts related to Entra ID:
  New alerts related to Active Directory:

Microsoft Defender for Office 365

Expanding User reporting in Teams to include Calls: Users can reported completed or missed one-to-one Microsoft Teams calls from the call history as malicious (scam) or non malicious (non-scam) to the specified reporting mailbox, or Microsoft and the reporting mailbox via user reported settings.
Added support for contextual Teams messages in User reported Teams Messages: When Users report Microsoft Teams messages from chats, channels (standard, shared, and private), and meeting conversations to Microsoft as malicious (security risk), up to fifteen messages before and after the reported message are shared for analysis.

Microsoft Defender for Cloud Apps

To improve accuracy and better protect organizational identities, some security recommendations categorized as Cloud apps recommendations are now considered identity‑related and grouped under the Identity category. While the total Secure Score remains unchanged, individual identity and app scores may change.

Fishing linking passwords and data

79470Valen — Thu, 02 Apr 2026 15:06:48 GMT

activar control de seguridad mejorada antivirus maleware and fishing data

Redefining identity security for the modern enterprise

YaronParyanty — Fri, 20 Mar 2026 16:00:00 GMT

Every breach has one thing in common: an identity was exploited. Attackers have learned that identity is the fastest path to lateral movement and escalation. The challenge for defenders is that today's identity landscape is vast and fragmented — spanning hybrid environments, SaaS apps, cloud platforms, and autonomous agents. Protecting it demands more than point solutions. It requires continuous visibility, proactive posture reduction, and the ability to detect and disrupt identity threats across the full attack lifecycle.

Leveraging our expertise as a leader in both Identity and Access Management (IAM) and Security, our focus has been to deliver a fast, comprehensive, and increasingly autonomous approach to identity security. It is designed to continuously strengthen identity posture and help SOC teams act faster with less manual effort. Today, I am excited to announce the next set of innovations including:

Reimagined Identity Security dashboard and experiences to surface identity insights
Expanded protection for more elements of modern identity fabrics including non-human identities.
Streamlined detections including a new identity-level risk score that can be applied directly within risk-based conditional access policies.
Unified identity view & protection across Active Directory, Entra ID, IAM solutions, SaaS and Cloud – with improved at-scale identity correlations
New autonomous response capabilities to further speed identity threat triage, disruption and response.

Below is a deeper look at what’s new.

Turning identity sprawl into clarity

Security teams don’t suffer from a lack of identity data — they suffer from a lack of insight across that data. Without context, the flood of activity from various directories, SaaS platforms, cloud services, and on‑premises infrastructure simply becomes noise. Disconnected alerts, isolated accounts, and fragmented investigations make it harder, not easier, to determine what actually matters.

The updated Identity security dashboard is one of the new experiences designed to help with just that. It serves as the starting point for the SOC to gain a birds eye view of their entire identity security status, surfacing critical information on the human and non-human identities from across on-premises, SaaS and cloud environments.

Fueling this, and other identity security experiences within Defender, are the advancements we have made in unifying the identity inventories. First, for human users we have expanded the account correlation capabilities we released at Ignite to include SaaS and cloud accounts. This means that security professionals will have an even more comprehensive view of related accounts, their holistic posture and identity risk. Additionally, we are also introducing new, policy-based linkage to help organizations customize these connections at scale.

But modern identity fabrics extend far beyond human users. To address this shift, we are also expanding identity security coverage to include a greater focus on non‑human identities. The new non‑human identity inventory helps security teams to discover, understand, and protect these critical identities within the same identity‑centric view as human accounts.

Defender helps teams see the full identity fabric — not as disconnected components, but as an interconnected system — so they can reduce blind spots, prioritize exposure, and apply consistent protection across the identities attackers increasingly rely on.

Expanded coverage across the modern identity fabric

Staying one step ahead of attackers starts with having a better understanding of what makes you vulnerable and closing those gaps before they can be exploited. With this mission in mind, I am excited to announce a new coverage and maturity view that shows how identity infrastructure, protections, and risk actually connect across your environment. This view serves as a snapshot revealing which access paths are protected, which are exposed, and what to fix next to meaningfully reduce blast radius.

Rather than treating coverage as a static checklist, this experience surfaces actionable insights that show both current status and prioritized next steps, helping teams understand not only what needs to be protected, but also how to systematically improve identity security posture over time. With this clear guidance Defender empowers SOC teams to move from fragmented awareness to confident, identity‑centric protection.

This new view is powered by the native integration available out-of-the-box with Microsoft Entra ID and the dedicated sensors and connectors available for other identity components like Privilege Access Management (PAM) solutions and other identity providers. Given this, I am pleased to share that we are adding new integrations with solutions like SailPoint and CyberArk that further our commitment to bringing additional depth and coverage for more elements of modern identity landscapes within Defender.

In this same vein, we're making it easier for customers to activate protections across their on-premises identity infrastructure. Today we are excited to share that the unified identity and endpoint agent is extending support for more identity infrastructure and releasing a streamlined experience for existing customers looking to migrate to the new sensor.

In addition to all this we are also adding a new identity explorer experience that is designed to help security professionals uncover identity-based exposures and lateral movement paths within their organization. Leveraging the graph capabilities within Defender and a robust set of pre-defined queries, SOC teams gain new visibility into potential exposure scenarios and end-to-end attack paths.

Streamlined protections and workflows across Defender and Entra

Security teams need to understand how the individual role, privilege, activity and alerts for each individual account relate to the risk of the identity as a whole. To address this, we’re introducing a new unified risk score that aggregates signals across all linked accounts to calculate a single risk score for the identity.

As you can see in the image above the score considers the observed activity, criticality, privilege and likelihood of compromise for each linked account and produces a single, actionable view of risk. This means analysts no longer need to decipher various alerts themselves, they can quickly prioritize investigations based on the potential impact and urgency of identity‑driven threats.

But the value of this new unified risk score doesn’t stop at investigation. Entra ID customers can now leverage these new risk signals directly within their risk-based conditional access policies. This gives admins a stronger signal for access decisions, resulting in earlier prevention, detection, and response across the identity control plane. This powers the feedback loop between identity and SOC teams, ensuring that insights gained in the SOC can immediately reduce exposure across the identity fabric.

Together, these advances transform identity sprawl into clarity. By automatically connecting the dots and surfacing insights instead of raw data Defender is elevating what matters most, helping security teams cut through noise, focus on true risk, and respond to identity‑based threats with greater speed and confidence.

New Identity detections using novel and unique sensor capabilities

Detection opportunities start with visibility and sensor capabilities and we are excited to share a new capability that significantly improves how we see identity-based attacks on Domain Controllers. We work closely with the Windows team within Microsoft and are introducing a new Event Tracking for Windows (ETW) that gives us richer insight into Kerberos activity. This allows us to safely access important ticket details that were previously hidden while the ticket was in use, without needing to break or decrypt the ticket itself.

With this additional context, we can spot unusual behavior that points to forged or tampered Kerberos tickets more accurately than before. By connecting this new operating system signal directly into our identity threat detection capabilities, we unlock a unique level of protection. It also opens up new investigation and hunting scenarios for SOC analysts who want deeper visibility into Kerberos related activity.

Our first detection using this new sensor capability (“Possible golden ticket attack (suspicious ticket)”) is now generally available, and further exemplifies why our strategy is so revolutionary. Previously detecting these types of attacks would require decrypting the ticket/token itself, introducing even more potential for exposure. With this ETW however we have the same visibility without the risk.

We know that Identity attacks no longer stop at the perimeter. Recognizing that modern adversaries target on‑premises, hybrid, and cloud identities alike, we invested heavily in expanding also our detection capabilities across this full spectrum. In particular, we introduced new detections for emerging attack techniques targeting Entra ID as a platform. While Entra ID Protection continues to deliver broad, native protection for Entra users and identities, the core mission of Identity Threat Protection products is to go further— detecting also sophisticated post‑breach activity and lateral movements where attackers directly target the identity provider itself, often by exploiting the hybrid trust and linkage between on‑premises and cloud environments. We are excited to announce the availability of the following new detections:

4 new detections for anomalies and attacks targeting Entra ID sync application in hybrid environments
2 new detections for suspicious device registration/join across Entra and Intune
1 new detection for techniques abusing Oauth Authorization Flow for browser-based attacks, as observed in-the-wild recently (“ConsentFix”)

Powering autonomous Identity Threat Protection

When a security incident is unfolding, every second matters. Attackers are already operating at machine speed, and human response alone can’t keep up, which is why AI-powered capabilities are essential for detecting, triaging and remediating identity threats in time.

As part of our push toward autonomous Identity Threat Protection, we’re extending Security Copilot’s agentic triage capabilities to identity. We’ve already seen the impact of outcome-driven autonomous workflows in phishing, where our agent identifies 6.5 times more malicious alerts than human analysts working alone. Today, that same capability is extending beyond phishing to include identity alerts.

The new Security Alert Triage Agent autonomously evaluates high‑volume identity alerts, distinguishing true threats from noise, and surfacing clear, explainable verdicts so analysts can focus immediately on what requires action. At Public Preview, it supports triage of alert types involving password spray attempts, suspicious inbox rules associated with business email compromise (BEC), and accounts potentially compromised following a password spray attack. Learn more about Security Copilot in Defender announcements here.

In parallel, we’re expanding identity takeover predictive shielding, using real‑time exposure and attack path insights to proactively harden the identity attack surface during an active incident—blocking attacker progression before high‑value identities can be compromised. Together, these capabilities shift identity defense from reactive investigation to real‑time disruption, helping security teams contain attacks faster, reduce blast radius, and stay ahead of adversaries when it matters most.

At Ignite, we introduced predictive shielding, an AI-powered capability in automatic attack disruption that predicts an attacker’s next move in an active attack and applies targeted, just-in-time hardening to block them before they can pivot. Today, predictive shielding proactively hardens many of the controls attackers most often rely on to regain access, such as SafeBoot abuse and Group Policy Objects. We’ve already seen tremendous impact across our customers, including a large public university:

“During a ransomware incident, Microsoft Defender’s attack disruption stopped the attack before it could progress. In parallel, predictive shielding applied Safe Boot hardening across key devices, helping protect against a common evasion tactic—rebooting endpoints into Safe Mode to try and bypass protections like disruption. Together, these layers increased our confidence and resilience during the incident.”

This speed and accuracy matter because identity-based attacks now operate at massive scale, with each user tied to many accounts across the environment, making it increasingly difficult to protect every identity.

We are excited to share that we’re expanding this set of just-in-time hardening actions tailored for identity-based attacks. This includes:

RemoteOps hardening: restricts high-risk remote administrative operations such as RPC-based actions that attackers rely on for lateral movement and hands-on-keyboard control.
Remote Registry hardening: prevents attackers from remotely modifying sensitive registry settings often used to weaken security controls or enable credential theft.

What makes these controls unique is their precision: Defender shields only the specific assets at risk, rather than applying broad, organization-wide restrictions, maximizing security while minimizing business impact.

Looking ahead

Identity has become the foundation of access, trust, and control in modern enterprises—and the primary target for attackers. The announcements detailed throughout this blog reflect our continued commitment to advancing identity security and to helping customers stay ahead of rapidly evolving identity-based threats.

We’re excited to share more throughout the week at RSA, and we look forward to partnering with customers as they continue their journey toward comprehensive, identity centric security.

RSA 2026: What’s new in Microsoft Defender?

Caroline_Lee — Fri, 20 Mar 2026 15:45:00 GMT

Modern attacks increasingly exploit the sprawl of today’s digital environments. In the identity space alone, over half of today’s organizations say each person now has more than 21 distinct accounts. Each one of these accounts is a potential entry point that an attacker can exploit. As organizations adopt cloud, SaaS, AI, and autonomous agents, the rapid growth of non‑human identities accelerates sprawl, expanding the attack surface and increasing gaps in protection. At the same time, agents help accelerate the SOC by automating high‑volume tasks, reducing noise, and enabling analysts to act faster and more consistently.

This shift demands a new approach: comprehensive identity security paired with agentic AI to help the SOC better reason across signals, predict risk, and act earlier, while augmenting human analysts to keep pace with increasingly fast and complex attacks.

At RSA, we’re excited to announce innovations in Microsoft Defender and Security Copilot to help customers defend against the latest threats. These include:

Identity Security: expanded capabilities and enhanced experiences to help the SOC better prepare for, detect and autonomously respond to identity-related threats.
Collaboration Security: protect against voice‑based attacks in Teams with real‑time user warnings, SOC‑ready investigation, and new threat & posture insights reporting.
Accelerate the SOC with Security Copilot: expansion of the Security Triage Agent to identity and cloud alerts, a new Security Analyst agent to uncover risk and a new chat experience directly in Microsoft Defender.
Cloud Security: expansion of multi-cloud visibility to new AWS and GCP services, near real-time container runtime protection to eliminate binary drift, and introducing AI model scanning. Learn more here.

Reshaping Identity Security

Today’s identity landscape is no longer defined by a single directory and a single set of users. It’s a fast-changing fabric of human, non-human, and emerging agentic identities spread across cloud services, SaaS apps, and on-premises infrastructure—that attackers actively target. To meet this new reality, we’re reshaping identity security in Microsoft Defender to move beyond point defenses and reactive investigation to an autonomous, end-to-end approach that continuously strengthens identity posture, stops active threats while they’re happening, and helps the SOC act faster with less manual effort.

To start, we’re broadening our coverage across modern identity fabrics, making posture and activity easier to understand quickly, and tightening the operational loop between identity and the SOC. To do this were delivering new detections, a unified risk score that assesses risk across all accounts and identity types, and updated experiences like the new identity security dashboard that brings your most important posture gaps, active exposures, and identity risk into one place - so security teams can move from fragmented signals to shared context and coordinated action.

On top of this improved foundation we are also unveiling autonomous ITDR in two complementary ways. First, we’re extending Security Copilot’s agentic triage capabilities to identity. With the new Security Alert Triage Agent, Defender can autonomously evaluate high‑volume identity alerts, distinguish true threats from noise, and surface clear, explainable verdicts so analysts can focus immediately on what requires action. Second, we’re bringing the AI-powered just-in-time hardening of predictive shielding to identity allowing Defender to not only disrupt threats but also anticipate an attacker’s next move and automatically enforces targeted controls to block credential- and token-driven pivots before they succeed.

Together, these innovations empower security teams to understand their identity footprint, prioritize what matters most, and stop identity-driven attacks earlier:

Expanded coverage across modern identity fabrics with new identity-specific detections
Identity-level insights that turn sprawl into clarity via an updated dashboard that provides a unified inventory and improved correlation across SaaS apps and identity types—elevating the SOC view from accounts to the identity.
Streamlined protections and aligned workflows across Defender and Entra, including a new identity-level risk score to help identity and SOC teams prioritize and act from shared signals.
Predictive shielding applies precise, just-in-time hardening actions used during identity attacks including RemoteOps hardening and Remote Registry hardening —helping prevent lateral movement.
Autonomous triage for identity alerts with Security Copilot, expanding the Security Triage Agent so identity alerts can be investigated consistently and at scale, with clear verdicts and explainable reasoning to speed up response.

Learn more about these innovations here.

Protect collaboration threats and prove security outcomes

As collaboration platforms become a new front door for attackers, Microsoft Defender extends protection beyond email to detect and respond to voice‑based social engineering in Microsoft Teams. New Teams calling protection surfaces suspicious and malicious calls, enables SOC teams to investigate and correlate call activity using Advanced Hunting, and delivers real‑time in‑call warnings when a call appears to impersonate a trusted contact, closing the gap between what users experience and what analysts can investigate.

To help organizations clearly measure and communicate the impact of these protections, Microsoft Defender is introducing the Protection & Posture Insights report. It gives customers a tenant‑specific view of the threats targeting their environment, highlighting spam, phishing, and malware campaigns observed against users. The report delivers personalized insights and policy recommendations to reduce exposure, while enabling teams to validate results, and share credible, executive‑ready security outcomes—without manual data assembly.

Read more here.

Accelerate your security operations at scale with Security Copilot

Adversaries are using AI to accelerate attacks and increase sophistication. At RSA Conference 2026, we’re expanding our innovation around autonomous and assistive AI in Microsoft Defender with Security Copilot—helping defenders operate with the speed, scale, and intelligence required to stay ahead of modern threats across the entire SOC lifecycle.

In addition to expanding agentic triage to identity alerts, we’re extending that same capability to cloud—bringing phish, identity and cloud triage together within a single agent. The Security Alert Triage Agent helps analysts autonomously determine whether these alerts represent real threats or false alarms, delivering natural language verdicts and transparent, step-by-step decision reasoning.

We’re also announcing the Security Analyst Agent, designed to help security teams uncover hidden risk. This agent performs deep, multi-step investigations across Microsoft Defender and Sentinel telemetry to surface high-impact threats, cut through the noise, and deliver prioritized insights in minutes. Every finding is accompanied by transparent reasoning and supporting evidence.

Lastly, we’re bringing a chat experience for Security Copilot directly within Microsoft Defender. Analysts can ask questions, explore hypotheses, and follow investigative threads across incidents, alerts, identities, devices, IPs, and other evidence without switching tools or manually piecing together context.

You can learn more about Microsoft Security Copilot news at RSA Conference 2026 here.

Looking ahead

The Microsoft Defender announcements at RSA 2026 reflect a clear shift toward agentic and autonomous security, while augmenting the SOC with Security Copilot–driven workflows. Together, these capabilities give defenders clearer context, tighter control, and the ability to stop attacks earlier, before adversaries can escalate privileges or move laterally. Microsoft’s continued investment signals a longer-term evolution toward agentic security operations that anticipate attacker behavior, adapt in real time, and steadily reduce risk as environments and threats continue to evolve.

Learn more at RSA Conference 2026!

To learn more about Microsoft Defender and Security Copilot, visit us at booth # at RSA Conference 2026. Our team will be demonstrating how autonomous agents and assistive AI experiences are helping SOC teams move faster through alert triage, investigation, and response.

You can join our booth sessions:

Empowering the SOC with assistive and autonomous AI with Yuval Derman | March 23rd at 5.15PM
Predictive Shielding: Protecting identities before attackers pivot | March 24th at 4.30PM
Identity Security with Microsoft | March 25 at 3:30PM

For a full list of all the ways to connect with us at RSA, check out our dedicated RSAC 2026 page.

Security Copilot in Defender: empowering the SOC with assistive and autonomous AI

cristinadagamah — Fri, 20 Mar 2026 15:30:00 GMT

Security operations centers are increasingly overwhelmed. Analysts must triage large volumes of alerts, investigate complex signals across multiple environments, and determine which threats require immediate action. Much of this work still involves manually gathering context, reconstructing timelines, and making decisions under time pressure.

As Microsoft Ignite 2025, we introduced how Security Copilot is bringing agentic AI directly into Microsoft Defender to transform how SOC teams detect, triage, and investigate threats. Building on that vision, Copilot continues to expand its capabilities with two complementary forms of AI: autonomous agents that reason dynamically to execute complex security tasks, and assistive experiences that help analysts complete their daily workflows faster and with greater scale.

Together, these innovations are designed to reduce operational burden while enabling analysts to focus on the decisions that matter most.

Autonomous AI: agents that triage alerts and investigate risk

Our vision is to bring autonomous AI across the SOC lifecycle, moving from isolated AI-enabled tasks to outcome-driven agentic transformation that elevates SOC teams across all experience levels. By applying frontier LLM reasoning to security telemetry and threat intelligence, Security Copilot is uniquely positioned to embed specialized agents at every stage—from anticipating risk and preventing attacks, to detecting, triaging, investigating, and responding. The result is a SOC that operates at machine speed while keeping humans firmly in control.

During RSA Conference 2026, we’re expanding that vision within the triage and investigation stage of the SOC lifecycle with the launch of one expanded agent and one new agent.

We’ve already demonstrated the impact of outcome-driven autonomous workflows with agentic phishing triage: our agent identifies 6.5 times more malicious alerts than human analysts working alone. Today, that same capability is extending beyond phishing to identity and cloud alerts.

The Security Alert Triage Agent helps analysts autonomously determine whether phishing, identity and cloud alerts represent real threats or just false alarms. The agent provides natural language verdicts and transparent, step-by-step reasoning that explains how it reached each decision. At Public Preview, for identity, it supports triage of alert types involving password spray attempts, suspicious inbox rules associated with business email compromise (BEC), and accounts potentially compromised following a password spray attack. For cloud, it supports more than 30 alert types related to cloud container activity.

This agent is designed to handle alerts that are both high risk and high noise. Identity and cloud alerts often require longer and more complex investigations, and missing them has important implications. For identity alerts, the challenge is scale—high-volume signals such as password spray generate noise, making it difficult to quickly isolate real compromise. The agent helps by rapidly triaging these alerts and filtering out false positives, allowing analysts to focus on identity activity that truly indicates risk. For cloud alerts, the challenge is different: alert volume may be lower, but investigations are inherently more complex and require deep expertise. In these cases, the agent applies advanced analysis across multiple signals to investigate alerts that would otherwise be burdensome and difficult to analyze manually, helping ensure critical cloud threats are surfaced quickly and not overlooked.

By providing natural language verdicts and transparent decision logic, the agent walks teams step-by-step through investigations that would typically require senior-level expertise. Clear explanations and visual decision graphs show how each conclusion was reached, reducing investigation effort and increasing confidence in outcomes. This transparency frees teams to focus on responding to real threats, while giving junior analysts visibility into the reasoning behind each verdict. The result is specialized expertise embedded directly into daily SOC workflows, raising the floor for the entire team.

At RSA Conference 2026, we’re also announcing the Security Analyst Agent in Microsoft Defender. This agent performs deep, multi-step investigations across Microsoft Defender and Sentinel telemetry to surface high-impact risks and deliver prioritized insights in minutes. Each finding includes clear reasoning and supporting evidence, enabling analysts to quickly understand and act on the results.

Today, teams often rely on advanced hunting to investigate potential threats by writing queries, iteratively refining hypotheses, and correlating results across multiple datasets. While powerful, this process typically requires manually piecing together context across tools, reconstructing timelines, and sifting through large volumes of telemetry to determine whether suspicious activity represents real risk. Given the breadth and complexity of modern threats, these investigations can take days or even weeks.

The Security Analyst Agent builds on the power of advanced hunting by autonomously orchestrating parts of that investigative process. The agent retrieves and analyzes large volumes of security data (up to ~100MB), correlates signals across telemetry sources, and iteratively explores hypotheses to surface patterns and threats that might otherwise go unnoticed. The results are synthesized into clear, risk-relevant findings with supporting evidence trails, helping analysts quickly understand what matters most. In doing so, the agent performs the kind of deep analytical work typically carried out by experienced security analysts.

Assistive AI: Chat experience in the analyst’s flow of work

While autonomous agents help execute complex security tasks with dynamic reasoning, Security Copilot also brings assistive AI directly into analysts’ daily workflows. These capabilities are designed to accelerate manual tasks, helping analysts gather context, and make decisions faster.

Today, Copilot is already embedded across Microsoft Defender experiences. Analysts can generate natural language summaries of incidents, receive guided response recommendations, draft incident reports, generate KQL queries with natural language, and more. These capabilities help accelerate specific tasks, but interactions with Copilot typically occur as individual actions within a side panel or embedded experience.

We’re now taking the next step by introducing a chat experience for Security Copilot directly within Microsoft Defender, enabling teams to interact with AI through an ongoing, two-way conversation. Analysts can ask questions, explore hypotheses, and follow investigative threads across incidents, alerts, identities, devices, IPs, and other evidence—without switching tools or manually piecing together context. Copilot understands the analyst’s investigation context, grounding each response in the relevant signals and telemetry already available in Defender.

Throughout the interaction, Copilot does more than respond. It actively advances the investigation by initiating step-by-step analysis, such as examining a specific entity, while continuously incorporating new signals as they emerge. Analysts can follow up in real time, refining their line of inquiry and digging deeper as the conversation evolves. This creates a more fluid, iterative workflow that lowers the barrier to AI adoption and enables SOC teams to operate with the speed and scale needed to stay ahead of modern threats.

Alongside this new embedded chat experience for Security Copilot, we are also extending conversational capabilities to third-party agents. From the Agents library in Defender, teams can start a chat with any eligible agent to validate findings, gather additional context, and accelerate response. For example, users can interact with XBOW’s Pentest Analysis Agent to determine whether vulnerabilities flagged by Microsoft Defender for Cloud are truly exploitable. The agent can initiate a pentest, explain the results, and recommend next steps—such as improving detection coverage in Microsoft Sentinel—to strengthen defenses.

Learn more at RSA Conference 2026!

To learn more about Security Copilot in Microsoft Defender, visit us at booth #5744. Our team will be demonstrating how AI is helping SOC teams move faster through alert triage, investigation, and response.

You can join our booth sessions:

Empowering the SOC with assistive and autonomous AI with Yuval Derman | March 23^rd at 5.15PM
Security Copilot agents: Insight. Action. Impact. with Lizzie Heinze and Donna Lee | March 24th at 3.00PM

You can also register for Security Copilot in action: An agentic approach to modern security on March 24^th at 8.30AM here.

What’s New in Microsoft Sentinel and XDR: AI Automation, Data Lake Innovation, and Unified SecOps

klianos — Wed, 18 Mar 2026 15:36:22 GMT

The most consequential “new” Microsoft Sentinel / Defender XDR narrative for a deeply technical Microsoft Tech Community article is the operational and engineering shift to unified security operations in the Microsoft Defender portal, including an explicit Azure portal retirement/sunset timeline and concrete migration implications (data tiering, correlation engine changes, schema differences, and automation behavior changes). Official sources now align on March 31, 2027 as the sunset date for managing Microsoft Sentinel in the Azure portal, with customers being redirected to the Defender portal after that date.

The “headline” feature announcements to anchor your article around (because they create new engineering patterns, not just UI changes) are:

AI playbook generator (preview): Natural-language-driven authoring of Python playbooks in an embedded VS Code environment (Cline), using Integration Profiles for dynamic API calls and an Enhanced Alert Trigger for broader automation triggering across Microsoft Sentinel, Defender, and XDR alert sources.
CCF Push (public preview): A push-based connector model built on the Azure Monitor Logs Ingestion API, where deploying via Content Hub can automate provisioning of the typical plumbing (DCR/DCE/app registration/RBAC), enabling near-real-time ingestion plus ingestion-time transformations and (per announcement) direct delivery into certain system tables.
Data lake tier ingestion for Advanced Hunting tables (GA): Direct ingestion of specific Microsoft XDR Advanced Hunting tables into the Microsoft Sentinel data lake without requiring analytics-tier ingestion—explicitly positioned for long-retention, cost-effective storage and retrospective investigations at scale.
Microsoft 365 Copilot data connector (public preview): Ingests Copilot-related audit/activity events via the Purview Unified Audit Log feed into a dedicated table (CopilotActivity) with explicit admin-role requirements and cost notes.
Multi-tenant content distribution expansion: Adds support for distributing analytics rules, automation rules, workbooks, and built-in alert tuning rules across tenants via distribution profiles, with stated limitations (for example, automation rules that trigger a playbook cannot currently be distributed).
Alert schema differences for “standalone vs XDR connector”: A must-cite engineering artifact documenting breaking/behavioral differences (CompromisedEntity semantics, field mapping changes, alert filtering differences) when moving to the consolidated Defender XDR connector path.

What’s new and when

Feature and release matrix

The table below consolidates officially documented Sentinel and Defender XDR features that are relevant to a “new announcements” technical article. If a source does not explicitly state GA/preview or a specific date, it is marked “unspecified.”

Feature	Concise description	Status (official)	Announcement / release date
Azure portal Sentinel retirement / redirection	Sentinel management experience shifts to Defender portal; sunset date extended; post-sunset redirection expected	Date explicitly stated	Mar 31, 2027 sunset (date stated) extension published Jan 29, 2026
Sentinel in Defender portal (core GA)	Sentinel is GA in Defender portal, including for customers without Defender XDR/E5; unified SecOps surface	GA	Doc updated Sep 30, 2025; retirement note reiterated 2026
AI playbook generator	Natural language → Python playbook, documentation, and a visual flow diagram; VS Code + Cline experience	Preview	Feb 23, 2026
Integration Profiles (playbook generator)	Centralized configuration objects (base URL, auth method, credentials) used by generated playbooks to call external APIs dynamically	Preview feature component	Feb 23, 2026
Enhanced Alert Trigger (generated playbooks)	Tenant-level trigger designed to target alerts across Sentinel + Defender + XDR sources and apply granular conditions	Preview feature component	Feb 23, 2026
CCF Push	Push-based ingestion model that reduces setup friction (DCR/DCE/app reg/RBAC), built on Logs Ingestion API; supports transformations and high-throughput ingestion	Public preview	Feb 12–13, 2026
Legacy custom data collection API retirement	Retirement of legacy custom data collection API noted as part of connector modernization	Retirement date stated	Sep 2026 (retirement)
Data lake tier ingestion for Microsoft XDR Advanced Hunting tables	Ingest selected Advanced Hunting tables from MDE/MDO/MDA directly into Sentinel data lake; supports long retention and lake-first analytics	GA	Feb 10, 2026
Microsoft 365 Copilot data connector	Ingests Copilot activities/audit logs; data lands in CopilotActivity; requires specific tenant roles to enable; costs apply	Public preview	Feb 3, 2026
Multi-tenant content distribution: expanded content types	Adds support for analytics rules, automation rules, workbooks, and built-in alert tuning rules; includes limitations and prerequisites	Stated as “supported”; feature described as part of public preview experience in monthly update	Jan 29, 2026
GKE dedicated connector	Dedicated connector built on CCF; ingests GKE cluster activity/workload/security events into GKEAudit; supports DCR transformations and lake-only ingestion	GA	Mar 4, 2026
UEBA behaviors layer	“Who did what to whom” behavior abstraction from raw logs; newer sources state GA; other page sections still label Preview	GA and Preview labels appear in official sources (inconsistent)	Feb 2026 (GA statement)
UEBA widget in Defender portal home	Home-page widget to surface anomalous user behavior and accelerate workflows	Preview	Jan 2026
Alert schema differences: standalone vs XDR connector	Documents field mapping differences, CompromisedEntity behavior changes, and alert filtering/scoping differences	Doc (behavioral/change reference)	Feb 4, 2026 (last updated)
Defender incident investigation: Blast radius analysis	Graph visualization built on Sentinel data lake + graph for propagation path analysis	Preview (per Defender XDR release notes)	Sep 2025 (release notes section)
Advanced hunting: Hunting graph	Graph rendering of predefined threat scenarios in advanced hunting	Preview (per Defender XDR release notes)	Sep 2025 (release notes section)
Sentinel repositories API version retirement	“Call to action” to update API versions: older versions retired June 1, 2026; enforcement June 15, 2026 for actions	Dates explicitly stated	March 2026 (noticed); Jun 1 / Jun 15, 2026 (deadline/enforcement)

Technical architecture and integrations

Unified reference architecture

Microsoft’s official integration documentation describes two “centers of gravity” depending on how you operate:

In Defender portal mode, Sentinel data is ingested alongside organizational data into the Defender portal, enabling SOC teams to analyze and respond from a unified surface.
In Azure portal mode, Defender XDR incidents/alerts flow via Sentinel connectors and analysts work across both experiences.

Integration model: Defender suite and third-party security tools

The Defender XDR integration doc is explicit about:

Supported Defender components whose alerts appear through the integration (Defender for Endpoint, Identity, Office 365, Cloud Apps), plus other services such as Purview DLP and Entra ID Protection.
Behavior when onboarding Sentinel to the Defender portal with Defender XDR licensing: the Defender XDR connector is automatically set up and component alert-provider connectors are disconnected.
Expected latency: Defender XDR incidents typically appear in Sentinel UI/API within ~5 minutes, with additional lag before securityIncident ingestion is complete.
Cost model: Defender XDR alerts and incidents that populate SecurityAlert / SecurityIncident are synchronized at no charge, while other data types (for example, Advanced Hunting tables) are charged.

For third-party tools, Microsoft’s monthly “What’s new” explicitly calls out new GA out-of-the-box connectors/solutions (examples include Mimecast audit logs, Vectra AI XDR, and Proofpoint POD email security) as part of an expanding connector ecosystem intended to unify visibility across cloud, SaaS, and on-premises environments.

Telemetry, schemas, analytics, automation, and APIs

Data flows and ingestion engineering

CCF Push and the “push connector” ingestion path

Microsoft’s CCF Push announcement frames the “old” model as predominantly polling-based (Sentinel periodically fetching from partner/customer APIs) and introduces push-based connectors where partners/customers send data directly to a Sentinel workspace, emphasizing that “Deploy” can auto-provision the typical prerequisites: DCE, DCR, Entra app registration + secrets, and RBAC assignments.

Microsoft also states that CCF Push is built on the Logs Ingestion API, with benefits including throughput, ingestion-time transformation, and system-table targeting.

A precise engineering description of the underlying Logs Ingestion API components (useful for your article even if your readers never build a connector) is documented in Azure Monitor:

Sender app authenticates via an app registration that has access to a DCR.
Sender sends JSON matching the DCR’s expected structure to a DCR endpoint or a DCE (DCE required for Private Link scenarios).
The DCR can apply a transformation to map/filter/enrich before writing to the target table.

DCR transformation (KQL)

Microsoft documents “transformations in Azure Monitor” and provides concrete sample KQL snippets for common needs such as cost reduction and enrichment.

// Keep only Critical events
source | where severity == "Critical"

// Drop a noisy/unneeded column
source | project-away RawData

// Enrich with a simple internal/external IP classification (example)
source | extend IpLocation = iff(split(ClientIp,".")[0] in ("10","192"), "Internal", "External")

These are direct examples from Microsoft’s sample transformations guidance; they are especially relevant because ingestion-time filtering is one of the primary levers for both performance and cost management in Sentinel pipelines.

A Sentinel-specific nuance: Microsoft states that Sentinel-enabled Log Analytics workspaces are not subject to Azure Monitor’s filtering ingestion charge, regardless of how much data a transformation filters (while other Azure Monitor transformation cost rules still exist in general).

Telemetry schemas and key tables you should call out

A “new announcements” article aimed at detection engineers should explicitly name the tables that are impacted by new features:

Copilot connector → CopilotActivity table, with a published list of record types (for example, CopilotInteraction and related plugin/workspace/prompt-book operations) and explicit role requirements to enable (Global Administrator or Security Administrator).
Defender XDR incident/alert sync → SecurityAlert and SecurityIncident populated at no charge; other Defender data types (Advanced Hunting event tables such as DeviceInfo/EmailEvents) are charged.
Sentinel onboarding to Defender advanced hunting: Sentinel alerts tied to incidents are ingested into AlertInfo and accessible in Advanced hunting; SecurityAlert is queryable even if not shown in the schema list in Defender (notable for KQL portability).
UEBA “core” tables (engineering relevance: query joins and tuning): IdentityInfo, BehaviorAnalytics, UserPeerAnalytics, Anomalies.
UEBA behaviors layer tables (new behavior abstraction): SentinelBehaviorInfo and SentinelBehaviorEntities, created only if behaviors layer is enabled.
Microsoft XDR Advanced Hunting lake tier ingestion GA: explicit supported tables from MDE/MDO/MDA (for example DeviceProcessEvents, DeviceNetworkEvents, EmailEvents, UrlClickEvents, CloudAppEvents) and an explicit note that MDI support will follow.

Detection and analytics: UEBA and graph

UEBA operating model and scoring

Microsoft’s UEBA documentation gives you citeable technical detail:

UEBA uses machine learning to build behavioral profiles and detect anomalies versus baselines, incorporating peer group analysis and “blast radius evaluation” concepts.
Risk scoring is described with two different scoring models: BehaviorAnalytics.InvestigationPriority (0–10) vs Anomalies.AnomalyScore (0–1), with different processing characteristics (near-real-time/event-level vs batch/behavior-level).
UEBA Essentials is positioned as a maintained pack of prebuilt queries (including multi-cloud anomaly detection), and Microsoft’s February 2026 update adds detail about expanded anomaly detection across Azure/AWS/GCP/Okta and the anomalies-table-powered queries.

Sentinel data lake and graph as the new “analytics substrate”

Microsoft’s data lake overview frames a two-tier model:

Analytics tier: high-performance, real-time analytics supporting alerting/incident management.
Data lake tier: centralized long-term storage for querying and Python-based analytics, designed for retention up to 12 years, with “single-copy” mirroring (data in analytics tier mirrored to lake tier).

Microsoft’s graph documentation states that if you already have Sentinel data lake, the required graph is auto-provisioned when you sign into the Defender portal, enabling experiences like hunting graph and blast radius. Microsoft also notes that while the experiences are included in existing licensing, enabling data sources can incur ingestion/processing/storage costs.

Automation: AI playbook generator details that matter technically

The playbook generator doc contains unusually concrete engineering constraints and required setup. Key technical points to carry into your article:

Prerequisites: Security Copilot must be enabled with SCUs available (Microsoft states SCUs aren’t billed for playbook generation but are required), and the Sentinel workspace must be onboarded to Defender.
Roles: Sentinel Contributor is required for authoring Automation Rules, and a Detection tuning role in Entra is required to use the generator; permissions may take up to two hours to take effect.
Integration Profiles: explicitly defined as Base URL + auth method + required credentials; cannot change API URL/auth method after creation; supports multiple auth methods including OAuth2 client credentials, API key, AWS auth, Bearer/JWT, etc.
Enhanced Alert Trigger: designed for broader coverage across Sentinel, Defender, and XDR alerts and tenant-level automation consistency.
Limitations: Python only, alerts as the sole input type, no external libraries, max 100 playbooks/tenant, 10-minute runtime, line limits, and separation of enhanced trigger rules from standard alert trigger rules (no automatic migration).

APIs and code/CLI (official)

Create/update a DCR with Azure CLI (official)

Microsoft documents an az monitor data-collection rule create workflow to create/update a DCR from a JSON file, which is directly relevant if your readers build their own “push ingestion” paths outside of CCF Push or need transformations not supported via a guided connector UI.

az monitor data-collection rule create \
--location 'eastus' \
--resource-group 'my-resource-group' \
--name 'my-dcr' \
--rule-file 'C:\MyNewDCR.json' \
--description 'This is my new DCR'

Send logs via Azure Monitor Ingestion client (Python) (official)

Microsoft’s Azure SDK documentation provides a straightforward LogsIngestionClient pattern (and the repo samples document the required environment variables such as DCE, rule immutable ID, and stream name).

import os
from azure.identity import DefaultAzureCredential
from azure.monitor.ingestion import LogsIngestionClient

endpoint = os.environ["DATA_COLLECTION_ENDPOINT"]
rule_id = os.environ["LOGS_DCR_RULE_ID"] # DCR immutable ID
stream_name = os.environ["LOGS_DCR_STREAM_NAME"] # stream name in DCR

credential = DefaultAzureCredential()
client = LogsIngestionClient(endpoint=endpoint, credential=credential)

body = [
{"Time": "2026-03-18T00:00:00Z", "Computer": "host1", "AdditionalContext": "example"}
]

# Actual upload method name/details depend on SDK version and sample specifics.
# Refer to official ingestion samples and README for the exact call.

The repo sample and README explicitly define the environment variables and the use of LogsIngestionClient + DefaultAzureCredential.

Sentinel repositories API version retirement (engineering risk)

Microsoft’s Sentinel release notes contain an explicit “call to action” that older REST API versions used for Sentinel Repositories will be retired (June 1, 2026) and that Source Control actions using older versions will stop being supported (starting June 15, 2026), recommending migration to specific versions. This is critical for “content-as-code” SOC engineering pipelines.

Migration and implementation guidance

Prerequisites and planning gates

A technically rigorous migration section should treat this as a set of gating checks. Microsoft’s transition guidance highlights several that can materially block or change behavior:

Portal transition has no extra cost: Microsoft explicitly states transitioning to the Defender portal has no extra cost (billing remains Sentinel consumption).
Data storage and privacy policies change: after onboarding, Defender XDR policies apply even when working with Sentinel data (data retention/sharing differences).
Customer-managed keys constraint for data lake: CMK is not supported for data stored in Sentinel data lake; even broader, Sentinel data lake onboarding doc warns that CMK-enabled workspaces aren’t accessible via data lake experiences and that data ingested into the lake is encrypted with Microsoft-managed keys.
Region and data residency implications: data lake is provisioned in the primary workspace’s region and onboarding may require consent to ingest Microsoft 365 data into that region if it differs.
Data appearance lag when switching tiers: enabling ingestion for the first time or switching between tiers can take 90–120 minutes for data to appear in tables.

Step-by-step configuration tasks for the most “new” capabilities

Enable lake-tier ingestion for Advanced Hunting tables (GA)

Microsoft’s GA announcement provides direct UI steps in the Defender portal:

Defender portal → Microsoft Sentinel → Configuration → Tables
Select an Advanced Hunting table (from the supported list)
Data Retention Settings → choose “Data lake tier” + set retention + save

Microsoft states that this allows Defender data to remain accessible in the Advanced Hunting table for 30 days while a copy is sent to Sentinel data lake for long-term retention (up to 12 years) and graph/MCP-related scenarios.

Deploy the Microsoft 365 Copilot data connector (public preview)

Microsoft’s connector post provides the operational steps and requirements:

Install via Content Hub in the Defender portal (search “Copilot”, install solution, open connector page).
Enablement requires tenant-level Global Administrator or Security Administrator roles.
Data lands in CopilotActivity.
Ingestion costs apply based on Sentinel workspace settings or Sentinel data lake tier pricing.

Configure multi-tenant content distribution (expanded content types)

Microsoft documents:

Navigate to “Content Distribution” in Defender multi-tenant management portal.
Create/select a distribution profile; choose content types; select content; choose up to 100 workspaces per tenant; save and monitor sync results.
Limitations: automation rules that trigger a playbook cannot currently be distributed; alert tuning rules limited to built-in rules (for now).
Prerequisites: access to more than one tenant via delegated access; subscription to Microsoft 365 E5 or Office E5.

Prepare for Defender XDR connector–driven changes

Microsoft explicitly warns that incident creation rules are turned off for Defender XDR–integrated products to avoid duplicates and suggests compensating controls using Defender portal alert tuning or automation rules. It also warns that incident titles will be governed by Defender XDR correlation and recommends avoiding “incident name” conditions in automation rules (tags recommended).

Common pitfalls and “what breaks”

A strong engineering article should include a “what breaks” section, grounded in Microsoft’s own lists:

Schema and field semantics drift: The “standalone vs XDR connector” schema differences doc calls out CompromisedEntity behavior differences, field mapping changes, and alert filtering differences (for example, Defender for Cloud informational alerts not ingested; Entra ID below High not ingested by default).
Automation delays and unsupported actions post-onboarding: Transition guidance states automation rules might run up to 10 minutes after alert/incident changes due to forwarding, and that some playbook actions (like adding/removing alerts from incidents) are not supported after onboarding—breaking certain playbook patterns.
Incident synchronization boundaries: incidents created in Sentinel via API/Logic App playbook/manual Azure portal aren’t synchronized to Defender portal (per transition doc).
Advanced hunting differences after data lake enablement: auxiliary log tables are no longer available in Defender Advanced hunting once data lake is enabled; they must be accessed via data lake exploration KQL experiences.
CI/CD failures from API retirement: repository connection create/manage tooling that calls older API versions must migrate by June 1, 2026 to avoid action failures.

Performance and cost considerations

Microsoft’s cost model is now best explained using tiering and retention:

Sentinel data lake tier is designed for cost-effective long retention up to 12 years, with analytics-tier data mirrored to the lake tier as a single copy.
For Defender XDR threat hunting data, Microsoft states it is available in analytics tier for 30 days by default; retaining beyond that and moving beyond free windows drives ingestion and/or storage costs depending on whether you extend analytics retention or store longer in lake tier.
Ingesting data directly to data lake tier incurs ingestion, storage, and processing costs; retaining in lake beyond analytics retention incurs storage costs.
Ingestion-time transformations are a first-class cost lever, and Microsoft explicitly frames filtering as a way to reduce ingestion costs in Log Analytics.

Sample deployment checklist

Phase	Task	Acceptance criteria (engineering)
Governance	Confirm target portal strategy and dates	Internal cutover plan aligns with March 31, 2027 retirement; CI/CD deadlines tracked
Identity/RBAC	Validate roles for onboarding + automation	Required Entra roles + Sentinel roles assigned; propagation delays accounted for
Data lake readiness	Decide whether to onboard to Sentinel data lake	CMK policy alignment confirmed; billing subscription owner identified; region implications reviewed
Defender XDR integration	Choose integration mode and test incident sync	Incidents visible within expected latency; bi-directional sync fields behave as expected
Schema regression	Validate queries/rules against XDR connector schema	KQL regression tests pass; CompromisedEntity and filtering changes handled
Connector modernization	Inventory connectors; plan CCF / CCF Push transitions	Function-based connectors migration plan; legacy custom data collection API retirement addressed
Automation	Pilot AI playbook generator + enhanced triggers	Integration Profiles created; generated playbooks reviewed; enhanced trigger scopes correct
Multi-tenant operations	Configure content distribution if needed	Distribution profiles sync reliably; limitations documented; rollback/override plan exists
Outage-proofing	Update Sentinel repos tooling for API retirement	All source-control actions use recommended API versions before June 1, 2026

Use cases and customer impact

Detection and response scenarios that map to the new announcements

Copilot governance and misuse detection
The Copilot connector’s published record types enable detections for scenarios such as unauthorized plugin/workspace/prompt-book operations and anomalous Copilot interactions. Data is explicitly positioned for analytic rules, workbooks, automation, and threat hunting within Sentinel and Sentinel data lake.

Long-retention hunting on high-volume Defender telemetry (lake-first approach)
Lake-tier ingestion for Advanced Hunting tables (GA) is explicitly framed around scale, cost containment, and retrospective investigations beyond “near-real-time” windows, while keeping 30-day availability in the Advanced Hunting tables themselves.

Faster automation authoring and customization (SOAR engineering productivity)
Microsoft positions the playbook generator as eliminating rigid templates and enabling dynamic API calls across Microsoft and third-party tools via Integration Profiles, with preview-customer feedback claiming faster automation development (vendor-stated).

Multi-tenant SOC standardization (MSSP / large enterprise)
Multi-tenant content distribution is explicitly designed to replicate detections, automation, and dashboards across tenants, reducing drift and accelerating onboarding, while keeping execution local to target tenants.

Measurable benefit dimensions (how to discuss rigorously)

Most Microsoft sources in this announcement set are descriptive (not benchmark studies). A rigorous article should therefore describe what you can measure, and label any numeric claims as vendor-stated.

Recommended measurable dimensions grounded in the features as documented:

Time-to-detect / time-to-ingest: CCF Push is positioned as real-time, event-driven delivery vs polling-based ingestion.
Time-to-triage / time-to-investigate: UEBA layers (Anomalies + Behaviors) are designed to summarize and prioritize activity, with explicit scoring models and tables for query enrichment.
Incident queue pressure: Defender XDR grouping/enrichment is explicitly described as reducing SOC queue size and time to resolve.
Cost-per-retained-GB and query cost: tiering rules and retention windows define cost tradeoffs; ingestion-time transformations reduce cost by dropping unneeded rows/columns.

Vendor-stated metrics: Microsoft’s March 2026 “What’s new” roundup references an external buyer’s guide and reports “44% reduction in total cost of ownership” and “93% faster deployment times” as outcomes for organizations using Sentinel (treat as vendor marketing unless corroborated by an independent study in your environment).

Comparison of old vs new Microsoft capabilities and competitor XDR positioning

Old vs new (Microsoft)

Capability	“Older” operating model (common patterns implied by docs)	“New” model emphasized in announcements/release notes
Primary SOC console	Split experience (Azure portal Sentinel + Defender portal XDR)	Defender portal as the primary unified SecOps surface; Azure portal sunset
Incident correlation engine	Sentinel correlation features (e.g., Fusion in Azure portal)	Defender XDR correlation engine replaces Fusion for incident creation after onboarding; incident provider always “Microsoft XDR” in Defender portal mode
Automation authoring	Logic Apps playbooks + automation rules	Adds AI playbook generator (Python) + Enhanced Alert Trigger, with explicit constraints/limits
Custom ingestion	Data Collector API legacy patterns + manual DCR/DCE plumbing	CCF Push built on Logs Ingestion API; emphasizes automated provisioning and transformation support
Long retention	Primarily analytics-tier retention strategies	Data lake tier supports up to 12 years; lake-tier ingestion for AH tables GA; explicit tier/cost model
Graph-driven investigations	Basic incident graphs	Blast radius analysis + hunting graph experiences built on Sentinel data lake + graph

Competitor XDR offerings (high-level, vendor pages)

The table below is intentionally “high-level” and marks details as unspecified unless explicitly stated on the cited vendor pages.

Vendor	Positioning claims (from official vendor pages)	Notes / unspecified items
CrowdStrike	Falcon Insight XDR is positioned as “AI-native XDR” for “endpoint and beyond,” emphasizing detection/response and threat intelligence.	Data lake architecture, ingestion transformation model, and multi-tenant content distribution specifics are unspecified in cited sources.
Palo Alto Networks	Cortex XDR is positioned as integrated endpoint security with AI-driven operations and broader visibility; vendor site highlights outcome metrics in customer stories and “AI-driven endpoint security.”	Lake/graph primitives, connector framework model, and schema parity details are unspecified in cited sources.
SentinelOne	Singularity XDR is positioned as AI-powered response with automated workflows across the environment; emphasizes machine-speed incident response.	Specific SIEM-style retention tiering and documented ingestion-time transformations are unspecified in cited sources.

Why there is no Signature status for the new process in the DeviceProcessEvent table?

rstanile — Thu, 12 Mar 2026 09:22:30 GMT

According to the schema, there is only field for checking the initiating (parent) process digital signature, named InitiatingProcessSignatureStatus. So we have information if the process that initiated the execution is signed. However, in many security use-cases it is important to know if the spawned (child) process is digitally signed.

Let's assume that Winword.exe (signed) executed unsigned binary - this is definitely different situation than Winword.exe executing some signed binary (although both may be suspicious, or legitimate).

I feel that some valuable information is not provided, and I'd like to know the reason. Is it related to the logging performance? Or some memory structures, that are present only for the already existing process?

Endpoint and EDR Ecosystem Connectors in Microsoft Sentinel

klianos — Thu, 05 Mar 2026 10:21:30 GMT

Most SOCs operate in mixed endpoint environments. Even if Microsoft Defender for Endpoint is your primary EDR, you may still run Cisco Secure Endpoint, WithSecure Elements, Knox, or Lookout in specific regions, subsidiaries, mobile fleets, or regulatory enclaves. The goal is not to replace any tool, but to standardize how signals become detections and response actions. This article explains an engineering-first approach: ingestion correctness, schema normalization, entity mapping, incident merging, and cross-platform response orchestration.

Think of these connectors as four different lenses on endpoint risk. Two provide classic EDR detections (Cisco, WithSecure). Two provide mobile security and posture signals (Knox, Lookout). The highest-fidelity outcomes come from correlating them with Microsoft signals (Defender for Endpoint device telemetry, Entra ID sign-ins, and threat intelligence).

Cisco Secure Endpoint

Typical signal types include malware detections, exploit prevention events, retrospective detections, device isolation actions, and file/trajectory context. Cisco telemetry is often hash-centric (SHA256, file reputation) which makes it excellent for IOC matching and cross-EDR correlation.

WithSecure Elements

WithSecure Elements tends to provide strong behavioral detections and ransomware heuristics, often including process ancestry and behavioral classification. It complements hash-based detections by providing behavior and incident context that can be joined to Defender process events.

Samsung Knox Asset Intelligence

Knox is posture-heavy. Typical signals include compliance state, encryption status, root/jailbreak indicators, patch level, device model identifiers and policy violations. This data is extremely useful for identity correlation: it helps answer whether a successful sign-in came from a device that should be trusted.

Lookout Mobile Threat Defense

Lookout focuses on mobile threats such as malicious apps, phishing, risky networks (MITM), device compromise indicators, and risk scores. Lookout signals are critical for identity attack chains because mobile phishing is often the precursor to token theft or credential reuse.

2. Ingestion architecture: from vendor API to Sentinel tables

Most third‑party connectors are API-based. In production, treat ingestion as a pipeline with reliability requirements.

The standard pattern is vendor API → connector runtime (codeless connector or Azure Function) → DCE → DCR transform → Log Analytics table.

Key engineering controls:

Secrets and tokens should be stored in Azure Key Vault where supported; rotate and monitor auth failures.
Use overlap windows (poll slightly more than the schedule interval) and deduplicate by stable event IDs.
Use DCR transforms to normalize fields early (device/user/IP/severity) and to filter obviously low-value noise.
Monitor connector health and ingestion lag; do not rely on ‘Connected’ status alone.

Ingestion health checks (KQL)

// Freshness & lag per connector table (adapt table names to your workspace)
let lookback = 24h
union isfuzzy=true
(<CiscoTable>      | extend Source="Cisco"),
(<WithSecureTable> | extend Source="WithSecure"),
(<KnoxTable>       | extend Source="Knox"),
(<LookoutTable>    | extend Source="Lookout")
| where TimeGenerated > ago(lookback)
| summarize LastEvent=max(TimeGenerated), Events=count() by Source
| extend IngestDelayMin = datetime_diff("minute", now(), LastEvent)
| order by IngestDelayMin desc

3. Normalization: make detections vendor-agnostic

The most common failure mode in multi-EDR SOCs is writing separate rules per vendor. Instead, build one normalization function that outputs a stable schema. Then write rules once.

Recommended canonical fields:

Vendor, AlertId, EventTime, SeverityNormalized
DeviceName (canonical), AccountUpn (canonical), SourceIP
FileHash (when applicable), ThreatName/Category
CorrelationKey (stable join key such as DeviceName + FileHash or DeviceName + AlertId)

// Example NormalizeEndpoint() pattern. Replace column_ifexists(...) mappings after getschema().
let NormalizeEndpoint = () {
union isfuzzy=true
(
Cisco
| extend Vendor="Cisco"
| extend DeviceName=tostring(column_ifexists("hostname","")),
           AccountUpn=tostring(column_ifexists("user","")),
           SourceIP=tostring(column_ifexists("ip","")),
           FileHash=tostring(column_ifexists("sha256","")),
           ThreatName=tostring(column_ifexists("threat_name","")),
           SeverityNormalized=tolower(tostring(column_ifexists("severity","")))
),
(
WithSecure
| extend Vendor="WithSecure"
| extend DeviceName=tostring(column_ifexists("hostname","")),
           AccountUpn=tostring(column_ifexists("user","")),
           SourceIP=tostring(column_ifexists("ip","")),
           FileHash=tostring(column_ifexists("file_hash","")),
           ThreatName=tostring(column_ifexists("classification","")),
           SeverityNormalized=tolower(tostring(column_ifexists("risk_level","")))
),
(
Knox
| extend Vendor="Knox"
| extend DeviceName=tostring(column_ifexists("device_id","")),
           AccountUpn=tostring(column_ifexists("user","")),
           SourceIP="",
           FileHash="",
           ThreatName=strcat("Device posture: ", tostring(column_ifexists("compliance_state",""))),
           SeverityNormalized=tolower(tostring(column_ifexists("risk","")))
),
(
Lookout
| extend Vendor="Lookout"
| extend DeviceName=tostring(column_ifexists("device_id","")),
         AccountUpn=tostring(column_ifexists("user","")),
           SourceIP=tostring(column_ifexists("source_ip","")),
           FileHash="",
           ThreatName=tostring(column_ifexists("threat_type","")),
           SeverityNormalized=tolower(tostring(column_ifexists("risk_level","")))
)
| extend CorrelationKey = iff(isnotempty(FileHash), strcat(DeviceName, "|", FileHash), strcat(DeviceName, "|", ThreatName))
| project TimeGenerated, Vendor, DeviceName, AccountUpn, SourceIP, FileHash, ThreatName, SeverityNormalized, CorrelationKey, *
}

4. Entity mapping and incident merging

Sentinel’s incident experience improves dramatically when alerts include entity mapping. Map Host, Account, IP, and File (hash) where possible. Incident grouping should merge alerts by DeviceName and AccountUpn within a reasonable window (e.g., 6–24 hours) to avoid alert storms.

5. Correlation patterns that raise confidence

High-confidence detections come from confirmation across independent sensors. These patterns reduce false positives while catching real compromise chains.

5.1 Multi-vendor confirmation (two EDRs agree)

NormalizeEndpoint()
| where TimeGenerated > ago(24h)
| summarize Vendors=dcount(Vendor), VendorSet=make_set(Vendor, 10) by DeviceName
| where Vendors >= 2

5.2 Third-party detection confirmed by Defender process telemetry

let tp =
NormalizeEndpoint()
| where TimeGenerated > ago(6h)
| where ThreatName has_any ("powershell","ransom","credential","exploit")
| project TPTime=TimeGenerated, DeviceName, AccountUpn, Vendor, ThreatName

tp
| join kind=inner (
    DeviceProcessEvents
    | where Timestamp > ago(6h)
    | where ProcessCommandLine has_any ("EncodedCommand","IEX","FromBase64String","rundll32","regsvr32")
    | project MDETime=Timestamp, DeviceName=tostring(DeviceName), Proc=ProcessCommandLine
) on DeviceName
| where MDETime between (TPTime .. TPTime + 30m)
| project TPTime, MDETime, DeviceName, Vendor, ThreatName, Proc

5.3 Mobile phishing signal followed by successful sign-in

let mobile =
NormalizeEndpoint()
| where TimeGenerated > ago(24h)
| where Vendor == "Lookout" and ThreatName has "phish"
| project MTDTime=TimeGenerated, AccountUpn, DeviceName, SourceIP

mobile
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(24h)
    | where ResultType == 0
    | project SigninTime=TimeGenerated, AccountUpn=tostring(UserPrincipalName), IPAddress, AppDisplayName
) on AccountUpn
| where SigninTime between (MTDTime .. MTDTime + 30m)
| project MTDTime, SigninTime, AccountUpn, DeviceName, SourceIP, IPAddress, AppDisplayName

5.4 Knox posture and high-risk sign-in

let noncompliant =
NormalizeEndpoint()
| where TimeGenerated > ago(7d)
| where Vendor=="Knox" and ThreatName has "NonCompliant"
| project DeviceName, AccountUpn, KnoxTime=TimeGenerated

noncompliant
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(7d)
    | where RiskLevelDuringSignIn in ("high","medium")
    | project SigninTime=TimeGenerated, AccountUpn=tostring(UserPrincipalName), RiskLevelDuringSignIn, IPAddress
) on AccountUpn
| where SigninTime between (KnoxTime .. KnoxTime + 2h)
| project KnoxTime, SigninTime, AccountUpn, DeviceName, RiskLevelDuringSignIn, IPAddress

6. Response orchestration (SOAR) design

Response should be consistent across vendors. Use a scoring model to decide whether to isolate a device, revoke tokens, or enforce Conditional Access. Prefer reversible actions, and log every automation step for audit.

6.1 Risk scoring to gate playbooks

let SevScore = (s:string) { case(s=="critical",5,s=="high",4,s=="medium",2,1) }
NormalizeEndpoint()
| where TimeGenerated > ago(24h)
| extend Score = SevScore(SeverityNormalized)
| summarize RiskScore=sum(Score), Alerts=count(), Vendors=make_set(Vendor, 10) by DeviceName, AccountUpn
| where RiskScore >= 8
| order by RiskScore desc

High-severity playbooks typically execute: (1) isolate device via Defender (if onboarded), (2) revoke tokens in Entra ID, (3) trigger Conditional Access block, (4) notify and open ITSM ticket. Medium-severity playbooks usually tag the incident, add watchlist entries, and notify analysts.

Monthly news - March 2026

HeikeRitter — Mon, 02 Mar 2026 12:13:48 GMT

Microsoft Defender
Monthly news - March 2026 Edition

This is our monthly "What's new" blog post, summarizing product updates and various new assets we released over the past month across our Defender products. In this edition, we are looking at all the goodness from February 2026. We are now including news related to Defender for Cloud in the Defender portal. For all other Defender for Cloud news, have a look at the dedicated Defender for Cloud Monthly News here.

🚀 New Virtual Ninja Show episode:

New AI-powered SIEM migration experience

Microsoft Defender

(Public Preview) Microsoft Defender for Cloud is expanding to the Defender portal to provide a unified security experience across cloud and code environments. As part of this expansion, some features are now available in the Microsoft Defender Portal, and additional capabilities will be added to the Defender portal over time. Follow instructions provided here to enable Defender for Cloud experience in XDR. Learn more on how to enable preview features in the Defender portal.
(Public Preview) Generate playbooks using AI in Microsoft Sentinel: The SOAR playbook generator creates python based automation workflows coauthored through a conversational experience with Cline, an AI coding agent. For more information, see the Playbook Generation blog post.
(Public Preview) The Microsoft Copilot Data Connector for Microsoft Sentinel. This new connector allows for audit logs and activities generated by Copilot to be ingested into Microsoft Sentinel and Microsoft Sentinel data lake. The data can be used in analytic rules/custom detections, Workbooks, automation, and more.
Update: We are extending the sunset date for managing Microsoft Sentinel in the Azure portal to March 31, 2027.
The upcoming Sentinel update standardizes Account Name in analytics, incidents, and automation. Starting July 1, 2026 for UPN-based mappings, Account Name will show only the UPN prefix, with new fields for full UPN and UPN suffix.
Microsoft Defender Experts for Hunting customers can now set up Notification contacts. These contacts are the individuals or groups that Microsoft needs to notify if there are critical incidents or service updates. Learn more on our docs.
The following advanced hunting schema tables are now generally available:
- IdentityAccountInfo
- EntraIdSignInEvents
- EntraIdSpnSignInEvents
- GraphApiAuditEvents
Lake only ingestion for Microsoft Defender Advanced Hunting tables is now General Available. You can now ingest Advanced Hunting data into Sentinel Data lake without the need to ingest into the Microsoft Sentinel Analytics tier.
Custom Guidebooks (SOP) for Copilot Guided Response is now Generally Available! Custom Guidebooks enable organizations to bring their own Standard Operating Procedures (SOPs) directly into the Copilot Guided Response experience, helping ensure investigations and remediation steps align with internal processes and best practices. Please find more information in our documentation.
On the new Custom Guidebookssettings page in the portal, users can upload guidebooks and review the parsed tasks generated from their SOP files.
(Public Preview) The Sentinel Codeless Connector Framework (CCF) Push feature. CCF addresses a critical need: enabling seamless, automated, and immediate delivery of security data to Microsoft Sentinel, so teams can respond to threats as they happen.
The UEBA behaviors layer in Microsoft Sentinel is now generally available, summarizing clear, human‑readable behavioral insights from high-volume, raw security logs. The behaviors layer aggregates and sequences related events into normalized behaviors, helping analysts more quickly understand who did what to whom without manually correlating raw logs. For more information, see Translate raw security logs to behavioral insights using UEBA behaviors in Microsoft Sentinel.
Watch the UEBA behaviors webinar for a full overview and demo of the UEBA behaviors layer.
To help SOC teams get value from behaviors from day one, Microsoft Sentinel now provides the behaviors workbook as part of the UEBA essentials solution. The workbook offers guided views and prebuilt, customizable analytics that turn rich behavioral data into actionable insights across three core SOC workflows. For more information about the workbook, see the Microsoft Sentinel Behaviors Workbook blog post.

Microsoft Defender for Endpoint / Microsoft Defender Vulnerability Management

(Public Preview) Microsoft Defender now has a Library Management for live response! This is addressing a long standing pain point. You can now centrally manage Live Response scripts and files directly in the Defender portal, not just during a live response session. Read more details in this blog post.
(General Availability) Effective Settings: Effective Settings Reporting for device security settings is now available in GA! This report presents the actual security settings enforced on a specific device, capturing the real configuration rather than just the admin’s intent.
This visibility empowers admins to easily track applied configurations and swiftly identify discrepancies.

A new tab, named "Effective Settings", is now enabled on the device page, under the "Configuration Management" section. This tab displays:
- The actual value of each security setting
- The configuring source for each setting
- Configuration attempts from other sources that were not effectively applied
(General Availability) To reflect Defender Vulnerability Management's visibility into all software components identified in your organization, the Vulnerable components page is now named Software components.
(General Availability) To provide comprehensive vulnerability management capabilities across all supported Windows versions, Microsoft Defender Vulnerability Management now gathers software product vulnerability data on Windows 7 devices.
The what's new and OS-specific release notes pages are now updated to provide better visibility and access to new features, improvements, and fixes:
- The what's new page is now named New features in Microsoft Defender for Endpoint and includes both features and links to latest release notes.
- The Release notes page now consolidates release details for all supported operating systems, including Windows Antivirus. The new page groups updates by platform and date, making it easier to find specific information.
- All previous release notes pages redirect to the consolidated release notes page.

Microsoft Defender for Identity

Webinar recording: Identity Control Plane Under Attack: Consent Abuse and Hybrid Sync Risks (YouTube)

A new wave of identity attacks abuses legitimate authentication flows, allowing attackers to gain access without stealing passwords or breaking MFA. In this webinar recording the team breaks down how attackers trick users into approving malicious apps, how this leads to silent account takeover, and why traditional phishing defenses often miss it. They also dive into the identity sync layer at the heart of hybrid environments. You’ll learn how Entra Connect Sync and Cloud Sync are protected as Tier-0 assets, how Microsoft Defender for Identity secures synchronization flows, and how the new application-based authentication model strengthens Entra Connect Sync against modern threats.

Microsoft Defender for Office 365

Expanding User reporting in Teams to Defender for Office 365 Plan 1: Users can report external and intra-org Microsoft Teams messages from chats, standard, shared, and private channels, meeting conversations to Microsoft as malicious (security risk) the specified reporting mailbox, or both via user reported settings.

Microsoft Defender for Cloud Apps

As part of Microsoft's ongoing efforts to increase accuracy in Secure Score, security recommendation categories will be updated in March 2026. As a result, identity and app Secure Scores may be impacted.

Issues blocking DeepSeek

KevinJohnson1 — Thu, 26 Feb 2026 02:45:18 GMT

Hi all,

I am investigating DeepSeek usage in our Microsoft security environment and have found inconsistent behaviour between Defender for Cloud Apps, Defender for Endpoint, and IOC controls. I am hoping to understand if others have seen the same.

Environment

Full Microsoft security and management suite

What we are seeing

Defender for Cloud Apps

DeepSeek is classified as an Unsanctioned app

Cloud Discovery shows ongoing traffic and active usage

Multiple successful sessions and data activity visible

Defender for Endpoint Indicators

DeepSeek domains and URIs have been added as Indicators with Block action

Indicators show as successfully applied

Advanced Hunting and Device Timeline

Multiple executable processes are initiating connections to DeepSeek domains

Examples include Edge, Chrome, and other executables making outbound HTTPS connections

Connection status is a mix of Successful and Unsuccessful

No block events recorded

Settings

Network Protection enabled in block mode

Web Content Filtering enabled

SmartScreen enabled

File Hash Computation enabled

Network Protection Reputation mode set to 1

Has anyone else had similar issues when trying to block DeepSeek or other apps via Microsoft security suite?

I am currently working with Microsoft support on this but wanted to ask here as well.

Threat Intelligence & Identity Ecosystem Connectors

klianos — Mon, 16 Feb 2026 12:21:06 GMT

Microsoft Sentinel’s capability can be greatly enhanced by integrating third-party threat intelligence (TI) feeds (e.g. GreyNoise, Team Cymru) with identity and access logs (e.g. OneLogin, PingOne). This article provides a detailed dive into each connector, data types, and best practices for enrichment and false-positive reduction. We cover how GreyNoise (including PureSignal/Scout), Team Cymru, OneLogin IAM, PingOne, and Keeper integrate with Sentinel – including available connectors, ingested schemas, and configuration. We then outline technical patterns for building TI-based lookup pipelines, scoring, and suppression rules to filter benign noise (e.g. GreyNoise’s known scanners), and enrich alerts with context from identity logs. We map attack chains (credential stuffing, lateral movement, account takeover) to Sentinel data, and propose KQL analytics rules and playbooks with MITRE ATT&CK mappings (e.g. T1110: Brute Force, T1595: Active Scanning). The report also includes guidance on deployment (ARM/Bicep examples), performance considerations for high-volume TI ingestion, and comparison tables of connector features. A mermaid flowchart illustrates the data flow from TI and identity sources into Sentinel analytics. All recommendations are drawn from official documentation and industry sources.

Threat Intel & Identity Connectors Overview

GreyNoise (TI Feed): GreyNoise provides “internet background noise” intelligence on IPs seen scanning or probing the Internet. The Sentinel GreyNoise Threat Intelligence connector (Azure Marketplace) pulls data via GreyNoise’s API into Sentinel’s ThreatIntelligenceIndicator table. It uses a daily Azure Function to fetch indicators (IP addresses and metadata like classification, noise, last_seen) and injects them as STIX-format indicators (Network IPs with provider “GreyNoise”). This feed can then be queried in KQL. Authentication requires a GreyNoise API key and a Sentinel workspace app with Contributor rights. GreyNoise’s goal is to help “filter out known opportunistic traffic” so analysts can focus on real threats. Official docs describe deploying the content pack and workbook template.

Ingested data: IP-based indicators (malicious vs. benign scans), classifications (noise, riot, etc.), organization names, last-seen dates. All fields from GreyNoise’s IP lookup (e.g. classification, last_seen) appear in ThreatIntelligenceIndicator.NetworkDestinationIP, IndicatorProvider="GreyNoise", and related fields.

Query:

ThreatIntelligenceIndicator
| where IndicatorProvider == "GreyNoise"
| summarize arg_max(TimeGenerated, *) by NetworkDestinationIP

This yields the latest GreyNoise record per IP.

Team Cymru Scout (TI Context): Team Cymru’s PureSignal™ Scout is a TI enrichment platform. The Team Cymru Scout connector (via Azure Marketplace) ingests contextual data (not raw logs) about IPs, domains, and account usage into Sentinel custom tables. It runs via an Azure Function that, given IP or domain inputs, populates tables like Cymru_Scout_IP_Data_* and Cymru_Scout_Domain_Data_CL. For example, an IP query yields multiple tables: Cymru_Scout_IP_Data_Foundation_CL, ..._OpenPorts_CL, ..._PDNS_CL, etc., containing open ports, passive DNS history, X.509 cert info, fingerprint data, etc. This feed requires a Team Cymru account (username/password) to access the Scout API.

Data types: Structured TI metadata by IP/domain. No native ThreatIndicator insertion; instead, analysts query these tables to enrich events (e.g. join on SourceIP). The Sentintel TechCommunity notes that Scout “enriches alerts with real-time context on IPs, domains, and adversary infrastructure” and can help “reduce false positives”.

OneLogin IAM (Identity Logs): The OneLogin IAM solution (Microsoft Sentinel content pack) ingests OneLogin platform events and user info via OneLogin’s REST API. Using the Codeless Connector Framework, it pulls from OneLogin’s Events API and Users API, storing data in custom tables OneLoginEventsV2_CL and OneLoginUsersV2_CL. Typical events include user sign-ins, MFA actions, app accesses, admin changes, etc. Prerequisites: create an OpenID Connect app in OneLogin (for client ID/secret) and register it in Azure (Global Admin). The connector queries hourly (or on schedule), within OneLogin’s rate limit of 5000 calls/hour.

Data mapping: OneLoginEventsV2_CL (CL suffix indicates custom log) holds event records (time, user, IP, event type, result, etc.); OneLoginUsersV2_CL contains user account attributes. These can be joined or used in analytics. For example, a query might look for failed login events:

OneLoginEventsV2_CL
| where Event_type_s == "UserSessionStart" and Result_s == "Failed"

(Actual field names depend on schema.)

PingOne (Identity Logs): The PingOne Audit connector ingests audit activity from the PingOne Identity platform via its REST API. It creates the table PingOne_AuditActivitiesV2_CL. This includes administrator actions, user logins, console events, etc. You configure a PingOne API client (Client ID/Secret) and set up the Codeless Connector Framework. Logs are retrieved (with attention to PingOne’s license-based rate limits) and appended to the custom table. Analysts can query, for instance, PingOne_AuditActivitiesV2_CL for events like MFA failures or profile changes.

Keeper (Password Vault Logs – optional): Keeper, a password management platform, can forward security events to Sentinel via Azure Monitor. As of latest docs, logs are sent to a custom log table (commonly KeeperLogs_CL) using Azure Data Collection Rules. In Keeper’s guide, you register an Azure AD app (“KeeperLogging”) and configure Azure Monitor data collection; then in the Keeper Admin Console you specify the DCR endpoint. Keeper events (e.g. user logins, vault actions, admin changes) are ingested into the table named (e.g.) Custom-KeeperLogs_CL. Authentication uses the app’s client ID/secret and a monitor endpoint URL. This is a bulk ingest of records, rather than a scheduled pull.

Data ingested: custom Keeper events with fields like user, action, timestamp. Keeper’s integration is essentially via Azure Monitor (in the older Azure Sentinel approach).

Connector Configuration & Data Ingestion

Authentication and Rate Limits: Most connectors require API keys or OAuth credentials. GreyNoise and Team Cymru use single keys/credentials, with the Azure Function secured by a Managed Identity. OneLogin and PingOne use client ID/secret and must respect their API limits (OneLogin ~5k calls/hour; PingOne depends on licensing). GreyNoise’s enterprise API allows bulk lookups; the community API is limited (10/day for free), so production integration requires an Enterprise plan.

Sentinel Tables: Data is inserted either into built-in tables or custom tables. GreyNoise feeds the ThreatIntelligenceIndicator table, populating fields like NetworkDestinationIP and ThreatSeverity (higher if classified “malicious”). Team Cymru’s Scout connector creates many Cymru_Scout_*_CL tables. OneLogin’s solution populates OneLoginEventsV2_CL and OneLoginUsersV2_CL. PingOne yields PingOne_AuditActivitiesV2_CL. Keeper logs appear in a custom table (e.g. KeeperLogs_CL) as shown in Keeper’s guide. Note: Sentinel’s built-in identity tables (IdentityInfo, SigninLogs) are typically for Microsoft identities; third-party logs can be mapped to them via parsers or custom analytic rules but by default arrive in these custom tables.
Data Types & Schema:

Threat Indicators: In ThreatIntelligenceIndicator, GreyNoise IPs appear as NetworkDestinationIP with associated fields (e.g. ThreatSeverity, IndicatorProvider="GreyNoise", ConfidenceScore, etc.). (Future STIX tables may be used after 2025.)
Custom CL Logs: OneLogin events may include fields such as user_id_s, user_login_s, client_ip_s, event_time, etc. (The published parser issues indicate fields like app_name_s, role_id_d, etc.) PingOne logs include eventType, user, clientIP, result. Keeper logs contain Action, UserName, etc. These raw fields can be normalized in analytic rules or parsed by data transformations.

Identity Info: Although not directly ingested, identity attributes from OneLogin/PingOne (e.g. user roles, group IDs) could be periodically fetched and synced to Sentinel (via custom logic) to populate IdentityInfo records, aiding user-centric hunts.

Configuration Steps :

GreyNoise: In Sentinel Content Hub, install the GreyNoise ThreatIntel solution. Enter your GreyNoise API key when prompted. The solution deploys an Azure Function (requires write access to Functions) and sets up an ingestion schedule. Verify the ThreatIntelligenceIndicator table is receiving GreyNoise entries
Team Cymru: From Marketplace install “Team Cymru Scout”. Provide Scout credentials. The solution creates an Azure Function app. It defines a workflow to ingest or lookup IPs/domains. (Often, analysts trigger lookups rather than scheduled ingestion, since Scout is lookup-based.) Ensure roles: the Function’s managed identity needs Sentinel contributor rights.
OneLogin: Use the Data Connectors UI. Authenticate OneLogin by creating a new Sentinel Web API authentication (with OneLogin’s client ID/secret). Enable both “OneLogin Events” and “OneLogin Users”. No agent is needed. After setup, data flows into OneLoginEventsV2_CL.
PingOne: Similarly, configure the PingOne connector. Use the PingOne administrative console to register an OAuth client. In Sentinel’s connector blade, enter the client ID/secret and specify desired log types (Audit, maybe IDP logs). Confirm PingOne_AuditActivitiesV2_CL populates hourly.

Keeper: Register an Azure AD app (“KeeperLogging”) and assign it Monitoring roles (Publisher/Contributor) to your workspace and data collection endpoint. Create an Azure Data Collection Rule (DCR) and table (e.g. KeeperLogs_CL). In Keeper’s Admin Console (Reporting & Alerts → Azure Monitor), enter the tenant ID, client ID/secret, and the DCR endpoint URL (format: https://<DCE>/dataCollectionRules/<DCR_ID>/streams/<table>?api-version=2023-01-01). Keeper will then push logs.
KQL Lookup: To enrich a Sentinel event with these feeds, you might write:

OneLoginEventsV2_CL
| where EventType == "UserLogin" and Result == "Success"
| extend UserIP = ClientIP_s
| join kind=inner (
    ThreatIntelligenceIndicator
    | where IndicatorProvider == "GreyNoise" and ThreatSeverity >= 3
    | project NetworkDestinationIP, Category
) on $left.UserIP == $right.NetworkDestinationIP

This joins OneLogin sign-ins with GreyNoise’s list of malicious scanners.

Enrichment & False-Positive Reduction

IOC Enrichment Pipelines: A robust TI pipeline in Sentinel often uses Lookup Tables and Functions. For example, ingested TI (from GreyNoise or Team Cymru) can be stored in reference data or scheduled lookup tables to enrich incoming logs. Patterns include: - Normalization: Normalize diverse feeds into common STIX schema fields (e.g. all IPs to NetworkDestinationIP, all domains to DomainName) so rules can treat them uniformly.
- Confidence Scoring: Assign a confidence score to each indicator (from vendor or based on recency/frequency). For GreyNoise, for instance, you might use classification (e.g. “malicious” vs. “benign”) and history to score IP reputation. In Sentinel’s ThreatIntelligenceIndicator.ConfidenceScore field you can set values (higher for high-confidence IOCs, lower for noisy ones).
- TTL & Freshness: Some indicators (e.g. active C2 domains) expire, so setting a Time-To-Live is critical. Sentinel ingestion rules or parsers should use ExpirationDateTime or ValidUntil on indicators to avoid stale IOCs. For example, extend ValidUntil only if confidence is high.
- Conflict Resolution: When the same IOC comes from multiple sources (e.g. an IP in both GreyNoise and TeamCymru), you can either merge metadata or choose the highest confidence. One approach: use the highest threat severity from any source. Sentinel’s ThreatType tags (e.g. malicious-traffic) can accommodate multiple providers.

False-Positive Reduction Techniques:
- GreyNoise Noise Scoring: GreyNoise’s primary utility is filtering. If an IP is labeled noise=true (i.e. just scanning, not actively malicious), rules can deprioritize alerts involving that IP. E.g. suppress an alert if its source IP appears in GreyNoise as benign scanner.
- Team Cymru Reputation: Use Scout data to gauge risk; e.g. if an IP’s open port fingerprint or domain history shows no malicious tags, it may be low-risk. Conversely, known hostile IP (e.g. seen in ransomware networks) should raise alert level. Scout’s thousands of context tags help refine a binary IOC.
- Contextual Identity Signals: Leverage OneLogin/PingOne context to filter alerts. For instance, if a sign-in event is associated with a high-risk location (e.g. new country) and the IP is a GreyNoise scan, flag it. If an IP is marked benign, drop or suppress. Correlate login failures: if a single IP causes many failures across multiple users, it might be credential stuffing (T1110) – but if that IP is known benign scanner, consider it low priority.
- Thresholding & Suppression: Build analytic suppression rules. Example: only alert on >5 failed logins in 5 min from IP and that IP is not noise. Or ignore DNS queries to domains that TI flags as benign/whitelisted. Apply tag-based rules: some connectors allow tagging known internal assets or trusted scan ranges to avoid alerts.

Use GreyNoise to suppress alerts:

SecurityEvent
| where EventID == 4625 and Account != "SYSTEM"
| join kind=leftanti (
    ThreatIntelligenceIndicator
    | where IndicatorProvider == "GreyNoise" and Classification == "benign"
    | project NetworkSourceIP
) on $left.IPAddress == $right.NetworkSourceIP

This rule filters out Windows 4625 login failures originating from GreyNoise-known benign scanners.

Identity Attack Chains & Detection Rules

Modern account attacks often involve sequential activities. By combining identity logs with TI, we can detect advanced patterns. Below are common chains and rule ideas:

Credential Stuffing (MITRE T1110): Often seen as many login failures followed by a success. Detection: Look for multiple failed OneLogin/PingOne sign-ins for the same or different accounts from a single IP, then a success. Enrich with GreyNoise: if the source IP is in GreyNoise (indicating scanning), raise severity. Rule:

     let SuspiciousIP =
OneLoginEventsV2_CL
| where EventType == "UserSessionStart" and Result == "Failed"
| summarize CountFailed=count() by ClientIP_s
| where CountFailed > 5;
OneLoginEventsV2_CL
| where EventType == "UserSessionStart" and Result == "Success"
and ClientIP_s in (SuspiciousIP | project ClientIP_s)
| join kind=inner (
    ThreatIntelligenceIndicator
    | where ThreatType == "ip"
    | extend GreyNoiseClass = tostring(Classification)
    | project IP=NetworkSourceIP, GreyNoiseClass
) on $left.ClientIP_s == $right.IP
| where GreyNoiseClass == "malicious"
| project TimeGenerated, Account_s, ClientIP_s, GreyNoiseClass

Tactics: Initial Access (T1110) – Severity: High.

Account Takeover / Impossible Travel (T1198): Sign-ins from unusual geographies or devices. Detection: Compare user’s current sign-in location against historical baseline. Use OneLogin/PingOne logs: if two logins by same user occur in different countries with insufficient time to travel, trigger. Enrich: if the login IP is also known infrastructure (Team Cymru PDNS, etc.), raise alert. Rule:

     PingOne_AuditActivitiesV2_CL
| where EventType_s == "UserLogin"
| extend loc = tostring(City_s) + ", " + tostring(Country_s)
| sort by TimeGenerated desc
| partition by User_s
    (
      where TimeGenerated < ago(24h) // check last day
      | summarize count(), min(TimeGenerated), max(TimeGenerated)
    )
| where max_TimeGenerated - min_TimeGenerated < 1h and count_>1 and (range(loc) contains ",")
| project User_s, TimeGenerated, loc

(This pseudo-query checks multiple locations in <1 hour.) Tactics: Reconnaissance / Initial Access – Severity: Medium.

Lateral Movement (T1021): Use of an account on multiple systems/apps. Detection: Two or more distinct application/service authentications by same user within a short time. Use OneLogin app-id fields or audit logs for access. If these are followed by suspicious network activity (e.g. contacting C2 via GreyNoise), escalate. Tactics: Lateral Movement – Severity: High.
Privilege Escalation (T1098): If an admin account is changed or MFA factors reset in OneLogin/PingOne, especially after anomalous login. Detection: Monitor OneLogin admin events (“User updated”, “MFA enrolled/removed”). Cross-check the actor’s IP against threat feeds. Tactics: Credential Access – Severity: High.

Analytics Rules (KQL)

Below are six illustrative Sentinel analytics rules combining TI and identity logs. Each rule shows logic, tactics, severity, and MITRE IDs. (Adjust field names per your schemas and normalize CL tables as needed.)

Multiple Failed Logins from Malicious Scanner (T1110) – High severity. Detect credential stuffing by identifying >5 failed login attempts from the same IP, where that IP is classified as malicious by GreyNoise.

let BadIP =
OneLoginEventsV2_CL
| where EventType == "UserSessionStart" and Result == "Failed"
| summarize attempts=count() by SourceIP_s
| where attempts >= 5;
OneLoginEventsV2_CL
| where EventType == "UserSessionStart" and Result == "Success"
and SourceIP_s in (BadIP | project SourceIP_s)
| join (
    ThreatIntelligenceIndicator
    | where IndicatorProvider == "GreyNoise" and ThreatSeverity >= 4
    | project MaliciousIP=NetworkDestinationIP
) on $left.SourceIP_s == $right.MaliciousIP
| extend AttackFlow="CredentialStuffing", MITRE="T1110"
| project TimeGenerated, UserName_s, SourceIP_s, MaliciousIP

Logic: Correlate failed-then-success login from same IP plus GreyNoise-malign classification.

Impossible Travel / Anomalous Geo (T1198) – Medium severity. A user signs in from two distant locations within an hour.

// Get last two logins per user
let lastLogins =
PingOne_AuditActivitiesV2_CL
| where EventType_s == "UserLogin" and Outcome_s == "Success"
| sort by TimeGenerated desc
| summarize first_place=arg_max(TimeGenerated, City_s, Country_s, SourceIP_s, TimeGenerated) by User_s;
let prevLogins =
PingOne_AuditActivitiesV2_CL
| where EventType_s == "UserLogin" and Outcome_s == "Success"
| sort by TimeGenerated desc
| summarize last_place=arg_min(TimeGenerated, City_s, Country_s, SourceIP_s, TimeGenerated) by User_s;
lastLogins
| join kind=inner prevLogins on User_s
| extend
dist=geo_distance_2points(first_place_City_s, first_place_Country_s, last_place_City_s, last_place_Country_s)
| where dist > 1000 and (first_place_TimeGenerated - last_place_TimeGenerated) < 1h
| project Time=first_place_TimeGenerated, User=User_s, From=last_place_Country_s, To=first_place_Country_s, MITRE="T1198"

Logic: Compute geographic distance between last two logins; flag if too far too fast.

Suspicious Admin Change (T1098) – High severity. Detect a change to admin settings (like role assign or MFA reset) via PingOne, from a high-risk IP (Team Cymru or GreyNoise) or after failed logins.

     PingOne_AuditActivitiesV2_CL
| where EventType_s in ("UserMFAReset", "UserRoleChange") // example admin events
| extend ActorIP = tostring(InitiatingIP_s)
| join (
    ThreatIntelligenceIndicator
    | where ThreatSeverity >= 3
    | project BadIP=NetworkDestinationIP
) on $left.ActorIP == $right.BadIP
| extend MITRE="T1098"
| project TimeGenerated, ActorUser_s, Action=EventType_s, ActorIP

Logic: Raise if an admin action originates from known bad IP.

Malicious Domain Access (T1498): Medium severity. Internal logs (e.g. DNS or Web proxy) show access to a domain listed by Team Cymru Scout as C2 or reconnaissance.

Logic: Correlate internal DNS queries with Scout’s flagged C2 domains. (Requires that domain data is ingested or synced.)

Brute-Force Firewall Blocked IP (T1110): Low to Medium severity. Firewall logs show an IP blocked for many attempts, and that IP is not noise per GreyNoise (i.e., malicious scanner).

AzureDiagnostics
| where Category == "NetworkSecurityGroupFlowEvent" and msg_s contains "DIRECTION=Inbound" and Action_s == "Deny"
| summarize attemptCount=count() by IP = SourceIp_s, FlowTime=bin(TimeGenerated, 1h)
| where attemptCount > 50
| join kind=leftanti (
    ThreatIntelligenceIndicator
    | where IndicatorProvider == "GreyNoise" and Classification == "benign"
    | project NoiseIP=NetworkDestinationIP
) on $left.IP == $right.NoiseIP
| extend MITRE="T1110"
| project IP, attemptCount, FlowTime

Logic: Many inbound denies (possible brute force) from an IP not whitelisted by GreyNoise.

New Device Enrolled (T1078): Low severity. A user enrolls a new device or location for MFA after unusual login.

OneLoginEventsV2_CL
| where EventType == "NewDeviceEnrollment"
| join kind=inner (
    OneLoginEventsV2_CL
    | where EventType == "UserSessionStart" and Result == "Success"
    | top 1 by TimeGenerated asc // assume prior login
    | project User_s, loginTime=TimeGenerated, loginIP=ClientIP_s
) on User_s
| where loginIP != DeviceIP_s
| extend MITRE="T1078"
| project TimeGenerated, User_s, DeviceIP_s, loginIP

Logic: Flag if new device added (strong evidence of account compromise).

Note: The above rules are illustrative. Tune threshold values (e.g. attempt counts) to your environment. Map the event fields (EventType, Result, etc.) to your actual schema. Use Severity mapping in rule configs as indicated and tag with MITRE IDs for context.

TI-Driven Playbooks and Automation

Automated response can amplify TI. Patterns include:
- IOC Blocking: On alert (e.g. suspicious IP login), an automation runbook can call Azure Firewall, Azure Defender, or external firewall APIs to block the offending IP. For instance, a Logic App could trigger on the analytic alert, use the TI feed IP, and call AzFWNetworkRule PowerShell to add a deny rule.
- Enrichment Workflow: After an alert triggers, an Azure Logic App playbook can enrich the incident by querying TI APIs. E.g., given an IP from the alert, call GreyNoise API or Team Cymru Scout API in real-time (via HTTP action), add the classification into incident details, and tag the incident accordingly (e.g. GreyNoiseStatus: malicious). This adds context for the analyst.
- Alert Suppression: Implement playbook-driven suppression. For example, an alert triggered by an external IP can invoke a playbook that checks GreyNoise; if the IP is benign, the playbook can auto-close the alert or mark as false-positive, reducing analyst load.
- Automated TI Feed Updates: Periodically fetch open-source or commercial TI and use a playbook to push new indicators into Sentinel’s TI store via the Graph API.
- Incident Enrichment: On incident creation, a playbook could query OneLogin/PingOne for additional user details (like department or location via their APIs) and add as note in the incident.

Performance, Scalability & Costs

TI feeds and identity logs can be high-volume. Key considerations:
- Data Ingestion Costs: Every log and TI indicator ingested into Sentinel is billable by the GB. Bulk TI indicator ingestion (like GreyNoise pulling thousands of IPs/day) can add storage costs. Use Sentinel’s Data Collection Rules (DCR) to apply ingestion-time filters (e.g. only store indicators above a confidence threshold) to reduce volume. GreyNoise feed is typically modest (since it’s daily, maybe thousands of IPs). Identity logs (OneLogin/PingOne) depend on org size – could be megabytes per day. Use sentinel ingestion sl analytic filters to drop low-value logs.
- Query Performance: Custom log tables (OneLogin, PingOne, KeeperLogs_CL) can grow large. Periodically archive old data (e.g. export >90 days to storage, then purge). Use materialized views or scheduled summary tables for heavy queries (e.g. pre-aggregate hourly login counts). For threat indicator tables, leverage built-in indices on IndicatorId and NetworkIP for fast joins. Use project-away _* to remove metadata from large join queries.
- Retention & Storage: Configure retention per table. If historical TI is less needed, set shorter retention. Use Azure Monitor’s tiering/Archive for seldom-used data. For large TI volumes (e.g. feeding multiple TIPs), consider using Sentinel Data Lake (or connecting Log Analytics to ADLS Gen2) to offload raw ingest cheaply.
- Scale-Out Architecture: For very large environments, use multiple Sentinel workspaces (e.g. regional) and aggregate logs via Azure Lighthouse or Sentinel Fusion. TI feeds can be shared: one workspace collects TI, then distribute to others via Azure Sentinel’s TI management (feeds can be published and shared cross-workspaces).
- Connector Limits: API rate limits dictate update frequency. Schedule connectors accordingly (e.g. daily for TI, hourly for identity events). Avoid hourly pulls of already static data (users list can be daily). For OneLogin/PingOne, use incremental tokens or webhooks if possible to reduce load.
- Monitoring Health: Use Sentinel’s Log Analytics and Monitor metrics to track ingestion volume and connector errors. For example, monitor the Functions running GreyNoise/Scout for failures or throttling.

Deployment Checklist & Guide

Prepare Sentinel Workspace: Ensure a Log Analytics workspace with Sentinel enabled. Record the workspace ID and region.
Register Applications: In Azure AD, create and note any Service Principal needed for functions or connectors (e.g. a Sentinel-managed identity for Functions). In each vendor portal, register API apps and credentials (OneLogin OIDC App, PingOne API client, Keeper AD app).
Network & Security: If needed, configure firewall rules to allow outbound to vendor APIs.
Install Connectors: In Sentinel Content Hub or Marketplace, install the solutions for GreyNoise TI, Team Cymru Scout, OneLogin IAM, PingOne. Follow each wizard to input credentials. Verify the “Data Types” (Logs, Alerts, etc.) are enabled.
Create Tables & Parsers (if manual): For Keeper or unsupported logs, manually create custom tables (via DCR in Azure portal). Import JSON to define fields as shown in Keeper’s docs
Test Data Flow: After each setup, wait 1–24 hours and run a simple query on the destination table (e.g. OneLoginEventsV2_CL | take 5) to confirm ingestion.
Deploy Ingestion Rules: Use Sentinel Threat intelligence ingestion rules to fine-tune feeds (e.g. mark high-confidence feeds to extend expiration). Optionally tag/whitelist known good.
Configure Analytics: Enable or create rules using the KQL above. Place them in the correct threat hunting or incident rule categories (Credential Access, Lateral Movement, etc.). Assign appropriate alert severity.
Set up Playbooks: For automated actions (alert enrichment, IOC blocking), create Logic App playbooks. Test with mock alerts (dry run) to ensure correct API calls.
Tuning & Baseline: After initial alerts, tune queries (thresholds, whitelists) to reduce noise. Maintain suppression lists (e.g. internal pentest IPs). Use the MITRE mapping in rule details for clarity.
Documentation & Training: Document field mappings (e.g. OneLoginEvents fields), and train SOC staff on new TI-enriched alert fields.

Connectors Comparison

Connector	Data Sources	Sent. Tables	Update Freq.	Auth Method	Key Fields Enriched	Limits/Cost	Pros/Cons
GreyNoise	IP intelligence (scanners)	ThreatIntelligenceIndicator	Daily (scheduled pull)	API Key	IP classification, noise, classification	API key required; paid license for large usage	Pros: Filters benign scans, broad scan visibility Con: Only IP-based (no domain/file).
Team Cymru Scout	Global IP/domain telemetry	Cymru_Scout_*_CL (custom tables)	On-demand or daily	Account credentials	Detailed IP/domain context (ports, PDNS, ASN, etc.)	Requires Team Cymru subscription. Potentially high cost for feed.	Pros: Rich context (open ports, DNS, certs); great for IOC enrichment. Con: Complex setup, data in custom tables only.
OneLogin IAM	OneLogin user/auth logs	OneLoginEventsV2_CL, OneLoginUsersV2_CL	Polls hourly	OAuth2 (client ID/secret)	User, app, IP, event type (login, MFA, etc.)	OneLogin API: 5K calls/hour. Data volume moderate.	Pros: Direct insight into cloud identity use; built-in parser available. Cons: Limited to OneLogin environment only.
PingOne Audit	PingOne audit logs	PingOne_AuditActivitiesV2_CL	Polls hourly	OAuth2 (client ID/secret)	User actions, admin events, MFA logs	Rate limited by Ping license. Data volume moderate.	Pros: Captures critical identity events; widely used product. Cons: Requires PingOne Advanced license for audit logs.
Keeper (custom)	Keeper security events	KeeperLogs_CL (custom)	Push (continuous)	OAuth2 (client ID/secret) + Azure DCR	Vault logins, record accesses, admin changes	None (push model); storage costs.	Pros: Visibility into password vault activity (often blind spot). Cons: More manual setup; custom logs not parsed by default.

Data Flow Diagram

This flowchart shows GreyNoise (GN) feeding the Threat Intelligence table, Team Cymru feeding enrichment tables, and identity sources pushing logs. All data converges into Sentinel, where enrichment lookups inform analytics and automated responses.

SAP & Business-Critical App Security Connectors

klianos — Thu, 12 Feb 2026 13:58:11 GMT

I validated what it takes to make SAP and SAP-adjacent security signals operational in a SOC: reliable ingestion, stable schemas, and detections that survive latency and schema drift. I focus on four integrations into Microsoft Sentinel: SAP Enterprise Threat Detection (ETD) cloud edition (SAPETDAlerts_CL, SAPETDInvestigations_CL), SAP S/4HANA Cloud Public Edition agentless audit ingestion (ABAPAuditLog), Onapsis Defend (Onapsis_Defend_CL), and SecurityBridge (also ABAPAuditLog).
Because vendor API specifics for ETD Retrieval API / Audit Retrieval API aren’t publicly detailed in the accessible primary sources I could retrieve, I explicitly label pagination/rate/time-window behaviors as unspecified where appropriate.

Connector architectures and deployment patterns

For SAP-centric telemetry I separate two planes:

First is SAP application telemetry that lands in SAP-native tables, especially ABAPAuditLog, ABAPChangeDocsLog, ABAPUserDetails, and ABAPAuthorizationDetails. These tables are the foundation for ABAP-layer monitoring and are documented with typed columns in Azure Monitor Logs reference.

Second is external “security product” telemetry (ETD alerts, Onapsis findings). These land in custom tables (*_CL) and typically require a SOC-owned normalization layer to avoid brittle detections.

Within Microsoft’s SAP solution itself, there are two deployment models: agentless and containerized connector agent. The agentless connector uses SAP Cloud Connector and SAP Integration Suite to pull logs, and Microsoft documents it as the recommended approach; the containerized agent is being deprecated and disabled on September 14, 2026.

On the “implementation technology” axis, Sentinel integrations generally show up as: - Codeless Connector Framework (CCF) pollers/pushers (SaaS-managed ingestion definitions with DCR support).
- Function/Logic App custom pipelines using the Logs Ingestion API when you need custom polling, enrichment, or a vendor endpoint that isn’t modeled in CCF.

In my view, ETD and S/4HANA Cloud connectors are “agentless” from the Sentinel side (API credentials only), while Onapsis Defend and SecurityBridge connectors behave like push pipelines because Microsoft requires an Entra app + DCR permissions (typical Logs Ingestion API pattern).

Authentication and secrets handling

Microsoft documents the required credentials per connector: - ETD cloud connector requires Client Id + Client Secret for ETD Retrieval API (token mechanics unspecified).
- S/4HANA Cloud Public Edition connector requires Client Id + Client Secret for Audit Retrieval API (token mechanics unspecified), and Microsoft notes “alternative authentication mechanisms” exist (details in linked repo are unspecified in accessible sources).
- Onapsis Defend and SecurityBridge connectors require a Microsoft Entra ID app registration and Azure permission to assign Monitoring Metrics Publisher on DCRs. This maps directly to the Logs Ingestion API guidance, where a service principal is granted DCR access via that role (or the Microsoft.Insights/Telemetry/Write data action).

For production, I treat these as “SOC platform secrets”: - Store client secrets/certificates in Key Vault when you own the pipeline (Function/Logic App); rotate on an operational schedule; alert on auth failures and sudden ingestion drops.
- For vendor-managed ingestion (Onapsis/SecurityBridge), I still require: documented ownership of the Entra app, explicit RBAC scope for the DCR, and change control for credential rotation because a rotated secret is effectively a data outage.

API behaviors and ingestion reliability

For ETD Retrieval API and Audit Retrieval API, pagination/rate limits/time windows are unspecified in the accessible vendor documentation I could retrieve. I therefore design ingestion and detections assuming non-ideal API behavior: late-arriving events, cursor/page limitations, and throttling.

CCF’s RestApiPoller model supports explicit retry policy, windowing, and multiple paging strategies, so if/when you can obtain vendor API semantics, you can encode them declaratively (rather than writing fragile code).

For the SAP solution’s telemetry plane, Microsoft provides strong operational cues: agentless collection flows through Integration Suite, and troubleshooting typically happens in the Integration Suite message log; this is where I validate delivery failures before debugging Sentinel-side parsers.

For scheduled detections, I always account for ingestion delay explicitly. Microsoft’s guidance is to widen event lookback by expected delay and then constrain on ingestion_time() to prevent duplicates from overlap.

Schema, DCR transformations, and normalization layer

Connector attribute comparison

Connector	Auth method	Sentinel tables	Default polling	Backfill	Pagination	Rate limits
SAP ETD (cloud)	Client ID + Secret (ETD Retrieval API)	SAPETDAlerts_CL, SAPETDInvestigations_CL	unspecified	unspecified	unspecified	unspecified
SAP S/4HANA Cloud (agentless)	Client ID + Secret (Audit Retrieval API); alt auth referenced	ABAPAuditLog	unspecified	unspecified	unspecified	unspecified
Onapsis Defend	Entra app + DCR permission (Monitoring Metrics Publisher)	Onapsis_Defend_CL	n/a (push pattern)	unspecified	n/a	unspecified
SecurityBridge	Entra app + DCR permission (Monitoring Metrics Publisher)	ABAPAuditLog	n/a (push pattern)	unspecified	n/a	unspecified

Ingestion-time DCR transformations

Sentinel supports ingestion-time transformations through DCRs to filter, enrich, and mask data before it’s stored.

Example: I remove low-signal audit noise and mask email identifiers in ABAPAuditLog:

source
| where isnotempty(TransactionCode) and isnotempty(User)
| where TransactionCode !in ("SM21","ST22") // example noise; tune per tenant
| extend Email = iif(Email has "@", strcat(substring(Email,0,2),"***@", tostring(split(Email,"@")[1])), Email)

Normalization functions

Microsoft explicitly recommends using SAP solution functions instead of raw tables because they can change the infrastructure beneath without breaking detections. I follow the same pattern for ETD/Onapsis custom tables: I publish SOC-owned functions as a schema contract.

.create-or-alter function with (folder="SOC/SAP") Normalize_ABAPAudit() {
ABAPAuditLog
| project TimeGenerated, SystemId, ClientId, User, TransactionCode, TerminalIpV6, MessageId, MessageClass, MessageText, AlertSeverityText, UpdatedOn
}

.create-or-alter function with (folder="SOC/SAP") Normalize_ETDAlerts() {
SAPETDAlerts_CL
| extend
      AlertId = tostring(coalesce(column_ifexists("AlertId",""), column_ifexists("id",""))),
      Severity = tostring(coalesce(column_ifexists("Severity",""), column_ifexists("severity",""))),
      SapUser = tostring(coalesce(column_ifexists("SAP_User",""), column_ifexists("User",""), column_ifexists("user","")))
| project TimeGenerated, AlertId, Severity, SapUser, *
}

.create-or-alter function with (folder="SOC/SAP") Normalize_Onapsis() {
Onapsis_Defend_CL
| extend
      FindingId = tostring(coalesce(column_ifexists("FindingId",""), column_ifexists("id",""))),
      Severity = tostring(coalesce(column_ifexists("Severity",""), column_ifexists("severity",""))),
      SapUser   = tostring(coalesce(column_ifexists("SAP_User",""), column_ifexists("user","")))
| project TimeGenerated, FindingId, Severity, SapUser, *
}

Health/lag monitoring and anti-gap

I monitor both connector health and ingestion delay. SentinelHealth is the native health table, and Microsoft provides a health workbook and a schema reference for the fields.

let lookback=24h;
union isfuzzy=true
(ABAPAuditLog | extend T="ABAPAuditLog"),
(SAPETDAlerts_CL | extend T="SAPETDAlerts_CL"),
(Onapsis_Defend_CL | extend T="Onapsis_Defend_CL")
| where TimeGenerated > ago(lookback)
| summarize LastEvent=max(TimeGenerated),
P95DelaySec=percentile(datetime_diff("second", ingestion_time(), TimeGenerated), 95),
Events=count()
by T

Anti-gap scheduled-rule frame (Microsoft pattern):

let ingestion_delay=10m;
let rule_lookback=5m;
ABAPAuditLog
| where TimeGenerated >= ago(ingestion_delay + rule_lookback)
| where ingestion_time() > ago(rule_lookback)

SOC detections for ABAP privilege abuse, fraud/insider behavior, and audit readiness

Privileged ABAP transaction monitoring

ABAPAuditLog includes TransactionCode, User, SystemId, and terminal/IP fields, so I start with a curated high-risk tcode set and then add baselines.

let PrivTCodes=dynamic(["SU01","PFCG","SM59","RZ10","SM49","SE37","SE16","SE16N"]);
Normalize_ABAPAudit()
| where TransactionCode in (PrivTCodes)
| summarize Actions=count(), Ips=make_set(TerminalIpV6,5) by SystemId, User, TransactionCode, bin(TimeGenerated, 1h)
| where Actions >= 3

Fraud/insider scenario: sensitive object change near privileged audit activity

ABAPChangeDocsLog exposes ObjectClass, ObjectId, and change types; I correlate sensitive object changes to privileged transactions in a tight window.

let w=10m;
let Sensitive=dynamic(["BELEG","BPAR","PFCG","IDENTITY"]);
ABAPChangeDocsLog
| where ObjectClass in (Sensitive)
| project ChangeTime=TimeGenerated, SystemId, User=tostring(column_ifexists("User","")), ObjectClass, ObjectId, TypeOfChange=tostring(column_ifexists("ItemTypeOfChange",""))
| join kind=innerunique (
Normalize_ABAPAudit()
| project AuditTime=TimeGenerated, SystemId, User, TransactionCode
) on SystemId, User
| where AuditTime between (ChangeTime-w .. ChangeTime+w)
| project ChangeTime, AuditTime, SystemId, User, ObjectClass, ObjectId, TransactionCode, TypeOfChange

Audit-ready pipeline: monitoring continuity and configuration touchpoints

I treat audit logging itself as a monitored control. A simple SOC-safe control is “volume drop” by system; it’s vendor-agnostic and catches pipeline breaks and deliberate suppression.

Normalize_ABAPAudit()
| summarize PerHour=count() by SystemId, bin(TimeGenerated, 1h)
| summarize Avg=avg(PerHour), Latest=arg_max(TimeGenerated, PerHour) by SystemId
| where Latest_PerHour < (Avg * 0.2)

Where Onapsis/ETD are present, I increase fidelity by requiring “privileged ABAP activity” plus an external SAP-security product finding (field mappings are tenant-specific; normalize first):

let win=1h;
Normalize_ABAPAudit()
| where TransactionCode in ("SU01","PFCG","SM59","SE16N")
| join kind=leftouter (Normalize_Onapsis()) on $left.User == $right.SapUser
| where isempty(FindingId) == false and TimeGenerated1 between (TimeGenerated .. TimeGenerated+win)
| project TimeGenerated, SystemId, User, TransactionCode, FindingId, OnapsisSeverity=Severity

Production validation, troubleshooting, and runbook

For acceptance, I validate in this order: table creation, freshness/lag percentiles, connector health state, and cross-check of event counts against the upstream system for the same UTC window (where available). Connector health monitoring is built around SentinelHealth plus the Data collection health workbook.

For SAP agentless ingestion, Microsoft states most troubleshooting happens in Integration Suite message logs—this is where I triage authentication/networking failures before tuning KQL.

For Onapsis/SecurityBridge-style ingestion, I validate Entra app auth, DCR permission assignment (Monitoring Metrics Publisher), and a minimal ingestion test payload using the Logs Ingestion API tutorial flow.

Operational runbook items I treat as non-optional: health alerts on connector failure and freshness drift; scheduled rule anti-gap logic; playbooks that capture evidence bundles (ABAPAuditLog slice + user context from ABAPUserDetails/ABAPAuthorizationDetails); DCR filters to reduce noise and cost; and change control for normalization functions and watchlists.

SOC “definition of done” checklist (short): 1) Tables present and steadily ingesting; 2) P95 ingestion delay measured and rules use the anti-gap pattern; 3) SentinelHealth enabled with alerts; 4) SOC-owned normalization functions deployed; 5) at least one privileged-tcode rule + one change-correlation rule + one audit-continuity rule in production.

Mermaid ingestion flow:

From signal to strategy: Closing attack paths with identity intelligence

Tal_Guetta — Mon, 09 Feb 2026 15:54:38 GMT

Compromised credentials remain one of the most common entry points for attackers. In the first half of 2025 alone, identity-based attacks surged more than 32% and its estimated that 97% of them are password focused. While that scale is overwhelming, it only takes a single exposed account to give an attacker a foothold from which they can move laterally towards the critical assets they are after. At today’s attack scale, identity signals need to be connected with broader context to stop attacks earlier in the kill chain.

Today we are excited to share more about how Microsoft Defender can help security professionals proactively understand how identity-related risks, like leaked credentials, relate back to critical assets, helping security professionals proactively close potential entry points before they can be exploited.

Understanding leaked credentials and attack paths:

Leaked credentials refer to valid usernames and passwords that have been exposed beyond their intended scope. Whether this exposure occurs as part of a data breach, phishing attack, or postings on dark web forums, the result is the same: an attacker may be using legitimate credentials to access your organization.

Similarly, attack paths describe the sequence of misconfigurations, permissions, and trust relationships that an attacker can chain together to move from an initial foothold to high‑value resources. Rather than relying on a single vulnerability, attackers tend to think in graphs, following paths of least resistance to systematically escalate privileges and expand access. This makes identities the primary control plane they target and leaked credentials as an extremely common entry point. The recent Microsoft digital defense report put this into focus, stating that more than 61% of attack paths lead to a sensitive user. These user accounts have elevated privileges or access to critical resources meaning that if they were to be attacked or misused it would significantly impact the organization.

Microsoft’s differentiated approach

Most solutions stop at the alert and can only tell you that a password was exposed, found, or leaked. That information matters, but it is incomplete, it describes an event, not the risk.

The real differentiation starts with the next question: what does this exposure mean for my environment right now. Not every exposed password creates the same level of risk. Context is what determines impact. Which identity does the password belong to? What assets can that identity access? Does that access still exists? And are those assets truly sensitive?

That is why exposed password detection is a starting point, not an end state. Effective protection begins when organizations move beyond technical alerts and toward an identity-aware understanding. This shift from detection to context is where better decisions are made and where meaningful security value is created. This is why we took our identity alerts a step further, connecting these risks with broader security context to reveal how an initial identity signal can lead to sensitive users, critical assets, and core business operations.

This perspective moves security beyond isolated alerts to prioritized, actionable insight that shows not just if risk exists, but how identity‑based threats could unfold and where to intervene to stop them before they have impact.

In the case of leaked credentials, Microsoft continuously scans for exposed accounts across public and private breach sources. If a match is found, Microsoft’s Advanced Correlation Engine (MACE) automatically identifies the affected user within your organization and surfaces the exposure with clear severity and context. By bringing this powerful detection into Defender, teams can investigate and respond with better context, allowing leaked credentials to be evaluated alongside endpoint, email, and app activity, giving teams additional context needed to prioritize response. Additionally, for Microsoft Entra ID accounts we can go a step further validating whether the discovered credentials actually corresponds to a real, usable password for an identity in the tenant. This confirmation further reduces unnecessary noise and gives defenders an early signal - often before any malicious activity begins.

Next, Microsoft Defender steps in to correlate these signals with your organization’s unique security context. Connecting the alert and associated account with other signals and like unusual authentications, lateral movement attempts, or privilege escalations, elevating the isolated alert into a complete story about any potential incidents related to that vulnerability.

At the same time, Microsoft Exposure management is analyzing the same data to create a potential attack path related to the exposed credentials. By tracing permissions, consents, and access relationships, Attack Paths show exactly which routes an attacker could take and what controls will break that path.

When these capabilities work together, visibility becomes action. MACE identifies who is exposed, Defender connects other signals into an incident level view and Attack Paths reveal where the attacker could go next. The result is a single, connected workflow that transforms early exposure data into prioritized, measurable risk reduction.

Conclusion

Leaked credentials should be treated as the beginning of a story, not an isolated event. Microsoft Defender is uniquely able to enrich security teams visibility and understanding of Identity-related threats from initial exposure to detection, risk prioritization, and remediation. This connected visibility fundamentally changes how defenders manage identity risk, shifting the focus from reacting to individual alerts to continuously reducing exposure and limiting blast radius. One leaked password doesn’t have to become a breach. With Microsoft’s identity security capabilities, it becomes a closed path, and a measurable step toward greater resilience.

Learn more about attack paths and the new leaked credentials capabilities in Defender.