A security team wants to set up a custom threat intelligence feed of Azure OpenAI endpoint abuse indicators (malicious IP addresses that have been observed submitting jailbreak prompts at scale) and use it in Sentinel analytics rules. Which Sentinel feature is the most direct mechanism for ingesting this custom threat intelligence?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — b is correct because Microsoft Sentinel's Threat Intelligence platform (the ThreatIntelligenceIndicator table) supports ingesting custom indicators via TAXII server connectors or the Microsoft Security Graph Tiindicators upload API. Once ingested, these indicators are available in Sentinel analytics rules through the ThreatIntelligenceIndicator table, enabling automatic correlation with activity logs.
Full explanation below image
Full Explanation
B is correct because Microsoft Sentinel's Threat Intelligence platform (the ThreatIntelligenceIndicator table) supports ingesting custom indicators via TAXII server connectors or the Microsoft Security Graph Tiindicators upload API. Once ingested, these indicators are available in Sentinel analytics rules through the ThreatIntelligenceIndicator table, enabling automatic correlation with activity logs. Sentinel also has built-in analytics rules that automatically correlate new TI indicators against ingested logs. A is wrong because watchlists are a valid alternative for smaller, manually managed lists, but the Threat Intelligence platform with TAXII or API ingestion is the purpose-built mechanism for operational threat intelligence feeds with automatic expiration and indicator management. C is wrong because Conditional Access named locations are for enforcing access policies based on network location, not for populating Sentinel analytics correlation. D is wrong because hard-coding IP addresses in KQL makes the rule static and difficult to maintain; it does not scale as the threat intelligence feed updates.