From signal to owned case
Alert triage is the initial process that determines whether a signal represents a relevant security event or incident, how urgent and severe it is, what additional information is required, and who owns the next action. Triage reduces uncertainty; it is not the complete investigation.
Minimum facts
Confirm detection logic and event authenticity. Identify time, asset, identity, resource, action, data source, scope, expected behavior, threat hypothesis, confidence, and affected security property. Enrich from inventory, change records, identity lifecycle, vulnerability state, and related events.
Prioritize by credible impact, active attacker opportunity, privilege, asset criticality, propagation, data sensitivity, recovery cost, and time sensitivity. Alert source severity alone is not enough.
Decision and handoff
Classify true positive, benign true positive, false positive, duplicate, expected test, or insufficient evidence. Record the reason. Escalate with a clear hypothesis, affected scope, evidence, actions already taken, preservation needs, and decision owner.
Automate repeatable enrichment and low-risk disposition. Keep human review for ambiguous context and high-impact containment.
Failure and residual risk
Analysts can anchor on the alert title and miss a wider incident. Missing inventory or time synchronization can misstate scope. Queue pressure can reward rapid closure. Aggressive automation can suppress a novel attack. Broad collection can expose personal data without improving qualification.
A false positive can show bad logic or bad context. A true positive with no impact can still improve coverage.
Pomerium boundary
Pomerium provides evidence only for requests through configured routes. Triage must add identity-provider, application, endpoint, network, cloud, and change context. A Pomerium denial can show a blocked attempt and does not prove the same identity or attacker had no direct path.
Evaluation checklist
- What hypothesis, asset, identity, action, source, time, scope, and security property does the alert represent?
- Is priority based on local impact and attacker opportunity instead of vendor severity alone?
- Which evidence and related events must be preserved before containment changes state?
- Is disposition reason recorded so detection and context can improve?
- Can queue pressure, automation, missing inventory, or anchoring hide a larger incident?
