Part 6: Appendices¶

Back to Handbook contents | Series index

Part 1, Section 1.4 told a team already mid-incident to skip straight to the matching playbook and "the appendix templates." This is where those templates live. This part collects the reference material a responder reaches for during an incident rather than reads once and sets aside: a glossary consolidating every acronym and role name defined across Parts 1 through 5, the full severity and triage matrix that Part 3, Section 6.2 promised but deferred, a vetted list of monitoring, forensics, and communication tooling, and a set of copy-ready message templates for the channels Part 2 defines. Appendix E closes the handbook by pointing to the complete, categorized bibliography rather than duplicating it here.

19. Appendix A: Glossary¶

A responder should not have to search five parts to remember what an acronym meant the first time it appeared. This glossary gathers every term and role name used in the handbook into one lookup table, grouped by the kind of work each belongs to, with a pointer back to where it was first introduced.

Lifecycle and governance

Roles and identity

Technical and on-chain

Communication, legal, and recovery

20. Appendix B: Severity and Triage Matrix¶

Part 3, Section 6.2 introduced the four-tier severity model every triage call in this handbook runs through and promised the full, standalone version here. Copy this table into your own runbook rather than re-deriving it from memory during a live incident; the Triage Lead role (Part 1, 3.3) exists specifically to apply it under pressure, not to invent it on the spot.

A four-tier model resolves which channel and which people get paged, but it does not rank two Critical findings against each other, and a live incident often produces more than one candidate at the same tier simultaneously. Part 3, Section 6.2 called this "CVSS-adjacent scoring guidance for cases that need finer granularity"; the table below borrows the base-metric structure of the FIRST CVSS v4.0 specification (Common Vulnerability Scoring System) without computing a full CVSS score, adapting it to on-chain incident triage rather than pre-disclosure vulnerability rating.

Sum the four dimension scores (0 to 12) to break ties within a severity tier: two Critical findings both score in the 9 to 12 range by definition of the tier's criteria, and the Containment Lead works the higher composite score first when resources cannot address both simultaneously. This is a prioritization aid, not a formal CVSS calculation, and it never overrides the tier assigned by the primary matrix above.

flowchart TD
    A[Report or alert received] --> B{Funds actively moving\nto an attacker right now?}
    B -->|Yes| C[CRITICAL\nPage full IRT, activate war room]
    B -->|No| D{Was an exploit already executed\nwith a bounded, realized loss?}
    D -->|Yes| E[HIGH\nPage Triage, Containment, Comms Leads]
    D -->|No loss yet| F{Is the vulnerability confirmed\nexploitable, e.g. working PoC?}
    F -->|Yes| G[MEDIUM\nNotify on-call, schedule same-day review]
    F -->|No, theoretical or cosmetic| H[LOW\nLog to ticket queue]

Figure 1. Triage decision tree. Each branch resolves to one severity tier from the primary matrix; the fine-grained scoring table only breaks ties among findings that land in the same tier.

A copy-ready worksheet turns this into something the Triage Lead fills out live rather than holds in their head:

# triage/worksheet_template.yaml
incident_id: ""
reported_at_utc: ""
reported_by: ""
first_signal_block_number: ""
funds_actively_moving: null        # true/false
loss_confirmed_bounded: null       # true/false
exploit_confirmed_reproducible: null  # true/false
initial_severity: ""               # Critical/High/Medium/Low
fine_grained_scoring:
  exploitability: null             # 0-3
  scope: null                      # 0-3
  fund_impact: null                # 0-3
  reversibility: null              # 0-3
escalated_to: []
war_room_activated: null

21. Appendix C: Suggested Tools and Platforms¶

None of the entries below are endorsements. They are the categories of capability the readiness checklist in Part 3, Chapter 7 assumes exist somewhere in your stack, with named examples so a team starting from zero has a concrete place to begin evaluating rather than a blank page. Weigh each candidate against your own asset inventory (Part 3, 7.1) and severity matrix (Appendix B) rather than adopting a tool because a peer protocol uses it.

On-chain monitoring and alerting

Infrastructure and application monitoring

Forensics and chain analysis

Evidence and secrets storage

Secure communications

Bug bounty and responsible disclosure

Threat intelligence and community response

Signer and fund-movement authorization

22. Appendix D: Message and Communication Templates¶

Part 2, Section 4.3.1 established that every incident communication should start from a pre-approved template rather than an improvised draft written under pressure. The six templates below are that starting point. Fill in the bracketed fields, keep the structure, and route every one of them through the Comms Lead (Part 1, 3.4) before it goes anywhere near a public channel; a template used unreviewed is only marginally better than no template at all.

Template 1: Internal incident declaration (paging message)

[SEVERITY] Incident declared: <one-line description>
Declared by: <Triage Lead>
Time (UTC): <timestamp> | Block: <block number>
Affected: <contract(s) / system(s)>
War room: <link or channel>
Next update: <time>

Template 2: Public holding statement (first hour)

