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.
We all have probably been there and developed a PowerShell script that took some fair amount of time until the execution completed, weren’t we? Of course one could argue and say that as long a script ‘works’ it is good enough but depending on the use case and environment a PowerShell script that runs 30 to 60 minutes exceeds the patience of most (IT) people and can also lead to increased costs. But what makes those kinds of scripts that awfully slow and can’t we just tweak them to run faster?
The following examples and script will be related to PowerShell and the Microsoft Graph API but the mentioned approaches can be adapted for any kind of RESTful API and scripting language. For all interactions with the Graph API I use the Microsoft Graph PowerShell SDK which is available as a PowerShell module from the PowerShell gallery.
Reasons why your script is slow # I would say I have already read and (tried to) understand hundreds of PowerShell scripts out there and I often notice the following flaws which lead to poor performance:
Slow algorithms and wrong data structures # Slow algorithms are extricably linked to the understanding of data structures when it comes to PowerShell scripting. Here the top two cases I often observe:
The Microsoft Store for Business will be discontinued mid 2023 and Intune recently introduced the new Windows Store experience backed by winget to distribute apps to your Intune managed endpoints.
To simplify the migration to the new Windows Store experience I created a PowerShell Script that migrates all currently assigned Windows Store for Business apps to the new Windows Store experience.
Kudos to Sander Rozemuller for providing detailed instructions about creating winget apps as PowerShell code samples.
Challenges # While scripting and extracting the existing Windows Store for Business (WSfB) apps I encountered the following issues:
Not all apps in WSfB have valid privacy and information URLs, therefore I added a check whether the URL starts with http(s). Some apps have characters present (äöüë….) that require UTF-8 encoding. So I explicitly set the HTTP content-type header to UTF8. Script prerequisites # To run the script you need to have the Microsoft Graph PowerShell SDK modules installed on your machine. You can install them with the following command:
Install-Module Microsoft.Graph.Authentication, Microsoft.Graph.Devices.CorporateManagement -Scope CurrentUser From a permissions perspective you need an Azure AD Application Administrator for the initial OAuth permission consent and for regular execution the Intune Administrator role.
Workload Identity Federation (let’s just call this WIF) allows app principals not residing within Azure to request short lived access tokens. This removes the need of storing client secrets or certificates within GitHub as Action secrets. One drawback ist that currently only the Azure modules support the usage of WIF.
How it works # WIF relies on trust. This trust is directly configured on the Azure AD app registration and scoped to an individual GitHub repository and optionally fine grained by limiting the usage to single git refs, specifically branches and tags. By trusting GitHub as external identity provider (IdP), a GitHub Action can request an identity token from the GitHub IdP and exchange this one against an access token within Azure AD.
A GitHub IdP issued token (decoded) contains the following information:
{ "jti": "1a9fe224-c936-46f6-a38b-3300e76251b0", "sub": "repo:nicolonsky/musical-octo-telegram:ref:refs/heads/main", "aud": "api://AzureADTokenExchange", "ref": "refs/heads/main", "sha": "9f112c0b82547e35b10250d7f3165789bf97862f", "repository": "nicolonsky/musical-octo-telegram", "repository_owner": "nicolonsky", "repository_owner_id": "32899754", "run_id": "3986560796", "run_number": "2", "run_attempt": "2", "repository_visibility": "private", "repository_id": "592303002", "actor_id": "32899754", "actor": "nicolonsky", "workflow": ".github/workflows/wif.yaml", "head_ref": "", "base_ref": "", "event_name": "push", "ref_type": "branch", "workflow_ref": "nicolonsky/musical-octo-telegram/.github/workflows/wif.yaml@refs/heads/main", "workflow_sha": "9f112c0b82547e35b10250d7f3165789bf97862f", "job_workflow_ref": "nicolonsky/musical-octo-telegram/.github/workflows/wif.yaml@refs/heads/main", "job_workflow_sha": "9f112c0b82547e35b10250d7f3165789bf97862f", "iss": "https://token.actions.githubusercontent.com", "nbf": 1674486850, "exp": 1674487750, "iat": 1674487450 } Did you recognize the matching sub attribute within the GitHub issued token and the Azure AD configuration? For a successful authentication the:
Windows Package Manager (winget) provides exciting features to install and upgrade apps on Windows devices. But how does winget actually work and how are new packages integrated? Within this post I want to elaborate on some questions I had when having a closer look into winget.
How does winget find sources? # By default, winget has the following sources configured:
msstore: Microsoft Store (public) winget: Winget Content Delivery Network (CDN) When searching for a particular package, e.g: winget search wireshark all configured sources are searched for a match.
lesson learned: winget can install packages from the public Microsoft store and the winget CDN.
How are winget CDN packages provided? # Winget CDN packages reside within a public git repository hosted on GitHub. The repository contains an alphabetic folder structure by vendor and product name holding manifests in YAML format that describe the app details.
The manifests folder within the repo is grouped by the app vendor and app name and YAML contents of a manifest look like this:
