Sentinel

Managing Microsoft Sentinel table retention and tiers is typically done through scripts or the portal, but neither approach fits well into an infrastructure-as-code workflow and it can be difficult to maintain tables at scale. While exploring the Log Analytics Bicep resource provider, I came across the Microsoft.OperationalInsights/workspaces/tables resource type1, which makes it possible to manage table tier and retention declaratively with Bicep: version-controlled, reviewable, and reproducible across environments. For each table we typically want to control: Table tier: Analytics or Data Lake (Auxiliary) Interactive retention: the hot, queryable period Total retention: the overall retention period of the table Typical Table Configuration Settings Managing the total retention per table is necessary whenever you want to keep logs longer than the 90-day default to satisfy logging or compliance requirements. Since there is no workspace-level default for total retention, it has to be configured table by table, a perfect fit for a declarative approach. Identify tables with recent ingestion # To identify ‘active’ tables, both a KQL- and API-based approach exist. KQL # The following KQL query lists tables that have received data in the last 90 days along with their current tier, which is helpful when deciding what to put under Bicep management:

In response to CVE-2026-416151 (Microsoft Authenticator Information Disclosure Vulnerability), Microsoft started exposing the used Microsoft Authenticator app details as part of the Entra ID Sign-In Logs in the AuthenticationAppDeviceDetails column. The information can be queried via KQL. Vulnerable builds include versions prior to 6.2605.2973 (Android) and 6.8.47 (iOS), which have been patched. You can use the below KQL query to find users with outdated Microsoft Authenticator app versions, which are vulnerable: // https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-41615 let MinimumVersions = datatable( AuthenticatorOperatingSystem: string, PatchedAuthenticatorVersion: string )[ "Android", "6.2605.2973", "Ios", "6.8.47" ]; SigninLogs | where isnotempty(AuthenticationAppDeviceDetails) | extend AuthenticationAppDetails = parse_json(AuthenticationAppDeviceDetails) | extend AuthenticatorOperatingSystem = tostring(AuthenticationAppDetails.operatingSystem) | extend UsedAuthenticatorVersion = tostring(AuthenticationAppDetails.appVersion) // b2b and guest accounts include: {"deviceId":"{PII Removed}"} and no authenticator details | where isnotempty(UsedAuthenticatorVersion) | join kind=leftouter MinimumVersions on AuthenticatorOperatingSystem | extend isVulnerable = parse_version(UsedAuthenticatorVersion) < parse_version(PatchedAuthenticatorVersion) | where isVulnerable | distinct UserPrincipalName, AuthenticatorOperatingSystem, UsedAuthenticatorVersion, isVulnerable The AuthenticationAppDeviceDetails (JSON) column itself consists of the following properties: appVersion clientApp deviceId operatingSystem The clientApp property is really helpful, as we now also have another option to identify users who use the Authenticator light capabilities, available as part of the Outlook app: SigninLogs | where isnotempty(AuthenticationAppDeviceDetails) | extend AuthenticationAppDetails = parse_json(AuthenticationAppDeviceDetails) | extend AuthenticationAppDetailsClientApp = tostring(AuthenticationAppDetails.clientApp) | where AuthenticationAppDetailsClientApp == "Outlook" | distinct UserPrincipalName, AuthenticationAppDetailsClientApp This might be relevant in your environment if you did not disable the Microsoft-managed setting for using the Authenticator light option, which, for example, does not support Conditional Access authentication strengths, passkeys, and app protection policies:

The Microsoft Sentinel SOAR playbook generator has mostly flown under the radar since it entered public preview, so let’s look at what it can do and whether it can replace Logic Apps with something more native. In SecOps conversations, I often hear the same view: Logic Apps are fine, but if you already script or code, they can feel like overhead rather than a productivity boost. Many MSSPs also rely on more flexible tooling such as Azure Functions or compiled code for incident automation. The new Sentinel playbook generator feels more native for Defender XDR and Sentinel integration, and it adds AI on top. Let’s see whether that actually helps. Playbook Generator in Action # You can find the playbook generator in the Unified Security Operations Platform (USOP) under the Sentinel automation blade, via the ‘Playbook Generator ✨’ option. It opens a Visual Studio Code or GitHub Codespaces-style editor with Cline preinstalled for building Python playbooks. Creating a playbook with natural language is straightforward. Cline uses a plan-and-act flow: you describe what you want, then it tests and builds the playbook. For my initial tests, I used the following prompt:

