Identity Prioritization: Moving beyond the 'Loudness' Factor in Risk Scoring
Just caught the latest piece on Identity Prioritization and it really hit home. The article argues that most of us are still managing identity risk like a tier-1 helpdesk queue: prioritizing based on who screams the loudest or which accounts failed a control check.
In modern environments, that logic falls apart. We aren't just dealing with human employees anymore; we have SPNs, B2B users, and automated identities. The risk is a compound of control posture, hygiene, and business context. If we just look at 'failed MFA attempts,' we miss the dormant admin account that hasn't logged in in 90 days but still holds Domain Admin rights.
We've started trying to apply some 'risk math' to our SIEM queries to catch these silent killers before they're used for lateral movement. For example, here is a KQL query we use to flag high-privilege accounts with stale sign-in data:
IdentityInfo
| where AssignedRoles contains "Admin" or isPrivileged == true
| join kind=inner (
SigninLogs
| summarize LastLogin = max(TimeGenerated) by UserPrincipalName
) on UserPrincipalName
| extend DaysInactive = datetime_diff('day', now(), LastLogin)
| where DaysInactive > 60
| project UserPrincipalName, AssignedRoles, LastLogin, DaysInactive
| order by DaysInactive desc
This helps us visualize the 'hygiene' aspect. But the article mentions adding 'business intent' to the equation, which is much harder to quantify programmatically.
How are you folks handling this? Are you relying on commercial Identity Threat Detection tools, or has anyone built a reliable custom scoring model that weighs context effectively?
We tried building a custom Python script to weigh 'Business Criticality' against 'Hygiene Score' and feed it back into our SOAR, but maintaining the 'Business Context' data manually was a nightmare. We eventually defaulted to using Entra ID's Identity Protection for the raw risk detection and just strictly enforcing PIM (Privileged Identity Management) for anything tier-1. It doesn't solve the math problem perfectly, but it reduces the attack surface significantly by ensuring standing privileges don't exist for long.
From a red team perspective, this is spot on. We almost exclusively target those 'quiet' service accounts or stale generic credentials (e.g., 'svc_sql_backup') that no one monitors because they don't trigger alerts like a failed MFA does. Detecting intent is hard, but watching for anomalies in usage patterns (like time-of-day or source location) usually catches the abuse faster than just checking password age.
We use a simple logic in our environment: if an account is privileged and inactive for >30 days, it gets automatically disabled. We run this via a scheduled PowerShell task against our AD and Entra ID. It forces the app owners to request reactivation, giving us a chance to review the necessity. It’s crude, but it solves the hygiene issue effectively.
Tanya, to bypass the manual context headache, we prioritize based on "Toxic Combinations" rather than subjective business criticality. We automatically flag high-privilege accounts that have also appeared in recent breach dumps.
If a service account is privileged and its hash is found on the dark web, the risk score skyrockets regardless of activity. We run a nightly check using a simple script:
if account.privileged and account.hashed_creds in leaked_db:
prioritize(account, level="CRITICAL")
This removes the guesswork and catches the quiet threats Tyler mentioned.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access