Asset and user criticality
How criticality validation works
Two alerts can be identical in content and very different in importance. An anomalous login to a developer’s sandbox account is one situation. The same anomalous login to a Domain Controller A server that responds to security authentication requests in a Windows domain environment. ‘s service account is another. Criticality validation is the strategy that builds this distinction into triage by attaching weights to the entities involved.
The strategy has two pillars. Asset Criticality The level of importance or sensitivity of an asset, which determines the level of protection it requires. describes the business and operational importance of the systems involved. User An individual who interacts with a system, network, or application. criticality describes the privilege level and access scope of the identities involved. Together they produce a risk-weighted view of the alert that the analyst can use to allocate time proportionally.
Asset criticality
Assets are usually classified into tiers like Critical / High / Medium / Low, or scored numerically. The classification reflects three things:
💰 Business value
Revenue impact if the asset is degraded, customer-facing visibility, contractual obligations. Revenue-generating systems and customer-data stores sit at the top of most classification schemes.
📋 Regulatory exposure
Whether the asset stores or processes data covered by HIPAA, PCI DSS, GDPR, SOX, or sector-specific regulation. Compliance-bound systems may demand investigation regardless of where they sit on the tier list.
🔌 Network proximity
An asset that is one hop from a critical system is effectively part of that system for triage purposes. A low-tier workstation that has direct access to the production database is no longer low-tier in practice.
User criticality
User accounts carry their own weight. Two factors define it:
🔑 Privilege level
Standard user, privileged user, service account, executive. Each has a different blast radius if compromised. Service accounts are especially important to model because they often outlive the people who created them.
🌐 Access scope
How many systems and how much data the account can touch. A privileged user with narrow scope is less dangerous than a standard user with wide scope. Both are worth weighting.
Example: identical alerts, very different responses
Two anomalous logins
Two anomaly alerts fire at 03:00 reporting unusual login times. Both alerts look identical in shape. They are not equivalent in priority.
Alert A: anomalous 03:00 login on a workstation belonging to a contractor account, tier-3 asset, no access to production systems. The contractor’s role is to maintain a single sandboxed application.
Alert B: anomalous 03:00 login on a service account whose role includes administrative access to two Domain A unique name or identifier for a system, network, or organization on the internet. controllers and a database tier holding regulated patient data.
Without criticality validation, both alerts compete for the same investigator at the same time. With criticality validation, the analyst’s queue is automatically ordered: Alert B becomes the immediate-action alert, Alert A is queued for review during regular hours unless other signals raise it.
The validation logic is doing two things at once. It is sorting by potential impact, and it is providing the analyst with a defensible justification for the choice. Months later, in a Post-Mortem The structured retrospective an organization runs after a closed incident: timeline, decisions, what worked, what failed, what the team learned. A good post-mortem points back at detection, process, or training gaps. A blameless one names the system, not the person. or an audit, the criticality data attached to the alert at the time of triage is what makes the prioritization decision reviewable.
Implementation requirements
Criticality validation is only as good as the data underneath it. Three sources matter most.
📦 Asset inventory
A CMDB (ServiceNow, custom) or asset platform that knows every system, its classification, its owner, its data sensitivity, and its network position. The inventory should update as the environment changes.
👤 Identity directory
Active Directory, Okta, SailPoint, or equivalent. The directory should know account types, role assignments, group memberships, and the relationships between them. Service accounts should be tagged separately.
📜 Compliance mapping
An explicit map of which assets and data flows are covered by which regulations. The map should be authoritative enough that an analyst can rely on it during triage without consulting legal counsel for every alert.
Operational practice
- Keep inventories current. Stale CMDB data degrades criticality scoring silently. The alerts still fire, but their priorities become wrong without anyone noticing for weeks.
- Define classification criteria clearly. “Critical” should mean the same thing in two different teams’ heads. A short documented definition with examples is worth the time.
- Re-classify during organizational change. Mergers, divestitures, system migrations, and major reorganizations all change criticality in ways that need to flow into the validation logic.
- Integrate compliance triggers explicitly. HIPAA-relevant systems may need investigation even when the tier score would not have demanded it. Make that rule visible in the validation logic rather than relying on analysts to remember it.
Next up
Parsing alerts
With detection mechanisms and validation covered, the next chapter turns to parsing: extracting the metadata that drives the rest of the investigation.
Read parsing