Feedback Edit

What's new in Microsoft Sentinel

  • Article
  • 10 minutes to read

This article lists recent features added for Microsoft Sentinel, and new features in related services that provide an enhanced user experience in Microsoft Sentinel.

The listed features were released in the last three months. For information about earlier features delivered, see our Tech Community blogs.

Note

For information about feature availability in US Government clouds, see the Microsoft Sentinel tables in Cloud feature availability for US Government customers.

December 2022

Customize more alert properties (Preview)

Alerts generated by a given analytics rule - and all incidents created as a result - inherit the name, description, severity, and tactics defined in the rule, without regard to the particular content of a specific instance of the alert.

You've already been able to use the alert details feature to override these four default properties of alerts; now there are nine more alert properties that can be customized to override their defaults.

See which ones, and learn how to use the updated mechanism, in Customize alert details in Microsoft Sentinel.

November 2022

Use Incident tasks to manage incident workflow (Preview)

SecOps analysts are expected to perform a list of steps, or tasks, in the process of triaging, investigating, or remediating an incident. Standardizing and formalizing the list of tasks can help keep your SOC running smoothly, ensuring the same requirements apply to all analysts.

SOC managers, automation engineers, and senior analysts can use Microsoft Sentinel's automation capabilities to generate lists of tasks that will apply across groups of incidents based on their content, ensuring that front-line analysts apply the same standards of care across the board and don't miss any critical steps.

Common Event Format (CEF) via AMA (Preview)

The Common Event Format (CEF) via AMA connector allows you to quickly filter and upload logs over CEF from multiple on-premises appliances to Microsoft Sentinel via the Azure Monitor Agent (AMA).

The AMA supports Data Collection Rules (DCRs), which you can use to filter the logs before ingestion, for quicker upload, efficient analysis, and querying.

Monitor the health of automation rules and playbooks

To ensure proper functioning and performance of your security orchestration, automation, and response operations in your Microsoft Sentinel service, keep track of the health of your automation rules and playbooks by monitoring their execution logs.

Set up notifications of health events for relevant stakeholders, who can then take action. For example, define and send email or Microsoft Teams messages, create new tickets in your ticketing system, and so on.

Updated Microsoft Sentinel Logstash plugin

A new version of the Microsoft Sentinel Logstash plugin leverages the new Azure Monitor Data Collection Rules (DCR) based Logs Ingestion API. The new plugin:

  • Provides data transformation capabilities like filtering, masking, and enrichment.
  • Allows full control over the output schema, including configuration of the column names and types.
  • Can forward logs from external data sources into both custom tables and standard tables.
  • Provides performance improvements, compression, and better telemetry and error handling.

October 2022

Account enrichment fields removed from Azure AD Identity Protection connector

