Monitor For New Actions In Sentinel And MDE
Sometimes I get the question, how can I keep up with all the new actions that are added to our security solutions? This question is very valid, as identifying potential (new) threats and detection capabilities is crucial. This blog will explain and share a solution to get weekly reports on all the newly logged actions in Sentinel and Defender For Endpoint that are found in your tenant. This proactive approach helps to understand your data and enables organizations to identify patterns, anomalies, and potential indicators of compromise.
If you do not have a mechanism in place to be alerted on new actions, I highly recommend implementing this solution or creating a similar feature yourself.
The Logic App presented in this blog can be deployed from GitHub: Link
Requirements
- Sentinel or Defender For Endpoint tenant
- Permission to change logic apps (e.g. Logic App Contributor, Resource Group Contributor)
- Azure Monitor API permissions
- Defender ATP Advanced Hunting API permissions
Solution
By deploying the logic app below you will receive period updates on the found actions. The logic app itself is relatively simple with only 4 or 5 steps to complete. The logic is split into two categories, the left side only uses the Defender ATP API, and the left side is based on the Azure Monitor API to query the logs from Sentinel.
The actions that are included in the report are based on the columns of the tables. Every table that has one of the below columns is included in the report.
ActionColumn | Example Tables |
---|---|
ActionType | CloudAppEvents, DeviceEvents, IdentityQueryEvents |
Operation | OfficeActivity |
OperationName | AuditLogs, AADUserRiskEvents, StorageBlobLogs |
OperationNameValue | AzureActivity |
EventID | SecurityEvent |
Deployment Strategy
The deployment strategy depends on the configuration of your Sentinel and Defender For Endpoint environment.
Product | Deploy Defender For Endpoint Solution | Deploy Sentinel Solution |
---|---|---|
Standalone Defender For Endpoint | ✔️ | ❌ |
Standalone Sentinel | ❌ | ✔️ |
Some Defender For Endpoint data forwarded to Sentinel | ✔️ | ✔️ |
All Defender For Endpoint data forwarded to Sentinel | ❌ | ✔️ |
If you forward all your Device based logs to Sentinel (Tables: DeviceEvents, DeviceFileEvents, DeviceFileCertificateInfo, DeviceInfo, DeviceLogonEvents, DeviceNetworkEvents, DeviceProcessEvents, DeviceRegistryEvents) it is recommended to not use the Defender For Endpoint solution. This is because the logs in Advanced Hunting are only available for 30 days, the value of the longer Sentinel retention is preferred. If you forward some of these tables keep the Defender For Endpoint solution active for the tables you do not forward to Sentinel.
Example Output
Below are two examples shared of the weekly email you receive once the Logic App has been implemented. The output is grouped by newly identified action for each table.
Defender For Endpoint Output
let TimeFrame = 30d;
let Schedule = 7d;
let KnownActions = union Device*
| where TimeGenerated between (startofday(ago(TimeFrame)) .. startofday(ago(Schedule)))
| where isnotempty(ActionType)
| distinct ActionType;
union Device*
| where TimeGenerated > startofday(ago(Schedule))
| where isnotempty(ActionType) and ActionType !in (KnownActions)
| distinct Type, ActionType
| project-rename DataType = Type
| sort by DataType, ActionType
Sentinel Output
let TimeFrame = 180d;
let Schedule = 7d;
let KnownActions = union *
| where TimeGenerated between (startofday(ago(TimeFrame)) .. startofday(ago(Schedule)))
| extend Action = coalesce(Operation, OperationName, OperationNameValue, ActionType, tostring(EventID))
| where isnotempty(Action)
| distinct Action;
union *
| where TimeGenerated > startofday(ago(Schedule))
| extend Action = coalesce(Operation, OperationName, OperationNameValue, ActionType, tostring(EventID))
| where isnotempty(Action) and Action !in (KnownActions)
| distinct Type, Action
| project-rename DataType = Type
| sort by DataType, Action
There is also a Sentinel Data Insight Workbook available on GitHub. This workbook provides information on the ingested tables and the different actions that arise in this table. Often tables contain multiple sources of data, for example, the OfficeActivity logs contain data from SharePoint, Exchange Online and Microsoft Teams. This does not only apply to the OfficeActivity table but is also applicable to other tables. Therefore it is important to review which tables you ingest, you may not even know that data is flowing to a particular table.
Configuration
Once you deploy the Logic App you will be served with a couple of errors. These are required configuration steps to adjust the Logic App to your environment.
- Adjust the recurrence based on your needs. If you change the recurrence you should also change the Schedule variable in the KQL accordingly.
- Set Recipient Mailbox.
- Configure Defender For Endpoint API connection.
- Configure Azure Monitor API connection.
- Configure Exchange Online API connection.
Once all these steps are completed you can sit back and wait for the first report to arrive.
Questions? Feel free to reach out to me on any of my socials.