We are aware of a potential security incident affecting <protocol/component>.
We have <action taken, e.g. "paused the affected contract"> as a precaution.
No further action is required from users at this time. / Users should
<specific action> until further notice.
We will post a further update by <fixed time, UTC>.

Template 3: Scheduled status update (recurring cadence)

Status update <N>, <timestamp UTC>

What we know: <verified facts only, no speculation>
What we have done: <containment/eradication actions completed>
What is next: <planned next step>
Next update by: <fixed time, UTC>

Template 4: Resolution and all-clear statement

As of <timestamp UTC>, the incident affecting <protocol/component> is resolved.
Root cause: <one-sentence summary; full postmortem link below>
Funds affected: <amount/status, e.g. "fully recovered", or "partial loss
of $X, restitution plan below">
Restitution: <link, or "not applicable">
Full postmortem: <link, published within the window committed to in Part 5>

Template 5: GPG-signed authenticity notice

Use this whenever official channels may themselves be compromised, the exact scenario Part 1, Section 3.7 built the fingerprint-publication requirement for.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

This statement is authentic and was issued by <organization>.
Verify against fingerprint: <published GPG fingerprint>
Statement: <the exact text of the public statement being authenticated>
-----BEGIN PGP SIGNATURE-----
<signature block>
-----END PGP SIGNATURE-----

Template 6: Exchange or stablecoin issuer freeze request

Subject: Urgent, security incident, freeze request for address <0x...>

<Exchange/Issuer security team>,

We are <organization>, operator of <protocol>. At <timestamp UTC>, block <N>,
an exploit moved approximately <amount, asset> to address <0x...>. Supporting
evidence (transaction hash, trace, public incident statement) is attached
or linked below.

We request an emergency freeze or enhanced monitoring on this address and any
funds that move from it. Point of contact for follow-up: <name, verified
channel, GPG fingerprint>.

Reference: <public incident statement URL>

flowchart LR
    D[Detected] --> T1[Template 1\ninternal declaration]
    T1 --> Tr[Triaging]
    Tr --> T2[Template 2\npublic holding statement]
    T2 --> C[Contained]
    C --> T3[Template 3\nscheduled status update]
    T3 --> Er[Eradicating]
    Er --> T3
    Er --> R[Recovering]
    R --> T4[Template 4\nresolution/all-clear]
    T4 --> Cl[Closed]
    Cl --> PM[PostMortem, Part 5]

Figure 2. Which template fires at which incident phase, mapped against the state diagram in Part 3, Figure 3. Template 5 (GPG authenticity) and Template 6 (freeze request) are not phase-bound: use Template 5 whenever a statement's authenticity might be questioned, and Template 6 the moment an attacker address is known, regardless of phase.

23. Appendix E: References and Further Reading¶

This handbook's complete, deduplicated source list lives in references.md, grouped into Standards and Frameworks, Incidents and Case Studies, Tools, and Further Reading, following the series convention (the series conventions). It is not reproduced here, so that the two documents never drift out of sync; treat references.md as the current bibliography and this section as a pointer to the five publications the handbook leans on most.

23.1 Standards¶

The lifecycle model in Part 1, the supplemental practices in Part 1, Section 2.6, and the evidence-handling discipline in Part 3 all trace back to a small set of NIST publications. Everything else this handbook cites, RFCs, incident post-mortems, and tool documentation, supports a specific claim in a specific chapter and is listed in full in references.md rather than here.

23.1.1 NIST SP 800-61r3, CSF 2.0, SP 800-92, SP 800-184, SP 800-150¶

Five NIST documents anchor this handbook's structure. SP 800-61 Revision 3 (April 2025) supplies the core lifecycle, nesting incident response inside the Cybersecurity Framework 2.0's six functions (Part 1, 2.1). SP 800-92 Revision 1, an initial public draft dated October 2023, governs the log management lifecycle behind Part 1, Section 2.6.1 and Part 3, Section 7.2. SP 800-184 (December 2016) grounds the recovery-rehearsal argument in Part 1, Section 2.6.2 and the drill schedule in Part 3, Section 7.6. SP 800-150 (October 2016) frames the threat-information-sharing relationships, SEAL 911 among them, referenced in Part 1, Section 2.6.3. A sixth publication outside this named set, SP 800-86, Guide to Integrating Forensic Techniques into Incident Response, underlies the evidence-collection ordering in Part 3, Section 6.3 and is listed alongside these five in references.md.

Key controls for Part 6

• Keep the glossary, severity matrix, and tool list from this part inside your own runbook, not just this handbook, so nobody is searching for definitions mid-incident.
• Have the Triage Lead fill out the Appendix B worksheet live during triage; the fine-grained scoring table breaks ties, it never overrides the primary four-tier matrix.
• Select and pre-provision the Appendix C tool categories before an incident; evaluating a monitoring or forensics platform for the first time during a live drain is a preparation failure, not a response one.
• Route every Appendix D template through the Comms Lead and, where authenticity may be questioned, through the GPG signature workflow from Part 1, Section 3.7, before it reaches a public or partner channel.
• Treat references.md as the single current bibliography for this handbook; update it rather than letting citations diverge across parts.

Back to Handbook contents