Threat Intelligence in Microsoft Sentinel

Threat intelligence (TI) in Microsoft Sentinel refers to the ability to import, store, and use structured threat indicators from various sources to detect, prioritize, and respond to threats. These indicators—such as IP addresses, domains, URLs, file hashes, and email addresses—are matched against log data ingested into Sentinel. When a match occurs, it generates an alert or incident, enabling security teams to act quickly.

Sentinel is a SIEM and SOAR platform; TI transforms it from a reactive log analyzer into a proactive threat detection system. Without TI, you rely solely on behavioral analytics and signatures you create. With TI, you leverage the collective knowledge of the global security community. For example, if a known malicious IP address connects to your network, Sentinel can alert you immediately, even if no other suspicious behavior is observed.

TI in Sentinel operates through a multi-step pipeline:

1. Ingestion: TI data is ingested via data connectors. Sentinel supports connectors for: - Microsoft Defender Threat Intelligence (MDTI) – premium TI from Microsoft - Threat Intelligence – TAXII – for STIX/TAXII feeds (e.g., from Anomali, AlienVault OTX) - Threat Intelligence Platforms (TIP) – via API connectors (e.g., MISP, Palo Alto Networks) - Custom connectors using Log Analytics API or Logic Apps

Each connector creates a table named ThreatIntelligenceIndicator in the Log Analytics workspace. The schema is based on the STIX 2.0 standard, including fields like SourceSystem, IndicatorType, ThreatType, ConfidenceScore, ExpirationDateTime, and Tags.

- ThreatIntelligenceIndicator table: Contains all ingested indicators. Key columns: - IndicatorType: e.g., "ipv4-addr", "domain-name", "file", "url" - Pattern: The actual value, e.g., "203.0.113.5" - ThreatType: e.g., "malicious-activity", "command-and-control" - ConfidenceScore: integer 0-100 - ExpirationDateTime: datetime; if null, defaults to 30 days from ingestion - Tags: array of strings for categorization - Default analytics rule: Microsoft Sentinel provides a built-in rule called "TI Map IP Entity To AzureActivity" (and similar for other entity types). These rules are disabled by default; you must enable them and configure the TI source. - Data retention: TI indicators are subject to the workspace retention policy (default 90 days for interactive retention, then archived). However, it's recommended to use a longer retention (e.g., 1 year) for TI.

To configure TI: 1. Navigate to Sentinel > Threat Management > Threat Intelligence. 2. Click Add to create a new TI data connector. - For TAXII: Enter the API root URL, collection ID, username/password (if required), and polling interval (default every 5 minutes). - For MDTI: Simply enable the connector; no additional configuration needed. 3. After connection, indicators appear in the ThreatIntelligenceIndicator table. Verify with a KQL query:

ThreatIntelligenceIndicator
   | where SourceSystem == "ThreatIntelligence"
   | summarize count() by IndicatorType

Ingesting too many indicators (e.g., millions) can impact query performance and increase costs. Best practices:

Threat intelligence in Sentinel is a data ingestion and matching pipeline. Indicators are ingested via connectors into a normalized table (ThreatIntelligenceIndicator). Analytics rules run scheduled queries (e.g., every 5 minutes) that join this table with other logs. When a match occurs, an alert is generated. The system relies on STIX/TAXII standards for interoperability. Key exam topics include connector types, table schema, default values, and the necessity of enabling analytics rules.

A mid-sized company uses Microsoft Sentinel with the TAXII connector to ingest indicators from AlienVault OTX. They configured the connector to poll every 10 minutes and enabled the 'TI Map IP Entity To AzureActivity' rule. One day, a user's Azure AD sign-in matched an IP address that was flagged as a known C2 server. The incident was automatically created and assigned to a Tier 2 analyst. The analyst used the indicator's context (provided by OTX) to determine that the IP was associated with a phishing campaign. The company then blocked the IP on their firewall via a playbook. The key lesson: TI allowed detection of a threat that behavioral analytics missed. However, they initially had too many low-confidence indicators causing false positives; they reduced the threshold to ConfidenceScore > 70.

A bank uses Microsoft Defender Threat Intelligence (MDTI) because they need high-fidelity indicators for critical assets. MDTI provides reputation scores and threat actor profiles. They integrated MDTI with Sentinel and enabled rules for DNS and network traffic. When a domain with a malicious reputation score of 99 was queried from an internal host, Sentinel generated a critical incident. The SOAR playbook automatically isolated the host. The bank also uses TI in hunting queries to proactively search for IOCs from recent threat reports. They set up a weekly job to expire indicators older than 30 days unless they are tagged 'persistent'. The challenge was cost: MDTI is a premium service, but for their risk profile it was justified.

A managed security service provider (MSSP) uses Sentinel for multiple customers. They deploy a centralized TI strategy: indicators from various sources are ingested into a single Log Analytics workspace, then distributed to customer workspaces via Azure Lighthouse. They use custom analytics rules that filter by customer tenant ID. The MSSP learned that each customer needs different TI sources—some prefer open-source, others require commercial feeds. They also had to manage indicator expiration carefully to avoid stale indicators affecting multiple customers. Performance was a concern: with millions of indicators, queries slowed down. They optimized by using only high-confidence indicators and creating separate workspaces for high-volume customers.