Sentinel Threat Maps and Security Dashboards

Microsoft Sentinel is a cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response) solution. Threat Maps and Security Dashboards are visualization components that help security analysts quickly identify patterns, anomalies, and potential threats across the environment.

Threat Maps rely on IP geolocation data. When Sentinel ingests a security alert, it extracts the source IP address (or destination IP, depending on configuration). This IP is then enriched with geolocation information using the Azure Maps service or third-party geolocation databases. The mapping engine in Sentinel uses this enriched data to plot points on a map. The process:

- Data Source: Any log source that includes IP addresses (e.g., AzureFirewallLogs, SecurityEvent, SigninLogs). - Analytics Rule: Must generate alerts with IP address fields. Built-in rules like 'Malicious IP address detected' automatically populate the map. - Geolocation Function: geolocation() in KQL returns latitude, longitude, country, state, city, and ASN for a given IP. - Map Visualization: Available in Workbooks as a 'Map' tile. Configuration options include: - Latitude/Longitude fields: Must be numeric. - Size metric: Determines marker size (e.g., count of alerts). - Color metric: Determines marker color (e.g., severity). - Zoom levels: Default is auto-fit; can be set to specific level. - Time range: Default is last 24 hours; configurable.

Security Dashboards in Sentinel are essentially Azure Workbooks. They are composed of tiles (queries) that display data in various formats: tables, charts (bar, line, pie), and maps. Each tile runs a KQL query against the Sentinel workspace.

- Workbook Template: Sentinel comes with several built-in templates, such as 'Azure Security Center Insights', 'Identity & Access', and 'Threat Intelligence'. These can be customized. - Custom Workbook: Create from scratch or edit a template. Steps: 1. In Sentinel, go to 'Workbooks'. 2. Click 'Add workbook' or open an existing one and click 'Edit'. 3. Add a new query tile: select data source (Log Analytics workspace), write KQL query. 4. Choose visualization type: Map, Time chart, Bar chart, etc. 5. Configure parameters (time range, subscriptions) for interactivity. 6. Save and publish.

To create a threat map, you typically need a query that returns geographic coordinates. Example:

SecurityAlert
| where TimeGenerated > ago(7d)
| extend Geo = geolocation(SourceIPAddress)
| where Geo is not null
| project Timestamp = TimeGenerated, SourceIPAddress, AlertName, Severity, Geo.latitude, Geo.longitude, Geo.country
| take 1000

For a dashboard showing failed sign-ins by country:

SigninLogs
| where ResultType == "50057" // User account is disabled
| extend Geo = geolocation(IPAddress)
| where Geo is not null
| summarize FailedSignins = count() by Geo.country
| render piechart

Workbooks support parameters that allow users to filter data (e.g., by time range, subscription, or severity). Parameters are defined at the top of the workbook and can be linked to queries. For example, a time range parameter:

let TimeRange = dynamic({TimeRange:timespan});
SecurityAlert
| where TimeGenerated > ago(TimeRange)

AZ-500 expects you to know:

A multinational corporation uses Sentinel to monitor attacks across its Azure and on-premises infrastructure. They deploy a threat map workbook that plots all failed authentication attempts (from Azure AD SigninLogs and Windows Security Events) on a world map. The map uses color-coded markers: red for brute-force attacks, yellow for suspicious IPs. The SOC team uses this to identify regions with high attack volumes. They notice a spike from a specific country and create a custom analytics rule to block all traffic from that country's IP range at the Azure Firewall. The map is configured with a time range parameter (last 7 days) and auto-refreshes every 5 minutes. Performance is acceptable with ~50,000 alerts per day; they use clustering to avoid marker overload. A misconfiguration—using the wrong IP field (destination IP instead of source)—caused the map to show internal Azure IPs, which geolocation returns null. After correcting to SourceIPAddress, the map worked correctly.

A managed security service provider (MSSP) builds a comprehensive security dashboard for its clients. The dashboard includes multiple tiles: a threat map showing active incidents, a bar chart of top alert types, a time chart of alerts over the last 24 hours, and a table of recent incidents. The dashboard uses parameters for client subscription and time range. Each tile is linked to the same parameters, so a SOC analyst can quickly switch between clients. The threat map uses the geolocation() function on the IP address from the SecurityIncident table (which includes alert data). They discovered that the SecurityIncident table does not always contain IP addresses; they had to join with SecurityAlert or use the ExtendedProperties field. This required a more complex KQL query. The dashboard is shared via Azure RBAC: analysts have Reader role, engineers have Contributor role. A common mistake is forgetting to set the Size metric to a numeric field, causing the map to show uniform markers.

A financial institution uses Sentinel to detect lateral movement. They create a custom workbook that maps outbound connections from compromised VMs. The threat map shows destination IPs plotted geographically. They use a KQL query that joins VMConnection logs with SecurityAlert to highlight connections from VMs with active alerts. The map uses marker size to indicate connection frequency. They set a threshold: if a single IP appears more than 100 times in an hour, it triggers a playbook that automatically blocks the IP. Performance issues arose when querying over 30 days; they optimized by using a materialized view that pre-aggregates connection counts by IP and hour. The exam may test this optimization technique.