Entities Recognized by Microsoft Sentinel and the Investigation Graph

Get more value out of your Microsoft Sentinel incidents with entities.

Microsoft Sentinel has a limited set of entities that it will recognize while gathering information about a security incident. We discussed some of these entities in our blog about Alert Enrichment, but we did not get an opportunity to go over the recognized entities in detail. Knowing more about the recognized entities will help make analytics more effective at conveying information.

In this blog we will go over all the current entities recognized by Microsoft Sentinel based on the categories that our analysts use when investigating. We will also discuss the practical uses for each of these entities so that when someone on your team writes an analytic rule, they will know which entity is the right tool for the job.

“Who” Entities

This category is used to identify the accounts used during the incident and any attributes associated with that account. Since only 5 entities are allowed while mapping an analytic rule, we recommend only using 1-2 of these entities to display account information.

• Account: This entity represents a user account and is essential in any incident that involves a user account. This entity should be mapped to table columns that have usernames, domain, and user account attributes.
• Security Group: This entity represents the groups the user is associated with. This entity should be mapped to table columns that have domains, group membership, and access the user gets from being in a group.
• Cloud Application (service principals): Sometimes there is not a user account involved with the incident, which is why the cloud application entity would be treated as an identity. This entity should be mapped to table columns that have formal names for the app, app permissions, and groups the app may be in.

“Where” Entities

This category is used to identify the logical and/or physical location of the incident. Since only 5 entities are allowed while mapping an analytic rule, we recommend using 2-3 of these entities to display where the incident happened.

• Microsoft Sentinel Resource: This entity represents objects the organization owns in Microsoft Sentinel; it could be anything from a storage account to a container image. This entity should be mapped to table columns that have the resource name, its resource group, and any other location data that is relevant to that resource.
• Cloud Application: This entity represents apps from a cloud service inside or outside Microsoft Sentinel. This entity should be mapped to table columns that have the name of the app, the service the app is from, and any relevant data about the app configuration.
• Host: This entity represents an endpoint that the incident happened on. This entity should be mapped to table columns that have the host name, domain it is joined to, and any relevant information about important data on the host.
• File: This entity represents both a file and the logical location of a file involved with the incident. This entity should be mapped to table columns that have the file name, file address, and any tags or labels associated with the file.
• IP: This entity represents any IP addresses involved with the incident, but it normally represents the IP address of the user attempting to interact with a resource. This entity should be mapped to table columns that have the IP address and any IOCs associated with that IP address.
• DNS: This entity represents a DNS server associated with the incident. This entity should be mapped to table columns that have the DNS server name and any relevant connected devices.
• Mailbox: This entity represents a mailbox associated with the incident. This entity should be mapped to table columns that have the name of the mailbox, users associated with that mailbox, and any groups that mailbox is associated with.
• Mail Cluster: This entity represents an email cluster, which is a way of logically networking email servers together. This entity should be mapped to table columns that have the cluster name and the domain that the mail cluster is managing mail for.

“What Happened” Entities

This category is used to identify the activities that happened during the incident. Since only 5 entities are allowed while mapping an analytic rule, we recommend using 2-3 of these entities to display what happened during the incident.

• File Hash: This entity represents a hash value of a file that is associated with the incident. This is treated like a “what happened” entity because it is information about the file and what it is for rather than the location of the file. This entity should be mapped to table columns that have hashes associated with a file and any IOC information that is available.
• Malware: This entity represents files and/or locations of suspected malware. This entity should be mapped to table columns that have the name of the file/location, the type of malware set off the detection, and descriptions about the suspected malware.
• Process: This entity represents processes that were created or started on a device during the incident. This entity should be mapped to table columns that have the name of the process, a description of the process, and any information about what started the process.
• Registry Key: This entity represents a folder location within a device’s registry. This entity should be mapped to table columns that have the path of registry entries that were made.
• Registry Value: This entity represents the value of an entry that was made into a device’s registry. This entity should be mapped to table columns that have the name of the registry entry, what the entry may do, and any information about what put that value into the device’s registry.
• Mail Message: This entity represents the text in the email associated with the incident. This entity should be mapped to table columns that have email addresses involved, contents of the email, and information about any attachments or links.
• Submission Mail: This entity is a bit of an anomaly because there are 2 different types of “submission” associated with email and the Docs articles are not clear on which one it is meant for. Your organization will have to agree upon whether this is used for “submission queues” or “submitting a potentially malicious email”. Once your organization has decided on a standard, you can map this entity based on the option selected.

We will continue to share best practices and lessons learned in future posts on creating quality Microsoft Sentinel detections in customer environments. We are constantly looking for information on concepts like entities so that we can make our investigations faster and more effective.

In closing, consider these three questions when using Microsoft Sentinel entities in your organization:

1. Do we have a consistent method for identifying the 5 most important entities when creating analytic rules?
2. Are we able to get security analysts to understand the data that we are mapping using these entities?
3. Can we find time to test analytic rules with new entities to make sure that they are working as intended?