Transform Identity Risk Management: Move Beyond Ticket Queues to Strategic Risk Mathematics
The Flaw in Traditional Identity Prioritization
In the fast-paced world of cybersecurity, security teams often fall into a familiar trap: prioritizing identity-related issues the same way they handle IT support tickets. First come, first served. Loudest complaints first. Whatever triggers an automated alert. This approach worked reasonably well when organizations primarily dealt with human employees who had been fully onboarded and established identities.
But the modern enterprise has changed dramatically. The landscape now includes automated bots, temporary contractors, third-party vendors, cloud service accounts, machine identities, and IoT devices. The days of a predominantly human, fully-onboarded workforce are gone, and with them, the effectiveness of traditional ticket-based prioritization.
When you apply a volume-first or alert-first model to today's complex identity ecosystem, critical risks can slip through the cracks while your team chases noisy but less dangerous alerts. This isn't just an efficiency problem—it's a fundamental security vulnerability that sophisticated attackers actively exploit.
Understanding Modern Identity Risk as a Compound Variable
Modern identity risk isn't a single-dimensional problem. It's created by a compound of multiple factors that interact in complex ways:
-
Control Posture: The strength and configuration of security controls applied to an identity. Are MFA requirements enforced? Are privilege controls properly implemented? What's the current state of access controls?
-
Identity Hygiene: How well-maintained and "clean" is the identity? Are there stale accounts, dormant credentials, or inconsistent access patterns? Has the identity been properly deprovisioned when no longer needed?
-
Business Context: What role does this identity play in the organization? Does it have access to critical systems, intellectual property, or sensitive data? Would its compromise significantly impact business operations?
-
Intent: What is the identity attempting to do? Are the actions consistent with expected behavior? Are there signs of malicious intent or data exfiltration?
When any single one of these factors shows weakness, it creates potential risk. When multiple factors align negatively, you have a high-risk situation that demands immediate attention. Traditional ticket-queue systems simply cannot capture or calculate this compound risk.
Why Volume-Based Approaches Fail in Modern Environments
Consider two scenarios that might appear in your security monitoring:
Scenario A: A help desk employee with limited access privileges triggers 50 failed login attempts over a week. This generates numerous alerts and occupies significant attention in a volume-based queue.
Scenario B: A third-party service account with administrative access to your customer database makes a single anomalous API call at 3 AM on a Sunday, downloading a large volume of data. This generates perhaps one alert or might even slip through unnoticed.
In a traditional priority-by-volume model, Scenario A receives immediate attention while Scenario B might be ignored or delayed. Yet Scenario B represents a far greater organizational risk. The compound of high privilege access (control posture), potential lack of oversight (hygiene), access to critical data (business context), and anomalous timing (intent) creates a dangerous situation that requires immediate investigation.
This example illustrates why prioritizing by "what failed a control check" or "what's generating the most alerts" can lead security teams to focus on the wrong problems while genuine threats operate in the background.
Executive Takeaways
For security leaders looking to modernize their identity risk management approach:
-
Risk Scoring Must Replace Queue Positioning: Implement identity risk scoring that accounts for the compound factors of control posture, hygiene, business context, and intent. This transforms prioritization from a manual queue exercise into a calculated risk-based decision.
-
Visibility Across All Identity Types: Your risk model must encompass human users, machine identities, service accounts, and third-party access. Each type presents different risk factors that need specific consideration.
-
Dynamic Prioritization is Essential: Risk scores should be calculated in near real-time, reflecting changing conditions like unusual access patterns, changes in business context, or evolving threat landscapes.
-
Integrate Business Impact into Security Decisions: Identity risk cannot be assessed in isolation. Understanding the business value of protected resources and the operational impact of potential compromise is crucial for effective prioritization.
-
Shift from Reactive to Proactive: Moving from alert-chasing to risk-based prioritization enables your team to address potential threats before they materialize into incidents.
Implementing Risk-Based Identity Prioritization
To implement a mathematical approach to identity risk, consider these specific steps:
1. Develop a Risk Scoring Framework
Create a scoring model that weighs the four key risk factors:
# Example Risk Scoring Framework
risk_factors:
control_posture:
mfa_enabled: 0.0 # No additional risk
mfa_disabled: 0.3 # Moderate risk
no_access_controls: 0.7 # High risk
identity_hygiene:
active_regular_use: 0.0
irregular_use: 0.3
dormant_gt_90_days: 0.5
dormant_gt_180_days: 0.9
business_context:
no_critical_access: 0.0
limited_critical_access: 0.4
admin_access: 0.7
privileged_access: 1.0
intent:
normal_behavior: 0.0
minor_anomaly: 0.3
significant_anomaly: 0.6
confirmed_malicious: 1.0
# Risk calculation
risk_score = (control_posture + identity_hygiene + business_context + intent) / 4
2. Query for High-Risk Identity Events
This KQL query can help identify high-risk identity activity in Microsoft Sentinel or Defender:
// Identify high-risk identity events
IdentityInfo
| join kind=inner (
SigninLogs
| where ResultType != 0
| summarize FailedAttempts=count(), LastFailed=max(TimeGenerated) by UserPrincipalName
) on UserPrincipalName
| extend
RiskScore = iff(isnotempty(FailedAttempts), FailedAttempts * 0.2, 0) +
iff(UserType == "Guest", 0.3, 0) +
iff(AccountEnabled == false, 0.5, 0)
| where RiskScore > 0.6
| project UserPrincipalName, RiskScore, FailedAttempts, LastFailed, UserType, AccountEnabled
| order by RiskScore desc
3. Automate Risk Assessment with PowerShell
This PowerShell script can help assess identity hygiene and calculate risk factors:
# Assess identity hygiene for risk calculation
function Get-IdentityRiskAssessment {
param(
[string]$UserId
)
$user = Get-MgUser -UserId $UserId
$signInActivity = Get-MgUserSignInActivity -UserId $UserId
# Calculate inactivity days
$lastSignIn = if ($signInActivity.LastSignInDateTime) {
[DateTime]$signInActivity.LastSignInDateTime
} else { $null }
$inactivityDays = if ($lastSignIn) {
(Get-Date).Subtract($lastSignIn).Days
} else { 999 }
# Determine risk factors
$riskFactors = @{
InactiveDays = $inactivityDays
MFAEnabled = -not (Get-MgUserAuthenticationMethod -UserId $UserId |
Where-Object { $_.AdditionalProperties -eq 'MicrosoftAuthenticator' })
GuestAccount = $user.UserType -eq 'Guest'
AccountEnabled = $user.AccountEnabled
}
# Calculate risk score
$riskScore = 0
$riskScore += if ($riskFactors.MFAEnabled) { 0.3 } else { 0 }
$riskScore += if ($riskFactors.GuestAccount) { 0.2 } else { 0 }
$riskScore += if (-not $riskFactors.AccountEnabled) { 0.4 } else { 0 }
$riskScore += switch ($riskFactors.InactiveDays) {
{$_ -gt 180} { 0.5 }
{$_ -gt 90} { 0.3 }
{$_ -gt 30} { 0.1 }
default { 0 }
}
return [PSCustomObject]@{
UserId = $user.UserPrincipalName
RiskScore = $riskScore
RiskFactors = $riskFactors
}
}
# Get risk assessment for all users
Get-MgUser -All | ForEach-Object { Get-IdentityRiskAssessment -UserId $_.Id } |
Sort-Object RiskScore -Descending |
Select-Object -First 20
4. Establish Response Thresholds and Playbooks
Define risk thresholds that trigger specific responses:
# Risk Response Threshold Configuration
# Format: RISK_SCORE:ACTION:NOTIFICATION:ESCALATION_TIME
# RISK_SCORE: 0.0-1.0
# ACTION: monitor|investigate|contain|disable
# NOTIFICATION: none|email|pager|immediate
# ESCALATION_TIME: hours until escalation
cat <<EOF > /etc/security/risk_response_config.txt
0.0-0.3:monitor:none:0
0.3-0.5:investigate:email:24
0.5-0.7:contain:pager:4
0.7-1.0:disable:immediate:1
EOF
# Function to determine response based on risk score
determine_response() {
local risk_score=$1
while read -r line; do
threshold=$(echo "$line" | cut -d: -f1)
action=$(echo "$line" | cut -d: -f2)
notification=$(echo "$line" | cut -d: -f3)
escalation=$(echo "$line" | cut -d: -f4)
min=$(echo "$threshold" | cut -d- -f1)
max=$(echo "$threshold" | cut -d- -f2)
if (( $(echo "$risk_score >= $min && $risk_score < $max" | bc -l) )); then
echo "$action:$notification:$escalation"
return
fi
done < /etc/security/risk_response_config.txt
}
Mitigation Strategies
To effectively implement a risk-based identity prioritization model:
-
Inventory All Identities: Begin with a comprehensive inventory of all identity types in your environment, including human users, service accounts, machine identities, and third-party access. You cannot calculate risk for identities you don't know exist.
-
Map Business Context: Document the business importance of systems and data, and map this to identities that have access. This provides the critical business context needed for accurate risk calculation.
-
Implement Continuous Monitoring: Establish continuous monitoring of all identity activities, not just those that trigger alerts. This baseline data is essential for identifying intent and detecting anomalies.
-
Deploy Automated Risk Scoring: Implement automated risk scoring tools that can continuously calculate identity risk based on the compound factors. Manual calculations cannot scale to modern enterprise environments.
-
Define Response Playbooks: Create clear playbooks tied to risk scores, ensuring consistent and appropriate responses based on calculated risk rather than queue position or alert volume.
-
Regularly Review and Adjust: Risk factors and business priorities change over time. Regularly review and adjust your risk scoring model to ensure it reflects current threats and business needs.
-
Train Security Teams: Transitioning from a queue-based to a risk-based model requires training. Ensure your security team understands the mathematical approach and can interpret risk scores effectively.
-
Integrate with SIEM and SOAR: Connect your identity risk scoring with your SIEM and SOAR platforms to enable automated responses and ensure risk-based prioritization across all security operations.
The future of identity security lies not in managing larger queues of alerts, but in implementing sophisticated risk calculations that direct security attention where it matters most. By treating identity prioritization as a mathematical problem rather than a backlog management exercise, organizations can dramatically improve their security posture while making more efficient use of limited security resources.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.