Common questions I get asked is “What should we map as entities?” and “What does the entity fields mean?”. Now it is easy for me to understand, because I have been working with Microsoft Sentinel ever since it was made available internally at Microsoft, but for others not so much.
As discussed previously, Microsoft Sentinel supports the collection of data, which is classified as entities. data item which can be categorised by relevant attributes. But identifying them can be difficult, depending on the data available to you.
Strong and Weak Identification
Each entity has various attributes, from unique identifiers in a directory, to domain names. When performing attribution, you want to ensure you have correctly identified the right entity with certainty. To do this we want to use strong identifiers.
Take a log from the SignInLogs table as an example. (shortened for brevity)
| Column | Value |
| OperationName | Sign-in activity |
| Category | SignInLogs |
| ResultType | 0 |
| Id | 8cabe9ad-2c00-4bb9-aed3-a01bb8ce4900 |
| UserDisplayName | Alistair Ross |
| UserId | 58e2f08f-a1bc-4acd-b95f-949dd0778511 |
| UserPrincipalName | thealistairross@contoso.com |
| AADTenantId | 7ce56e6c-da40-4f69-ad96-85bbc05ada56 |
Here we can see various columns, that while are useful for the investigation, are irrelevant to the entity, such as OperationName, Category and ResultType.
There is also a UserDisplayName with the value “Alistair Ross”, but nothing stops people having the same display name in the same organisation, so this could be considered weak at best.
The AADTenantId is a weak identifier as well, while it does confirm which tenant this relates to, which is globally unique, it does not identify the individual.
Do not let the Id field here fool you, it is easy to make a mistake and choose the wrong field. If you are ever unsure, check with the Azure Monitor tables reference for built in tables, or with third party providers.
The UserId and UserPrincipalName would be strong identifiers, as they identify the user account with only one data point. If the UserPrincipalName was split into the name and NTDomain “thealistairross” and “contoso.com”, these would both be considered weak by themselves.
Not every log source will have the same identifiers and many will not even have strong identifiers, so using a combination would produce strong results. When Microsoft Sentinel can recognise the same entity based on strong identification, it merges the two entities into one, ensuring that they are handled consistently. If you discover an entity that is weakly identified, such as a user display name, then it will not be merged and will remain separate. Therefore it is key that you test your alerts and properly identify the entities based.
If you are ever unsure on what identifiers to use for an entity, we have an entity reference guide here https://learn.microsoft.com/en-us/azure/sentinel/entities-reference. This will give you descriptions and examples of each identifier as well as list strong identifiers.
I won’t go into detail on how to map the entities, our documentation lists this pretty well over at https://learn.microsoft.com/en-us/azure/sentinel/map-data-fields-to-entities
Limitations
You can select up to three identifiers per mapping.
You can only select up to three identifiers per mapping, some are required and you must pick at least one. Try to pick multiple strong identifiers for the best results.
The image below shows the Microsoft Sentinel entity mapping when creating analytic rules. It shows the entity type selected is Account and the AadUserId identifier is being mapped to the AccountName column in the results. This shows a single entity mapping with one selected identifier.
You can map up to five entities in a single analytics rule.
You have the ability to map five entities in a single analytic rule, giving you the scope to discover the entities related to that alert. You can map more than one entity of the same type as well. For example you may wish to map an IP Address more than once for firewall logs with the source IP address and destination IP address. The image below shows this scenario.
Each mapped entity can identify up to ten entities.
The image below shows the Microsoft Sentinel entity mapping when creating analytic rules. It shows the entity type selected is Account and the AadUserId identifier is being mapped to the AccountName column in the results. This entity selection and the identifiers is one mapping. You can select + Add new entity and select the same type “Account” again if you wish, this will be a separate mapping. If an alert identifies more than ten different entities within the same mapping, then it will take the first ten and drop the rest.
The size limit for an entire alert is 64 KB.
Alerts have a maximum size of 64K KB, so if too many entities are discovered, they will be dropped from the alert, in this scenario consider creating multiple alerts for the Incident and group your alerts according to your needs.
I hope this provides some clarity. In the next post I will talk about mapping entities when querying other Microsoft Sentinel workspaces.
The Cloud Brain Dump - By TheAlistairRoss 