Extending entity mapping in Microsoft Sentinel, Mapping User Accounts and IP Addresses

Leestijd: 4 minuten

As more SIEM/SOAR activities center around identity and entities within a company’s infrastructure, enriching alerts and incidents within the SIEM with the right entity mapping has become critical for SOC analysts to do their work properly. Benefits of having the right entity mapping within Microsoft Sentinel Analytics Rules include a reduction in alert fatigue among SOC staff and more possibilities for automation which centers around entities which are involved in the alerts/incidents (my following blog post series will concern this topic).

The introduction of the Microsoft Sentinel Content Hub has made it significantly simpler to deploy quality content such as analytics rules, playbooks and hunting queries. However, some of the analytics rules deployed from the content hub might not provide the exact entity mapping which is desired for your Sentinel deployment and SOC operations. Additionally, you might want to extend the entity mapping of your selfmade analytics rules. I will provide three different entity mapping scenarios in increasing order of complexity. Let’s start off this blog series with a simple example for the entity mapping of a user account which is involved in an incident.

We have received the following NRT MFA Rejected by User incident in our Sentinel instance:

As you can see, there is no entity related to the incident. This prevents us from using the investigation graph which can be clicked in the left bottom of the incident page in case there is an entity related to the incident. Let’s look into the log analytics which actually triggered this incident. First click on the alert in the incident timeline, then click on “Link to LA” as shown below.

This takes us to the following overview where we retrieve the related entity. The fields which can be used for entity mapping of an account are highlighted in red. Please note that in order to create and populate some of these fields, you will have to write the KQL yourself. Doing so is most often done by using the KQL extend operator for creating a new log attribute, after which the project operator can be used to show the attribute and allow the entity mapping to retrieve it from the logs. If you want to read the official documentation on Sentinel account entity mapping, you can do so here: Microsoft Sentinel entity types reference | Microsoft Learn

We can now change the analytics rule which triggered the incident. You can edit the analytics rule by clicking the rule in the incident overview.

Next, in the Analytics rule wizard, we can go to the Set rule logic tab in order to change the entity mapping based on the information we retrieved from looking through the log analytics which triggered the incident. In there we found the Name, UPNSuffix and UserId. We can now map these so that the next time the analytics rule is triggered, the incident is enriched with the related account. I have also added the IP address mapping to provide our SOC analysts with even more information, without requiring them to go through the log analytics themself.

We map the account entity according to the strong strong identifiers of an account entity as described in the official Microsoft documentation (each one of these bullet points forms a sufficient combination to identitfy the account):

Name + UPNSuffix
AadUserId
Sid + Host (required for SIDs of builtin accounts)
Sid (except for SIDs of builtin accounts)
Name + NTDomain (unless NTDomain is a builtin domain, for example “Workgroup”)
Name + Host (if NTDomain is a builtin domain, for example “Workgroup”)
Name + DnsDomain
PUID
ObjectGuid

Weak identifiers of an account entity (this is not sufficient to provide adequate entity mapping):

Name

The mapping of an IP entity only requires the address according to the documentation (Microsoft Sentinel entity types reference | Microsoft Learn). Strong identifiers of an IP entity:

Address

If we now trigger the incident again, we see that the new incident coming in has the account and IP entities mapped properly according to the defined entity mapping in our analytics rule. Additionally, we now see that with this incident the investigation graph (left bottom of the screen) is available, and that the top insights for the account is now available (right top of the screen).

In the next blog we will dive into entity mapping of non-user accounts Azure resources.

For questions you can contact us via: LinkedIn or email us contact@cloudlife.nl

Written by Keving Blijd

Op zoek naar een kennispartner?

Wij helpen je graag!

Extending entity mapping in Microsoft Sentinel, Mapping User Accounts and IP Addresses

Op zoek naar een kennispartner?

Menu

Diensten