After enabling Azure Sentinel as the SIEM/SOAR solution and using Defender for Cloud as one of the data ingestion sources I found myself in a predictable-in-hindsight situation where I get the incidents to Sentinel to handle, but am left with the same incidents and alerts dangling in Defender for Cloud. To some this may not be too big of a deal, but I’d hate to have them open despite having them handled elsewhere. Sadly the solution to this problem wasn’t as straightforward as one would hope.
To begin with, we’re dealing with an adaptive application control audit policy violation, where the typically used suppression entity would be either the path of the executable or the certificate. In this instance we didn’t want to use either, and just stick to the file hash - and not only because one was conveniently provided in the alert itself. Sounded easy enough in theory; just create a suppression rule based on that hash and you’re off to the races, however when trying to validate or create such rule, you’re greeted with the following error message:
Alert type VM_AdaptiveApplicationControlWindowsViolationAudited is not supported in the suppression rules capability due to forbidden entity “filehash” for this alert type
Thanks. Off to search other possible solutions.
Now it makes sense that while the incidents are ingested to Sentinel, nothing is done to them in Defender for Cloud, and while I’d argue that at least the option to replicate the end state between the two would be beneficial, at the time of writing you’re left with two “different” incidents.
The solution to this lies in the Analytics blade of Sentinel.
The following will sound like rather backwards thinking, but it does work:
- Go to Analytics blade in Sentinel
- Create a Microsoft Incident creation rule
- Select “Microsoft Defender for Cloud” as the Microsoft security service
- Move to Automated response, and create a rule that matches your requirements (e.g., uses the file hash)
- Select “Closed” as the “Change status” outcome and select the wanted classification.
After this the event created in Defender for Cloud will get sent to Sentinel as usual, but will also be automatically dismissed in Defender for Cloud.
