● Built for security engineers, SOC analysts, and detection-engineering teams.
Engineering site For your team On-call playbook
On-call playbook

When this fires at 2am. The exact checks. The exact decision. Ninety seconds, end to end.

A per-event runbook so the on-call analyst doesn't have to reason it through from first principles at the worst possible time. For each event type: what it likely means, three checks to run inside the 90-second window, the recommended response, and the escalation criteria. Pin this above the SOC desk; that's where I'd want it.

Most vendor runbooks are useless at 2am: they're written for a quiet conference room, not the chair you actually sit in when the page lands. The format below is built for the chair. If any check below takes longer than 30 seconds, it's broken; flag it and we'll fix it.

device-substituted

P1 · 90-second decision

What it means. The Device DNA on a specific port no longer matches the historical signature for that port. Similarity score below substitution threshold. A swap attack, a hardware refresh nobody told you about, or a firmware change too large to fall under firmware-shift tolerance.

First 90 seconds: three checks
  1. Open change-management. Is there an approved ticket covering this port in the last 24h? If yes → suppress, document, return to queue.
  2. Check the device class. What kind of device should be on this port? AV codec, AV controller, conference camera, dealer board, etc. Cross-reference against the current vendor hint. Mismatch = escalate.
  3. Check similarity score. Score 0.3–0.5 = significant DNA shift. Score <0.3 = almost certainly a different device. Score <0.1 = different vendor entirely.
Recommended response

If checks 1+2 clean and similarity > 0.4: log, lower priority, validate in business hours. If checks fail OR similarity < 0.3: quarantine the port via NAC API now (SOAR playbook handles this if wired). Engage IR on-call lead.

Escalation criteria

Wake the IR lead if: similarity ≤ 0.2, OR vendor mismatch (Crestron → unknown / unknown → known-malicious), OR multiple ports substituted within 30 minutes (coordinated tampering signal).

ndaa-prohibited-detected

P1 / Compliance

What it means. A Layer 1 fingerprint matches a vendor on the NDAA Section 889 banned list with confidence ≥0.85. Vendor relabeling, gray-market substitution, or supply-chain compromise. For federal contractors: an immediate compliance failure regardless of intent.

First 90 seconds: three checks
  1. Confirm the confidence score. ≥0.85 = act. 0.70–0.85 = manual physical inspection required. <0.70 = high-uncertainty; log and queue.
  2. Check the port's regulatory scope. Is this port in scope for NDAA / CMMC / NIST 800-171? CUI rooms, federal contract work, sanctioned-customer-data systems. If yes → escalate immediately.
  3. Cross-reference procurement records. Was this device known to be on the banned list at purchase? (Sometimes yes, exempted use case. Most times no.)
Recommended response

Isolate the port at the NAC. Open a compliance incident. Notify the GRC team and (if federal contractor) the contracts officer. Do not power down, the device may be evidence.

Escalation criteria

Always notify GRC and compliance ownership. Wake legal counsel if: federal contract scope, OR multiple banned-vendor detections in same procurement window (supply-chain compromise signal).

port-topology-changed

P2 · Investigate within shift

What it means. An unmanaged hop has appeared between the wall jack and the endpoint. Usually an unauthorized switch inserted to bridge a personal device, but legitimate causes include planned cable changes, network team adding a small switch, or contractor work.

First 5 minutes: three checks
  1. Change-management. Any approved cable / network change for this port in the last 24h? If yes → suppress.
  2. Check the hop's signature. Is it a known managed switch (corporate stock, in CMDB)? Or unknown? Unknown = elevated.
  3. Walk the floor (if possible). Quick physical inspection identifies most cases in <10 minutes.
Recommended response

If unknown hop on a high-security floor (executive, HR, finance, R&D): isolate the port pending investigation. Elsewhere: log, walk-the-floor by next business day.

Escalation criteria

If the hop is upstream of a port that handles regulated data (PCI, HIPAA, CUI), escalate as if it's a swap. Most insider data-exfiltration setups start with one of these.

device-appeared (unenrolled)

P3 · Daily queue

What it means. A new Device DNA has been observed on a port for more than the grace period (default 4h), but the device is not authenticating via 802.1X and not enrolled in EDR.

First 10 minutes
  1. Check the onboarding queue, is this a planned-but-not-yet-enrolled device?
  2. Check the port's expected device class, AV codec on a corporate VLAN is a mismatch even if expected.
  3. Notify the device owner (use port-to-cost-center mapping if maintained).
Recommended response

Push through onboarding flow. Most resolve as "someone plugged in their personal monitor / dock / printer." Track repeat offenders for policy review.

device-firmware-shift

P4 · Cross-check & log

What it means. DNA similarity dropped into the 0.65–0.85 range, consistent with firmware update, not a swap. Most are routine.

Standard response: Cross-reference with change-management. If an approved firmware rollout is in progress for the device class, attribute and close. If not, investigate as a low-priority swap candidate.

device-silent-extended

P4 · Operational

What it means. A device has been physically connected (link up, drawing power) but producing no upstream traffic for an extended period (default 7 days). Most often a codec in a rarely-used room.

Standard response: Notify the asset / facilities owner. Decide whether to deprioritize the room (deactivate scheduling), repurpose the equipment, or investigate why traffic stopped. Marginal security signal unless followed by a device-firmware-shift on the same port.

SOAR-friendly playbook structure

If you want to wire the response above into your SOAR (Splunk SOAR, Cortex XSOAR, Tines, Microsoft Sentinel automation), every event from CybrIQ carries enough structured fields to drive the entire flow without human judgment for the routine cases:

FieldUse in SOAR logic
eventBranch by event type
severitySet incident priority
similarityAuto-suppress vs. auto-escalate threshold
port + siteLookup scope & ownership tables
mitreTag incident with technique IDs for trend tracking
controlsAuto-create compliance incident if SOC2/PCI/HIPAA
vendor_hint & confidenceDrive NDAA / banned-vendor branch

Most customers automate 60–80% of the playbook so the analyst only sees the cases that genuinely need judgment. See integrations for SOAR-specific templates.

Want to see how this playbook lands in your SOAR?

SOAR templates ship with the pilot for the major NAC and SIEM combinations. Your team adapts the trigger thresholds and routing to match your environment; we walk through the integration during the working session.

Book a working session