Web3 Threat Model
1) Scope
– On-chain code & state (smart contracts/modules/canisters)
– Key custody: user keys, multisigs, operator keys
– Node/validator infrastructure & consensus
– Bridges, relayers, oracles, off-chain adapters
– Frontends, APIs, wallets (custodial & non-custodial)
– Developer toolchain: repos, CI/CD, artifact stores
– Governance systems (DAO/NNS-equivalent)
– Monitoring, logging, incident response
2) High-value assets
– Private keys/signing material
– On-chain logic & persistent state
– Treasury funds / token supply controls
– Node operator signing keys & consensus integrity
– Oracle feeds & bridge relayers
– CI/CD signed artifacts and repos
– Governance control rights (timelocks, quorums)
– Forensic logs and telemetry
3) Actors & motivations
– Financial attackers (exploiters, MEV bots)
– Nation-state APTs (disruption, espionage)
– Malicious insiders or compromised signers
– Colluding operators/validators
– Supply-chain attackers and opportunistic hackers
4) Common attack surfaces & threats
– Contract logic flaws (reentrancy, integer, access control)
– Key exfiltration and multisig compromise
– Validator equivocation or censorship
– Bridge/relay message forgery, replay, collusion
– Oracle poisoning and stale feeds
– Supply-chain attacks (CI/CD compromise, malicious packages)
– Governance capture via flash proposals or vote manipulation
– Mempool/MEV exploitation and front-running
– Frontend phishing and wallet compromise
5) Prioritized risks (example)
– Critical: key compromise or multisig breach → theft/unauthorized upgrades
– Critical: critical contract exploit → treasury drain
– High: bridge compromise → cross-chain theft
– High: oracle poisoning → economic loss/liquidations
– Medium: governance capture/flash-proposal
6) Core controls & mitigations
– Keys: HSM, MPC, threshold sigs; enforce signer diversity, rotation, audit logs
– Code: SDLC, formal methods for critical modules, SAST/DAST/fuzzing, multi-audit policy, bug bounties
– Upgrades: timelocks, multisig approval, pre-execution simulation, canary/staged rollouts
– Oracles/Bridges: multi-source feeds, medianization, dispute/circuit-breakers, cryptographic proofs
– Nodes: operator vetting, attestation, separation of roles, patching policies
– CI/CD: artifact signing, secrets vault, SBOM, pinned deps, provenance
– Frontends: CSP, XSS protections, wallet UX safeguards
– MEV: private relays, bundling, transaction privacy tools
– Governance: quorum/timelocks, delegation controls, proposal simulation
– Monitoring: watchlists, anomaly detection, immutable logs, alerting
– IR & Recovery: prepaid emergency multisig, freeze mechanisms where possible, tested backups
7) Monitoring & metrics
– MTTD/MTTR for exploits; proportion of funds under HSM/MPC; audit coverage; signed-release percentage; number of critical vulnerabilities open; time to patch nodes.
8) 90/180/365-day roadmap (generic)
– 0–90: inventory assets, move keys to HSM/MPC, sign releases, baseline monitoring, fix critical audit findings.
– 90–180: implement multisource oracles, timelocks, supply-chain hardening, private tx relays for sensitive flows.
– 180–365: full MPC rollout, policy-as-code for governance, automated remediation and advanced detection.
ICP-Specific Threat Model
1) Scope (ICP-specific)
– Canister code & state, controller principals and upgrade paths
– Replica nodes, DKG/key materials, boundary nodes, Internet Identity
– NNS governance & neuron keys, SNS token canisters
– Off-chain adapters/bridges and HTTP gateways
– DFX/IC toolchain, WASM artifacts, canister lifecycle, canister wallets/ledger canisters
2) ICP additional/high-value assets
– Controller principals and neuron keys
– Replica DKG material and signing keys
– Boundary node TLS and gateway config
– Internet Identity anchors and device credentials
– WASM artifacts, canister state snapshots
3) ICP-specific threats (highlights)
– Unauthorized canister upgrades via compromised controller principals or rushed governance proposals
– DKG leakage or malicious node operator collusion enabling equivocation or signing of fraudulent state
– Boundary node compromise exposing ingress/egress or allowing request manipulation
– Malicious or buggy canister migrations causing state corruption
– NNS proposal abuse to push unsafe runtime or system upgrades
– Insecure Internet Identity anchors leading to impersonation for privileged principals
4) ICP-centric controls & mitigations
– Controller practice: hardware-backed principals, MPC/HSM for controllers, minimize number of controllers, multisig-like gating (timelocks) on upgrades
– Upgrade safety: staged canary deployments, pre-flight proposal simulations on an isolated replica, determinism checks for WASM, signed artifact provenance and SBOM
– DKG & node ops: vetted operators, attestation, rotate thresholds, split signing from consensus, monitor replica drift and slashing risks
– Boundary nodes: WAF, TLS mutual auth, rate limiting, strict gateway configs; CDN + DDoS protections for HTTP frontends
– Governance: enforce review windows, quorum, delegation limits; proposal pre-flight sandboxing and impact analysis
– Internet Identity: encourage WebAuthn/FIDO for privileged anchors, monitor anchor events, require re-auth for high-risk ops
– CI/CD: protect dfx keys, sign WASM artifacts, ephemeral creds for deploys, SBOM and pinned deps
5) ICP prioritized risks
– Critical: controller key compromise → unauthorized canister upgrades and fund loss
– Critical: DKG compromise by colluding operators → forged messages / equivocation
– High: governance proposal abuse causing unsafe changes
– Medium: boundary node compromise leading to request tampering
– Medium: adapter/oracle compromise causing financial misstate
6) ICP monitoring & metrics
– Alerts: canister controller changes, canister upgrade attempts, neuron vote spikes, new neuron delegation, large ledger transfers, replica version drift
– Metrics: percentage of controllers on HSM/MPC, signed-WASM coverage, number of canisters with multi-controller/MPC, operator attestation coverage
7) ICP roadmap (90/180/365)
– 0–90: inventory canisters/controllers/neurons, move controllers to HSM/MPC, sign WASM artifacts, enable basic upgrade alerting and treasury watchlists
– 90–180: deploy pre-flight proposal simulations, staged upgrades & canary canisters, enforce governance timelocks
– 180–365: full MPC for controllers, operator attestation program, incident tabletop including governance-capture and DKG compromise scenarios
Key differences & compensating controls
– Controller principals vs contract owners: ICP requires stronger principal/key hygiene (HSM/MPC + multisig gating).
– DKG/replica risk: address via operator vetting, attestation, and rotating thresholds — not present in many non-ICP chains.
– Boundary nodes & HTTP gateway: ICP exposes classic web-layer risk vectors at boundary nodes; add WAF/CDN and gateway hardening.
– NNS governance: ICP’s NNS adds a governance attack vector; deploy proposal simulation and mandatory timelocks.
– WASM artifacts & canister migrations: require deterministic builds, signed artifacts, and rigorous migration tests.
Threat model diagrams
– Generic Web3 diagram elements:
– Users / wallets (custodial & non-custodial)
– dApp frontend -> API / gateway -> node/validator / RPC -> smart contracts / ledgers
– Multisig / treasury module
– Oracles & data providers -> smart contracts
– Bridges / relayers -> external chains
– CI/CD -> artifact store -> deployment keys
– Monitoring/alerting / SIEM
– Trust boundaries annotated (public chain, operator trust, third-party services)
– ICP diagram elements:
– Users -> frontend -> Boundary Node (HTTP Gateway) -> Replica -> Canister A -> Canister B -> Ledger canister
– Controller principals (hardware/MPC) mapped to canisters
– NNS governance flow -> Neuron holders -> Proposal -> Upgrade actions
– Node operator set + DKG/key distribution
– Internet Identity anchors and device credentials
– Off-chain adapters/oracles and bridges crossing trust boundaries
– CI/CD pipeline producing signed WASM artifacts and staged upgrade approvals
– Monitoring hooks: canister upgrade alerts, neuron activity, replica drift
Sample Runbooks
Runbook 1 — Compromised Signing Key / Controller Principal (Generic & ICP)
– Trigger: Alert for unauthorized signer activity OR controller change OR unexpected signed transaction from privileged key.
– Immediate actions (first 15 minutes):
1. Revoke or quarantine compromised key if possible (rotate via backup signers/MPC emergency key).
2. Pause automated upgrade pipelines and lock deployment gates (freeze new deploy approvals).
3. Notify core on-call incident commander and legal/comms teams; open IR incident channel.
4. If multisig present, require emergency quorum meeting and initiate emergency txn to transfer funds to safe treasury (pre-funded escape wallet) OR set spend cap.
– Containment (15–60 minutes):
1. Use remaining signers/MPC to rotate controller ownership to a safe HSM/MPC-controlled principal.
2. For ICP: submit emergency neuron proposal or coordinate with NNS (if required) to pause upgrades or enact mitigations.
3. Revoke compromised credentials across CI/CD, admin consoles, and vaults.
– Eradication & Recovery (1–24 hours):
1. Rebuild compromised signing environment, rekey using fresh hardware-backed principals, and re-deploy signed artifacts if necessary.
2. Reconcile ledger balances, freeze suspicious outgoing transfers, and restore normal ops with stricter gates.
– Post-incident:
1. Forensics: collect logs (auth, deploy, node telemetry), signer activity, WASM artifacts, and any related repo commits.
2. Postmortem, timeline, root cause, update key-management policy, and run additional training.
– Communications: coordinated disclosure to stakeholders, users (if funds affected), and regulators per policy.
Runbook 2 — On-chain Exploit / Contract Drain (Generic)
– Trigger: Large unexpected outgoing transfer OR abnormal contract state change OR third-party alert.
– Immediate actions:
1. Alert on-call, notify multisig signers.
2. If possible, invoke emergency circuit-breaker/pause function; if not available, attempt to route through governance to pause (timelock paths).
3. Trace txs: identify attacker address, affected contracts, and drain vector.
– Containment:
1. Freeze upstream liquidity pools and related contracts (if multi-contract system).
2. Blacklist attacker addresses via guard contracts or via centralized mitigations (if custodial participants).
– Recovery:
1. Prepare rollback/migration plan if contract vulnerability can be patched; stage upgrade to patched contract with audited fix.
2. Coordinate with exchanges/custodians to freeze tainted funds off-chain.
3. Engage legal/forensics and bounty/whitehat coordination.
– Post-incident: full audit, reimbursements if policy allows, update SDLC and add additional automated checks.
Runbook 3 — Oracle/Adapter Manipulation (Generic & ICP)
– Trigger: Price feed deviation > threshold OR inconsistent feed signatures OR unexpected on-chain state changes tied to input feeds.
– Immediate actions:
1. Alert on-call and pause automated liquidations or sensitive flows (disable dependent executors).
2. Switch to fallback data sources or pause execution via governance/multisig.
– Containment:
1. Identify malicious or stale oracle source; revoke or stop consuming its feed.
2. If adapter is compromised, isolate relay service and rotate keys.
– Recovery:
1. Reconcile affected positions and state, patch adapter ingestion logic, add additional validation & sanity checks.
2. Add medianization and circuit-breaker checks; expand oracle sources.
– Post-incident: update monitoring thresholds, add test harness for oracle anomalies, and document incident.