Azure
Analytic rule "TI map Domain entity to Web Session Events (ASIM Web Session schema)" not processing Url
Describe the bug The rule "TI map Domain entity to Web Session Events (ASIM Web Session schema)" in the file https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Threat%20Intelligence%20(NEW)/Analytic%20Rules/DomainEntity_imWebSession.yaml
Appears to have been written to map Threat Intel items of type url:value or domain-name:* however the placement of a where clause means it will only process items of type domain-name:*
Reduces the effectiveness of this rule very significantly as a lot of IOC may rely on a full URL path rather than just the FQDN
To Reproduce Steps to reproduce the behavior: Go to: https://github.com/Azure/Azure-Sentinel/blob/aaca33fc6e4cf5fa1560b410aae3525cc241419e/Solutions/Threat%20Intelligence%20(NEW)/Analytic%20Rules/DomainEntity_imWebSession.yaml#L38 Copy lines 1-11 of the query only (31-42 of the yaml file) and run in a Sentinel instance that is configured to have populated the ThreatIntelIndicators table with indicators of both type "url:value" and "domain-name:value"
Expected behavior Query should return indicators of type "url:value" or "domain-name", but it only returns those of type "domain-name"
Hello @cg-techgw, thanks for flagging this. We will look into it and get back to you. Thanks!
After a bit more thinking, this might just be a messy usage of the TI. I initially presumed the URL indicators ought to be included as they are incorrectly referenced in the rule (hence the related pull request), but they are really a different sort of indicator than domains so perhaps they are not appropriate for this rule.
So my question would be: is the best course of action to,
A: Include indicators of the URL type in this rule by extracting the domain portion for comparison against the WebSession logs, or B: Exclude URL type indicators from this rule and just add a new one which compares them against WebSession logs instead.
My inclination is option B as it seems like the obvious place to check URL indicators anyway, and there's always a possibility that URL indicators contain a benign domain with a malicious URL path. but perhaps I'm missing something about the way the TI is used?
Can someone from the content creation team comment?
Hello @cg-techgw,
Yes, combining both domain and URL indicator-based IOCs within a single rule can introduce complexity. Kindly create a separate rule specifically for URL-based IOC. Thank you for your cooperation!