Επεξεργασία

Κοινή χρήση μέσω

Entities in Microsoft Sentinel

  • Άρθρο

When alerts are sent to or generated by Microsoft Sentinel, they contain data elements that Sentinel can recognize and classify into categories as entities. When Microsoft Sentinel understands what kind of entity a particular data element represents, it knows the right questions to ask about it, and it can then compare insights about that item across the full range of data sources, and easily track it and refer to it throughout the entire Sentinel experience - analytics, investigation, remediation, hunting, and so on. Some common examples of entities are user accounts, hosts, mailboxes, IP addresses, files, cloud applications, processes, and URLs.

Important

Microsoft Sentinel is generally available within Microsoft's unified security operations platform in the Microsoft Defender portal. For preview, Microsoft Sentinel is available in the Defender portal without Microsoft Defender XDR or an E5 license. For more information, see Microsoft Sentinel in the Microsoft Defender portal.

In the Microsoft Defender portal, entities generally fall into two main categories:

Entity category Characterization Main examples
Assets
  • Internal objects
  • Protected objects
  • Inventoried objects
    		•
  • Accounts (Users)
  • Hosts (Devices)
  • Mailboxes
  • Azure resources
    		•
    Other entities
    (evidence)
  • External items
  • Not in your control
  • Indicators of compromise
    		•
  • IP addresses
  • Files
  • Processes
  • URLs
    		•

    Entity identifiers

    Microsoft Sentinel supports a wide variety of entity types. Each type has its own unique attributes, which are represented as fields in the entity schema, and are called identifiers. See the full list of supported entities below, and the complete set of entity schemas and identifers in Microsoft Sentinel entity types reference.

    Strong and weak identifiers

    For each type of entity there are fields, or sets of fields, that can identify particular instances of that entity. These fields or sets of fields can be referred to as strong identifiers if they can uniquely identify an entity without any ambiguity, or as weak identifiers if they can identify an entity under some circumstances, but are not guaranteed to uniquely identify an entity in all cases. In many cases, though, a selection of weak identifiers can be combined to produce a strong identifier.

    For example, user accounts can be identified as account entities in more than one way: using a single strong identifer like a Microsoft Entra account's numeric identifier (the GUID field), or its User Principal Name (UPN) value, or alternatively, using a combination of weak identifiers like its Name and NTDomain fields. Different data sources can identify the same user in different ways. Whenever Microsoft Sentinel encounters two entities that it can recognize as the same entity based on their identifiers, it merges the two entities into a single entity, so that it can be handled properly and consistently.

    If, however, one of your resource providers creates an alert in which an entity is not sufficiently identified—for example, using only a single weak identifier like a user name without the domain name context—then the user entity cannot be merged with other instances of the same user account. Those other instances would be identified as a separate entity, and those two entities would remain separate instead of unified.

    In order to minimize the risk of this happening, you should verify that all of your alert providers properly identify the entities in the alerts they produce. Additionally, synchronizing user account entities with Microsoft Entra ID may create a unifying directory, which will be able to merge user account entities.

    Supported entities

    The following types of entities are currently identified in Microsoft Sentinel:

    You can view these entities' identifiers and other relevant information in the entities reference.

    Entity mapping

    How does Microsoft Sentinel recognize a piece of data in an alert as identifying an entity?

    Let's look at how data processing is done in Microsoft Sentinel. Data is ingested from various sources through connectors, whether service-to-service, agent-based, or API-based. The data is stored in tables in your Log Analytics workspace. These tables are queried at regular intervals by the scheduled or near-real-time analytics rules you've defined and enabled, or on-demand as part of hunting queries when you hunt for threats. Part of the definition of these analytics rules and hunting queries is the mapping of data fields in the tables to entity types recognized by Microsoft Sentinel. According to the mappings you define, Microsoft Sentinel will take fields from the results returned by your query, recognize them by the identifiers you specified for each entity type, and apply to them the entity type identified by those identifiers.

    What's the point of all this?

    When Microsoft Sentinel is able to identify entities in alerts from different types of data sources, and especially if it can do so using strong identifiers common to each data source or to another schema, it can then easily correlate between all of these alerts and data sources. These correlations help build a rich store of information and insights on the entities, giving you a solid foundation and context for investigating and responding to security threats.

    Learn how to map data fields to entities.

    Learn which identifiers strongly identify an entity.

    Entity pages

    Information about entity pages can now be found at Entity pages in Microsoft Sentinel.

    Next steps

    In this document, you learned about working with entities in Microsoft Sentinel. For practical guidance on implementation, and to use the insights you've gained, see the following articles: