BTA CBSP cheat sheet

Confidentiality, integrity, and availability apply to on-chain data, node infrastructure, and key material; blockchain adds non-repudiation via signed transactions and public verifiability of ledger state.

Immutability is a security control and a risk: appended blocks resist tampering, but erroneous or malicious transactions persist, so remediation requires compensating controls or forks.

The CIA triad does not cover blockchain well; add decentralization, transparency, and finality, since a transaction considered final may still be reorganized.

Key management is the dominant control: whoever holds the private key controls the asset, so key compromise equals full asset compromise regardless of smart contract safety.

Trust boundaries exist at wallet software, node RPC endpoints, oracles, bridges, and off-chain data stores; every boundary crossing is an attack surface.

Defense in depth for a DApp layers contract-level checks, transaction simulation, rate limiting, monitoring, and multi-signature custody rather than relying on code audits alone.

Least privilege applies to smart contracts: an admin role that can mint, pause, or upgrade should be time-locked and multi-signature controlled.

Public-key cryptography provides authentication and integrity, not confidentiality; on-chain data is visible to all nodes unless encrypted off-chain or via zero-knowledge proofs.

A block header contains the previous block hash, a Merkle root, a timestamp, a nonce, and difficulty target; changing any transaction changes the Merkle root and invalidates the header hash chain.

Hash functions used in blockchains must be preimage-resistant, second-preimage-resistant, and collision-resistant; SHA-256 and Keccak-256 are common, MD5 and SHA-1 are unsuitable.

Digital signatures (ECDSA, EdDSA, Schnorr) provide authentication and integrity; ECDSA requires a unique random nonce per signature or the private key can be recovered.

A Merkle tree lets a client verify transaction inclusion with a logarithmic-size proof rather than downloading the full block.

Consensus finality differs by protocol: proof-of-work uses probabilistic finality via confirmations, while BFT-style protocols may offer deterministic finality after a quorum of votes.

Account-based chains store balances and contract state per address; UTXO-based chains track unspent outputs, changing how replay and double-spend checks are implemented.

Smart contracts are deterministic code executed by all validating nodes; non-determinism or reliance on external state breaks consensus and must be handled via oracles.

Layer-2 and bridge designs move trust to sequencers, fraud proofs, or validators; the security model of the bridge differs from that of the underlying chain.

Reentrancy: an external call hands control to attacker code before state is updated; the checks-effects-interactions pattern and reentrancy guards mitigate it.

Integer overflow and underflow were common before Solidity 0.8; unchecked blocks reintroduce the risk, so explicit bounds checks are required.

Oracle manipulation: an attacker distorts a price feed (for example via flash loans) to trigger mispriced lending or liquidation logic; use time-weighted and multi-source feeds.

Front-running and MEV: transaction ordering is visible in the mempool, enabling sandwich attacks; commit-reveal schemes and private relays reduce exposure.

Phishing and approval abuse: malicious approvals let attackers drain tokens later; wallet drainers exploit signed permits and unlimited allowances.

51% and eclipse attacks: majority hash power enables double-spends and chain reorganization, while eclipse attacks isolate a node from honest peers.

Bridge and cross-chain attacks exploit message verification flaws, validator key compromise, or fake deposit events.

Social engineering targets people, not code: fake support, seed-phrase requests, and lookalike domains are common entry points.

Follow checks-effects-interactions and use reentrancy guards on functions that make external calls or transfer value.

Use pull-payments over push-payments for withdrawals to avoid denial of service and reentrancy in loops.

Apply the principle of least privilege to on-chain roles; separate admin keys from operational keys and require multi-signature approval for privileged actions.

Static analysis, fuzzing, formal verification, and independent audits are complementary; no single tool catches all vulnerability classes.

Use established libraries for token standards (for example OpenZeppelin) and pin dependency versions to avoid supply-chain risk.

Implement circuit breakers, pause mechanisms, and rate limits, and test them in staging before deployment.

Secure the software supply chain: verify build reproducibility, sign releases, and restrict CI/CD secrets.

Establish a bug bounty and responsible disclosure process to surface issues before adversaries do.

Identify regulatory obligations by jurisdiction: AML/KYC, sanctions screening, securities law, and data protection rules may apply to on-chain activity.

Maintain an asset and key inventory with owners, classification, and recovery procedures; loss of key material is a top operational risk.

Risk assessment should score likelihood and impact per threat (for example key compromise, contract exploit, regulatory action) and map controls to each.

Incident response phases: preparation, detection and analysis, containment, eradication, recovery, and post-incident lessons learned.

Containment for a key compromise may require pausing contracts, revoking approvals, moving funds to a safe wallet, and notifying counterparties.

Preserve forensic evidence: logs, transaction hashes, and node data with chain of custody to support investigation and legal action.

Define communication and notification duties (regulators, users, insurers) in advance with clear time limits and approval paths.

Third-party and vendor risk: assess auditors, custodians, cloud providers, and bridges for security posture and contractual protections.