As of September 30, 2022, alerts coming from the Azure Active Directory Identity Protection connector no longer contain the following fields:

  • CompromisedEntity
  • ExtendedProperties["User Account"]
  • ExtendedProperties["User Name”]

We are working to adapt Microsoft Sentinel's built-in queries and other operations affected by this change to look up these values in other ways (using the IdentityInfo table).

In the meantime, or if you've built any custom queries or rules directly referencing these fields, you'll need another way to get this information. Use the following two-step process to have your queries look up these values in the IdentityInfo table:

  1. If you haven't already, enable the UEBA solution to sync the IdentityInfo table with your Azure AD logs. Follow the instructions in this document.
    (If you don't intend to use UEBA in general, you can ignore the last instruction about selecting data sources on which to enable entity behavior analytics.)

  2. Incorporate the query below in your existing queries or rules to look up this data by joining the SecurityAlert table with the IdentityInfo table.

    SecurityAlert
| where TimeGenerated > ago(7d)
| where ProductName == "Azure Active Directory Identity Protection"
| mv-expand Entity = todynamic(Entities)
| where Entity.Type == "account"
| extend AadTenantId = tostring(Entity.AadTenantId)
| extend AadUserId = tostring(Entity.AadUserId)
| join kind=inner (
    IdentityInfo
    | where TimeGenerated > ago(14d)
    | distinct AccountTenantId, AccountObjectId, AccountUPN, AccountDisplayName
    | extend UserAccount = AccountUPN
    | extend UserName = AccountDisplayName
    | where isnotempty(AccountDisplayName) and isnotempty(UserAccount)
    | project AccountTenantId, AccountObjectId, UserAccount, UserName
    )
    on
    $left.AadTenantId == $right.AccountTenantId,
    $left.AadUserId == $right.AccountObjectId
| extend CompromisedEntity = iff(CompromisedEntity == "N/A" or isempty(CompromisedEntity), UserAccount, CompromisedEntity)
| project-away AadTenantId, AadUserId, AccountTenantId, AccountObjectId

For information on looking up data to replace enrichment fields removed from the UEBA UserPeerAnalytics table, See Heads up: Name fields being removed from UEBA UserPeerAnalytics table for a sample query.

Microsoft 365 Defender now integrates Azure Active Directory Identity Protection (AADIP)

As of October 24, 2022, Microsoft 365 Defender will be integrating Azure Active Directory Identity Protection (AADIP) alerts and incidents. Customers can choose between three levels of integration:

  • Show high-impact alerts only (Default) includes only alerts about known malicious or highly suspicious activities that might require attention. These alerts are chosen by Microsoft security researchers and are mostly of Medium and High severities.
  • Show all alerts includes all AADIP alerts, including activity that might not be unwanted or malicious.
  • Turn off all alerts disables any AADIP alerts from appearing in your Microsoft 365 Defender incidents.

Microsoft Sentinel customers (who are also AADIP subscribers) with Microsoft 365 Defender integration enabled will automatically start receiving AADIP alerts and incidents in their Microsoft Sentinel incidents queue. Depending on your configuration, this may affect you as follows:

  • If you already have your AADIP connector enabled in Microsoft Sentinel, and you've enabled incident creation, you may receive duplicate incidents. To avoid this, you have a few choices, listed here in descending order of preference:

    Preference Action in Microsoft 365 Defender Action in Microsoft Sentinel
    1 Keep the default AADIP integration of Show high-impact alerts only. Disable any Microsoft Security analytics rules that create incidents from AADIP alerts.
    2 Choose the Show all alerts AADIP integration. Create automation rules to automatically close incidents with unwanted alerts.

    Disable any Microsoft Security analytics rules that create incidents from AADIP alerts.
    3 Don't use Microsoft 365 Defender for AADIP alerts:
    Choose the Turn off all alerts option for AADIP integration.    		 Leave enabled those Microsoft Security analytics rules that create incidents from AADIP alerts.

  • If you don't have your AADIP connector enabled, you must enable it. Be sure not to enable incident creation on the connector page. If you don't enable the connector, you may receive AADIP incidents without any data in them.

  • If you're first enabling your Microsoft 365 Defender connector now, the AADIP connection will be made automatically behind the scenes. You won't need to do anything else.

Out of the box anomaly detection on the SAP audit log (Preview)

The Microsoft Sentinel for SAP solution now includes the SAP - Dynamic Anomaly Detection analytics rule, adding an out of the box capability to identify suspicious anomalies across the SAP audit log events.

Learn how to use the new rule for anomaly detection.

IoT device entity page (Preview)

The new IoT device entity page is designed to help the SOC investigate incidents that involve IoT/OT devices in their environment, by providing the full OT/IoT context through Microsoft Defender for IoT to Sentinel. This enables SOC teams to detect and respond more quickly across all domains to the entire attack timeline.

Learn more about investigating IoT device entities in Microsoft Sentinel.

September 2022

Create automation rule conditions based on custom details (Preview)

You can set the value of a custom detail surfaced in an incident as a condition of an automation rule. Recall that custom details are data points in raw event log records that can be surfaced and displayed in alerts and the incidents generated from them. Through custom details you can get to the actual relevant content in your alerts without having to dig through query results.

Learn how to add a condition based on a custom detail.

Add advanced "Or" conditions to automation rules (Preview)

You can now add OR conditions to automation rules. Also known as condition groups, these allow you to combine several rules with identical actions into a single rule, greatly increasing your SOC's efficiency.

For more information, see Add advanced conditions to Microsoft Sentinel automation rules.

Heads up: Name fields being removed from UEBA UserPeerAnalytics table

As of September 30, 2022, the UEBA engine will no longer perform automatic lookups of user IDs and resolve them into names. This change will result in the removal of four name fields from the UserPeerAnalytics table:

  • UserName
  • UserPrincipalName
  • PeerUserName
  • PeerUserPrincipalName

The corresponding ID fields remain part of the table, and any built-in queries and other operations will execute the appropriate name lookups in other ways (using the IdentityInfo table), so you shouldn’t be affected by this change in nearly all circumstances.

The only exception to this is if you’ve built custom queries or rules directly referencing any of these name fields. In this scenario, you can incorporate the following lookup queries into your own, so you can access the values that would have been in these name fields.

The following query resolves user and peer identifier fields:

UserPeerAnalytics 
| where TimeGenerated > ago(24h) 
// join to resolve user identifier fields 
| join kind=inner ( 
    IdentityInfo  
    | where TimeGenerated > ago(14d) 
    | distinct AccountTenantId, AccountObjectId, AccountUPN, AccountDisplayName 
    | extend UserPrincipalNameIdentityInfo = AccountUPN 
    | extend UserNameIdentityInfo = AccountDisplayName 
    | project AccountTenantId, AccountObjectId, UserPrincipalNameIdentityInfo, UserNameIdentityInfo 
) on $left.AADTenantId == $right.AccountTenantId, $left.UserId == $right.AccountObjectId 
// join to resolve peer identifier fields 
| join kind=inner ( 
    IdentityInfo  
    | where TimeGenerated > ago(14d) 
    | distinct AccountTenantId, AccountObjectId, AccountUPN, AccountDisplayName 
    | extend PeerUserPrincipalNameIdentityInfo = AccountUPN 
    | extend PeerUserNameIdentityInfo = AccountDisplayName 
    | project AccountTenantId, AccountObjectId, PeerUserPrincipalNameIdentityInfo, PeerUserNameIdentityInfo 
) on $left.AADTenantId == $right.AccountTenantId, $left.PeerUserId == $right.AccountObjectId

If your original query referenced the user or peer names (not just their IDs), substitute this query in its entirety for the table name (“UserPeerAnalytics”) in your original query.

Windows DNS Events via AMA connector (Preview)

You can now use the new Windows DNS Events via AMA connector to stream and filter events from your Windows Domain Name System (DNS) server logs to the ASimDnsActivityLog normalized schema table. You can then dive into your data to protect your DNS servers from threats and attacks.

Create and delete incidents manually (Preview)

Microsoft Sentinel incidents have two main sources:

  • They are generated automatically by detection mechanisms that operate on the logs and alerts that Sentinel ingests from its connected data sources.

  • They are ingested directly from other connected Microsoft security services (such as Microsoft 365 Defender) that created them.

There can, however, be data from sources not ingested into Microsoft Sentinel, or events not recorded in any log, that justify launching an investigation. For this reason, Microsoft Sentinel now allows security analysts to manually create incidents from scratch for any type of event, regardless of its source or associated data, in order to manage and document the investigation.

Since this capability raises the possibility that you'll create an incident in error, Microsoft Sentinel also allows you to delete incidents right from the portal as well.

Add entities to threat intelligence (Preview)

Microsoft Sentinel now allows you to flag entities as malicious, right from within the investigation graph. You'll then be able to view this indicator both in Logs and in the Threat Intelligence blade in Sentinel.

Learn how to add an entity to your threat intelligence.

Next steps

On-board Azure Sentinel

Get visibility into alerts