Intune Endpoint Security Configuration Settings have become the way to go for configuring security features on various platforms. What did start with Microsoft Defender for Endpoint settings for Windows clients has evolved to settings for macOS, Windows Servers and is treated like a first class citizen. So it is important to guard those sensitive configurations as they control (and can potentially disable) vital security features on endpoints such as defender tamper protection, attack surface reduction rules, firewall and many more.
Within this post I want to show you an approach to monitor changes to Intune Endpoint security settings with Microsoft Sentinel and watchlists that can be easily customised based on your environment and needs. My main idea is to classify the sensitive configurations in the environment and only creating incidents for those. Of course you could alert on every Intune configuration change but for most of the environments this would lead to many alerts without providing value.
Prerequisites
Changes to the Intune Endpoint security settings area are visible like other changes within the Intune Audit Logs.
To have the audit events within our Sentinel workspace we need to enable the forwarding for at least AuditLogs. This can be done within the Intune Tenant Administration > Diagnostic Settings blade.
As we can configure multiple diagnostic settings it might even be a good idea only ingesting AuditLogs to Sentinel and storing the other logs in a dedicated Azure Log Analytics Workspace (to save some bucks).
Classifying our settings with a Sentinel Watchlist
The next step is to classify our settings. Of course we could monitor all the settings but maybe we do not want to create alerts for every change, because based on the environment we have multiple administrators working and we do not want to bother our SOC when someone changes a wallpaper configuration.
So we want define a CSV that will serve as our Sentinel watchlist, containing the most important Intune Endpoint Security configurations in place. The most important part is the ConfigurationId property. This is the unique ID of the Intune Endpoint Security setting and will later serve as the searchkey for the watchlist, whereas the other columns mainly provide additional context.
To get the ConfigurationId you can simply copy the value from your browser’s address bar when browsing the Intune profile:
In our Sentinel workspace we then create the watchlist:
As a source type we provide the previously created CSV with the ConfigurationId as the SearchKey:
Using the watchlist
The idea is to compare the generated events in the IntuneAuditLogs table against our watchlist. When querying the data we can do an inner join (the lookup is basically the same as a join but optimised for this use-case) to get only the events that affect a configuration that we classified as sensitive enough to be within our watchlist.
To get all the modifications that do not affect items in our watchlist (e.g. to get non-critical audit events) you can simply switch the lookup keywoard with join kind = leftanti.
Query:
Creating the analytics rule
With our query we can move on and create an analytic rule to alert on the modifications and providing the most important details within the alert. Besides the standard alert rule information I also use the Custom details to provide the necessary context about the affected configuration:
End result
Within the generated incident we have access to the most important information right away and can then perform the investigation why the setting was modified:
Thanks to the watchlist this process can be further fine tuned. For example “authorised” actors, e.g. staff from the security team that are allowed to modify the settings could be considered and in that case the alert being suppressed.
By Nicola on March 12, 2023.
Exported from Medium on December 3, 2023.