Alert Severity and Response Authority Are Different Decisions

A critical alert can be wrong.

It can also be correct about the activity and wrong about the response. A detection may accurately identify repeated authentication failures, but disabling the account could interrupt a service. A network rule may correctly identify traffic to a suspicious address, but blocking that address could cut off a shared resolver, content delivery network, or security service. A runtime rule may accurately report a shell in a container, but terminating the workload could destroy volatile evidence or interrupt patient care, manufacturing, or another safety-relevant process.

Severity describes the possible consequence of an observation. It does not grant permission to act.

I separate four decisions:

1. Severity: How harmful could the observed condition be if it is real?
2. Confidence: How strongly does the available evidence support the detection and its interpretation?
3. Asset context: What is this target, who owns it, what does it support, and what would a response disrupt?
4. Response authority: Which actions may this workflow take now, against this target, with what approval and rollback?

Combining those values into one score is convenient for sorting. It is dangerous for authorization.

This distinction follows the broader approach in Cybersecurity Architect's Handbook, Second Edition: architecture connects risk and control decisions to operating authority, trust boundaries, and evidence. A SOAR platform does not get to invent authority because a detection rule emitted the number 15.

Severity answers only one question

Severity is usually an estimate of potential impact. It can consider the behavior, affected security objective, scope, persistence, attacker capability, and plausible consequence.

A severity rubric might look like this:

severity:
  critical:
    criteria:
      - confirmed destructive activity
      - active compromise of a privileged control plane
      - material safety or enterprise-wide availability risk
  high:
    criteria:
      - likely unauthorized privileged access
      - execution with material data or service impact
      - credible lateral movement on a sensitive segment
  medium:
    criteria:
      - suspicious behavior requiring timely analyst review
      - policy violation with bounded impact
  low:
    criteria:
      - weak signal retained for correlation
      - routine denied activity with no demonstrated effect

That rubric says nothing about whether an endpoint may be isolated. It does not know whether the source is a domain controller, a developer laptop, a decoy, a shared jump host, or a production database. It does not know whether the rule is newly deployed or has a strong history of precision.

Severity also should not be copied blindly from a tool. Wazuh rule levels, Sigma level, Falco priorities, OpenSearch Security Analytics severity, and a case-management severity can be mapped, but the mapping is a local policy decision. Sigma includes falsepositives and level fields in its rule format. Those fields help communicate rule intent. They do not establish an organization's authority to disable an account or block an address.

Confidence belongs beside severity, not inside it

Confidence measures evidence quality. I treat it as an explicit field with reasons.

{
  "detection_id": "det-20260917-00412",
  "severity": "critical",
  "confidence": {
    "value": 0.62,
    "band": "medium",
    "reasons": [
      "rule matched two independent telemetry sources",
      "source identity is authenticated",
      "process ancestry is incomplete",
      "indicator age exceeds local high-confidence threshold"
    ]
  }
}

A decimal score is not useful unless its inputs and calibration are defined. I prefer a small band such as low, medium, high, and confirmed, with machine-readable reasons and the underlying evidence references. If a model produces the score, retain the model and prompt version, source inputs, and any policy threshold applied after inference. Model output is advisory unless a separate authorization policy says otherwise.

Confidence can rise through corroboration: a host event, identity event, and network observation that share stable identities and a credible time relationship. It can fall because of stale threat intelligence, incomplete fields, an untrusted forwarding path, a rule under evaluation, clock skew, or a known benign administrative pattern.

False positives are evidence that a detection or its local assumptions need work, not just annoying alerts. I record them with a reason code:

false_positive_disposition:
  code: authorized-administration
  detection_revision: sigma:3f9a8c2
  asset_id: vm-0042
  evidence:
    - change_record: CHG-2026-0917-12
    - operator_identity: user-184
  expires_at: 2026-10-17T00:00:00Z
  owner: detection-engineering

A disposition should narrow future suppression by rule revision, asset, principal, command, time, or approved change. A broad exception such as ignore powershell.exe can erase the very behavior the rule was meant to expose. Exceptions require owners and expiry because environments change and administrative behavior gets copied.