With the Unified Security Operations Platform (USOP), Microsoft introduces Unified Detections - a single detection framework spanning both Sentinel and Defender XDR data. Pair this with native Sentinel Data Lake ingestion for XDR tables, and you have a compelling cost-optimization story. But is it ready for prime time? Let’s dive into the capabilities, current limitations, and what it means for your detection strategy. Architecture Overview # Previous Detection Architecture # In the ‘previous’ architecture, detections were created and managed separately for Microsoft Sentinel and Microsoft Defender XDR. This often led to overhead in terms of ‘where to create the detection’. Let’s take the use-case of IoC (Indicators of Compromise) based detections. Previously, if a security team wanted to create a detection based on IoCs imported via TAXII into Sentinel and the DeviceNetworkEvents table, they would need to ingest the DeviceNetworkEvents data into Sentinel as well and create the detection rule there. Furthermore, many MSSPs leveraged this pattern to create custom detections for their customers across Defender Advanced Hunting Data. As part of the USOP onboarding, the following effects come into play, marked with an asterisk above:

Microsoft 365 Defender and Sentinel provide an IdentityInfo table that contains various information that is helpful for threat hunting and detections. One key piece are also the assigned Entra directory roles for a specific identity. Unfortunately only permanently assigned permissions are covered and in times of Entra Privileged Identity Management (PIM) we should have standing permissions only for non-privileged roles and break-glass accounts. Within this blog post I want to share a few tips and tricks to answer the following questions with Sentinel and a little bit of scripting and KQL: How can we enrich the IdentityInfo table to include eligible assigned directory roles? Which synchronized user accounts have permanent or eligible directory roles assigned? (Spoiler: this should be avoided at all cost) Were eligible directory role assignments not used within the last couple of days and can therefore be removed? As a bonus I also prepared an analytics rule for mass unassignment of highly privileged Entra roles, as this tactic was used for example by the LAPSUS$ group. Gathering PIM eligible Entra Directory Roles # As the IdentityInfo and other available built-in data sources do not include eligible role assignments we need a way to gather the existing role assignments. Fortunately, we can query the following Microsoft Graph endpoint to get the eligible permission assignments:

Microsoft Sentinel Analytic Rules can be shared in both the YAML and ARM format, whereas the ARM format leverages JSON as file type. Within… Microsoft Sentinel Analytic Rules can be shared in both the YAML and ARM format, whereas the ARM format leverages JSON as file type. Within this short post I want to demonstrate an approach that leverages a GitHub Action to automatically build and update the rules in YAML format — so you can just export and update existing rules without any manual conversion effort. Fabian Bader built a cool solution called SentinelARConverter that allows conversion of exported Sentinel Analctic rules from ARM/JSON to YAML (and vice-versa). To emphasize sharing of analytic rules I wanted to adopt also the YAML format without the need to always manually convert the rules. Therefore I incorporated his solution into a GitHub Action. Building a GitHub Action # The automation of this task is fairly simple if you are already familiar with GitHub actions. In case you want to directly see the full pipeline, you can find it here. Otherwise keep on reading. The GitHub action should be triggered as soon as I upload a new Export of an Analytics Rule to the repository. For that, we need to define a folder structure. I maintain the rules within a folder called AnalyticRules. Based on that we can define the triggers for the workflow and filter only for the analytic rules path. This will only run the Action, when a file within that folder get’s changed. Additionally, I added a workflow_dispatch trigger, this allows manual execution of the pipeline.

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.