diff --git a/docs/pages/incident-management/communication-strategies.mdx b/docs/pages/incident-management/communication-strategies.mdx index fe7edb8b6..1ced09217 100644 --- a/docs/pages/incident-management/communication-strategies.mdx +++ b/docs/pages/incident-management/communication-strategies.mdx @@ -1,9 +1,16 @@ --- title: "Incident Communication Strategies | SEAL" -description: "Establish secure communication channels for incident response. Appoint spokespersons, develop pre-approved notification templates, and provide regular stakeholder updates during security incidents." +description: "Establish secure incident channels, appoint primary and backup spokespersons, and use pre-approved templates to update stakeholders on a fixed cadence." tags: - Security Specialist - Operations & Strategy +contributors: + - role: wrote + users: [] + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter } from '../../../components' @@ -13,6 +20,10 @@ import { TagList, AttributionList, ContributeFooter } from '../../../components' +> ๐Ÿ”‘ **Key Takeaway**: Designate a single spokesperson and fixed update cadence before +> chaos starts. Ship only confirmed facts; "no new information" is a valid status update +> that reduces speculation damage. + Communication during an incident can be very hard, as people are often scrambling to fix the issue at hand. Nonetheless, from a team memberโ€™s, outsiderโ€™s, or observerโ€™s point of view, communication is very important to be able to understand what's happening, and it also provides some time to reflect and think about what is going on. With that said, providing @@ -20,7 +31,7 @@ information before confirming that it's accurate, can often be very negative and have a person designated for communication during an incident, and that updates are sent out on a fixed schedule, and it can often be that the update is that there is currently no new information available. -## Best Practices +## Best practices 1. Define and establish secure communication channels for incident response teams. Use [encrypted messaging apps](/encryption/communication-encryption) @@ -37,6 +48,13 @@ Avoid speculation and provide factual information. For message templates and example public updates, see [Incident Response Template: Communications](/incident-management/incident-response-template/communications). +## Further reading + +- [Incident Management overview](/incident-management/overview): how the pages of this framework fit together +- [Communications template](/incident-management/incident-response-template/communications): ready-to-adapt holding statements and updates +- [Community Management](/community-management/overview): the channels these messages go out on +- [Incident Detection and Response](/incident-management/incident-detection-and-response): what triggers a communication + --- diff --git a/docs/pages/incident-management/forensic-readiness.mdx b/docs/pages/incident-management/forensic-readiness.mdx index 697cf4997..6f43fe63e 100644 --- a/docs/pages/incident-management/forensic-readiness.mdx +++ b/docs/pages/incident-management/forensic-readiness.mdx @@ -1,6 +1,6 @@ --- title: "Forensic Readiness | Security Alliance" -description: "Forensic readiness: prepare your organization to preserve, collect, and present trustworthy evidence before an incident occurs. Design evidence collection into architecture, maintain chain of custody, and meet regulatory disclosure requirements." +description: "Forensic readiness: prepare your organization to preserve, collect, and present trustworthy evidence before an incident occurs. Design evidence collection into..." tags: - Security Specialist - Operations & Strategy diff --git a/docs/pages/incident-management/incident-detection-and-response.mdx b/docs/pages/incident-management/incident-detection-and-response.mdx index 92dd98621..db087386e 100644 --- a/docs/pages/incident-management/incident-detection-and-response.mdx +++ b/docs/pages/incident-management/incident-detection-and-response.mdx @@ -1,9 +1,16 @@ --- title: "Incident Detection And Response | SEAL" -description: "Detect security incidents early with continuous on-chain monitoring and logging. Build an Incident Response Team (IRT) with clear roles for containment, recovery, and post-incident review." +description: "Detect security incidents early with continuous on-chain monitoring and logging. Build an Incident Response Team (IRT) with clear roles for containment" tags: - Security Specialist - Operations & Strategy +contributors: + - role: wrote + users: [] + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter } from '../../../components' @@ -13,6 +20,10 @@ import { TagList, AttributionList, ContributeFooter } from '../../../components' +> ๐Ÿ”‘ **Key Takeaway**: Detect on-chain and off-chain anomalies early, then execute a +> prepared response cycle: IRT roles, containment, recovery, and post-incident review. +> Delay multiplies irreversible Web3 losses. + You don't want to be the project that has funds stolen and then doesn't notice it for multiple days. Early detection and effective response to security incidents will help minimize damage. @@ -41,6 +52,13 @@ For a complete incident response policy template covering roles, severity, docum and [Incident Response Template: Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing). +## Further reading + +- [Incident Management overview](/incident-management/overview): how the pages of this framework fit together +- [Monitoring overview](/monitoring/overview): the signals detection depends on +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation +- [Lessons Learned](/incident-management/lessons-learned): turning each incident into a change + --- diff --git a/docs/pages/incident-management/incident-response-template/communications.mdx b/docs/pages/incident-management/incident-response-template/communications.mdx index 36ab43051..e62ffadf0 100644 --- a/docs/pages/incident-management/incident-response-template/communications.mdx +++ b/docs/pages/incident-management/incident-response-template/communications.mdx @@ -1,13 +1,16 @@ --- title: "Communication Templates | Security Alliance" -description: "Templates and building blocks for incident communications. Adapt these to your situation and tone." +description: "Templates and building blocks for incident communications. Adapt these to your situation and tone. Adapt pre-built internal and public message blocks" tags: - Security Specialist - Operations & Strategy contributors: - role: wrote users: [hexnickk4997, n0guest] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../components' @@ -17,6 +20,10 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ +> ๐Ÿ”‘ **Key Takeaway**: Adapt pre-built internal and public message blocks so spokespeople +> ship factual updates under pressure. Avoid root-cause speculation, blame, and +> excessive apologies until facts are confirmed. + Templates and building blocks for incident communications. Adapt these to your situation and tone. ## Before You Post @@ -201,6 +208,15 @@ Use these as modular pieces. Combine as needed for your situation. - Acknowledge impact on users - Avoid excessive apologies (one is enough) -*See [Incident Response Policy](./incident-response-policy) for the overall response process.* +*See [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy) for the overall response process.* + +## Further reading + +- [Incident Response Template overview](/incident-management/incident-response-template/overview): how the template pieces fit together +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation +- [Communication Strategies](/incident-management/communication-strategies): the principles behind these templates +- [Community Management](/community-management/overview): the channels these messages go out on + +--- diff --git a/docs/pages/incident-management/incident-response-template/contacts.mdx b/docs/pages/incident-management/incident-response-template/contacts.mdx index 8102809a1..9b28fd910 100644 --- a/docs/pages/incident-management/incident-response-template/contacts.mdx +++ b/docs/pages/incident-management/incident-response-template/contacts.mdx @@ -1,13 +1,16 @@ --- title: "Critical Contacts | Security Alliance" -description: "Keep this updated. Stale contacts during an incident waste critical time." +description: "Keep this updated. Stale contacts during an incident waste critical time. Keep emergency internal, partner, vendor, legal, and PR contacts verified" tags: - Security Specialist - Operations & Strategy contributors: - role: wrote users: [hexnickk4997, n0guest] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../components' @@ -17,6 +20,10 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ +> ๐Ÿ”‘ **Key Takeaway**: Keep emergency internal, partner, vendor, legal, and PR contacts +> verified and owned. Stale phone trees waste the minutes that matter most during +> containment. + Keep this updated. Stale contacts during an incident waste critical time. **Last verified:** [DATE] @@ -119,7 +126,7 @@ Protocols, exchanges, or other partners to notify during major incidents. | Public updates | | | | Team alerts | | | -## Quick Reference - P1 Escalation +### Quick Reference - P1 Escalation For P1 (critical) incidents, contact in this order: @@ -130,7 +137,7 @@ For P1 (critical) incidents, contact in this order: 4. [ ] Legal (if fund loss or regulatory implications) -## Maintenance +### Maintenance - [ ] Review and update quarterly @@ -140,7 +147,16 @@ For P1 (critical) incidents, contact in this order: **Owner:** [Assign someone to maintain this document] -*See [Incident Response Policy](./incident-response-policy) and [Roles and Staffing](./roles-and-staffing) for how +*See [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy) and [Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing) for how these contacts fit into the response process.* +## Further reading + +- [Incident Response Template overview](/incident-management/incident-response-template/overview): how the template pieces fit together +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation +- [Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing): the roles these contacts fill +- [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines): reaching outside help fast + +--- + diff --git a/docs/pages/incident-management/incident-response-template/incident-response-policy.mdx b/docs/pages/incident-management/incident-response-template/incident-response-policy.mdx index 31d66a8e9..4f0c30b15 100644 --- a/docs/pages/incident-management/incident-response-template/incident-response-policy.mdx +++ b/docs/pages/incident-management/incident-response-template/incident-response-policy.mdx @@ -1,6 +1,6 @@ --- title: "Incident Response Policy | Security Alliance" -description: "This policy defines how we respond to security and operational incidents. It covers roles, severity classification, and the steps from detection through post-incident review." +description: "This policy defines how we respond to security and operational incidents. It covers roles, severity classification. Define severity, decision makers" tags: - Security Specialist - Operations & Strategy @@ -8,7 +8,10 @@ tags: contributors: - role: wrote users: [hexnickk4997, n0guest] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../components' @@ -18,12 +21,16 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ -## Overview +> ๐Ÿ”‘ **Key Takeaway**: Define severity, decision makers, and the detect-to-review flow in +> writing before an incident. Policy that exists only in heads fails when minutes matter +> and funds can leave forever. -This policy defines how we respond to security and operational incidents. It covers roles, severity classification, -and the steps from detection through post-incident review. +This policy defines how we respond to security and operational incidents. It covers roles, +severity classification, and the steps from detection through post-incident review. For role +structures and on-call options, see +[Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing). -For role structures and on-call options, see [Roles and Staffing](./roles-and-staffing). +## Overview ## Roles @@ -40,7 +47,9 @@ Makers when needed. ### Scribe -Documents everything in the [Incident Log](./templates/incident-log-template). Maintains timestamps (UTC), captures +Documents everything in the [Incident + Log](/incident-management/incident-response-template/templates/incident-log-template). Maintains + timestamps (UTC), captures decisions and rationale. This is a focused role. Don't also assign the Scribe to fix things. ### Communication Manager @@ -134,7 +143,7 @@ The Detector's job: get the right people involved, fast. **Incident Leader responsibilities:** 1. Pull in relevant SMEs -2. Assign a Scribe โ†’ they create an [Incident Log](./templates/incident-log-template) +2. Assign a Scribe โ†’ they create an [Incident Log](/incident-management/incident-response-template/templates/incident-log-template) 3. Assign Communication Manager(s) ### Step 3: Investigation @@ -163,7 +172,8 @@ If a temporary fix (rollback, pause, disable feature) is faster than a full fix - [ ] Plan permanent fix with owner and timeline -See [Runbooks](./runbooks/overview) for step-by-step guides for specific incident types. +See [Runbooks](/incident-management/incident-response-template/runbooks/overview) for step-by-step + guides for specific incident types. ### Step 5: Monitoring @@ -179,7 +189,7 @@ See [Runbooks](./runbooks/overview) for step-by-step guides for specific inciden **Goal:** Learn and prevent recurrence. 1. Incident Leader schedules post-mortem (within a week of resolution) -2. Scribe prepares [Post-Mortem](./templates/post-mortem-template) draft +2. Scribe prepares [Post-Mortem](/incident-management/incident-response-template/templates/post-mortem-template) draft 3. Team reviews timeline, identifies root causes, captures lessons 4. Define action items with owners and deadlines 5. Share with team (and community if appropriate) @@ -189,19 +199,11 @@ See [Runbooks](./runbooks/overview) for step-by-step guides for specific inciden ## Communication Guidelines - **Internal:** Regular updates in the incident channel. Frequency depends on severity. -- **External:** Communication Manager drafts, gets approval before posting. See [Communications](./communications) for +- **External:** Communication Manager drafts, gets approval before posting. See + [Communications](/incident-management/incident-response-template/communications) for examples. - **Transparency:** Default to sharing post-mortems publicly (redacting sensitive details). -## Related Documents - -- [Roles and Staffing](./roles-and-staffing) - Team structure options -- [Communications](./communications) - Public announcement guidance -- [Incident Log Template](./templates/incident-log-template) - Fill out during incidents -- [Post-Mortem Template](./templates/post-mortem-template) - Complete after incidents -- [Contacts](./contacts) - Critical contacts -- [Runbooks](./runbooks/overview) - Step-by-step incident guides - ## Document Control | Version | Date | Author | Changes | @@ -210,4 +212,13 @@ See [Runbooks](./runbooks/overview) for step-by-step guides for specific inciden *Customize this policy for your protocol's tools, team structure, and communication channels.* +## Further reading + +- [Incident Response Template overview](/incident-management/incident-response-template/overview): how the template pieces fit together +- [Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing): team structure options +- [Runbooks overview](/incident-management/incident-response-template/runbooks/overview): how the runbooks in this section fit together +- [Templates overview](/incident-management/incident-response-template/templates/overview): how the templates in this section fit together + +--- + diff --git a/docs/pages/incident-management/incident-response-template/overview.mdx b/docs/pages/incident-management/incident-response-template/overview.mdx index 2bcfbbcda..3eac86287 100644 --- a/docs/pages/incident-management/incident-response-template/overview.mdx +++ b/docs/pages/incident-management/incident-response-template/overview.mdx @@ -1,13 +1,16 @@ --- title: "Incident Response Template for Web3 Protocols | Security Alliance" -description: "A practical template for building incident response capabilities at cryptocurrency protocols and DAOs." +description: "A practical template for building incident response capabilities at cryptocurrency protocols and DAOs. Customize severity, roles, contacts, and runbook" tags: - Security Specialist - Operations & Strategy contributors: - role: wrote users: [hexnickk4997, n0guest] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../components' @@ -17,6 +20,10 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ +> ๐Ÿ”‘ **Key Takeaway**: This template is a skeleton, not a finished plan. Customize +> severity, roles, contacts, and runbook commands, then tabletop the result before a +> real exploit forces improvisation. + A practical template for building incident response capabilities at cryptocurrency protocols and DAOs. > **This is a template, not a turnkey solution.** Every document, runbook, and checklist must be reviewed and customized @@ -78,22 +85,24 @@ That's it to start. Add complexity only as you need it. - Review past incidents (yours or others via [Rekt News](https://rekt.news/)) - Update docs when you find gaps -## Using This Template +## What this framework covers Review and adapt these pages for your own internal incident response documentation. ### What's Included -| Document | Purpose | -| --- | --- | -| [Incident Response Policy](./incident-response-policy) | Core policy defining roles, severity levels, and response steps | -| [Roles and Staffing](./roles-and-staffing) | Options for structuring your response team | -| [Communications](./communications) | Guidance and examples for public announcements | -| [Contacts](./contacts) | Critical partner and vendor contact sheet | -| [Templates](./templates/overview) | Incident log and post-mortem templates | -| [Example Incident Log](./templates/example-incident-log) | Sample filled-out incident log | -| [Example Post-Mortem](./templates/example-post-mortem) | Sample filled-out post-mortem | -| [Runbooks](./runbooks/overview) | Step-by-step guides for specific incident types | +1. [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): + roles, severity levels, and response steps. +2. [Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing): how to + structure the response team by size. +3. [Communications](/incident-management/incident-response-template/communications): internal and public + announcement building blocks. +4. [Contacts](/incident-management/incident-response-template/contacts): critical partner and vendor + contact sheet. +5. [Templates hub](/incident-management/incident-response-template/templates/overview): incident log, + post-mortem, runbook templates, and examples. +6. [Runbooks hub](/incident-management/incident-response-template/runbooks/overview): step-by-step + guides for specific incident types. ### Customization Checklist @@ -144,7 +153,7 @@ These documents support effective incident response but typically live elsewhere You don't need all of these to start. Build them over time as your protocol matures. -## Key Principles +## Key principles **When in doubt, escalate.** Treating a P2 as P1 creates some noise. Treating a P1 as P2 can cost millions. @@ -163,4 +172,6 @@ You don't need all of these to start. Build them over time as your protocol matu *This template is open source. Adapt it to your needs.* +--- + diff --git a/docs/pages/incident-management/incident-response-template/roles-and-staffing.mdx b/docs/pages/incident-management/incident-response-template/roles-and-staffing.mdx index bf968a779..600289a07 100644 --- a/docs/pages/incident-management/incident-response-template/roles-and-staffing.mdx +++ b/docs/pages/incident-management/incident-response-template/roles-and-staffing.mdx @@ -8,7 +8,10 @@ tags: contributors: - role: wrote users: [hexnickk4997, n0guest] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../components' @@ -18,10 +21,16 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ +> ๐Ÿ”‘ **Key Takeaway**: Match IR staffing to team size: small teams split lead versus fix, +> larger teams add on-call and specialists. A light process people follow beats a +> heavyweight binder nobody opens. + How you staff incident response depends on your team size and structure. This document covers options from small teams to larger organizations. -See [Incident Response Policy](./incident-response-policy#roles) for role definitions. +See [Incident Response + Policy](/incident-management/incident-response-template/incident-response-policy#roles) for role + definitions. ## Core Roles (All Team Sizes) @@ -30,7 +39,7 @@ Every incident needs these roles filled, even if one person wears multiple hats: | Role | Responsibility | | ------- | ----------------- | | **Incident Leader** | Coordinates response, assigns tasks, makes decisions | -| **Scribe** | Documents everything in [Incident Log](./templates/incident-log-template) | +| **Scribe** | Documents everything in [Incident Log](/incident-management/incident-response-template/templates/incident-log-template) | | **Responders** | Execute fixes, investigate, implement mitigations | For larger incidents, add: @@ -56,7 +65,7 @@ Everyone knows everything. Just make sure someone is always reachable. ### Expectations -- Keep a shared contact list (see [Contacts](./contacts)) +- Keep a shared contact list (see [Contacts](/incident-management/incident-response-template/contacts)) - Establish one communication channel for incidents - Someone should always be reachable (informal coverage) @@ -146,8 +155,11 @@ ex. With 8 people per rotation, each person is on-call one week every two months Before going on-call, complete: -- [ ] Review [Incident Response Policy](./incident-response-policy) -- [ ] Review [Incident Log](./templates/incident-log-template) and [Post-Mortem](./templates/post-mortem-template) templates +- [ ] Review [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy) +- [ ] Review [Incident + Log](/incident-management/incident-response-template/templates/incident-log-template) and + [Post-Mortem](/incident-management/incident-response-template/templates/post-mortem-template) + templates - [ ] Read 2-3 past post-mortems - [ ] Understand basic architecture (infra and smart contracts) - [ ] Know how to reach SMEs and Decision Makers @@ -196,7 +208,7 @@ Ensure your on-call personnel have access to: - [ ] Video conferencing - [ ] Monitoring dashboards - [ ] On-call schedule -- [ ] [Contacts](./contacts) list +- [ ] [Contacts](/incident-management/incident-response-template/contacts) list ## Choosing Your Model @@ -211,6 +223,15 @@ Ensure your on-call personnel have access to: **Start simple and add structure as you grow.** A lightweight process that people follow beats a heavyweight process that gets ignored. -*See [Incident Response Policy](./incident-response-policy) for how these roles work during an actual incident.* +*See [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy) for how these roles work during an actual incident.* + +## Further reading + +- [Incident Response Template overview](/incident-management/incident-response-template/overview): how the template pieces fit together +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation +- [Contacts template](/incident-management/incident-response-template/contacts): who to reach for each role +- [Communications template](/incident-management/incident-response-template/communications): who speaks publicly and when + +--- diff --git a/docs/pages/incident-management/incident-response-template/runbooks/build-pipeline-compromise.mdx b/docs/pages/incident-management/incident-response-template/runbooks/build-pipeline-compromise.mdx index 6247152cf..83c9572c4 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/build-pipeline-compromise.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/build-pipeline-compromise.mdx @@ -1,6 +1,6 @@ --- title: "Runbook: Build Pipeline Compromise | Security Alliance" -description: "Stub runbook. Customize with your CI/CD platform and procedures." +description: "Stub runbook. Customize with your CI/CD platform and procedures. A compromised CI/CD path can ship trojans as trusted releases. Freeze pipelines, rotate" tags: - Security Specialist - Operations & Strategy @@ -8,7 +8,10 @@ tags: contributors: - role: wrote users: [isaac] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../../components' @@ -18,7 +21,11 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ -> **Stub runbook.** Customize with your CI/CD platform and procedures. +> ๐Ÿ”‘ **Key Takeaway**: A compromised CI/CD path can ship trojans as trusted releases. +> Freeze pipelines, rotate secrets and signing keys, audit recent jobs, and only +> re-enable after integrity checks pass. + +**Stub runbook.** Customize with your CI/CD platform and procedures. ## Quick Reference @@ -75,10 +82,13 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ - [ ] Separate build and deploy permissions -## Related +## Further reading -- [Frontend Compromise](./frontend-compromise) -- [Dependency Attack](./dependency-attack) -- [Incident Response Policy](../incident-response-policy) +- [Runbooks overview](/incident-management/incident-response-template/runbooks/overview): how the runbooks in this section fit together +- [Dependency Attack](/incident-management/incident-response-template/runbooks/dependency-attack): the adjacent supply chain scenario +- [CI/CD Security](/devsecops/continuous-integration-continuous-deployment): pipeline controls that prevent this +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation + +--- diff --git a/docs/pages/incident-management/incident-response-template/runbooks/cdn-hosting-compromise.mdx b/docs/pages/incident-management/incident-response-template/runbooks/cdn-hosting-compromise.mdx index 74474a4ba..4c2bf6299 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/cdn-hosting-compromise.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/cdn-hosting-compromise.mdx @@ -1,6 +1,6 @@ --- title: "Runbook: CDN/Hosting Compromise | Security Alliance" -description: "Stub runbook. Customize with your CDN and hosting provider details." +description: "Stub runbook. Customize with your CDN and hosting provider details. Compromised CDN or hosting can serve malicious assets at your legitimate origin." tags: - Security Specialist - Operations & Strategy @@ -8,7 +8,10 @@ tags: contributors: - role: wrote users: [isaac] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../../components' @@ -18,7 +21,11 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ -> **Stub runbook.** Customize with your CDN and hosting provider details. +> ๐Ÿ”‘ **Key Takeaway**: Compromised CDN or hosting can serve malicious assets at your +> legitimate origin. Invalidate caches, rotate credentials, restore known-good builds, +> and verify integrity of what users fetch. + +**Stub runbook.** Customize with your CDN and hosting provider details. ## Quick Reference @@ -72,9 +79,13 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ - [ ] Regular access audits -## Related +## Further reading -- [Frontend Compromise](./frontend-compromise) -- [Incident Response Policy](../incident-response-policy) +- [Runbooks overview](/incident-management/incident-response-template/runbooks/overview): how the runbooks in this section fit together +- [Frontend Compromise](/incident-management/incident-response-template/runbooks/frontend-compromise): the broader scenario this feeds into +- [Web Application Security](/front-end-web-app/web-application-security): hardening the delivery path +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation + +--- diff --git a/docs/pages/incident-management/incident-response-template/runbooks/ddos-attack.mdx b/docs/pages/incident-management/incident-response-template/runbooks/ddos-attack.mdx index c3b0c913a..b6dd8bcab 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/ddos-attack.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/ddos-attack.mdx @@ -8,7 +8,10 @@ tags: contributors: - role: wrote users: [isaac] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../../components' @@ -18,8 +21,11 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ -> **This is an example runbook.** Review and customize for your protocol before use. Add your specific CDN/WAF -> provider commands and escalation contacts. +> ๐Ÿ”‘ **Key Takeaway**: Under DDoS, engage your CDN/WAF play, protect origin capacity, and +> separate availability response from security compromise until evidence says otherwise. + +**This is an example runbook.** Review and customize for your protocol before use. Add your specific +CDN/WAF provider commands and escalation contacts. ## Quick Reference @@ -134,8 +140,10 @@ For AWS: ## Escalation -- [ ] [CDN/hosting provider](../contacts#infrastructure-vendors) - for attack mitigation support -- [ ] [Decision Makers](../contacts#decision-makers) - if extended outage +- [ ] [CDN/hosting + provider](/incident-management/incident-response-template/contacts#infrastructure-vendors) - + for attack mitigation support +- [ ] [Decision Makers](/incident-management/incident-response-template/contacts#decision-makers) - if extended outage ## Recovery @@ -181,10 +189,13 @@ After resolving, consider: - [ ] Backup/failover infrastructure -## Related +## Further reading -- [Third-Party Outage](./third-party-outage) -- [Frontend Compromise](./frontend-compromise) -- [Incident Response Policy](../incident-response-policy) +- [Runbooks overview](/incident-management/incident-response-template/runbooks/overview): how the runbooks in this section fit together +- [Third-Party Outage](/incident-management/incident-response-template/runbooks/third-party-outage): the adjacent availability scenario +- [DDoS Protection](/infrastructure/ddos-protection): controls to have in place beforehand +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation + +--- diff --git a/docs/pages/incident-management/incident-response-template/runbooks/dependency-attack.mdx b/docs/pages/incident-management/incident-response-template/runbooks/dependency-attack.mdx index 06f4441fe..3b99a6289 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/dependency-attack.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/dependency-attack.mdx @@ -1,6 +1,6 @@ --- title: "Runbook: Dependency Attack | Security Alliance" -description: "Stub runbook. Customize with your package management and build procedures." +description: "Stub runbook. Customize with your package management and build procedures. Pin and verify dependencies, revoke tainted artifacts, rotate exposed secrets" tags: - Security Specialist - Operations & Strategy @@ -8,7 +8,10 @@ tags: contributors: - role: wrote users: [isaac] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../../components' @@ -18,7 +21,11 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ -> **Stub runbook.** Customize with your package management and build procedures. +> ๐Ÿ”‘ **Key Takeaway**: Malicious package updates poison builds and frontends. Pin and +> verify dependencies, revoke tainted artifacts, rotate exposed secrets, and rebuild +> from known-good sources. + +**Stub runbook.** Customize with your package management and build procedures. ## Quick Reference @@ -44,7 +51,7 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ ``` npm audit -# or + # or yarn audit ``` @@ -79,10 +86,13 @@ Check for recent lockfile changes in git history. - [ ] Review dependency changes in PRs -## Related +## Further reading -- [Frontend Compromise](./frontend-compromise) -- [Build Pipeline Compromise](./build-pipeline-compromise) -- [Incident Response Policy](../incident-response-policy) +- [Runbooks overview](/incident-management/incident-response-template/runbooks/overview): how the runbooks in this section fit together +- [Build Pipeline Compromise](/incident-management/incident-response-template/runbooks/build-pipeline-compromise): the adjacent scenario upstream +- [Frontend Compromise](/incident-management/incident-response-template/runbooks/frontend-compromise): where a poisoned dependency usually surfaces +- [Supply Chain](/supply-chain/overview): prevention side of the same risk + +--- diff --git a/docs/pages/incident-management/incident-response-template/runbooks/dns-hijack.mdx b/docs/pages/incident-management/incident-response-template/runbooks/dns-hijack.mdx index d585f0809..2a7971ab1 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/dns-hijack.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/dns-hijack.mdx @@ -1,6 +1,6 @@ --- title: "Runbook: DNS Hijack | Security Alliance" -description: "Stub runbook. Customize with your DNS provider details and procedures." +description: "Stub runbook. Customize with your DNS provider details and procedures. Lock registrar controls, restore authoritative records, force cache abandonment" tags: - Security Specialist - Operations & Strategy @@ -8,7 +8,10 @@ tags: contributors: - role: wrote users: [isaac] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../../components' @@ -18,7 +21,11 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ -> **Stub runbook.** Customize with your DNS provider details and procedures. +> ๐Ÿ”‘ **Key Takeaway**: DNS hijacks redirect users to attacker infrastructure. Lock +> registrar controls, restore authoritative records, force cache abandonment, and verify +> resolution from multiple resolvers. + +**Stub runbook.** Customize with your DNS provider details and procedures. ## Quick Reference @@ -69,9 +76,13 @@ dig yourdomain.com - [ ] Monitor DNS records for changes -## Related +## Further reading -- [Frontend Compromise](./frontend-compromise) -- [Incident Response Policy](../incident-response-policy) +- [Runbooks overview](/incident-management/incident-response-template/runbooks/overview): how the runbooks in this section fit together +- [Frontend Compromise](/incident-management/incident-response-template/runbooks/frontend-compromise): what users see when DNS is redirected +- [Domain & DNS Security](/infrastructure/domain-and-dns-security/overview): registrar and record controls that prevent this +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation + +--- diff --git a/docs/pages/incident-management/incident-response-template/runbooks/frontend-compromise.mdx b/docs/pages/incident-management/incident-response-template/runbooks/frontend-compromise.mdx index 300b82fd9..04bef4447 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/frontend-compromise.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/frontend-compromise.mdx @@ -8,7 +8,10 @@ tags: contributors: - role: wrote users: [isaac] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../../components' @@ -18,8 +21,12 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ -> **This is an example runbook.** Review and customize for your protocol before use. Add your specific DNS -> provider, hosting platform, and deployment procedures. +> ๐Ÿ”‘ **Key Takeaway**: Treat a compromised UI as a user-fund risk path. Restrict traffic, +> identify the vector (DNS, CDN, dependency, or pipeline), and route into the matching +> specialized runbook. + +**This is an example runbook.** Review and customize for your protocol before use. Add your specific +DNS provider, hosting platform, and deployment procedures. ## Quick Reference @@ -103,10 +110,10 @@ The first priority is understanding how the attacker gained access so you can cl Once identified, go to the specific runbook: -- DNS hijack โ†’ [DNS Hijack](./dns-hijack) -- CDN/hosting compromise โ†’ [CDN/Hosting Compromise](./cdn-hosting-compromise) -- Dependency attack โ†’ [Dependency Attack](./dependency-attack) -- Build pipeline compromise โ†’ [Build Pipeline Compromise](./build-pipeline-compromise) +- DNS hijack โ†’ [DNS Hijack](/incident-management/incident-response-template/runbooks/dns-hijack) +- CDN/hosting compromise โ†’ [CDN/Hosting Compromise](/incident-management/incident-response-template/runbooks/cdn-hosting-compromise) +- Dependency attack โ†’ [Dependency Attack](/incident-management/incident-response-template/runbooks/dependency-attack) +- Build pipeline compromise โ†’ [Build Pipeline Compromise](/incident-management/incident-response-template/runbooks/build-pipeline-compromise) ### Post-Mitigation Investigation @@ -132,10 +139,10 @@ After the threat is contained, investigate impact: See the specific runbook for detailed mitigation steps: -- [DNS Hijack](./dns-hijack) -- [CDN/Hosting Compromise](./cdn-hosting-compromise) -- [Dependency Attack](./dependency-attack) -- [Build Pipeline Compromise](./build-pipeline-compromise) +- [DNS Hijack](/incident-management/incident-response-template/runbooks/dns-hijack) +- [CDN/Hosting Compromise](/incident-management/incident-response-template/runbooks/cdn-hosting-compromise) +- [Dependency Attack](/incident-management/incident-response-template/runbooks/dependency-attack) +- [Build Pipeline Compromise](/incident-management/incident-response-template/runbooks/build-pipeline-compromise) ## Recovery @@ -171,9 +178,13 @@ If users signed malicious transactions: ## Escalation -- [ ] [Decision Makers](../contacts#decision-makers) - immediately -- [ ] [Infrastructure Vendors](../contacts#infrastructure-vendors) - if hosting/CDN involved -- [ ] [Legal & Communications](../contacts#legal--communications) - for user communication +- [ ] [Decision Makers](/incident-management/incident-response-template/contacts#decision-makers) - immediately +- [ ] [Infrastructure + Vendors](/incident-management/incident-response-template/contacts#infrastructure-vendors) - if + hosting/CDN involved +- [ ] [Legal & + Communications](/incident-management/incident-response-template/contacts#legal--communications) + - for user communication ## Prevention Checklist @@ -189,14 +200,13 @@ After resolving, review: - [ ] Content Security Policy -## Related +## Further reading -- [DNS Hijack](./dns-hijack) -- [CDN/Hosting Compromise](./cdn-hosting-compromise) -- [Dependency Attack](./dependency-attack) -- [Build Pipeline Compromise](./build-pipeline-compromise) -- [DDoS Attack](./ddos-attack) -- [Third-Party Outage](./third-party-outage) -- [Incident Response Policy](../incident-response-policy) +- [Runbooks overview](/incident-management/incident-response-template/runbooks/overview): how the runbooks in this section fit together +- [DNS Hijack](/incident-management/incident-response-template/runbooks/dns-hijack): one of the common root causes +- [CDN/Hosting Compromise](/incident-management/incident-response-template/runbooks/cdn-hosting-compromise): another common root cause +- [Web Application Security](/front-end-web-app/web-application-security): hardening the app itself + +--- diff --git a/docs/pages/incident-management/incident-response-template/runbooks/key-compromise.mdx b/docs/pages/incident-management/incident-response-template/runbooks/key-compromise.mdx index 12289fe58..a36aa2b86 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/key-compromise.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/key-compromise.mdx @@ -8,7 +8,10 @@ tags: contributors: - role: wrote users: [isaac] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../../components' @@ -18,8 +21,12 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ -> **This is an example runbook.** Review and customize for your protocol before use. Fill in your key types, what -> each controls, and your specific rotation procedures. +> ๐Ÿ”‘ **Key Takeaway**: On suspected key or signer compromise, inventory what the key +> controls, revoke and rotate fast, and assess blast radius before declaring the +> environment clean. + +**This is an example runbook.** Review and customize for your protocol before use. Fill in your key +types, what each controls, and your specific rotation procedures. ## Quick Reference @@ -154,9 +161,12 @@ For hot wallets: ## Escalation -- [ ] [Decision Makers](../contacts#decision-makers) - immediately for any confirmed compromise -- [ ] [Security Partners](../contacts#security-partners) - for investigation support -- [ ] [Legal](../contacts#legal--communications) - if funds were stolen +- [ ] [Decision Makers](/incident-management/incident-response-template/contacts#decision-makers) - + immediately for any confirmed compromise +- [ ] [Security + Partners](/incident-management/incident-response-template/contacts#security-partners) - for + investigation support +- [ ] [Legal](/incident-management/incident-response-template/contacts#legal--communications) - if funds were stolen ## Prevention Checklist @@ -172,9 +182,13 @@ After resolving, review: - [ ] Key rotation schedule -## Related +## Further reading -- [Smart Contract Exploit](./smart-contract-exploit) -- [Incident Response Policy](../incident-response-policy) +- [Runbooks overview](/incident-management/incident-response-template/runbooks/overview): how the runbooks in this section fit together +- [Smart Contract Exploit](/incident-management/incident-response-template/runbooks/smart-contract-exploit): the follow-on scenario when keys hold admin roles +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation +- [Seed Phrase Management](/wallet-security/seed-phrase-management): key custody practice that limits exposure + +--- diff --git a/docs/pages/incident-management/incident-response-template/runbooks/overview.mdx b/docs/pages/incident-management/incident-response-template/runbooks/overview.mdx index ff0d683b9..c07bd0f7d 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/overview.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/overview.mdx @@ -8,7 +8,10 @@ tags: contributors: - role: wrote users: [isaac] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../../components' @@ -18,6 +21,9 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ +> ๐Ÿ”‘ **Key Takeaway**: Runbooks cut cognitive load during active incidents. Customize every +> command and contact for your stack; untested generic runbooks can be worse than none. + Step-by-step guides for specific incident types. Use these during active incidents to reduce cognitive load and ensure consistent response. @@ -26,26 +32,37 @@ ensure consistent response. > and procedures before relying on them during an actual incident. Untested runbooks can be worse than no runbook > at all. -## Available Runbooks +## What this framework covers ### Critical (P1) -- [Smart Contract Exploit](./smart-contract-exploit) - Active exploit or critical vulnerability -- [Key Compromise](./key-compromise) - Private key or signer compromise -- [Frontend Compromise](./frontend-compromise) - Website/UI compromise (routes to specific runbooks below) - - [DNS Hijack](./dns-hijack) - Domain/DNS compromise - - [CDN/Hosting Compromise](./cdn-hosting-compromise) - CDN or hosting provider compromise - - [Dependency Attack](./dependency-attack) - npm/package supply chain attack - - [Build Pipeline Compromise](./build-pipeline-compromise) - CI/CD compromise +1. [Smart Contract Exploit](/incident-management/incident-response-template/runbooks/smart-contract-exploit): + active exploit or critical vulnerability. +2. [Key Compromise](/incident-management/incident-response-template/runbooks/key-compromise): private + key or signer compromise. +3. [Frontend Compromise](/incident-management/incident-response-template/runbooks/frontend-compromise): + website/UI compromise (routes to specialized runbooks below). +4. [DNS Hijack](/incident-management/incident-response-template/runbooks/dns-hijack): domain/DNS + compromise. +5. [CDN/Hosting Compromise](/incident-management/incident-response-template/runbooks/cdn-hosting-compromise): + CDN or hosting provider compromise. +6. [Dependency Attack](/incident-management/incident-response-template/runbooks/dependency-attack): + npm/package supply chain attack. +7. [Build Pipeline Compromise](/incident-management/incident-response-template/runbooks/build-pipeline-compromise): + CI/CD compromise. ### High/Moderate (P2-P3) -- [DDoS Attack](./ddos-attack) - Denial of service attacks -- [Third-Party Outage](./third-party-outage) - External provider issues +1. [DDoS Attack](/incident-management/incident-response-template/runbooks/ddos-attack): denial of + service attacks. +2. [Third-Party Outage](/incident-management/incident-response-template/runbooks/third-party-outage): + external provider issues. ## Creating New Runbooks -Use [Runbook Template](../templates/runbook-template) as your starting point. +Use +[Runbook Template](/incident-management/incident-response-template/templates/runbook-template) as +your starting point. Good runbooks: @@ -66,6 +83,17 @@ Consider creating runbooks for: - [ ] Data inconsistency -*See [Incident Response Policy](../incident-response-policy) for the overall response process.* +See +[Incident Response Policy](/incident-management/incident-response-template/incident-response-policy) +for the overall response process. + +## Further reading + +- [Incident Response Template overview](/incident-management/incident-response-template/overview): how the template pieces fit together +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation +- [Runbook Template](/incident-management/incident-response-template/templates/runbook-template): the blank structure for writing your own +- [Incident Management overview](/incident-management/overview): how the pages of this framework fit together + +--- diff --git a/docs/pages/incident-management/incident-response-template/runbooks/smart-contract-exploit.mdx b/docs/pages/incident-management/incident-response-template/runbooks/smart-contract-exploit.mdx index 4d47967d2..6e131b732 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/smart-contract-exploit.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/smart-contract-exploit.mdx @@ -1,6 +1,6 @@ --- title: "Runbook: Smart Contract Exploit | Security Alliance" -description: "This is an example runbook. Review and customize for your protocol before use. Fill in the placeholder commands, add your specific contracts and addresses, and test during a tabletop exercise." +description: "This is an example runbook. Review and customize for your protocol before use. Fill in the placeholder commands, add your specific contracts and addresses" tags: - Security Specialist - Operations & Strategy @@ -8,7 +8,10 @@ tags: contributors: - role: wrote users: [isaac] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../../components' @@ -18,8 +21,13 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ -> **This is an example runbook.** Review and customize for your protocol before use. Fill in the placeholder -> commands, add your specific contracts and addresses, and test during a tabletop exercise. +> ๐Ÿ”‘ **Key Takeaway**: For active smart-contract exploits, confirm scope, pause or contain +> if possible, preserve evidence, and coordinate recovery using your protocol-specific +> commandsโ€”not the placeholders in this example. + +**This is an example runbook.** Review and customize for your protocol before use. Fill in the +placeholder commands, add your specific contracts and addresses, and test during a tabletop +exercise. ## Quick Reference @@ -69,7 +77,7 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ **Why:** Get immediate expert support for active exploits -See [SEAL 911](../contacts#seal-911) +See [SEAL 911](/incident-management/incident-response-template/contacts#seal-911) ### Step 3: Pause if Possible @@ -149,9 +157,9 @@ If your contracts have pause functionality: Contact immediately: -- [ ] [Decision Makers](../contacts#decision-makers) -- [ ] [Security Partners](../contacts#security-partners) -- [ ] [Legal](../contacts#legal--communications) if significant fund loss +- [ ] [Decision Makers](/incident-management/incident-response-template/contacts#decision-makers) +- [ ] [Security Partners](/incident-management/incident-response-template/contacts#security-partners) +- [ ] [Legal](/incident-management/incident-response-template/contacts#legal--communications) if significant fund loss ## Post-Exploit @@ -164,7 +172,7 @@ Contact immediately: - [ ] Engage with law enforcement if appropriate -## Common Root Causes +### Common Root Causes | Cause | Signs | Prevention | | ------- | ------- | ------------ | @@ -172,9 +180,13 @@ Contact immediately: | Access control | Unauthorized caller | Proper modifiers | | Oracle manipulation | Price deviation before exploit | TWAP, multiple sources | -## Related +## Further reading -- [Key Compromise](./key-compromise) -- [Incident Response Policy](../incident-response-policy) +- [Runbooks overview](/incident-management/incident-response-template/runbooks/overview): how the runbooks in this section fit together +- [Key Compromise](/incident-management/incident-response-template/runbooks/key-compromise): the adjacent scenario when admin keys are involved +- [Safe Harbor](/safe-harbor/overview): the whitehat rescue framework during an active exploit +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation + +--- diff --git a/docs/pages/incident-management/incident-response-template/runbooks/third-party-outage.mdx b/docs/pages/incident-management/incident-response-template/runbooks/third-party-outage.mdx index 39f9be2ad..b4f7aa7bd 100644 --- a/docs/pages/incident-management/incident-response-template/runbooks/third-party-outage.mdx +++ b/docs/pages/incident-management/incident-response-template/runbooks/third-party-outage.mdx @@ -8,7 +8,10 @@ tags: contributors: - role: wrote users: [isaac] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../../components' @@ -18,8 +21,12 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ -> **This is an example runbook.** Review and customize for your protocol before use. Fill in your specific vendors, -> dependencies, and failover procedures. +> ๐Ÿ”‘ **Key Takeaway**: Vendor outages cascade into protocol impact. Identify the +> dependency, fail over if ready, communicate status honestly, and track vendor +> remediation without pretending you control their systems. + +**This is an example runbook.** Review and customize for your protocol before use. Fill in your +specific vendors, dependencies, and failover procedures. ## Quick Reference @@ -163,8 +170,11 @@ Include: ## Escalation -- [ ] [Infrastructure Vendors](../contacts#infrastructure-vendors) - contact provider support -- [ ] [Decision Makers](../contacts#decision-makers) - if extended outage or no ETA +- [ ] [Infrastructure + Vendors](/incident-management/incident-response-template/contacts#infrastructure-vendors) - + contact provider support +- [ ] [Decision Makers](/incident-management/incident-response-template/contacts#decision-makers) - + if extended outage or no ETA ## Prevention @@ -187,9 +197,13 @@ Reduce third-party dependency risk: | | | | | | | | -## Related +## Further reading -- [DDoS Attack](./ddos-attack) -- [Incident Response Policy](../incident-response-policy) +- [Runbooks overview](/incident-management/incident-response-template/runbooks/overview): how the runbooks in this section fit together +- [DDoS Attack](/incident-management/incident-response-template/runbooks/ddos-attack): the adjacent availability scenario +- [Vendor Risk Management](/supply-chain/vendor-risk-management): assessing dependencies before they fail +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation + +--- diff --git a/docs/pages/incident-management/incident-response-template/templates/example-incident-log.mdx b/docs/pages/incident-management/incident-response-template/templates/example-incident-log.mdx index d4eaf5c0a..d0634145f 100644 --- a/docs/pages/incident-management/incident-response-template/templates/example-incident-log.mdx +++ b/docs/pages/incident-management/incident-response-template/templates/example-incident-log.mdx @@ -1,6 +1,6 @@ --- title: "Incident: API Outage - Rate Limiter Misconfiguration | Security Alliance" -description: "This is an example incident log. Delete this file or use it as reference when creating real incident logs." +description: "This is an example incident log. Delete this file or use it as reference when creating real incident logs. never treat sample commands or timelines as" tags: - Security Specialist - Operations & Strategy @@ -8,17 +8,32 @@ tags: contributors: - role: wrote users: [hexnickk4997, n0guest] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter } from '../../../../../components' +{/* + content-model-exception: + type: template + reason: Reusable template body intentionally uses many H2 placeholders and static task lists for copy-paste. + owner: maintainers +*/} + # Incident: API Outage - Rate Limiter Misconfiguration -> **This is an example incident log.** Delete this file or use it as reference when creating real incident logs. +> ๐Ÿ”‘ **Key Takeaway**: Use this filled API-outage log as a format reference only. Replace +> it with real incident records; never treat sample commands or timelines as operational +> truth. + +**This is an example incident log.** Delete this file or use it as reference when creating real +incident logs. ## Summary @@ -113,7 +128,7 @@ Rolled back rate limiter configuration to previous known-good version. - [x] Sample API calls succeeding - [x] No user reports of issues post-fix -## Communications Sent +### Communications Sent | Time | Channel | Summary | | ---- | ------- | ------- | @@ -121,18 +136,27 @@ Rolled back rate limiter configuration to previous known-good version. | 15:45 UTC | Discord #announcements | "API issues resolved" | | 16:00 UTC | Twitter | Brief update (optional) | -## Post-Incident +### Post-Incident - [x] Post-mortem scheduled for: 2024-01-17 15:00 UTC -- [x] [Post-mortem document](./example-post-mortem) created +- [x] [Post-mortem document](/incident-management/incident-response-template/templates/example-post-mortem) created - [ ] Action items assigned (pending post-mortem) -## Links & Evidence +### Links & Evidence - DataDog dashboard: [link] - Config PR that caused issue: [link] - Rollback PR: [link] -*See [Incident Response Policy](../incident-response-policy) for severity definitions and process.* +*See [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy) for severity definitions and process.* + +## Further reading + +- [Templates overview](/incident-management/incident-response-template/templates/overview): how the templates in this section fit together +- [Incident Log Template](/incident-management/incident-response-template/templates/incident-log-template): the blank version to copy +- [Post-Mortem Template](/incident-management/incident-response-template/templates/post-mortem-template): what to complete once the incident closes +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation + +--- diff --git a/docs/pages/incident-management/incident-response-template/templates/example-post-mortem.mdx b/docs/pages/incident-management/incident-response-template/templates/example-post-mortem.mdx index 4a705bf5a..d800ac5b5 100644 --- a/docs/pages/incident-management/incident-response-template/templates/example-post-mortem.mdx +++ b/docs/pages/incident-management/incident-response-template/templates/example-post-mortem.mdx @@ -1,6 +1,6 @@ --- title: "Post-Mortem: API Outage - Rate Limiter Misconfiguration | Security Alliance" -description: "This is an example post-mortem. Delete this file or use it as reference when creating real post-mortems." +description: "This is an example post-mortem. Delete this file or use it as reference when creating real post-mortems. Covers Post-Mortem: API Outage - Rate Limiter" tags: - Security Specialist - Operations & Strategy @@ -8,17 +8,32 @@ tags: contributors: - role: wrote users: [hexnickk4997, n0guest] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter } from '../../../../../components' +{/* + content-model-exception: + type: template + reason: Reusable template body intentionally uses many H2 placeholders and static task lists for copy-paste. + owner: maintainers +*/} + # Post-Mortem: API Outage - Rate Limiter Misconfiguration -> **This is an example post-mortem.** Delete this file or use it as reference when creating real post-mortems. +> ๐Ÿ”‘ **Key Takeaway**: This sample post-mortem shows tone and structure for a config-driven +> outage. Copy the learning postureโ€”systems over blameโ€”and write your own facts for +> every real incident. + +**This is an example post-mortem.** Delete this file or use it as reference when creating real post- +mortems. ## Metadata @@ -28,7 +43,7 @@ import { TagList, AttributionList, ContributeFooter } from '../../../../../compo | **Severity** | P2 | | **Authors** | Alice, Bob | | **Status** | Final | -| **Incident Log** | [2024-01-15 Example API Outage](./example-incident-log) | +| **Incident Log** | [2024-01-15 Example API Outage](/incident-management/incident-response-template/templates/example-incident-log) | ## Summary @@ -74,7 +89,7 @@ at risk, but approximately 3,000 users experienced failed transactions during th | 15:25 | Rollback complete | | 16:45 | Incident resolved | -See [Incident Log](./example-incident-log) for detailed timeline. +See [Incident Log](/incident-management/incident-response-template/templates/example-incident-log) for detailed timeline. ## Root Cause @@ -114,13 +129,13 @@ Human error during configuration change. The rate limit threshold was typed as ` 3. Alert took 17 minutes to fire (threshold too high) 4. No validation for obviously wrong values (10 vs 1000) -## Where We Got Lucky +### Where We Got Lucky 1. This happened during business hours when the team was available 2. The fix (rollback) was simple. If the old config was also broken, recovery would have been harder 3. No financial impact because this was the API layer, not smart contracts -## Action Items +### Action Items | Action | Owner | Deadline | Status | | ------ | ----- | -------- | ------ | @@ -130,12 +145,14 @@ Human error during configuration change. The rate limit threshold was typed as ` | Add staging environment testing for config changes | Dave | 2024-02-15 | In Progress | | Document config change process | Alice | 2024-01-31 | Not Started | -## Lessons for Runbooks +### Lessons for Runbooks -- [x] Existing runbook sufficient: [Third-Party Outage](../runbooks/third-party-outage) (config rollback section applicable) +- [x] Existing runbook sufficient: [Third-Party + Outage](/incident-management/incident-response-template/runbooks/third-party-outage) (config + rollback section applicable) - [ ] No new runbook needed -## Detection +### Detection | Aspect | Details | | ------ | ------- | @@ -143,14 +160,14 @@ Human error during configuration change. The rate limit threshold was typed as ` | Time to detection | 17 minutes | | Could we detect faster? | Yes - lower alert threshold to 1% | -## Links +### Links -- Incident Log: [2024-01-15 Example API Outage](./example-incident-log) +- Incident Log: [2024-01-15 Example API Outage](/incident-management/incident-response-template/templates/example-incident-log) - Config PR (bad): [link] - Rollback PR: [link] - Monitoring dashboard: [link] -## Meeting Notes +### Meeting Notes **Attendees:** Alice, Bob, Carol, Dave @@ -160,6 +177,15 @@ Human error during configuration change. The rate limit threshold was typed as ` - Discussed whether to require staging for all changes (decided yes) - Dave to implement validation this week -*See [Incident Response Policy](../incident-response-policy#step-6-post-incident-review) for post-mortem process.* +*See [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy#step-6-post-incident-review) for post-mortem process.* + +## Further reading + +- [Templates overview](/incident-management/incident-response-template/templates/overview): how the templates in this section fit together +- [Post-Mortem Template](/incident-management/incident-response-template/templates/post-mortem-template): the blank version to copy +- [Lessons Learned](/incident-management/lessons-learned): turning findings into durable change +- [Incident Log Template](/incident-management/incident-response-template/templates/incident-log-template): the record this draws from + +--- diff --git a/docs/pages/incident-management/incident-response-template/templates/incident-log-template.mdx b/docs/pages/incident-management/incident-response-template/templates/incident-log-template.mdx index 9243bcb54..35d4dee04 100644 --- a/docs/pages/incident-management/incident-response-template/templates/incident-log-template.mdx +++ b/docs/pages/incident-management/incident-response-template/templates/incident-log-template.mdx @@ -1,6 +1,6 @@ --- title: "Incident Log Template | Security Alliance" -description: "Use this template during active incidents. The Scribe owns this document." +description: "Use this template during active incidents. The Scribe owns this document. Timestamp decisions, actions, and links continuously so later investigation" tags: - Security Specialist - Operations & Strategy @@ -8,17 +8,33 @@ tags: contributors: - role: wrote users: [hexnickk4997, n0guest] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../../components' +{/* + content-model-exception: + type: template + reason: Reusable template body intentionally uses many H2 placeholders and static task lists for copy-paste. + owner: maintainers +*/} + # Incident Log Template -Use this template during active incidents. The [Scribe](../incident-response-policy#scribe) owns this document. +> ๐Ÿ”‘ **Key Takeaway**: The Scribe owns the live incident log. Timestamp decisions, actions, +> and links continuously so later investigation and post-mortems are reconstruction, not +> guesswork. + +Use this template during active incidents. The + [Scribe](/incident-management/incident-response-template/incident-response-policy#scribe) owns this + document. ## How to Use @@ -108,27 +124,29 @@ HH:MM UTC - ... - [ ] [Check 2] -## Communications Sent +### Communications Sent | Time | Channel | Summary | | ---- | ------- | ------- | | | | | -## Post-Incident +### Post-Incident - [ ] Post-mortem scheduled for: [date] -- [ ] [Post-mortem document](./post-mortem-template) created (save to your post-mortems folder) +- [ ] [Post-mortem + document](/incident-management/incident-response-template/templates/post-mortem-template) + created (save to your post-mortems folder) - [ ] Action items assigned -## Links & Evidence +### Links & Evidence - [Relevant dashboard] - [Relevant PR/commit] - [Screenshots] -## Severity Reference +### Severity Reference | Level | Description | | ----- | ----------- | @@ -138,6 +156,17 @@ HH:MM UTC - ... | P4 | Low - minor issues | | P5 | Info - no action needed | -See [Incident Response Policy](../incident-response-policy#severity-levels) for full definitions. +See [Incident Response + Policy](/incident-management/incident-response-template/incident-response-policy#severity-levels) + for full definitions. + +## Further reading + +- [Templates overview](/incident-management/incident-response-template/templates/overview): how the templates in this section fit together +- [Example Incident Log](/incident-management/incident-response-template/templates/example-incident-log): a completed log to model +- [Post-Mortem Template](/incident-management/incident-response-template/templates/post-mortem-template): what to complete once the incident closes +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation + +--- diff --git a/docs/pages/incident-management/incident-response-template/templates/overview.mdx b/docs/pages/incident-management/incident-response-template/templates/overview.mdx index 030a3a0e1..dec1768b7 100644 --- a/docs/pages/incident-management/incident-response-template/templates/overview.mdx +++ b/docs/pages/incident-management/incident-response-template/templates/overview.mdx @@ -1,6 +1,6 @@ --- title: "Templates | Security Alliance" -description: "Templates for incident response documentation. Copy these when needed." +description: "Templates for incident response documentation. Copy these when needed. Practice incident log, post-mortem, and runbook templates before the first real" tags: - Security Specialist - Operations & Strategy @@ -8,7 +8,10 @@ tags: contributors: - role: wrote users: [hexnickk4997, n0guest] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter } from '../../../../../components' @@ -18,32 +21,43 @@ import { TagList, AttributionList, ContributeFooter } from '../../../../../compo +> ๐Ÿ”‘ **Key Takeaway**: Practice incident log, post-mortem, and runbook templates before the +> first real page-out. Format familiarity under calm conditions ends format thrash +> during emergencies. + Templates for incident response documentation. Copy these when needed. > **Review these templates before your first incident.** Familiarize yourself with the structure so you're not > learning the format during an emergency. Consider running a tabletop exercise to practice filling them out. -## Available Templates +## What this framework covers -| Template | When to Use | -| -------- | ----------- | -| [Incident Log Template](./incident-log-template) | Copy when declaring an incident | -| [Post-Mortem Template](./post-mortem-template) | Copy after resolving a significant incident (P1-P3) | -| [Runbook Template](./runbook-template) | Copy when creating a new scenario-specific runbook | +1. [Incident Log Template](/incident-management/incident-response-template/templates/incident-log-template): + copy when declaring an incident. +2. [Post-Mortem Template](/incident-management/incident-response-template/templates/post-mortem-template): + copy after resolving a significant incident (P1-P3). +3. [Runbook Template](/incident-management/incident-response-template/templates/runbook-template): + copy when creating a new scenario-specific runbook. +4. [Example Incident Log](/incident-management/incident-response-template/templates/example-incident-log): + filled-out incident log for format reference. +5. [Example Post-Mortem](/incident-management/incident-response-template/templates/example-post-mortem): + filled-out post-mortem for format reference. -## Examples +For communication guidance and examples, see +[Communications](/incident-management/incident-response-template/communications). -| Example | Purpose | -| ------- | ------- | -| [Example Incident Log](./example-incident-log) | Shows a filled-out incident log for reference | -| [Example Post-Mortem](./example-post-mortem) | Shows a filled-out post-mortem for reference | +See [Runbooks](/incident-management/incident-response-template/runbooks/overview) for existing +scenario runbooks, and +[Incident Response Policy](/incident-management/incident-response-template/incident-response-policy) +for the full response process. -For communication guidance and examples, see [Communications](../communications). +## Further reading -## Runbook Template +- [Incident Response Template overview](/incident-management/incident-response-template/overview): how the template pieces fit together +- [Incident Log Template](/incident-management/incident-response-template/templates/incident-log-template): fill out during an incident +- [Post-Mortem Template](/incident-management/incident-response-template/templates/post-mortem-template): complete after an incident +- [Runbook Template](/incident-management/incident-response-template/templates/runbook-template): structure for writing your own runbooks -See [Runbooks](../runbooks/overview) for the runbook template and existing runbooks. - -*See [Incident Response Policy](../incident-response-policy) for the full response process.* +--- diff --git a/docs/pages/incident-management/incident-response-template/templates/post-mortem-template.mdx b/docs/pages/incident-management/incident-response-template/templates/post-mortem-template.mdx index 03ee808e7..fef8a94f2 100644 --- a/docs/pages/incident-management/incident-response-template/templates/post-mortem-template.mdx +++ b/docs/pages/incident-management/incident-response-template/templates/post-mortem-template.mdx @@ -1,6 +1,6 @@ --- title: "Post-Mortem Template | Security Alliance" -description: "Complete this after significant incidents (P1-P3). Focus on learning, not blame." +description: "Complete this after significant incidents (P1-P3). Focus on learning, not blame. Timeline, impact, contributing factors, and tracked actions turn pain" tags: - Security Specialist - Operations & Strategy @@ -8,16 +8,30 @@ tags: contributors: - role: wrote users: [hexnickk4997, n0guest] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../../components' +{/* + content-model-exception: + type: template + reason: Reusable template body intentionally uses many H2 placeholders and static task lists for copy-paste. + owner: maintainers +*/} + # Post-Mortem Template +> ๐Ÿ”‘ **Key Takeaway**: Complete a blameless post-mortem after P1โ€“P3 incidents. Timeline, +> impact, contributing factors, and tracked actions turn pain into durable process +> improvement. + Complete this after significant incidents (P1-P3). Focus on learning, not blame. ## How to Use @@ -111,14 +125,14 @@ See linked Incident Log for detailed timeline. 2. 3. -## Where We Got Lucky +### Where We Got Lucky [What fortunate circumstances helped that we shouldn't rely on next time?] 1. 2. -## Action Items +### Action Items > Every action item needs an owner and deadline. @@ -128,9 +142,10 @@ See linked Incident Log for detailed timeline. | | | | | | | | | | -## Lessons for Runbooks +### Lessons for Runbooks -Should we create or update a [runbook](../runbooks/overview) based on this incident? +Should we create or update a + [runbook](/incident-management/incident-response-template/runbooks/overview) based on this incident? - [ ] New runbook needed: [type] @@ -138,7 +153,7 @@ Should we create or update a [runbook](../runbooks/overview) based on this incid - [ ] No runbook changes needed -## Detection +### Detection | Aspect | Details | | ------ | ------- | @@ -146,19 +161,28 @@ Should we create or update a [runbook](../runbooks/overview) based on this incid | Time to detection | | | Could we detect faster? | | -## Links +### Links - Incident Log: [Link to incident log] - Relevant PRs: - Dashboards: - External references: -## Meeting Notes +### Meeting Notes **Attendees:** **Discussion points:** -*Template based on [Incident Response Policy](../incident-response-policy#step-6-post-incident-review)* +*Template based on [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy#step-6-post-incident-review)* + +## Further reading + +- [Templates overview](/incident-management/incident-response-template/templates/overview): how the templates in this section fit together +- [Example Post-Mortem](/incident-management/incident-response-template/templates/example-post-mortem): a completed write-up to model +- [Incident Log Template](/incident-management/incident-response-template/templates/incident-log-template): the record this draws from +- [Lessons Learned](/incident-management/lessons-learned): turning findings into durable change + +--- diff --git a/docs/pages/incident-management/incident-response-template/templates/runbook-template.mdx b/docs/pages/incident-management/incident-response-template/templates/runbook-template.mdx index 84cd4e470..477494104 100644 --- a/docs/pages/incident-management/incident-response-template/templates/runbook-template.mdx +++ b/docs/pages/incident-management/incident-response-template/templates/runbook-template.mdx @@ -1,6 +1,6 @@ --- title: "Runbook Template | Security Alliance" -description: "Copy this template to create runbooks for specific incident types." +description: "Copy this template to create runbooks for specific incident types. Clone this structure for each scenario: quick reference, detection, containment" tags: - Security Specialist - Operations & Strategy @@ -8,16 +8,30 @@ tags: contributors: - role: wrote users: [hexnickk4997, n0guest] - + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../../components' +{/* + content-model-exception: + type: template + reason: Reusable template body intentionally uses many H2 placeholders and static task lists for copy-paste. + owner: maintainers +*/} + # Runbook Template +> ๐Ÿ”‘ **Key Takeaway**: Clone this structure for each scenario: quick reference, detection, +> containment, eradication, recovery, and communication. Fill real commands and owners +> before an incident, not during one. + Copy this template to create runbooks for specific incident types. # Runbook: [INCIDENT TYPE] @@ -111,7 +125,7 @@ If you see [X] but not [Y], it might be [different issue] instead. ## Escalation -Escalate to [Contacts](../contacts) if: +Escalate to [Contacts](/incident-management/incident-response-template/contacts) if: - [ ] Mitigation doesn't work within [time] @@ -124,19 +138,23 @@ Escalate to [Contacts](../contacts) if: - [ ] Mitigation verified - [ ] Stakeholders notified -- [ ] Timeline documented in [Incident Log](../templates/incident-log-template) +- [ ] Timeline documented in [Incident Log](/incident-management/incident-response-template/templates/incident-log-template) - [ ] Post-mortem scheduled if warranted -## Common Root Causes +### Common Root Causes | Cause | Signs | Fix | | ----- | ----- | --- | | | | | -## Related +## Further reading -- Related runbook for this scenario -- [Incident Response Policy](../incident-response-policy) +- [Templates overview](/incident-management/incident-response-template/templates/overview): how the templates in this section fit together +- [Runbooks overview](/incident-management/incident-response-template/runbooks/overview): how the runbooks in this section fit together +- [Key Compromise runbook](/incident-management/incident-response-template/runbooks/key-compromise): a worked example of this structure +- [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy): severity levels, roles, and escalation + +--- diff --git a/docs/pages/incident-management/lessons-learned.mdx b/docs/pages/incident-management/lessons-learned.mdx index 44d44f8e9..8d77841a8 100644 --- a/docs/pages/incident-management/lessons-learned.mdx +++ b/docs/pages/incident-management/lessons-learned.mdx @@ -1,11 +1,18 @@ --- title: "Incident Lessons Learned | Security Alliance" -description: "Conduct post-incident reviews to improve response capabilities. Document timelines, root causes, and action plans. Share lessons with the ecosystem to promote security awareness." +description: "Conduct post-incident reviews to improve response capabilities. Document timelines, root causes, and action plans. By analyzing what went well and what" tags: - Security Specialist - Operations & Strategy - DevOps - SRE +contributors: + - role: wrote + users: [] + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter } from '../../../components' @@ -15,11 +22,15 @@ import { TagList, AttributionList, ContributeFooter } from '../../../components' +> ๐Ÿ”‘ **Key Takeaway**: Review every significant incident blamelessly while memory is fresh. +> Capture timeline, root cause, and owners with deadlines so the output is procedure +> change, not a tucked-away write-up. + Conducting a post-incident review and identifying lessons learned will improve your project's incident response capabilities. By analyzing what went well and what could be improved, you can enhance your readiness for future incidents. -## Best Practices +## Best practices 1. Review the incident together with everybody involved in handling it shortly after the incident is resolved. 2. Record details about the incident, including the timeline, root cause, impact, and response efforts. @@ -57,6 +68,13 @@ For a concrete post-mortem structure and example write-up, see and [Incident Response Template: Example Post-Mortem](/incident-management/incident-response-template/templates/example-post-mortem). +## Further reading + +- [Incident Management overview](/incident-management/overview): how the pages of this framework fit together +- [Post-Mortem Template](/incident-management/incident-response-template/templates/post-mortem-template): the structure for writing it up +- [Example Post-Mortem](/incident-management/incident-response-template/templates/example-post-mortem): a completed example to model +- [Security Metrics and KPIs](/governance/security-metrics-kpis): tracking whether lessons changed outcomes + --- diff --git a/docs/pages/incident-management/overview.mdx b/docs/pages/incident-management/overview.mdx index 59e99b312..ab46d2830 100644 --- a/docs/pages/incident-management/overview.mdx +++ b/docs/pages/incident-management/overview.mdx @@ -1,11 +1,18 @@ --- title: "Incident Management | Security Alliance" -description: "Incident Management Framework: Prepare for, detect, respond to, and recover from security incidents. Build response plans, communication strategies, playbooks, and lessons learned processes." +description: "Incident management for Web3: prepare detection and response, communications, forensics, playbooks, SEAL 911 paths, and a customizable IR template with runbooks." tags: - Security Specialist - Operations & Strategy - DevOps - SRE +contributors: + - role: wrote + users: [] + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter } from '../../../components' @@ -15,19 +22,83 @@ import { TagList, AttributionList, ContributeFooter } from '../../../components' -Incident management involves preparing for, detecting, responding to, and recovering from security incidents. By -thinking about incident management prior to actually experiencing an incident, you can help increase the likelihood of a -timely recovery. +> ๐Ÿ”‘ **Key Takeaway**: Decide who leads, how you communicate, and what to freeze before the incident. Web3 response +> windows are short and many losses are irreversible. -## Contents +Incident management is preparing for, detecting, responding to, and recovering from security incidents. Plans written +under stress lose to plans practiced in calm. This framework covers communication, detection and response, forensic +preparation, lessons learned, SEAL-oriented victim playbooks, and a full customizable incident response template with +policy, templates, and technical runbooks. -1. [Communication Strategies](/incident-management/communication-strategies) -2. [Incident Detection and Response](/incident-management/incident-detection-and-response) -3. [Forensic Readiness](/incident-management/forensic-readiness) -4. [Lessons Learned](/incident-management/lessons-learned) -5. [Playbooks](/incident-management/playbooks/overview) +## What this framework covers + +1. [Communication Strategies](/incident-management/communication-strategies): spokespeople, schedules, and stakeholder + updates without spreading unconfirmed claims. +2. [Incident Detection and Response](/incident-management/incident-detection-and-response): find incidents early and work + a basic response cycle. +3. [Forensic Readiness](/incident-management/forensic-readiness): preserve trustworthy evidence before you need it + (`dev` page โ€” in progress). +4. [Lessons Learned](/incident-management/lessons-learned): post-incident review that improves the next response. +5. [Playbooks](/incident-management/playbooks/overview): scenario playbooks and SEAL 911 victim guidance. +6. [Incident Response Template](/incident-management/incident-response-template/overview): policy, roles, contacts, + copy-ready templates, and technical runbooks for Web3 protocols. + +### Playbooks subsection + +1. [Playbooks overview](/incident-management/playbooks/overview) +2. [Malware Infection](/incident-management/playbooks/malware) +3. [North Korea (DPRK) Attack](/incident-management/playbooks/hacked-dprk) +4. [Wallet Drainer Attack](/incident-management/playbooks/hacked-drainer) +5. [ELUSIVE COMET Attack](/incident-management/playbooks/hacked-elusive-comet) 6. [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines) -7. [Incident Response Template](/incident-management/incident-response-template/overview) +7. [Decentralized Incident Response Framework (DeIRF)](/incident-management/playbooks/decentralized-ir) + +### Incident response template subsection + +1. [Template overview](/incident-management/incident-response-template/overview) +2. [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy) +3. [Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing) +4. [Communications](/incident-management/incident-response-template/communications) +5. [Contacts](/incident-management/incident-response-template/contacts) +6. [Templates hub](/incident-management/incident-response-template/templates/overview) +7. [Runbooks hub](/incident-management/incident-response-template/runbooks/overview) + +### IR templates + +1. [Incident Log Template](/incident-management/incident-response-template/templates/incident-log-template) +2. [Post-Mortem Template](/incident-management/incident-response-template/templates/post-mortem-template) +3. [Runbook Template](/incident-management/incident-response-template/templates/runbook-template) +4. [Example Incident Log](/incident-management/incident-response-template/templates/example-incident-log) +5. [Example Post-Mortem](/incident-management/incident-response-template/templates/example-post-mortem) + +### IR runbooks + +1. [Smart Contract Exploit](/incident-management/incident-response-template/runbooks/smart-contract-exploit) +2. [Key Compromise](/incident-management/incident-response-template/runbooks/key-compromise) +3. [Frontend Compromise](/incident-management/incident-response-template/runbooks/frontend-compromise) +4. [DNS Hijack](/incident-management/incident-response-template/runbooks/dns-hijack) +5. [CDN/Hosting Compromise](/incident-management/incident-response-template/runbooks/cdn-hosting-compromise) +6. [Dependency Attack](/incident-management/incident-response-template/runbooks/dependency-attack) +7. [Build Pipeline Compromise](/incident-management/incident-response-template/runbooks/build-pipeline-compromise) +8. [DDoS Attack](/incident-management/incident-response-template/runbooks/ddos-attack) +9. [Third-Party Outage](/incident-management/incident-response-template/runbooks/third-party-outage) + +## Related frameworks + +- [Monitoring](/monitoring/overview): signals that feed detection +- [Multisig for Protocols](/multisig-for-protocols/overview): emergency signer and admin paths +- [Wallet Security](/wallet-security/overview): key and signer hygiene adjacent to compromise playbooks +- [DPRK IT Workers](/dprk-it-workers/overview): long-running human threat context for DPRK playbooks +- [Supply Chain](/supply-chain/overview): dependency and pipeline incidents +- [Infrastructure](/infrastructure/overview): DNS, DDoS, and hosting response context +- [SEAL Certifications](/certs/overview): certification paths related to ops maturity + +## Further reading + +- [Incident Response Template](/incident-management/incident-response-template/overview): the customization checklist + for adapting these documents +- [SEAL 911](https://securityalliance.org/seal-911): emergency response coordination +- [Rekt News](https://rekt.news/): public post-mortems to learn from --- diff --git a/docs/pages/incident-management/playbooks/decentralized-ir.mdx b/docs/pages/incident-management/playbooks/decentralized-ir.mdx index 8e24ee933..b8b0c3750 100644 --- a/docs/pages/incident-management/playbooks/decentralized-ir.mdx +++ b/docs/pages/incident-management/playbooks/decentralized-ir.mdx @@ -1,6 +1,6 @@ --- title: "Decentralized Incident Response | SEAL" -description: "Decentralized Incident Response Framework (DeIRF) for security teams without a single authority. Zero-trust by default, shared responsibility, and open tooling for faster containment." +description: "Decentralized Incident Response Framework (DeIRF) for security teams without a single authority. Zero-trust by default, shared responsibility" tags: - Security Specialist - Operations & Strategy @@ -9,7 +9,12 @@ tags: contributors: - role: wrote users: [relotnek] + - role: reviewed + users: [] + - role: fact-checked + users: [] --- + import { TagList, AttributionList, ContributeFooter } from '../../../../components' # Decentralized Incident Response Framework (DeIRF) @@ -17,6 +22,10 @@ import { TagList, AttributionList, ContributeFooter } from '../../../../componen +> ๐Ÿ”‘ **Key Takeaway**: DeIRF is a menu for teams without a single authority: zero-trust +> defaults, shared responsibility, and open tooling. Prefer simple fundamentals over +> heavy process nobody will follow. + A lightweight, end-to-end scaffold for security teams that work without a single authority. Use it as a menu, not a mandate. @@ -145,6 +154,13 @@ Keep a one-liner command ready for each action and store it in the runbook. > **Remember**: Simplicity plus strong fundamentals beat heavy processes every time. +## Further reading + +- [Playbooks overview](/incident-management/playbooks/overview): how the playbooks in this section fit together +- [Incident Management overview](/incident-management/overview): how the pages of this framework fit together +- [Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing): assigning response roles without a central team +- [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines): reaching outside help fast + --- diff --git a/docs/pages/incident-management/playbooks/hacked-dprk.mdx b/docs/pages/incident-management/playbooks/hacked-dprk.mdx index bb1d253a3..a169a2f75 100644 --- a/docs/pages/incident-management/playbooks/hacked-dprk.mdx +++ b/docs/pages/incident-management/playbooks/hacked-dprk.mdx @@ -1,12 +1,16 @@ --- title: "North Korea (DPRK) Attack Response | SEAL" -description: "Respond to North Korea (DPRK) cyberattacks. Learn how hacking squads use fake video conference software and fake PDFs to steal private keys, files, and credentials. Immediate response steps included." +description: "Respond to North Korea (DPRK) cyberattacks. Learn how hacking squads use fake video conference software and fake PDFs to steal private keys, files" tags: - Security Specialist - Operations & Strategy contributors: - role: wrote users: [SEAL] + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter } from '../../../../components' @@ -16,6 +20,10 @@ import { TagList, AttributionList, ContributeFooter } from '../../../../componen +> ๐Ÿ”‘ **Key Takeaway**: Treat a confirmed DPRK compromise as full credential and key theft. +> Follow the malware playbook first, assume impersonation risk to contacts, and rotate +> everything reachable from the infected host. + If youโ€™ve been sent this document, then we have very good reason to believe that you have been hacked by North Korea (DPRK). This document will give you some information about North Korea, why theyโ€™ve hacked you, and how they mightโ€™ve done it. @@ -81,6 +89,13 @@ In this method, you are sent a link to download a report, slide deck, or other p If you download and run this file, you will have executed the malware. The first thing the malware does is open the PDF file you were expecting, so that you do not suspect you were infected. +## Further reading + +- [Playbooks overview](/incident-management/playbooks/overview): how the playbooks in this section fit together +- [DPRK IT Workers](/dprk-it-workers/overview): who the actor is and how they get hired +- [Mitigating DPRK IT Workers](/dprk-it-workers/mitigating-dprk-it-workers): hardening and post-discovery steps +- [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines): reaching outside help fast + --- diff --git a/docs/pages/incident-management/playbooks/hacked-drainer.mdx b/docs/pages/incident-management/playbooks/hacked-drainer.mdx index 50dd72f1d..bc3507278 100644 --- a/docs/pages/incident-management/playbooks/hacked-drainer.mdx +++ b/docs/pages/incident-management/playbooks/hacked-drainer.mdx @@ -1,13 +1,18 @@ --- title: "Wallet Drainer Attack Response | SEAL" -description: "Recover from wallet drainer attacks. Understand how drainers request token approvals, DEX signatures, and 7702 wallet upgrades. Steps to recover control after different drainer types." +description: "Recover from a wallet drainer attack. Identify whether it took token approvals, DEX signatures, an EIP-7702 upgrade, or full key control, then act on that." tags: - Security Specialist - Operations & Strategy contributors: - role: wrote users: [SEAL] + - role: reviewed + users: [] + - role: fact-checked + users: [] --- + import { TagList, AttributionList, ContributeFooter } from '../../../../components' # Wallet Drainer Attack @@ -15,6 +20,10 @@ import { TagList, AttributionList, ContributeFooter } from '../../../../componen +> ๐Ÿ”‘ **Key Takeaway**: Wallet drainers abuse approvals, signatures, and account +> upgradesโ€”not always seed phrases. Identify the drainer type first; recovery steps +> differ for approvals versus full key control. + If youโ€™ve been sent this document, then we believe that your funds have been stolen by a wallet drainer. This document will give you some information about drainers, how they work, and how you can protect yourself going forward. @@ -42,6 +51,13 @@ known to: Depending on which type of drainer affected you, you might need to take different actions to recover control of your wallet. +## Further reading + +- [Playbooks overview](/incident-management/playbooks/overview): how the playbooks in this section fit together +- [Smart Contract Interaction Security](/wallet-security/smart-contract-interaction-security): approvals and signing hygiene that prevent this +- [Understanding Threat Vectors](/awareness/understanding-threat-vectors): how drainer lures reach users +- [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines): reaching outside help fast + --- diff --git a/docs/pages/incident-management/playbooks/hacked-elusive-comet.mdx b/docs/pages/incident-management/playbooks/hacked-elusive-comet.mdx index 2e95cb15e..3870d84b4 100644 --- a/docs/pages/incident-management/playbooks/hacked-elusive-comet.mdx +++ b/docs/pages/incident-management/playbooks/hacked-elusive-comet.mdx @@ -1,13 +1,18 @@ --- title: "ELUSIVE COMET Attack Response | SEAL" -description: "Defend against ELUSIVE COMET threat actor using Zoom remote control attacks. Learn how they impersonate investors and journalists to trick victims into sharing screens and installing malware." +description: "Defend against ELUSIVE COMET threat actor using Zoom remote control attacks. Learn how they impersonate investors and journalists to trick victims into sharing" tags: - Security Specialist - Operations & Strategy contributors: - role: wrote users: [SEAL] + - role: reviewed + users: [] + - role: fact-checked + users: [] --- + import { TagList, AttributionList, ContributeFooter } from '../../../../components' # ELUSIVE COMET Attack @@ -15,6 +20,10 @@ import { TagList, AttributionList, ContributeFooter } from '../../../../componen +> ๐Ÿ”‘ **Key Takeaway**: ELUSIVE COMET social-engineers victims on Zoom into screen share and +> remote control. Never grant remote control or full-screen share to unsolicited +> "investors" or "press." + If youโ€™ve been sent this, then we believe that youโ€™ve been hacked by a threat actor weโ€™ve identified as ELUSIVE COMET. This document will give you some information about drainers, how they work, and how you can protect yourself going forward. @@ -67,6 +76,13 @@ accounts and sending out phishing messages to more people.

