Threat Detection¶
The central workspace already collects the signals needed to spot most attacks on the platform: Entra ID sign-ins and directory changes, and every subscription's Activity Log. Threat detection turns those logs into alerts that someone acts on.
Status: planned
The data is collected, but no alert rules exist yet. No SIEM is deployed.
Start with alert rules on the workspace¶
Scheduled query alerts on log-platform-prod cost little and cover the highest-value signals without a SIEM. Start with these:
| Detection | Why it matters | Severity |
|---|---|---|
| Any break-glass account signs in | These accounts should only be used in an emergency. Any sign-in is either an incident or a test that should have been announced. | Critical |
A role is assigned at the tenant root or mg-intermediate-root |
This is Tier 0 access being granted | High |
| A directory role is assigned outside PIM | This bypasses the access package and PIM model | High |
| A Conditional Access policy is changed or deleted | Controls may be being weakened | High |
| A diagnostic setting is deleted, or logs stop arriving | Someone may be turning off the audit trail | High |
| A pipeline identity signs in from somewhere unexpected | Pipeline identities should only ever sign in from GitLab | High |
| A credential is added to an app registration | A common way to keep access after a compromise. Platform identities use federated credentials only. | High |
Example queries¶
Break-glass sign-in:
SigninLogs
| where UserPrincipalName startswith "bg-admin-"
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, ResultType
Role assignment written anywhere (filter to the scopes you care about):
AzureActivity
| where OperationNameValue =~ "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE"
| where ActivityStatusValue == "Success"
| project TimeGenerated, Caller, _ResourceId, Properties
Management group activity isn't collected yet
Subscription Activity Logs only record operations inside a subscription. Role assignments and policy changes made at management group scope, including mg-intermediate-root, go to that management group's own activity log. That log needs its own diagnostic setting (supported through the REST API for the Administrative and Policy categories). None is configured today, so the Tier 0 role assignment detection cannot work yet. See GAP-010 in the Exceptions Register.
A secret or certificate added to an application:
AuditLogs
| where OperationName has "Certificates and secrets management"
| project TimeGenerated, InitiatedBy, TargetResources
Tune before you escalate
Run each rule for a week with alerts going to a mailbox only. Then add suppressions for known-good activity, such as planned PIM activations and Lane A applies, before routing alerts to anyone who is paged.
When to add Microsoft Sentinel¶
Sentinel runs on top of a Log Analytics workspace. It adds analytics rule templates, incidents that group related alerts, UEBA (entity behaviour analytics), threat intelligence and automated responses. Consider it when:
- the number of alert rules and their tuning becomes hard to manage by hand;
- there is someone to triage incidents regularly, because a SIEM nobody watches adds cost, not safety;
- compliance requires a SIEM.
Sentinel is billed on data ingested into the workspace, on top of Log Analytics. Check Log Analytics Costs before enabling it on log-platform-prod.
Where alerts go¶
Define one action group for security alerts, with email to the platform and security owners at first and a paging integration later. Keep it separate from operational alerts in Monitoring and Alerting, so security alerts don't get lost among service noise.