A security team uses Microsoft Sentinel to monitor AI-related threats. They need to create a hunting query to find users who interacted with Azure OpenAI but whose IP addresses are listed in a threat intelligence watchlist. Which Sentinel feature links the watchlist to the query?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — a is correct because Microsoft Sentinel watchlists store reference data (such as a list of malicious IP addresses) that can be queried in KQL using the '_GetWatchlist("WatchlistName")' function. The hunting query can join the Azure OpenAI diagnostic logs (AzureDiagnostics) with the watchlist on the IP address field to identify calls from threat intelligence-flagged IPs.
Full explanation below image
Full Explanation
A is correct because Microsoft Sentinel watchlists store reference data (such as a list of malicious IP addresses) that can be queried in KQL using the '_GetWatchlist("WatchlistName")' function. The hunting query can join the Azure OpenAI diagnostic logs (AzureDiagnostics) with the watchlist on the IP address field to identify calls from threat intelligence-flagged IPs. B is wrong because Fusion rules use machine learning to correlate signals and cannot be directed to use a specific watchlist as a join source. C is wrong because the Microsoft Threat Intelligence data connector populates ThreatIntelligenceIndicator table; while you can join against that, using a watchlist for a curated custom list is the more direct and appropriate approach. D is wrong because creating a custom parser changes how raw logs are ingested and parsed; it is not the method for correlating against a watchlist.