A message sent from an account belonging to a victim of ELUSIVE COMET

+## Further reading + +- [Playbooks overview](/incident-management/playbooks/overview): how the playbooks in this section fit together +- [Zoom Hardening](/guides/endpoint-security/zoom-hardening): closing the vector this attack uses +- [Malware playbook](/incident-management/playbooks/malware): response once code has run on the device +- [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines): reaching outside help fast + --- diff --git a/docs/pages/incident-management/playbooks/malware.mdx b/docs/pages/incident-management/playbooks/malware.mdx index 961ffc565..cc7b3a7b7 100644 --- a/docs/pages/incident-management/playbooks/malware.mdx +++ b/docs/pages/incident-management/playbooks/malware.mdx @@ -1,13 +1,18 @@ --- title: "Malware Infection Response | Security Alliance" -description: "Step-by-step malware infection response guide from SEAL 911. Secure crypto assets, notify colleagues, protect accounts from sweeper bots, and recover from MetaMask, Ledger Live, and browser compromises." +description: "Step-by-step malware response from SEAL 911. Secure crypto assets against sweeper bots, notify colleagues, regain accounts, and rebuild on a clean machine." tags: - Security Specialist - Operations & Strategy contributors: - role: wrote users: [SEAL] + - role: reviewed + users: [] + - role: fact-checked + users: [] --- + import { TagList, AttributionList, ContributeFooter } from '../../../../components' # Malware Infection @@ -15,6 +20,10 @@ import { TagList, AttributionList, ContributeFooter } from '../../../../componen +> ๐Ÿ”‘ **Key Takeaway**: If you suspect malware, disconnect and power off immediately, then +> continue from a clean device. Secure crypto assets and accounts before forensic +> curiosity costs more keys. + This is a short guide prepared by SEAL that will help you navigate a malware infection. You have a limited amount of time to reduce the amount of damage that can be done to you. If you need help at any point, contact [**SEAL 911**](https://t.me/seal_911_bot) @@ -173,6 +182,13 @@ Here are some guides specifically for securing your: - [Securing Telegram](/community-management/telegram) - [Securing Google](/opsec/google/overview) +## Further reading + +- [Playbooks overview](/incident-management/playbooks/overview): how the playbooks in this section fit together +- [Endpoint Security](/opsec/endpoint/overview): device hardening that limits the blast radius +- [Drainer playbook](/incident-management/playbooks/hacked-drainer): response if wallet access followed +- [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines): reaching outside help fast + --- diff --git a/docs/pages/incident-management/playbooks/overview.mdx b/docs/pages/incident-management/playbooks/overview.mdx index d9fe0721c..4bb84a7d7 100644 --- a/docs/pages/incident-management/playbooks/overview.mdx +++ b/docs/pages/incident-management/playbooks/overview.mdx @@ -1,9 +1,16 @@ --- title: "Incident Response Playbooks | Security Alliance" -description: "Create step-by-step incident response playbooks for stolen funds, data breaches, and DDoS attacks. Define indicators of compromise (IOCs), containment actions, and recovery procedures." +description: "Create step-by-step incident response playbooks for stolen funds, data breaches, and DDoS attacks. Define indicators of compromise (IOCs), containment actions" tags: - Security Specialist - Operations & Strategy +contributors: + - role: wrote + users: [] + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter } from '../../../../components' @@ -13,15 +20,33 @@ import { TagList, AttributionList, ContributeFooter } from '../../../../componen -Generally speaking, incident response playbooks aim to provide detailed, step-by-step procedures for handling specific -types of security incidents. Obviously, it's not possible to have thought about every possible scenario ahead of time, -but one could create documentation for the most likely or devastating scenarios. +> ๐Ÿ”‘ **Key Takeaway**: Write playbooks for your most likely and most devastating scenarios +> before they hit. Each playbook should cover detection IOCs, containment, eradication, +> recovery, and a lessons-learned loop. -## Best Practices +Incident response playbooks provide step-by-step procedures for handling specific security incidents. +You cannot cover every scenario ahead of time, so prioritize the most likely and most devastating cases. + +## What this framework covers + +1. [Malware Infection](/incident-management/playbooks/malware): immediate containment when a host may be + compromised. +2. [North Korea (DPRK) Attack](/incident-management/playbooks/hacked-dprk): victim guidance for confirmed + DPRK compromise paths. +3. [Wallet Drainer Attack](/incident-management/playbooks/hacked-drainer): recover control after approval + or signature drainage. +4. [ELUSIVE COMET Attack](/incident-management/playbooks/hacked-elusive-comet): Zoom remote-control social + engineering response. +5. [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines): how to + engage SEAL 911 and run a crisis channel. +6. [Decentralized Incident Response Framework (DeIRF)](/incident-management/playbooks/decentralized-ir): + IR scaffold for teams without a single authority. + +## Best practices 1. Define the type of incident the playbook addresses (e.g., stolen funds, data breach, DDoS attack). -2. Outline the steps for detecting and analyzing the incident, including key indicators of compromise (IOCs) and tools -to use. +2. Outline the steps for detecting and analyzing the incident, including key indicators of compromise + (IOCs) and tools to use. 3. Describe immediate actions to contain the incident and prevent further damage. 4. Provide detailed steps for eradicating the root cause of the incident. 5. Outline procedures for restoring everything affected to normal operation. @@ -30,6 +55,13 @@ to use. For example incident runbooks and templates, see [Incident Response Template: Templates](/incident-management/incident-response-template/templates/overview). +## Further reading + +- [Incident Management overview](/incident-management/overview): how the pages of this framework fit together +- [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines): reaching outside help fast +- [Incident Response Template overview](/incident-management/incident-response-template/overview): how the template pieces fit together +- [Incident Detection and Response](/incident-management/incident-detection-and-response): the detection step before any playbook + --- diff --git a/docs/pages/incident-management/playbooks/seal-911-war-room-guidelines.mdx b/docs/pages/incident-management/playbooks/seal-911-war-room-guidelines.mdx index 74f14a733..20847694e 100644 --- a/docs/pages/incident-management/playbooks/seal-911-war-room-guidelines.mdx +++ b/docs/pages/incident-management/playbooks/seal-911-war-room-guidelines.mdx @@ -1,12 +1,16 @@ --- title: "SEAL 911 War Room Guidelines | SEAL" -description: "SEAL 911 War Room guidelines for smart contract hack response. Create incident channels, assign key roles, gather attack transactions, pause contracts, and coordinate recovery with the Telegram bot." +description: "SEAL 911 War Room guidelines for smart contract hack response. Create incident channels, assign key roles, gather attack transactions, pause contracts" tags: - Security Specialist - Operations & Strategy contributors: - role: wrote users: [SEAL] + - role: reviewed + users: [] + - role: fact-checked + users: [] --- import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../components' @@ -16,6 +20,10 @@ import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../ +> ๐Ÿ”‘ **Key Takeaway**: SEAL 911 coordinates trusted researchers via the Telegram bot under +> a strict code of conduct. Bring complete incident facts early so responders avoid +> duplicated work during a crisis. + SEAL 911 is a project designed to give users, developers, and even other security researchers an accessible method to contact a small group of highly trusted security researchers. The group can be reached via the [Telegram bot](https://t.me/seal_911_bot). @@ -283,6 +291,13 @@ Funds at Risk: [Estimated Amount in USD or Token] [Brief Description of the incident] ``` +## Further reading + +- [Playbooks overview](/incident-management/playbooks/overview): how the playbooks in this section fit together +- [Incident Management overview](/incident-management/overview): how the pages of this framework fit together +- [Contacts template](/incident-management/incident-response-template/contacts): the contact list to have ready before you need it +- [Communications template](/incident-management/incident-response-template/communications): coordinating public messaging during the incident + ---