Asset context changes the response

An IP address is not enough asset context. Addresses move, proxies concentrate many users, and load balancers represent services rather than one host.

I want the response decision to see a stable asset identity and current context:

{
  "asset": {
    "asset_id": "cmdb:prod-db-07",
    "hostname": "prod-db-07.example.internal",
    "environment": "production",
    "business_service": "order-processing",
    "criticality": "tier-0",
    "data_classification": ["confidential", "regulated"],
    "owner": "database-operations",
    "response_profile": "tier0-stateful-server",
    "maintenance_state": "normal",
    "last_inventory_at": "2026-09-17T12:42:00Z"
  }
}

Freshness matters. A workflow must not use a six-month-old CMDB record to decide that an address belongs to a disposable test machine. If required context is missing or stale, authority should decrease. Missing context is not permission to assume the least disruptive case.

The response profile should state operational constraints:

response_profiles:
  tier0-stateful-server:
    automatic:
      - collect_process_snapshot
      - collect_network_connections
      - preserve_relevant_logs
    approval_required:
      - isolate_host
      - stop_process
      - disable_service_account
    prohibited:
      - power_off
      - delete_file
      - revoke_cluster_identity
    approvers:
      - incident-commander
      - database-operations-oncall
    rollback_required: true

That profile prevents a general endpoint playbook from treating a stateful production server like a replaceable workstation.

Asset context also includes identity and dependency context. A user account may be a human, service principal, emergency account, or shared legacy identity. A domain may front many unrelated tenants. A hash may identify an approved internal tool. Before acting, the system needs enough context to understand both the suspected harm and the harm its own action can cause.

Response authority is an access-control decision

Response authority answers who or what may perform a specific action on a specific target under specific conditions.

I model it separately from detection content:

response_authority:
  policy_version: response-policy.v7
  subject: workflow:contain-suspicious-endpoint
  action: endpoint.isolate
  target_scope:
    asset_class: managed-workstation
    environment: [development, corporate]
    exclusions:
      - break-glass-endpoint
      - executive-travel-device
      - active-incident-evidence-hold
  conditions:
    minimum_confidence: high
    accepted_severity: [high, critical]
    asset_context_max_age_seconds: 900
    require_two_telemetry_sources: true
    require_reversible_action: true
  approval:
    mode: single-human
    roles: [soc-tier2, incident-commander]
    timeout_seconds: 600
  rollback:
    action: endpoint.release_isolation
    verification_required: true

The workflow identity should have no broader permission than this policy requires. A read-and-enrich workflow does not need an endpoint-isolation credential. An isolation action does not need permission to delete a host or change identity policy. Credentials should be scoped by environment, target group, and action where the platform supports it.

Wazuh Active Response can run scripts when alerts meet configured criteria, and its documentation explicitly warns that poorly implemented response rules can increase endpoint vulnerability. The safe design question is not whether Wazuh, Shuffle, or StackStorm can execute a command. It is whether the command is authorized for this alert, target, and moment.

A practical authority matrix

I use an authority matrix that security operations, system owners, and incident leadership can review together.

The matrix is intentionally conservative. Read-only enrichment and case creation are usually easier to authorize. Evidence collection belongs in a separate authority class and becomes automatic only when a tested profile proves bounded source impact, authorized data scope, resource ceilings, abort behavior, and safe temporary-tool cleanup. Blocking, disabling, isolation, process termination, and deletion can affect availability, evidence, or safety. Their authority needs a stronger policy.

The matrix also distinguishes a default from an exception. A preapproved automatic IP block may be reasonable at an internet edge for a narrow, short-lived rule with protected allowlists and tested rollback. The same action is not automatically reasonable on an internal core firewall.

Dry runs are an operating mode, not a comment

Every disruptive playbook should support a real dry-run mode that resolves targets, evaluates policy, and renders the exact planned actions without calling the enforcement API.

{
  "mode": "dry-run",
  "decision": "approval-required",
  "policy_version": "response-policy.v7",
  "detection_id": "det-20260917-00412",
  "target": "cmdb:prod-db-07",
  "proposed_actions": [
    {
      "action": "endpoint.isolate",
      "provider_target_id": "agent-0091",
      "current_state": "connected",
      "desired_state": "isolated"
    }
  ],
  "blocked_reasons": ["target profile requires database-operations-oncall approval"],
  "rollback_plan": "endpoint.release_isolation agent-0091"
}

A useful dry run checks current state and authorization. It does not print a hard-coded command while skipping target lookup. It should fail if the provider target is ambiguous, context is stale, a required approver group is unavailable, or rollback cannot be constructed.

Dry-run output becomes approval evidence. The approved payload should be cryptographically bound, or at least hash-bound, to the policy version, target, action, parameters, and expiry. If the target or action changes after approval, approval must be requested again.

Approval gates need identity, scope, and expiry

A button labeled Approve is not a complete gate.

An approval record needs:

approval:
  request_id: apr-20260917-7712
  requester: workflow:contain-suspicious-endpoint
  approver: user:incident-commander-14
  approver_role: incident-commander
  action_digest: sha256:<digest-of-versioned-canonical-request>
  digest_profile: response-action-jcs-v1
  approval_nonce: <single-use-nonce>
  authenticated_session: <approval-session-id>
  target: cmdb:prod-db-07
  decision: approve
  reason: active-lateral-movement-investigation
  issued_at: 2026-09-17T14:20:00Z
  expires_at: 2026-09-17T14:30:00Z
  single_use: true

StackStorm Inquiries can pause a workflow and ask for approval or other information before continuing. Shuffle workflows provide triggers, conditions, variables, and app actions that can implement a similar orchestration boundary. The product mechanism is only part of the control. The policy still needs to verify approver role, scope, freshness, and single use.

Approval should fail closed on timeout. It should not turn a missing response into implicit consent. Emergency procedures can define a different path, but that path needs explicit roles, stronger logging, and retrospective review.

Separation of duties matters most for high-impact actions. The rule author should not silently grant a workflow new production permissions. Detection review, response-policy review, credential provisioning, and incident approval can be separate gates even when a small team assigns more than one role to the same person.

Idempotency prevents response from becoming the incident

Alerting and orchestration are usually at least once. Retries, reconnects, duplicate events, and rule overlap happen. Every action needs an idempotency key and a current-state check.

response_key = sha256(JCS({
  "schema": "response-request.v1",
  "request_id": immutable_action_request_id,
  "tenant": provider_tenant_id,
  "target": provider_target_id,
  "desired_state": desired_state,
  "incident_lineage": incident_id,
  "policy_version": policy_version
}))

Expiry is stored and enforced separately. Every retry of the same request reuses this key, including retries that cross a time-window boundary. The approval service authenticates the approver and protects the canonical digest; a caller-supplied hash beside a mutable payload is not approval evidence.

Before execution, the workflow asks whether the same key already succeeded, remains in progress, or failed in a retryable way. It also reads current provider state. If the endpoint is already isolated by this incident, a retry records already_satisfied rather than opening another action. If it is isolated for another reason, the workflow must not claim ownership of that state or release it during rollback.

Case creation needs the same discipline. TheHive alerts provide a structure for bringing event information and observables into an investigation workflow. A stable source reference should update or correlate with the existing alert according to policy rather than create a new case every time a collector retries.

Idempotency does not mean hiding every duplicate. Preserve execution attempts, decisions, provider receipts, and errors. The objective is to avoid repeating the side effect while retaining evidence that retries occurred.

Rollback is part of authorization

I do not authorize a disruptive action until I know how to reverse it or can explain why reversal is impossible.

Rollback should capture prior state before change:

{
  "action": "network.block_ip",
  "target": "203.0.113.44",
  "pre_state": {
    "object_present": false,
    "policy_revision": "fw-rev-1882"
  },
  "applied_state": {
    "object_id": "block-9014",
    "expires_at": "2026-09-17T15:30:00Z",
    "policy_revision": "fw-rev-1883"
  },
  "rollback": {
    "remove_object_id": "block-9014",
    "do_not_remove_by_value_only": true,
    "verify_revision_after": true
  }
}

The object ID matters. Removing every rule that mentions the same address could delete another incident's block. Rollback should reverse only the state this execution owns.

A time-to-live is useful for temporary containment, but TTL is not a replacement for rollback verification. The workflow should confirm that the object expired, the enforcement point accepted the change, and intended connectivity returned. If rollback fails, escalate it as an operational incident.

Some actions are not fully reversible. Password rotation invalidates existing secrets. Process termination can lose state. File deletion may be permanent. Those actions need higher approval, backup or quarantine where possible, and an honest statement of residual impact.

Evidence has to follow the decision and the effect

NIST SP 800-61 Revision 3 places incident response within cybersecurity risk management rather than treating it as an isolated technical activity. NIST SP 800-53 includes control families for incident response, audit, access control, configuration management, and system monitoring that together support governed response operations. The practical implication is that evidence must cover both the decision and the effect.

For each response, I retain:

• the original event and normalized detection
• detection rule ID and revision
• severity with rubric version
• confidence value, reasons, and supporting evidence
• asset and identity context with collection times
• evaluated response-policy version
• dry-run plan and exact action hash
• approval or denial with actor, role, scope, reason, and expiry
• workflow execution and idempotency key
• provider request and response IDs
• enforcement evidence from the target boundary
• pre-action and post-action state
• rollback result
• case or alert reference

A successful API response is not enforcement evidence. For an endpoint isolation, verify the endpoint's network state while preserving the management channel required for release. For a firewall block, test the intended flow and inspect rule-hit telemetry. For account disablement, read back directory state and account sessions. For a case creation, read back the case or alert from the case-management system.

Evidence should also preserve denials and no-action decisions. When a critical alert is not allowed to isolate a tier-0 server because confidence is medium and context is stale, that is a successful control decision, not an automation failure.

Open-source components can support the separation

The architecture does not depend on one product bundle.

• Wazuh can produce detections and invoke Active Response, but its execution path should be constrained by explicit response policy and target scope.
• Graylog and OpenSearch can retain and query the event, context, and decision evidence.
• Sigma can express portable detection intent, including level and false-positive guidance, while deployment-specific policy controls authority.
• Falco can provide runtime detections whose priority is mapped into the local severity model.
• ElastAlert 2 can query indexed data and route notifications, but notification routing should not imply enforcement permission.
• Shuffle can orchestrate enrichment, approvals, action calls, and evidence collection through workflows.
• StackStorm can implement event-driven actions and explicit human pauses through Inquiries.
• TheHive can hold alerts, observables, cases, tasks, and response evidence.

The important interface is the decision contract between them. Each component should receive only the data and credentials needed for its role. The detector emits facts and assessment. The policy engine evaluates authority. The orchestrator executes the authorized action. The case system preserves the investigation record. The enforcement platform proves the resulting state.

A small environment may combine those roles in fewer components. It should not combine the decisions conceptually.

Keep the final rule simple

I use this operating rule:

Severity prioritizes attention.
Confidence qualifies belief.
Asset context explains consequence.
Response policy grants authority.
Evidence proves the decision and effect.

A critical, low-confidence detection on a tier-0 asset may justify immediate paging and evidence collection while prohibiting automatic containment. A high-confidence, high-severity detection on a managed workstation may qualify for preapproved isolation. A medium-severity event tied to a confirmed compromised service identity may require faster action than its initial severity suggests because the asset context changes the consequence.

Those outcomes are not contradictions. They are what happens when the SOC stops asking one alert field to make four different decisions.

Automation is valuable when it makes a bounded, reviewable decision faster and executes it consistently. It becomes dangerous when urgency is mistaken for permission. I want the system to move quickly, but only with the authority it was deliberately given.