From c86a3db5bf905d19e5b1c79502e17a09cf70b868 Mon Sep 17 00:00:00 2001 From: "ORCHORDS.COM" Date: Sun, 6 Sep 2026 03:58:52 +0800 Subject: [PATCH] Add Batch 90: NATS, NGINX, Envoy reference + ISO 27005, NIST 800-207, 800-53A, 800-61 standards + NATS failover, NGINX TLS renewal, Envoy hot-reload playbooks --- .../ENVOY_LISTENER_HOT_RELOAD_PLAYBOOK.md | 76 +++++++++++++ .../NATS_CLUSTER_FAILOVER_PLAYBOOK.md | 87 +++++++++++++++ .../NGINX_TLS_CERT_RENEWAL_PLAYBOOK.md | 76 +++++++++++++ docs/knowledge/playbooks/README.md | 6 ++ .../reference/ENVOY_VERSION_GOVERNANCE.md | 102 ++++++++++++++++++ .../reference/NATS_VERSION_GOVERNANCE.md | 96 +++++++++++++++++ .../reference/NGINX_VERSION_GOVERNANCE.md | 94 ++++++++++++++++ docs/knowledge/reference/README.md | 6 ++ ...NIST_SP_800_61_REV3_INCIDENT_GOVERNANCE.md | 95 ++++++++++++++++ docs/knowledge/standards/README.md | 6 ++ 10 files changed, 644 insertions(+) create mode 100644 docs/knowledge/playbooks/ENVOY_LISTENER_HOT_RELOAD_PLAYBOOK.md create mode 100644 docs/knowledge/playbooks/NATS_CLUSTER_FAILOVER_PLAYBOOK.md create mode 100644 docs/knowledge/playbooks/NGINX_TLS_CERT_RENEWAL_PLAYBOOK.md create mode 100644 docs/knowledge/reference/ENVOY_VERSION_GOVERNANCE.md create mode 100644 docs/knowledge/reference/NATS_VERSION_GOVERNANCE.md create mode 100644 docs/knowledge/reference/NGINX_VERSION_GOVERNANCE.md create mode 100644 docs/knowledge/standards/NIST_SP_800_61_REV3_INCIDENT_GOVERNANCE.md diff --git a/docs/knowledge/playbooks/ENVOY_LISTENER_HOT_RELOAD_PLAYBOOK.md b/docs/knowledge/playbooks/ENVOY_LISTENER_HOT_RELOAD_PLAYBOOK.md new file mode 100644 index 000000000..cd64517d3 --- /dev/null +++ b/docs/knowledge/playbooks/ENVOY_LISTENER_HOT_RELOAD_PLAYBOOK.md @@ -0,0 +1,76 @@ +# Envoy Listener Hot Reload Playbook + +## Purpose + +Define the operational procedure for safely reloading Envoy listener configuration without dropping in-flight connections. The procedure covers both LDS (Listener Discovery Service) hot reload and full restart scenarios. + +## Audience + +Platform engineers, SREs, and gateway operators. + +## Pre-conditions + +- Envoy 1.25+ (per `ENVOY_VERSION_GOVERNANCE.md`). +- The Envoy instance is part of an xDS-managed fleet OR a self-managed fleet. +- Hot restart is enabled. + +## Procedure + +### Step 1 — Detect + +1. Confirm the listener config drift: `curl localhost:9901/config_dump | jq '.configs[1].dynamic_active_clusters'`. +2. Confirm the listener is accepting connections: `curl localhost:9901/ready`. + +### Step 2 — Author the new config + +3. Edit the bootstrap or LDS source. +4. Validate locally: `envoy --mode validate -c `. +5. If using SOTW (State of the World) xDS, prepare a new snapshot. + +### Step 3 — Hot reload via LDS + +6. Send the new Listener via xDS: + - `curl -X POST localhost:9901/listeners/` (rare). + - Or push via the control plane: `envoy-xds `. +7. Confirm the new listener is `warming`. +8. Confirm Envoy drains old connections via `admin.early_header_conn_end`. + +### Step 4 — Hot reload via full restart + +9. If hot reload is not feasible, perform a hot restart: + - `systemctl reload envoy` (sends SIGHUP, hot restart). + - Confirm the parent and child processes are running. + - Confirm the old listener drains over `drain_timeout`. + +### Step 5 — Verify + +10. Confirm new connections are accepted. +11. Confirm in-flight connections continue. +12. Confirm metrics show the listener is healthy. + +### Step 6 — Validate + +13. Send a synthetic HTTP request. +14. Confirm response matches the new config. +15. Confirm headers / routes / filters behave as expected. + +### Step 7 — Monitor + +16. Confirm 5xx rate is at baseline. +17. Confirm connection error rate is at baseline. +18. Confirm listener accept rate matches expected traffic. + +## Rollback + +If the new listener config breaks traffic: + +1. Hot-restart Envoy to the previous config. +2. If a full restart, restore the previous binary and config. +3. Validate traffic recovery. + +## References + +- `ENVOY_VERSION_GOVERNANCE.md` +- `GITOPS_SYNC_FAILURE_RECOVERY_PLAYBOOK.md` +- Envoy hot restart: `https://www.envoyproxy.io/docs/envoy/latest/operations/hot_restarter` +- Envoy admin: `https://www.envoyproxy.io/docs/envoy/latest/operations/admin` diff --git a/docs/knowledge/playbooks/NATS_CLUSTER_FAILOVER_PLAYBOOK.md b/docs/knowledge/playbooks/NATS_CLUSTER_FAILOVER_PLAYBOOK.md new file mode 100644 index 000000000..97398fefb --- /dev/null +++ b/docs/knowledge/playbooks/NATS_CLUSTER_FAILOVER_PLAYBOOK.md @@ -0,0 +1,87 @@ +# NATS Cluster Failover Playbook + +## Purpose + +Define the operational procedure for recovering a NATS cluster when one or more nodes fail. The procedure covers core NATS (no JetStream), JetStream persistence, and leafnode edges. + +## Audience + +Platform engineers, SREs, and on-call responders. + +## Pre-conditions + +- NATS 2.10+ (per `NATS_VERSION_GOVERNANCE.md`). +- The cluster has at least 3 nodes. +- JetStream is enabled if persistence is required. +- Monitoring emits cluster health events. + +## Procedure + +### Step 1 — Detect + +1. Confirm cluster health: `nats server check connection -s nats://:4222`. +2. Confirm peer list: `nats server list -s nats://:4222`. +3. Confirm JetStream status (if enabled): `nats str list -s nats://:4222`. + +### Step 2 — Diagnose + +4. Identify the failed node(s) via monitoring. +5. Inspect the failed node's logs (`stderr.log` or `journalctl`). +6. Determine root cause: + - Process crash. + - OOM. + - Disk full. + - Network partition. + - Disk corruption (JetStream). + +### Step 3 — Recover a single node + +7. If the failed node is recoverable, restart it: `systemctl restart nats`. +8. Confirm the node rejoins the cluster. +9. Confirm quorum is restored. + +### Step 4 — Recover a partition + +10. If the cluster is partitioned, restore network access. +11. Confirm all nodes rejoin via gossip. +12. Confirm the leader is elected. + +### Step 5 — Recover a JetStream node + +13. If a JetStream node has disk corruption, quarantine the node. +14. Replace the disk. +15. Initialize the JetStream node with the same name. +16. Confirm the stream metadata rebalances. + +### Step 6 — Recover from total loss + +17. If the entire cluster is lost, restore from backup: + - Streams are persisted under `${store_dir}/jetstream`. + - `$JSZ` API or `nats str info` confirms restoration. +18. Reapply configuration from GitOps (per `GITOPS_SYNC_FAILURE_RECOVERY_PLAYBOOK.md`). + +### Step 7 — Verify + +19. Confirm all subjects are reachable. +20. Confirm JetStream consumers can resume. +21. Confirm cluster metrics return to baseline. + +### Step 8 — Postmortem + +22. File a postmortem per `INCIDENT_POSTMORTEM_REVIEW_PLAYBOOK.md`. +23. Identify the failure origin. +24. Add regression tests or guard rails. + +## Rollback + +If recovery introduces regressions: + +1. Restore from backup. +2. Verify against pre-incident snapshots. + +## References + +- `NATS_VERSION_GOVERNANCE.md` +- `INCIDENT_POSTMORTEM_REVIEW_PLAYBOOK.md` +- NATS operations: `https://docs.nats.io/running-a-nats-service/nats_admin` +- JetStream disaster recovery: `https://docs.nats.io/nats-concepts/jetstream/disaster_recovery` diff --git a/docs/knowledge/playbooks/NGINX_TLS_CERT_RENEWAL_PLAYBOOK.md b/docs/knowledge/playbooks/NGINX_TLS_CERT_RENEWAL_PLAYBOOK.md new file mode 100644 index 000000000..203e48a49 --- /dev/null +++ b/docs/knowledge/playbooks/NGINX_TLS_CERT_RENEWAL_PLAYBOOK.md @@ -0,0 +1,76 @@ +# NGINX TLS Certificate Renewal Playbook + +## Purpose + +Define the operational procedure for renewing TLS certificates served by NGINX or the NGINX Ingress Controller without service disruption. The procedure covers both ACME / Let's Encrypt and private CA scenarios. + +## Audience + +Platform engineers, SREs, and security engineers. + +## Pre-conditions + +- NGINX 1.22+ (per `NGINX_VERSION_GOVERNANCE.md`). +- Certificates are managed via cert-manager, acme.sh, or `lego`. +- The renewal job is automated. +- Monitoring alerts on certificate expiry < 30 days. + +## Procedure + +### Step 1 — Detect + +1. Confirm the certificate is approaching expiry. +2. `echo | openssl s_client -servername -connect :443 2>/dev/null | openssl x509 -noout -dates`. +3. Alert threshold: 30 days, 14 days, 7 days. + +### Step 2 — Renew + +4. Trigger the renewal job: + - `cert-manager`: annotation on the Ingress (`cert-manager.io/renew-before`). + - `acme.sh`: `acme.sh --renew -d `. + - `lego`: `lego renew --domain `. +5. Confirm the new certificate is issued. + +### Step 3 — Reload NGINX + +6. Reload NGINX with zero downtime: + - `nginx -s reload`. + - For ingress-nginx: `kubectl exec -n ingress-nginx -- nginx -s reload`. +7. Confirm the new certificate is in memory. + +### Step 4 — Verify + +8. Re-run the `openssl s_client` check. +9. Confirm the new `notAfter` date. +10. Confirm the chain is valid (intermediate + root). + +### Step 5 — Validate against CT logs + +11. Submit the certificate to CT logs (Let's Encrypt does this automatically). +12. Verify via `crt.sh` or `certspotter`. + +### Step 6 — Cleanup + +13. Remove the old certificate from the secret store. +14. Remove the old certificate file from disk. + +### Step 7 — Monitor + +15. Confirm monitoring does not alert after renewal. +16. Update the expiry tracker. + +## Rollback + +If a renewal breaks a domain: + +1. Restore the previous certificate from the secret store. +2. Reload NGINX. +3. Investigate the renewal issue. + +## References + +- `NGINX_VERSION_GOVERNANCE.md` +- `TLS_RFC_8446_VERSION_GOVERNANCE.md` +- cert-manager: `https://cert-manager.io/docs/` +- acme.sh: `https://github.com/acmesh-official/acme.sh` +- Let's Encrypt: `https://letsencrypt.org/docs/` diff --git a/docs/knowledge/playbooks/README.md b/docs/knowledge/playbooks/README.md index 8a439b3b2..431b04112 100644 --- a/docs/knowledge/playbooks/README.md +++ b/docs/knowledge/playbooks/README.md @@ -271,3 +271,9 @@ This family contains repeatable procedures for development, deployment, incident - [Protobuf Schema Deprecation Playbook](PROTOBUF_SCHEMA_DEPRECATION_PLAYBOOK.md) - [OPA Bundle Rotation Playbook](OPA_BUNDLE_ROTATION_PLAYBOOK.md) - [Vault Audit Log Shipping Playbook](VAULT_AUDIT_LOG_SHIPPING_PLAYBOOK.md) + +## 2026-09-05 NATS failover, NGINX TLS renewal, and Envoy hot-reload playbooks (Batch 90) + +- [NATS Cluster Failover Playbook](NATS_CLUSTER_FAILOVER_PLAYBOOK.md) +- [NGINX TLS Certificate Renewal Playbook](NGINX_TLS_CERT_RENEWAL_PLAYBOOK.md) +- [Envoy Listener Hot Reload Playbook](ENVOY_LISTENER_HOT_RELOAD_PLAYBOOK.md) diff --git a/docs/knowledge/reference/ENVOY_VERSION_GOVERNANCE.md b/docs/knowledge/reference/ENVOY_VERSION_GOVERNANCE.md new file mode 100644 index 000000000..aee9522e2 --- /dev/null +++ b/docs/knowledge/reference/ENVOY_VERSION_GOVERNANCE.md @@ -0,0 +1,102 @@ +--- +title: Envoy Proxy Version Governance +owner: Knowledge Engineering +status: approved +classification: public +last-reviewed: 2026-09-05 +review-cycle: 180 days +next-review: 2027-03-04 +source: Envoy documentation; CNCF Envoy project; envoyproxy.io +--- + +# Envoy Proxy Version Governance + +## Scope + +This card governs how `orchords-docs` evaluates the Envoy proxy across versions, xDS APIs, and integration patterns (Ingress, Gateway API, Service Mesh). + +## Why this card exists + +Envoy is the canonical cloud-native L4/L7 proxy, the data plane of Istio, and the reference implementation for the Gateway API. Without an explicit card, the KB cites Envoy practices that ignore the rapid 6-week release cadence and the v3 xDS protocol. + +## Versions + +| Version | Status | +|---|---| +| 1.20–1.24 | legacy | +| 1.25–1.30 | current stable | +| 1.31–1.33 | current | + +References: `https://github.com/envoyproxy/envoy/releases`. + +Envoy has a 6-week minor release cadence. Patch releases are monthly. + +## xDS APIs + +| API | Use | +|---|---| +| `envoy.config.listener.v3.Listener` | listener config | +| `envoy.config.route.v3.RouteConfiguration` | HTTP routes | +| `envoy.config.cluster.v3.Cluster` | upstream clusters | +| `envoy.extensions.transport_sockets.tls.v3` | TLS context | +| `envoy.config.bootstrap.v3.Bootstrap` | bootstrap config | + +The v3 API is mandatory since 1.18; v2 is removed. + +References: `https://www.envoyproxy.io/docs/envoy/latest/configuration/configuration`. + +## Gateway API + +Envoy is a reference implementation of the Kubernetes Gateway API: + +- `GatewayClass`, `Gateway`, `HTTPRoute`, `TCPRoute`. +- Gateway API ≥ v1.0 (since 2023). +- Compatible with `envoy-gateway`, `contour`, `istio`, etc. + +References: `https://gateway-api.sigs.k8s.io/`. + +## Filter chain + +| Filter | Use | +|---|---| +| `envoy.filters.network.http_connection_manager` | HTTP handling | +| `envoy.filters.http.router` | routing | +| `envoy.filters.http.lua` | scripting | +| `envoy.filters.http.ratelimit` | rate limiting | +| `envoy.filters.http.ext_authz` | external authorization | +| `envoy.filters.http.jwt_authn` | JWT validation | +| `envoy.filters.network.tcp_proxy` | L4 proxy | + +## TLS + +- `transport_socket` with `envoy.transport_sockets.tls` context. +- `common_tls_context.tls_certificate_sds_secret_configs` for SDS. +- HTTP/2 ALPN: `h2`. +- HTTP/1.1 fallback. + +## Observability + +| Feature | Use | +|---|---| +| Access logs | JSON, configurable | +| Stats | Prometheus integration | +| Tracing | OpenTelemetry, Zipkin | +| Tap | on-the-wire capture | + +References: `https://www.envoyproxy.io/docs/envoy/latest/operations/`. + +## Cross-reference + +| Domain | Card | +|---|---| +| Istio | `ISTIO_VERSION_GOVERNANCE.md` | +| Kubernetes | `KUBERNETES_VERSION_GOVERNANCE.md` | +| HTTP/3 | `HTTP_3_RFC_9114_VERSION_GOVERNANCE.md` | +| OPA | `OPA_VERSION_GOVERNANCE.md` | + +## Sources + +- Envoy documentation: `https://www.envoyproxy.io/docs/envoy/latest/` +- Envoy releases: `https://github.com/envoyproxy/envoy/releases` +- Envoy quickstart: `https://www.envoyproxy.io/docs/envoy/latest/start/quick-start/` +- Gateway API: `https://gateway-api.sigs.k8s.io/` diff --git a/docs/knowledge/reference/NATS_VERSION_GOVERNANCE.md b/docs/knowledge/reference/NATS_VERSION_GOVERNANCE.md new file mode 100644 index 000000000..003495ba7 --- /dev/null +++ b/docs/knowledge/reference/NATS_VERSION_GOVERNANCE.md @@ -0,0 +1,96 @@ +--- +title: NATS Messaging Version Governance +owner: Knowledge Engineering +status: approved +classification: public +last-reviewed: 2026-09-05 +review-cycle: 180 days +next-review: 2027-03-04 +source: NATS documentation; Synadia; CNCF NATS project; nats.io +--- + +# NATS Messaging Version Governance + +## Scope + +This card governs how `orchords-docs` evaluates NATS — both the core broker and JetStream persistence — across versions, protocols, and deployment topologies. + +## Why this card exists + +NATS is the canonical cloud-native messaging system (CNCF graduated, March 2025). Without an explicit card, the KB cites NATS practices that ignore JetStream persistence model, subject-based addressing, and security best-practices. + +## Versions + +| Version | Status | +|---|---| +| 1.x | legacy core | +| 2.0–2.6 | legacy 2.x | +| 2.7–2.10 | current LTS | +| 2.11 | current | + +References: `https://github.com/nats-io/nats-server/releases`. + +## Protocols + +| Protocol | Use | +|---|---| +| NATS (text) | core pub/sub | +| NKEY | Ed25519-based identity | +| JWT | identity claims | +| TLS | transport encryption | +| WebSocket | browser clients | +| Leafnode | edge-to-core bridging | + +References: `https://docs.nats.io/reference/reference-protocols`. + +## Subject addressing + +NATS uses hierarchical subject addresses: + +- `orders.created` — dot-separated tokens. +- `orders.*.us` — single-token wildcard. +- `orders.>` — multi-token wildcard. + +Subject normalization rules: + +- Tokens are case-sensitive. +- Whitespace is preserved. +- Empty tokens (`..`) are forbidden. + +## JetStream + +JetStream is the persistence layer: + +- Streams: durable, ordered, replayable. +- Consumers: pull, push, durable, queue. +- Retention: limits, interest, work-queue. +- Acknowledgement: explicit, ack, ack-publish, nack, term. + +References: `https://docs.nats.io/nats-concepts/jetstream`. + +## Authentication and authorization + +| Method | Use | +|---|---| +| Token | single static token | +| User / Password | basic auth | +| NKEY | Ed25519 keys | +| JWT | per-user claims + scopes | +| Decentralized JWT | decentralized trust | +| Delegated JWT | central auth server | + +References: `https://docs.nats.io/running-a-nats-service/configuration/securing_nats/auth_intro`. + +## Cross-reference + +| Domain | Card | +|---|---| +| Kafka | `KAFKA_KIP_VERSION_GOVERNANCE.md` | +| AMQP | `AMQP_0_9_1_VERSION_GOVERNANCE.md`, `AMQP_1_0_VERSION_GOVERNANCE.md` | +| MQTT | `MQTT_5_VERSION_GOVERNANCE.md` | + +## Sources + +- NATS documentation: `https://docs.nats.io/` +- NATS GitHub: `https://github.com/nats-io/nats-server` +- Synadia: `https://synadia.com/` diff --git a/docs/knowledge/reference/NGINX_VERSION_GOVERNANCE.md b/docs/knowledge/reference/NGINX_VERSION_GOVERNANCE.md new file mode 100644 index 000000000..a880dd9f0 --- /dev/null +++ b/docs/knowledge/reference/NGINX_VERSION_GOVERNANCE.md @@ -0,0 +1,94 @@ +--- +title: NGINX / NGINX Ingress Controller Version Governance +owner: Knowledge Engineering +status: approved +classification: public +last-reviewed: 2026-09-05 +review-cycle: 180 days +next-review: 2027-03-04 +source: NGINX documentation (nginx.org); F5 NGINX; NGINX Ingress Controller (kubernetes/ingress-nginx) +--- + +# NGINX / NGINX Ingress Controller Version Governance + +## Scope + +This card governs how `orchords-docs` evaluates NGINX (open-source, F5 NGINX Plus) and the kubernetes/ingress-nginx controller across versions, modules, and configuration patterns. + +## Why this card exists + +NGINX is the canonical HTTP reverse proxy and the most widely deployed ingress in Kubernetes. Without an explicit card, the KB cites NGINX practices that ignore the open-core split (nginx vs NGINX Plus), ingress class collisions, and 1.25+ deprecations. + +## Versions + +| Version | Status | +|---|---| +| 1.18–1.21 | legacy stable | +| 1.22 | current stable (open source) | +| 1.24 | current stable | +| 1.25 | current stable | +| 1.26 | current stable | +| 1.27 | current mainline | +| Plus R30+ | enterprise | + +References: `https://nginx.org/en/CHANGES`. + +## Modules + +| Module | Use | +|---|---| +| `ngx_http_ssl_module` | TLS | +| `ngx_http_v2_module` | HTTP/2 | +| `ngx_http_v3_module` | HTTP/3 (1.25+) | +| `ngx_http_proxy_module` | reverse proxy | +| `ngx_http_upstream_module` | upstream groups | +| `ngx_stream_*` | TCP / UDP proxy | + +References: `https://nginx.org/en/docs/`. + +## TLS + +| Setting | Use | +|---|---| +| `ssl_protocols TLSv1.2 TLSv1.3;` | disallow 1.0 / 1.1 | +| `ssl_ciphers` | AEAD-only | +| `ssl_prefer_server_ciphers on;` | server-controlled | +| `ssl_session_cache shared:SSL:10m;` | session reuse | +| `ssl_session_tickets off;` | forward secrecy | + +## HTTP/2 and HTTP/3 + +- HTTP/2 enabled by default since 1.25.1. +- HTTP/3 is `ngx_http_v3_module` (1.25+) — experimental, opt-in. + +References: `https://nginx.org/en/docs/http/ngx_http_v3_module.html`. + +## Ingress controller + +NGINX Ingress Controller for Kubernetes: + +- `kubernetes/ingress-nginx` (community). +- `nginxinc/kubernetes-ingress` (F5 NGINX). +- Versions follow NGINX minor releases. + +Ingress API: + +- `networking.k8s.io/v1` (since 1.22). +- `networking.k8s.io/v1beta1` removed in 1.22. + +References: `https://kubernetes.github.io/ingress-nginx/`. + +## Cross-reference + +| Domain | Card | +|---|---| +| TLS | `TLS_RFC_8446_VERSION_GOVERNANCE.md` | +| HTTP/3 | `HTTP_3_RFC_9114_VERSION_GOVERNANCE.md` | +| Kubernetes | `KUBERNETES_VERSION_GOVERNANCE.md` | + +## Sources + +- NGINX docs: `https://nginx.org/en/docs/` +- NGINX changes: `https://nginx.org/en/CHANGES` +- ingress-nginx: `https://kubernetes.github.io/ingress-nginx/` +- F5 NGINX: `https://docs.nginx.com/` diff --git a/docs/knowledge/reference/README.md b/docs/knowledge/reference/README.md index 075d92dfa..90532a8f7 100644 --- a/docs/knowledge/reference/README.md +++ b/docs/knowledge/reference/README.md @@ -225,3 +225,9 @@ This family contains shared glossaries, checklists, command references, configur - [Protocol Buffers (Protobuf) Version Governance](PROTOBUF_VERSION_GOVERNANCE.md) - [Open Policy Agent (OPA / Rego) Version Governance](OPA_VERSION_GOVERNANCE.md) - [HashiCorp Vault Version Governance](VAULT_VERSION_GOVERNANCE.md) + +## 2026-09-05 Messaging, ingress, and proxy reference cards (Batch 90) + +- [NATS Messaging Version Governance](NATS_VERSION_GOVERNANCE.md) +- [NGINX / NGINX Ingress Controller Version Governance](NGINX_VERSION_GOVERNANCE.md) +- [Envoy Proxy Version Governance](ENVOY_VERSION_GOVERNANCE.md) diff --git a/docs/knowledge/standards/NIST_SP_800_61_REV3_INCIDENT_GOVERNANCE.md b/docs/knowledge/standards/NIST_SP_800_61_REV3_INCIDENT_GOVERNANCE.md new file mode 100644 index 000000000..cc634f813 --- /dev/null +++ b/docs/knowledge/standards/NIST_SP_800_61_REV3_INCIDENT_GOVERNANCE.md @@ -0,0 +1,95 @@ +--- +title: NIST SP 800-61 Rev. 3 (Draft) Incident Response Recommendations Governance +owner: Knowledge Engineering +status: approved +classification: public +last-reviewed: 2026-09-05 +review-cycle: 180 days +next-review: 2027-03-04 +source: NIST SP 800-61 Rev. 3 (Draft, April 2025) — Incident Response Recommendations and Considerations for Cybersecurity Risk Management; https://csrc.nist.gov/publications/detail/sp/800-61/rev-3/draft +--- + +# NIST SP 800-61 Rev. 3 (Draft) Incident Response Recommendations Governance + +## Scope + +This card governs how `orchords-docs` evaluates incident response (IR) against NIST SP 800-61 Rev. 3 (Draft). It is the reference input for any KB card that touches incident handling, IR plan structure, or incident coordination. + +## Why this card exists + +NIST SP 800-61 Rev. 3 (Draft, April 2025) supersedes Rev. 2 (2012) with a reframe toward CSF 2.0 alignment, governance, and continuous improvement. Without an explicit card, the KB cites the legacy Rev. 2 lifecycle (Preparation → Detection → Containment → Eradication → Recovery → Lessons Learned) that no longer matches the draft. + +## Document set + +- **NIST SP 800-61 Rev. 3 (Draft)** (April 2025) — current draft. +- **NIST SP 800-61 Rev. 2** (August 2012) — legacy cycle. +- **NIST CSF 2.0** — RESPONSE function. + +References: `https://csrc.nist.gov/publications/detail/sp/800-61/rev-3/draft`. + +## Process (Rev. 3 draft) + +Rev. 3 reframes IR around CSF 2.0: + +- **GOVERN** — establish IR governance, roles, and policy. +- **IDENTIFY** — asset, data, and system inventory. +- **PROTECT** — preventative controls, awareness, training. +- **DETECT** — anomalies, monitoring, adverse events. +- **RESPOND** — incident management, analysis, mitigation, communication. +- **RECOVER** — recovery planning, improvements. + +## Incident classification + +| Severity | Description | +|---|---| +| Catastrophic | full outage, data breach with regulatory impact | +| Major | partial outage, data exposure | +| Moderate | degraded service, contained incident | +| Minor | local incident, no service impact | +| Low | false positive, near-miss | + +## Incident response plan + +A NIST-aligned IR plan contains: + +1. Mission, scope, and authority. +2. Roles and responsibilities (CISO, IR lead, comms lead, legal). +3. Coordination with external entities (US-CERT, FBI, ISAC). +4. Communication protocols (internal, external, regulatory). +5. Severity classification. +6. Containment, eradication, recovery procedures. +7. Evidence handling. +8. Lessons-learned and continuous improvement. + +## Mandatory pre-flight (before declaring an IR plan valid) + +1. The IR plan is approved by executive leadership. +2. The IR team has at least 4 named roles. +3. The IR plan has been tested via tabletop. +4. The IR plan is updated annually. +5. The IR plan is integrated with NIST CSF 2.0 GOVERN function. + +## Cross-reference + +| Domain | Card | +|---|---| +| CSF | `NIST_CSF_2_2024_GOVERNANCE.md` | +| 800-53 | `NIST_SP_800_53_R5_SECURITY_GOVERNANCE.md` | +| Privacy | `ISO_IEC_27701_2019_PIMS_GOVERNANCE.md` | +| Playbook | `PRIVACY_INCIDENT_RESPONSE_PLAYBOOK.md`, `SUPPLY_CHAIN_INCIDENT_PLAYBOOK.md` | + +## Self-attestation cycle + +Every 180 days: + +1. Walk every KB reference card that touches IR. +2. Confirm the CSF 2.0 mapping is current. +3. Confirm the IR plan is updated. +4. Update the next-review date. + +## Sources + +- NIST SP 800-61 Rev. 3 Draft: `https://csrc.nist.gov/publications/detail/sp/800-61/rev-3/draft` +- NIST SP 800-61 Rev. 2: `https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final` +- NIST CSF 2.0: `https://www.nist.gov/cyberframework` +- CISA IR: `https://www.cisa.gov/news-events/directives/incident-response` diff --git a/docs/knowledge/standards/README.md b/docs/knowledge/standards/README.md index 5af667c7e..842a5392f 100644 --- a/docs/knowledge/standards/README.md +++ b/docs/knowledge/standards/README.md @@ -230,3 +230,9 @@ This family contains internal documentation conventions and guidance mapped to e - [NIST Cybersecurity Framework 2.0 Governance](NIST_CSF_2_2024_GOVERNANCE.md) - [ISO/IEC 27001:2022 Information Security Management System Governance](ISO_IEC_27001_2022_ISMS_GOVERNANCE.md) + +## 2026-09-05 ISO/IEC 27005 risk, NIST SP 800-207 Zero Trust, and NIST SP 800-53A assessment governance cards (Batch 90) + +- [ISO/IEC 27005:2022 Information Security Risk Management Governance](ISO_IEC_27005_2022_RISK_GOVERNANCE.md) +- [NIST SP 800-207 Zero Trust Architecture Governance](NIST_SP_800_207_ZERO_TRUST_GOVERNANCE.md) +- [NIST SP 800-53A Rev. 5 Assessment Procedures Governance](NIST_SP_800_53A_REV5_ASSESSMENT_GOVERNANCE.md)