Runbooks, response and post-incident hardening

The runbook makes containment happen in minutes, and the post-incident turns what hurt into a permanent defense, in the application and not only at the edge.

PagerDutyCloudflare RulesTerraformCSP Evaluator

What it is

Runbooks are short, actionable scripts for the most likely incidents: who decides, what to check, which action to take and how to undo it. A good runbook fits on one screen and works at three in the morning, for someone who just woke up.

Post-incident hardening is the other side: the edge contains, but only the fix in the application and the configuration prevents a repeat.

Containment ladder with expiry

In volumetric or abuse attacks, the response escalates in steps, each with a TTL, so a misclassification does not block anyone forever. Start with a challenge (cheap for the legitimate user, expensive for the robot) and only then block.

runbook: credential stuffing on loginyaml

trigger: alert login_failures_zscore > 4 for 3 minutes
owner: soc-l7 (on-call)
steps:
  - verify: dominant ASNs and fingerprints, accounts tried (distinct vs repeated)
  - contain:
      1: Managed Challenge on offending ASNs        # TTL 30 min
      2: Block on confirmed fingerprints             # TTL 4 h
      3: require MFA / forced reset on accounts with suspicious success
  - communicate: channel #incidentes, update every 30 min
  - undo: remove rules if the failure rate returns to baseline for 30 min
after: post-mortem within 5 business days

Blameless post-mortem

The goal is to learn, not to find someone to blame. A good post-mortem records the timeline (when it started, when we detected, when we contained), the cause, what worked, what got in the way and actions with owners and deadlines. Detection and containment metrics come out of it and feed tuning.

Hardening in the application

Every incident points to controls that should not depend on the edge. Three frequent examples:

CSP with nonce: a content security policy that only runs scripts with a per-request nonce, reducing the impact of .
Strict : explicit allowed origins, no wildcard on endpoints with credentials.
Schema validation at the gateway: reject bodies and parameters that do not match the API specification, the applied close to the application.

Example: CSP with nonce

response headertext

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{random-per-request}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';
  frame-ancestors 'none'

Exercises

An untested runbook is an assumption. Tabletop exercises and simulations with synthetic traffic reveal gaps in permissions, contacts and tooling before the real incident, and keep the team trained.

XSScross-site scriptingInjection into a web page: untrusted input is rendered as HTML or script in another user's browser. Escape on output by context and add a Content-Security-Policy.see in glossary →CORScross-origin resource sharingA browser mechanism that lets a server say which other origins may read its responses. A wildcard origin combined with credentials is a misconfiguration.see in glossary →Positive modelallowlistDefine what is valid for an endpoint (methods, paths, formats, sizes) and block everything else. More precise than signatures, but requires knowing the application.see in glossary →

connections on the map

Bot managementtriggersRunbooks, response and post-incident hardening
WAF - observation, shadow and enforcementexecutesRunbooks, response and post-incident hardening

updated on 14/10/2026 · sources to go deeper · report an error

in other domains

The incident response lifecycleresponserunbooks are the rehearsed, written-down cycle
SASTappsecpost-incident hardening becomes a rule and a fix in code
Cloud incident responsecloudsecthe L7 runbook is a specific case of the general response
Security automation and playbooks as codesecengthe runbook that becomes an automated playbook, with brakes

Study before

test what you learned

Loading questions…