Skip to content

Add communication channel integrity gates to IR playbook (#1680) #1691

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
cuph7022 wants to merge 1 commit into
base: main
Choose a base branch
from
+45 −6
Open

Add communication channel integrity gates to IR playbook (#1680) #1691

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 45 additions & 6 deletions skills/incident-response/ir-playbook/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,13 +7,13 @@ description: >
classification, containment decisions, stakeholder notification, or evidence
preservation. Produces an incident response plan with severity determination,
containment decision tree, communication templates, and escalation criteria.
tags: [incident-response, ir, playbook]
tags: [incident-response, ir, playbook, communication-integrity]
role: [soc-analyst, security-engineer, vciso]
phase: [respond, recover]
frameworks: [NIST-SP-800-61r2, SANS-IH]
difficulty: intermediate
time_estimate: "30-60min"
version: "1.0.1"
version: "1.1.0"
author: unitoneai
license: MIT
allowed-tools: Read, Grep, Glob
Expand Down Expand Up @@ -60,6 +60,7 @@ Before beginning, gather or confirm the following. Mark each item as obtained or
- [ ] **Business context** -- What business functions do the affected systems support? Revenue impact, customer impact, regulatory exposure.
- [ ] **Current state** -- Is the attack ongoing, contained, or resolved? What actions have already been taken?
- [ ] **Existing IR plan** -- Does the organization have a documented IR plan, designated IR team, and established communication channels?
- [ ] **Communication channel trust** -- Which email, chat, bridge, paging, ticketing, endpoint-management, and IR-retainer channels are trusted, degraded, or potentially monitored by the adversary?
- [ ] **Regulatory obligations** -- Applicable breach notification requirements (GDPR 72-hour rule, HIPAA, state breach notification laws, SEC 4-day rule, PCI DSS).
- [ ] **Third-party dependencies** -- Managed security providers (MSSP/MDR), cyber insurance carrier notification requirements, external IR retainer.

Expand Down Expand Up @@ -110,6 +111,35 @@ Verify that the foundational elements for incident response are in place. If gap
| Regulatory notification requirements documented | [ ] | GDPR, HIPAA, state laws, SEC |
| Evidence storage with chain-of-custody procedures | [ ] | |

#### Step 1.1: Communication Channel Integrity Gate

For SEV-1 and SEV-2 incidents, do not assume normal business communications are safe. Record evidence that the IR team assessed each coordination channel before using it for containment orders, stakeholder notifications, or regulatory decisions.

**Channel integrity review:**

| Channel | Trust Status | Evidence Required | Decision |
|---------|--------------|-------------------|----------|
| Corporate email | [Trusted / Degraded / Suspect] | Mailbox access review, forwarding rule check, audit-log availability | [Use / Monitor only / Do not use] |
| Chat or collaboration platform | [Trusted / Degraded / Suspect] | Admin/audit access, channel membership, export or retention status | [Use / Switch / Preserve only] |
| Ticketing or case-management system | [Trusted / Degraded / Suspect] | Queue permissions, automation/webhook review, attacker visibility assessment | [Use / Restrict / Freeze] |
| Phone bridge or paging path | [Trusted / Degraded / Suspect] | Participant verification, dial-in control, bridge recording decision | [Use / Rotate / Replace] |
| Endpoint-management or remote-admin channel | [Trusted / Degraded / Suspect] | Tool compromise check, operator approval path, command logging | [Use / Disable / Isolate] |
| External IR-retainer portal | [Trusted / Degraded / Suspect] | Named approver, portal access list, evidence upload handling | [Use / Escalate / Hold] |

**Finding IDs:**

| ID | Condition | Severity |
|----|-----------|----------|
| IR-COMMS-01 | SEV-1/SEV-2 response continues on a channel the adversary can plausibly monitor without documented risk acceptance. | SEV-1 |
| IR-COMMS-02 | No timestamped trigger or named approver exists for switching to out-of-band communications. | SEV-2 |
| IR-COMMS-03 | War-room, bridge, ticket, or retainer-portal access lacks participant verification or least-privilege membership evidence. | SEV-2 |
| IR-COMMS-04 | Containment orders, legal approvals, customer notices, or regulator communications are not preserved in a trusted record. | SEV-2 |
| IR-COMMS-05 | The team fails to review attacker visibility into mailboxes, chat exports, IdP logs, ticket queues, or endpoint-management tools. | SEV-2 |
| IR-COMMS-06 | High-impact containment or public/regulatory communication proceeds without named approval evidence. | SEV-2 |
| IR-COMMS-07 | Return-to-normal criteria are missing before resuming internal communication channels. | SEV-3 |

Document the chosen channel, trigger time, approver, participants, preservation location, and return-to-normal criteria in the final report.

### Phase 2: Detection and Analysis (NIST) / Identification (SANS)

#### Step 2.1: Incident Classification
Expand Down Expand Up @@ -367,7 +397,7 @@ Produce the incident response report with these exact sections:
```markdown
## Incident Response Report: [Incident ID]
**Date:** [YYYY-MM-DD]
**Skill:** ir-playbook v1.0.0
**Skill:** ir-playbook v1.1.0
**Frameworks:** NIST SP 800-61 Rev 2, SANS Incident Handler's Handbook
**Incident Commander:** [Name or "Unassigned -- assign immediately"]

Expand Down Expand Up @@ -407,6 +437,11 @@ and recommended immediate actions. Lead with the most critical fact.]
- **Recovery Actions:** [List of restoration actions taken or planned]
- **Enhanced Monitoring:** [Description of increased monitoring posture]

### Communication Channel Integrity
| Channel | Trust Status | Evidence | Decision | Approver |
|---|---|---|---|---|
| [Email / Chat / Ticketing / Phone / Paging / IR portal] | [Trusted / Degraded / Suspect] | [Audit log, membership review, forwarding rule check, recording/export path] | [Use / Switch / Restrict / Preserve only] | [Name / Role] |

### Stakeholder Notifications
| Stakeholder | Notified | Timestamp | Method |
|---|---|---|---|
Expand Down Expand Up @@ -456,15 +491,19 @@ Responders under pressure often prioritize containment speed over evidence prese

Communicating about the incident over channels the attacker may be monitoring (corporate email, Slack, Teams) can tip off the adversary, prompting them to accelerate data exfiltration, deploy destructive payloads, or cover their tracks. For SEV-1 and SEV-2 incidents, use out-of-band communication channels (personal phones, dedicated secure messaging, physical meetings) until the attacker's access to communication systems has been assessed and ruled out.

### Pitfall 3: Failing to Establish a Clear Incident Commander
### Pitfall 3: Treating Out-of-Band as a Label Instead of Evidence

Simply saying "use out-of-band communications" is not enough during a severe incident. The team must prove why the selected channel is trusted, who can access it, whether the adversary can monitor or alter it, where decisions are preserved, and when normal channels can safely resume. Without that evidence, containment orders and stakeholder notifications can be exposed or disputed.

### Pitfall 4: Failing to Establish a Clear Incident Commander

Without a designated incident commander, response efforts become fragmented. Multiple responders may take conflicting actions (one isolating a system while another is collecting evidence from it), communication breaks down, and stakeholder notifications are missed or duplicated. Assign an incident commander at the start of every SEV-1/SEV-2 incident, with clear authority over response actions and communication.

### Pitfall 4: Declaring Recovery Before Confirming Eradication
### Pitfall 5: Declaring Recovery Before Confirming Eradication

Reconnecting systems to the network before thoroughly removing all persistence mechanisms, backdoors, and compromised credentials results in re-compromise -- often within hours. Attackers routinely deploy multiple persistence mechanisms (scheduled tasks, web shells, new user accounts, modified startup scripts, implanted SSH keys). Validate eradication through IOC scanning, behavioral monitoring, and integrity verification before transitioning to recovery.

### Pitfall 5: Neglecting Regulatory Notification Deadlines
### Pitfall 6: Neglecting Regulatory Notification Deadlines

Breach notification regulations impose strict timelines that begin running at the moment of discovery, not at the conclusion of investigation. GDPR requires notification within 72 hours of becoming aware of a personal data breach. Missing these deadlines exposes the organization to regulatory penalties independent of the incident itself. Track notification deadlines from the moment a potential data breach is identified, and involve legal counsel early.

Expand Down