Security Vendor Generic

Triage a security alert from a product with no dedicated runbook. security-alert-response
owns routing, tiering and the investigation canon; you add the vendor-agnostic extraction
and escalation mechanics. Console actions are technician steps you direct and record; never
invent alert detail.

1. Make the alert answer five questions; record which ones it cannot:
   - WHO: the affected identity, device or tenant, and which client (route per
     security-alert-response, never on name similarity).
   - WHAT: detection type and the vendor's verdict language, copied verbatim.
   - WHEN: event time versus detection time versus alert time — the gaps are exposure
     windows.
   - WHERE: source and target (IP, host, mailbox, app).
   - ACTION TAKEN: what it claims it already did (blocked, quarantined, isolated) versus
     detect-only.

2. Map severity onto the desk's tiers per security-alert-response from the evidence, not the
   label: a vendor "critical" for a blocked commodity event can be Medium; a vendor "low"
   showing detect-only on a credential stealer is not Low. State the mapping and why; never close
   on the vendor's label alone, either way.

3. Work the containment matrix — "the product says blocked" is a claim until confirmed.
   Claimed contained and verifiable → verify in the console or by effect, then investigate
   scope. Claimed but unverifiable → treat as uncontained until the technician confirms.
   Detect-only, allowed, or no action field → treat as live and contain first, per
   edr-detection-runbook for endpoints or compromised-account-containment for identities.

4. Investigate per the generic runbook for the event class: identity → the
   impossible-travel-runbook family; endpoint → edr-detection-runbook; email →
   phishing-triage or quarantine-release-request; exposure feed → dark-web-alert-lifecycle.
   Identity first when the event is a login. Read the vendor's documentation for field
   meanings; mark anything inferred as inferred.

5. When the product itself must answer — unexplained verdict, suspected product fault,
   remediation only the vendor can do — build the escalation package first: alert or
   incident ID and exact timestamps with timezone, tenant identifier, product and agent
   versions, raw alert text, what was checked and ruled out, actions taken with times, and
   the specific question. One complete package in the ticket.

6. Note the decision: the five-question extraction, the severity rationale, the containment
   outcome and the verdict. Classify per soc-classification-tree; write client-facing
   wording per defensive-writing-standard. Exclusions and allowlists are security decisions
   whatever the vendor: narrowest scope, named approver, review date. If this vendor keeps appearing, flag that it deserves its own runbook.

When in doubt do nothing irreversible and escalate.