liveBook · Manning

Entity mapping

As explained in Azure Security

A configuration that maps query results to recognized security entities such as accounts or hosts.

Entity mapping connects query results to Microsoft Sentinel entities, making accounts, hosts, and other recognized objects available during incident investigation. section 8.4.4

Configure mappings in a scheduled rule:

  • Choose Account as the entity type, select Name as the identifier, and map it to the query’s Account field. section 8.4.4
  • Add Host, select HostName, and map it to the Computer field so investigations connect the user with the endpoint. section 8.4.4
  • Map up to five recognized Sentinel entities; leave Custom Details and Alert Details blank when they are unnecessary. section 8.4.4

Failed-login detection

A query summarizes failed logins by Account and Computer. Mapping those fields to Account/Name and Host/HostName identifies both the involved user and endpoint in resulting incidents. section 8.4.4

Figure 8.5 Test with current data runs a simulation of the query you’re writing on top of your own data

Preview the rule with current environment data before relying on its entity mappings. section 8.4.4

How Azure Security covers it

How deep it goes
Configures entity type, identifier, value, and mapping limits, but does not detail investigation workflows.
Examples
Uses failed-login results grouped by Account and Computer, mapped to Account and Host entities.
What it assumes
Assumes a detection query returning mappable fields; teaches entity types, identifiers, and values from configuration steps.
What you can do after
Apply it via Microsoft Sentinel to associate detected activity with users and endpoints in incidents.
How it connects
Connects scheduled query rules with Microsoft Sentinel entities and incident investigation.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Azure Security. The section links point to the parts of the book it draws on.