Tips & Good Practice

B.1 — Inventory & Classification

1. 01

   Keep the CCM inventory in a CMDB or DevSecOps tool, not an unmanaged spreadsheet; each entry under version control with a mandatory security reviewer on change.

2. 02

   For L2/L3, add automated CCM discovery in production via code scanning and runtime introspection — a manual inventory does not scale.

3. 03

   Maintain CME diagrams as code (PlantUML, Mermaid, Structurizr) with automated validation against the real network topology; update the data flow in the same pull request as the code change.

4. 04

   Run the quarterly inventory review as a cross-functional workshop with security, ops and development — it surfaces undocumented changes more reliably than a single owner's task.

B.2 — Generation

1. 01

   Use an entropy pool from several independent sources (hardware TRNG + OS DRBG + jitter entropy) even at Level 1 — defense-in-depth.

2. 02

   Run continuous health monitoring of RNG output in production (NIST SP 800-90B health tests) with alerting on failure modes; mandatory for L2+.

3. 03

   Run the ceremony 'two-keyboard' style, with commands entered alternately by two independent participants so no one can execute the script unilaterally.

4. 04

   Document a pre-ceremony rehearsal on a test environment within 7 days of the production ceremony, and explicit kill-switch conditions for halting it.

B.3 — Storage

1. 01

   Use envelope encryption: the HSM holds the MEK, which encrypts the DEK, which encrypts the CCM — so you can rotate the MEK without re-encrypting all CCM.

2. 02

   Use high-level AEAD libraries (libsodium, AWS Encryption SDK, Google Tink), not low-level APIs; document the tamper-response if AEAD tag verification fails.

3. 03

   Use WORM (Write-Once-Read-Many) backup storage for tamper-evidence; review tier ratios quarterly as AUM grows.

4. 04

   Back up not just the CCM but the metadata — derivation paths, multi-sig configuration, ceremony records — so recovery is self-contained.

B.4 — Usage

1. 01

   Use an HSM whose PKCS#11 interface cannot export the private key by design (only signing, decrypt, verify).

2. 02

   Make the approval UI a separate application from the initiation UI — this reduces UI-spoofing risk; add a mandatory destination-address preview with a diff against the whitelist.

3. 03

   Prefer OAuth 2.0 + DPoP (RFC 9449) over bearer tokens; add anomaly detection on session patterns (geo-velocity, device change, time of day).

4. 04

   For PAM, support break-glass with mandatory post-event review; record cause, expected outcome and justification in the session metadata.

B.5 — Lifecycle

1. 01

   Use envelope encryption (B.3.2) for efficient MEK rotation without re-encrypting all CCM; add a 'defensive rotation' after ambiguous events.

2. 02

   Document post-rotation reconciliation: confirm watch-only monitoring, accounting and backups have switched to the new key.

3. 03

   Pre-generate emergency-transfer backup addresses in the ceremony and store them apart from the primary; keep communication templates in several languages.

4. 04

   For recovery use Shamir's Secret Sharing with m-of-n shares across locations and jurisdictions; verify physical accessibility of recovery materials annually.

B.6 — Wallet Architecture

1. 01

   For chains without native m-of-n use threshold schemes (MPC-CMP, GG18/20); for native multi-sig (Bitcoin, GnosisSafe) use only audited, battle-tested implementations.

2. 02

   Include pre-defined backup keyholders in the keyholder list, activated via a documented procedure (B.5.3).

3. 03

   Use independent blockchain nodes for watch-only monitoring (not shared with the signing infrastructure) and cross-check multiple nodes to detect a reorg.

4. 04

   Isolate tiers into separate cloud accounts (AWS Organizations SCPs); run cold-to-warm transitions at a fixed scheduled time so watchers can tell normal from anomalous.

B.7 — Compromise Detection

1. 01

   Use a SIEM with native hash-chaining (Splunk, Elastic with a frozen tier); run integrity verification of the whole log chain monthly.

2. 02

   For L3, anchor the log-chain hash to a public blockchain (e.g. via OpenTimestamps).

3. 03

   Use independent blockchain nodes for reconciliation; set a propagation-delay tolerance (e.g. +/-2 minutes) but no larger, so detection is not diluted.

4. 04

   Pre-position bilingual incident-communication templates and an explicit 'do not' list (no public statement before coordinated disclosure, no media contact without legal approval).

B.8 — Personnel & Access

1. 01

   Use licensed background-check vendors with a public methodology; for L3 consider a psychological assessment for those with access to the largest cold-storage holdings.

2. 02

   Use identity management with built-in SoD analysis; make the quarterly access review test explicit conflict scenarios, not a rubber-stamp.

3. 03

   Document business-justified exceptions with time-bounded validity, not permanent access.

4. 04

   Include realistic simulation scenarios in training (phishing, social engineering); use spaced repetition (re-train at 3 and 6 months) and a mentor during the probationary period.