# Security Frameworks by SEAL > Comprehensive security framework documentation for Web3 projects and blockchain security best practices. import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Account Abstraction Wallets ### User Profile Advanced users, developers, and organizations interested in programmable security, customizable transaction rules, and moving beyond the limitations of standard Externally Owned Accounts (EOAs) to eliminate single points of failure like seed phrase loss. ### Primary Goal To leverage the power of smart contracts at the account level, enabling features like social recovery, gas sponsorship, batch transactions, and flexible security policies that are not possible with an EOA. ### Core Concept: ERC-4337 Account Abstraction (AA) turns a user's account into a smart contract, making it programmable. Instead of being controlled directly by a single private key, the account's logic is defined by its code. This is achieved through **ERC-4337**, a standard that enables AA without requiring changes to the core Ethereum protocol. It introduces a higher-level pseudo-transaction system with several key components: * **Smart Contract Account**: The user's wallet itself is a smart contract, containing custom logic for validating transactions. * **UserOperation**: A data structure that bundles the user's intent, calldata, and signature. This object is sent to a dedicated, alternative mempool. * **Bundlers**: Specialized nodes that package multiple `UserOperation` objects from the mempool into a single transaction and submit it to the `EntryPoint` contract. * **EntryPoint**: A singleton smart contract that acts as the central orchestrator. It verifies and executes the bundled `UserOperations`, ensuring that accounts and paymasters have sufficient funds to pay for gas. * **Paymasters**: Optional smart contracts that can sponsor gas fees on behalf of the user, enabling gasless transactions for the end-user or allowing fees to be paid in ERC-20 tokens. ### Key Benefits & Features * **Enhanced Security**: * **Social Recovery**: Mitigate the risk of losing a primary key by designating trusted "guardians" (other accounts or devices) who can collectively approve an account recovery. * **Customizable Policies**: Implement robust security rules directly into the wallet, such as daily spending limits, whitelisting trusted contracts, or requiring multisig confirmation for transactions over a certain value. * **Improved User Experience**: * **Gasless Transactions**: Enjoy a smoother experience where dApps can sponsor gas fees, or pay for transactions using ERC-20 tokens instead of needing the chain's native asset (e.g., ETH). * **Simplified Interactions**: Perform complex, multi-step actions (like `approve` and `swap`) in a single, atomic transaction, reducing clicks and potential points of failure. ### Security Considerations & Best Practices * **Smart Contract Risk**: The security of an AA wallet is entirely dependent on the quality and security of its underlying smart contract code. Bugs or vulnerabilities in the account's implementation can lead to a total loss of funds. **Thorough audits of the account logic are non-negotiable.** * **Guardian Selection and Security**: The strength of the social recovery model depends on the security and independence of the guardians. They should be diverse and not susceptible to a single common threat. * **EntryPoint Centralization**: The `EntryPoint` contract is a central trust point for the entire ERC-4337 ecosystem. A vulnerability in the official `EntryPoint` could have widespread consequences. Use only the canonical, heavily audited `EntryPoint` contract. * **Paymaster and Factory Security**: Malicious or poorly coded Paymasters and Factories can introduce DoS vectors or other risks. The ERC-4337 standard includes a reputation system and staking mechanisms to throttle or ban misbehaving entities, but users should only interact with trusted and audited Paymasters. * **Gas Overhead**: The added logic in a smart contract account means that transactions can be more expensive than those from a standard EOA. This trade-off between features and cost should be considered, though it can be offset by gas sponsorship. * **Key Revocation**: If the primary signing key is compromised, the recovery process allows you to swap it out for a new one without having to move all assets to a new wallet address. * **Advanced Guardian Setups**: For enhanced security, guardian roles can be implemented using **Multi-Party Computation (MPC)**. In an MPC-based recovery, guardians hold cryptographic shares that are used collectively to authorize a recovery action. This method allows guardians to produce a valid signature through a distributed computation using their individual shares, without ever reconstructing a single master key on any device. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Cold vs. Hot Wallets The primary distinction between wallet types is their connectivity to the internet. This factor dictates their security threat model, risk profile, and ideal use cases. ### Cold Wallets #### What Are They? Cold wallets are cryptocurrency wallets that store private keys in an offline environment. By being disconnected from the internet, or "air-gapped," by default, they provide the highest level of security against online attacks like malware and phishing. Transactions are signed offline and then broadcast to the network using a connected device, ensuring the private keys are stored on device with minimal connectivity. > ❓ Did you know? > > Most cold wallets still need a way to exchange transaction data with a connected device, such as via USB, Bluetooth, > QR codes, or SD cards. This does not make them hot by itself. The key distinction is whether the private key remains > isolated from the internet-connected system during signing. #### Types of Cold Wallets * **Hardware Wallets**: Dedicated physical devices that store private keys offline and sign transactions without exposing the keys to a connected internet device. * **Paper Wallets**: Physical printouts or handwritten notes of private keys and QR codes. * **Software Wallets on Air-Gapped Devices**: Standard wallet software installed on a device that is permanently disconnected from the internet, used for offline transaction signing. * **Brain Wallets**: Private keys that are memorized. Account abstraction wallets and multisig wallets are separate account and authorization models, not types of cold wallets. Either approach can use hot signers, cold signers, or a mix of both. #### Use Cases * **Long-Term Storage**: Ideal for storing large amounts of cryptocurrency for extended periods. * **High-Security Needs**: Essential for individuals securing significant value and operating with a low risk tolerance. ### Hot Wallets #### What Are They? Hot wallets are actively and consistently connected to the internet. This connectivity makes them highly convenient for daily use but also inherently more vulnerable to online attacks. #### Types of Hot Wallets * **Browser Wallets (Extensions)**: Software that integrates directly into a web browser, allowing seamless interaction with dApps. * **Mobile Wallets**: Apps installed on smartphones. #### Use Cases * **Daily Transactions & dApp Interaction**: Perfect for users who need quick and frequent access to their funds for interacting with applications. * **Small Balances**: Suitable for storing smaller, non-critical amounts of cryptocurrency that are used regularly. ### Comparison | **Feature** | **Cold Wallets** | **Hot Wallets** | | :-------------- | :------------------- | :---------------------- | | **Convenience** | Low | High | | **Use Case** | Long-term storage | Daily transactions | | **Risk** | Physical loss/damage | Online attacks, malware | ### **Key Security Considerations** Regardless of the type, non-custodial wallets place the full burden of security on the user: * **Online Vulnerabilities**: If the device they are on (computer or phone) is compromised, your assets can be stolen. * **Supply Chain Attacks**: Be cautious of both software and hardware integrity. Always download wallet software from official sources and purchase hardware wallets directly from the manufacturer to avoid receiving a tampered device. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Custodial vs. Non-Custodial Wallets The distinction between custodial and non-custodial wallets centers on who controls the private keys. This control directly impacts ownership, security responsibility, and the ability to interact with the web3 ecosystem. ### Custodial Wallets #### What Are They? Custodial wallets are managed by a third party, such as a centralized exchange (CEX) or a dedicated wallet service provider. In this model, the third party holds and manages the private keys on behalf of the user. #### Characteristics * **Managed Private Keys**: The third party has full control over the private keys. You do not possess them. * **Recovery Options**: It is often easier to recover account access if login credentials are lost, as the custodian can assist. * **Security Dependence**: The security of your assets is entirely dependent on the custodian's security practices, infrastructure, and operational integrity. * **Ease of Use**: Provides a simpler user experience, abstracting away the complexities of private key management. #### Use Cases * **New Users/Beginners**: Suitable for users who are new to cryptocurrency and prefer a simpler, managed solution. * **Convenience Over Control**: Ideal for users who prioritize convenience and ease of use over full control. ### Non-Custodial Wallets #### What Are They? Non-custodial (or self-custody) wallets are managed directly by the user, who has sole and complete control over their private keys. The user is entirely responsible for the security, backup, and management of these keys. #### Characteristics * **User-Controlled Private Keys**: The user has exclusive control and possession of their private keys. * **Eliminates Counterparty Risk**: Assets are not exposed to the risk of a third-party custodian being hacked, becoming insolvent, or freezing funds. Security becomes dependent on the user's own practices. * **Full Responsibility**: The user is solely responsible for backing up their seed phrase and securing their private keys. Loss of these keys means irreversible loss of funds. * **Web3 Interaction**: Enable seamless interaction with dApps. #### Use Cases * **Experienced Users & Developers**: Preferred by users who understand blockchain and wallet security best practices. * **Security & Control Prioritization**: Ideal for users who prioritize full control over their assets and are willing to undertake the responsibility of self-custody. ### Comparison | **Feature** | **Custodial Wallets** | **Non-Custodial Wallets** | | ----------------------- | -------------------------------------- | ----------------------------------------- | | **Private Key Control** | Third Party | User | | **Recovery Options** | Custodian-assisted | User responsibility | | **Web3 Interaction** | Limited | Direct and Full | | **Primary Risk** | Counterparty Risk, Centralization | User Error, Loss of Keys | | **Use Case** | New Users, Trading on CEX, Convenience | Full Control, dApp Use, Long-Term Storage | *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## TEE-based Encumbered Wallets ### User Profile Advanced users, developers, and organizations wanting to implement fine-grained security policies, that don't want to (EVM, Solana, Sui) or can't (Bitcoin, Litecoin, Dogecoin, XRP) make fully customizable logic on each chain individually. Additionally, encumbered wallets can use encrypted storage thus providing a level of transaction privacy. ### Primary Goal To implement optionally private smart contract-like logic and programmable policies for wallet operations across any blockchain by encumbering private keys with restrictions. This enables features like conditional signing, multi-party authorization, time-locked transactions, and compliance policies that work universally, regardless of the underlying chain's capabilities, by instead relying on TEEs. ### Core Concept: Key Encumbrance Key encumbrance refers to placing cryptographic or policy-based restrictions on a private key’s signing power. Instead of a raw key being free to sign any message, its use is “handcuffed” by rules or proofs, and access to it is limited to a preset interface. Examples include: * A key can only sign if a specific policy is met (e.g., only transfers to whitelisted addresses). * A key must co-sign with another party’s key (multi-sig or MPC). * A key’s signing rights are tied to a verifiable execution environment (e.g., inside a TEE or governed by smart contract logic). Essentially, key encumbrance adds programmable controls to private keys, enabling fine-grained access, delegation, and compliance. ### Core Concept: Trusted Execution Environments (TEEs) A Trusted Execution Environment (TEE) is a secure area of a processor that provides hardware-level protection for code and data. TEEs create an isolated environment where sensitive operations can run protected from the main operating system, other applications, and even privileged system software. **Key TEE Properties:** * **Hardware-based Isolation**: Code and data within the TEE are protected by CPU-level security features, not just software isolation. * **Attestation**: TEEs can cryptographically prove their identity and the integrity of the code running inside them. * **Sealed Storage**: Data can be encrypted and tied to the specific TEE instance, ensuring it cannot be accessed outside the secure environment. * **Memory Protection**: TEE memory is encrypted and isolated from the host system, preventing external access to sensitive data. **Common TEE Technologies:** * **Intel SGX (Software Guard Extensions)**: Creates secure enclaves within applications that protect against privileged malware and physical attacks. * **ARM TrustZone**: Divides the processor into "secure" and "non-secure" worlds, with hardware-enforced separation. * **AMD Memory Guard**: Provides memory encryption and isolation features similar to Intel SGX. * **Confidential Computing Platforms**: Cloud-based TEE services like Azure Confidential Computing or AWS Nitro Enclaves. **In Encumbered Wallets:** TEEs enable private keys to be generated, stored, and used within a protected environment where: * Keys never exist in plaintext outside the TEE * Policy logic runs confidentially within the secure enclave * External observers cannot see the encumbrance rules or key operations * Attestation proves the wallet is running authentic, unmodified code This hardware-level protection makes TEE-based encumbered wallets significantly more secure than software-only solutions, as even root or physical access to the host system cannot compromise the keys or policies within the TEE. **Please note that lately there has been a lot of controversy around TEEs, and many researchers are proving that it is not always the case that they add a layer of security. For more information on this, you can check out [TEE.fail](https://TEE.fail), which addresses vulnerabilities in Intel's and AMD's implementation.** ### Key Benefits & Features **Cross-Chain Compatibility:** * **Universal Policy Logic**: Implement sophisticated access controls and transaction policies on any blockchain, including Bitcoin, Litecoin, Dogecoin, and other non-smart contract chains. * **Chain-Agnostic Security**: Deploy consistent security policies across multiple blockchains without depending on each chain's native capabilities. **Advanced Access Control:** * **Fine-Grained Permissions**: Delegate specific rights (voting, trading, asset transfer) to different parties without revealing the full wallet structure. * **Time-Bounded Policies**: Implement temporary access controls that automatically expire after specified periods. * **Hierarchical Delegation**: Create multi-level permission structures where sub-policies can grant further access down the chain. * **Asset-Time Segmentation**: Ensure that specific assets are controlled by exactly one policy at any given time, preventing conflicts. **Privacy & Selective Disclosure:** * **Confidential Operations**: Policy logic and key operations remain encrypted and hidden from external observers. * **Compartmentalized Access**: Each delegatee only sees their authorized subset of operations, maintaining privacy of the overall wallet structure. * **Selective Transparency**: Use view keys to prove compliance or ownership to auditors without revealing spending control or full delegation hierarchy. **Compliance & Auditability:** * **Regulatory Compliance**: Support AML/KYC requirements through selective disclosure mechanisms without compromising user privacy. * **Institutional Auditing**: Enable institutions to prove 1:1 collateralization or policy adherence to regulators using view keys. * **Non-Transferability Proofs**: Demonstrate that certain assets (like compliance-bound RWAs or soulbound tokens) remain under original owner control. **Operational Flexibility:** * **Programmable Recovery**: Implement sophisticated recovery mechanisms that work across any blockchain without relying on smart contract support. * **Dynamic Policy Updates**: Modify access controls and delegation structures without changing the underlying blockchain infrastructure. * **Multi-Asset Management**: Apply consistent policies across different cryptocurrencies and blockchain networks from a single encumbered wallet system. ### Security Considerations & Best Practices * Implement threshold or multi-party computation-based key custody rather than placing sole trust in a single TEE enclave. Use multi-party threshold signatures or distributed key generation so that a single compromised node cannot break the entire system, providing resilience against both hardware attacks and operational failures. * Incorporate economic incentive mechanisms such as staking requirements for TEE operators to align security incentives through cryptoeconomic design. Require operators to post collateral that can be slashed for malicious behavior, attestation failures, or policy violations, creating financial disincentives for compromise attempts and encouraging proactive security maintenance of TEE infrastructure. * Carefully evaluate TEE technology selection based on application memory requirements and security priorities. For encumbered wallet applications with modest memory needs (under 256MB), prefer Intel SGX v1 (Client SGX) which provides integrity protection against hardware attacks, whereas applications requiring larger secure memory may need to accept the trade-offs of newer implementations like Scalable SGX or SEV-SNP that offer greater memory capacity but lack integrity protection against physical attacks. * Establish continuous re-attestation processes that periodically re-verify enclave conformance on a regular schedule such as hourly or per-block intervals. This helps detect drift, tampering, or compromise attempts over time and ensures that the enclave maintains its security properties throughout its operational lifetime. * Implement dual-attestation architectures for cloud-deployed nodes by requiring both Intel DCAP quotes and cloud provider attestation services (such as Azure MAA or AWS Nitro Attestation). This approach provides defense-in-depth by anchoring trust through multiple independent attestation roots with different threat models and security assumptions. * Maintain transparent attestation policy publication by documenting and publicly sharing allowed CPU models, TCB versions, QE/PCS builds, and upgrade paths. This enables operators and auditors to verify compliance independently while providing clear guidance for secure deployment configurations and helping detect potentially compromised or outdated systems. * Collaborate with hardware vendors and ecosystem partners to push for enhanced TEE security features including replay protection, alias detection, and memory mapping integrity. Engage in industry efforts to improve the fundamental security properties of TEE implementations and advocate for standardized security enhancements across different TEE platforms. ### Relevant Papers * Austgen, J., Fábrega, A., Kelkar, M., Vilardell, D., Allen, S., Babel, K., Yu, J., & Juels, A. (2024, December 3). Liquefaction: Privately liquefying blockchain assets. [arXiv.org](https://arxiv.org/abs/2412.02634) * Dai, W., Deng, J., Wang, Q., Cui, C., Zou, D., & Jin, H. (2018). SBLWT: a secure blockchain lightweight wallet based on TrustZone. IEEE Access, 6, 40638–40648. [https://doi.org/10.1109/access.2018.2856864](https://doi.org/10.1109/access.2018.2856864) * Yu, J. (n.d.). PASS: A Provenanced Access Subaccount System for Blockchain Wallets [Stanford University](https://cs191.stanford.edu/projects/Yu,%20Jay_Systems%20191W.pdf) * Aublin, P.-L., Mahhouk, M., & Kapitza, R. (n.d.). Towards TEEs with Large Secure Memory and Integrity Protection Against HW Attacks [IIJ Innovation Institute, TU Braunschweig](https://www.ibr.cs.tu-bs.de/bib/xml/aublin2022scalableSGX.html) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## For Beginners & Small Balances ### User Profile A user with foundational web3 knowledge who is actively learning and interacting with dApps. The asset value is typically non-critical, where a potential loss would not be financially significant. This profile prioritizes **ease of use** and **learning** over protections against online threats. ### Primary Goal The primary objective is a low-friction setup for **convenience** and **dApp interaction**. This includes frequent transactions, exploring DeFi protocols, and engaging with NFTs. ### Recommended Setup The standard setup for this profile is a **hot wallet**, which provides the necessary internet connectivity for active use. The most common types are: * **Browser Extension Wallets:** Integrate directly into a web browser for seamless dApp interaction. * **Mobile Wallets:** Applications installed on a smartphone, offering convenience and on-the-go access. * **Desktop Wallets:** Software applications installed on a computer, which can sometimes offer more advanced features than mobile or browser counterparts. ### Key Considerations & Trade-offs While convenient, this setup carries inherent risks that the user must understand and accept. * **Online Threat Vector:** As hot wallets are internet-connected, they are inherently vulnerable to malware and exploits targeting the browser or operating system. * **Supply Chain Risk:** It is critical to download wallet software *only* from official, verified sources. ### How to Select a Wallet When selecting a wallet, prioritize those whose code is **open-source**, as this allows for public scrutiny and independent verification by the security community. For users who are not developers, several platforms provide independent analysis to help evaluate a wallet's security. For example, [Wallet Scrutiny](https://walletscrutiny.com/) focuses on verifying if a wallet's code is verifiably open-source. Others, like [Wallet Security Ranking](https://www.coinspect.com/wallets/), provide a security score based on specific criteria such as transaction clarity, protection against known threats, and how it handles dApp permissions. Using these tools can provide valuable data points to help you assess a wallet's security posture and make an informed decision. *** ## Hardware Wallets {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Wallet Security > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Wallet Security](/wallet-security/overview) * [Custodial Vs Non-Custodial Wallets](/wallet-security/custodial-vs-non-custodial) * [Cold Vs Hot Wallet](/wallet-security/cold-vs-hot-wallet) * [Wallets for Beginners & Small Balances](/wallet-security/for-beginners-and-small-balances) * [Wallets for Intermediates & Medium Funds](/wallet-security/intermediates-and-medium-funds) * [Secure Multisig Best Practices](/wallet-security/secure-multisig-best-practices) * [Account Abstraction Wallets](/wallet-security/account-abstraction) * [TEE-based Encumbered Wallets](/wallet-security/encumbered-wallets) * [Smart Contract Interaction Security](/wallet-security/smart-contract-interaction-security) * [Seed Phrase Management](/wallet-security/seed-phrase-management) * [Wallet Security Tools & Resources](/wallet-security/tools-and-resources) * [Signing And Verification](/wallet-security/signing-and-verification) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## For Intermediates & Medium Balances ### User Profile An intermediate user who is comfortable with web3 interactions and is now managing a significant, but not life-altering, amount of assets. This user understands the inherent risks of hot wallets and is actively seeking to upgrade their security posture to protect their capital. ### Primary Goal The main objective is to secure balances against online threats while still retaining the ability to interact with dApps when necessary. This involves **separating the bulk of assets** from daily operational balances. ### Recommended Setup A **hardware wallet** is the core of this setup. This dedicated physical device stores private keys offline in a secure, tamper-resistant environment, acting as a vault for the majority of the user's balances. Hardware wallets are the cornerstone of secure asset storage and your last line of defense against attacks. All other security controls could fail and your hardware wallet would still keep you safe when used properly. ### Key Considerations & Trade-offs Adopting a hardware wallet introduces a new set of security considerations focused on physical and supply chain vectors. * **Physical Security:** A hardware wallet is a physical asset that must be protected from theft, damage, or coercion. Wallets should be physically secured in a safe or secret hiding place when not in use. * **Convenience vs. Security:** Using a hardware wallet introduces friction into the transaction process, as it requires physical access and approval on the device for every signature. ### How to Select a Hardware Wallet * **Large Screen:** Ensure your device has a large screen that supports displaying full transaction data. Wallets with clear signing technology are highly recommended. * **Touch Screen PIN:** Use touch screen PIN entry with shuffled buttons. * **Brute Force Protection:** PIN entry must have time-based lockouts to prevent brute force attacks. * **Open Source:** Evaluate if the wallet's firmware and software are open-source, which allows for public auditing and verification by the security community. * **Secure Element (SE):** Look for devices with a SE certified, tamper-resistant chip that protects against physical attacks. Check for high assurance ratings like `EAL6+` and features like **attestation**, which verifies the device is genuine. * **Reputation & Incident:** Investigate the manufacturer's security track record, including their response to past vulnerabilities, data breaches, and overall transparency. * **Verify Device Integrity:** A legitimate hardware wallet will arrive uninitialized, requiring you to perform the initial setup. Reject any device that comes with a pre-set PIN, a pre-generated recovery phrase, or appears to be already configured, as it is likely compromised. #### Brand Diversification Consider diversifying wallet brands amongst your team to reduce risk of 0-day and supply chain vulnerabilities impacting multi-sig quorums. ### Initial Setup #### Purchase & Verification * **Direct Purchase:** Purchase your wallet directly from the manufacturer, do not purchase from a reseller. Use a pseudonym and ideally have it delivered to a P.O. box or secure locker. * Verify tamper-resistant packaging is untouched * Check for authenticity indicators on packaging #### Device Authenticity Verification Before using a new hardware wallet, verify its authenticity: * **Ledger:** Follow [Ledger's device verification guide](https://support.ledger.com/article/4404389367057-zd#h_01FPAFSEH1S9Q6B0NN21ZNKFHS) * **GridPlus:** Follow [GridPlus authenticity verification](https://docs.gridplus.io/lattice1/lattice1-guides/how-to-verify-that-your-lattice1-is-authentic) * **Trezor:** Follow [Trezor authentication guide](https://trezor.io/learn/a/authenticate-trezor-safe-5) #### Device Configuration * Update firmware to latest version before creating accounts * **Strong PIN:** Use at least a 6-digit PIN, but the longer the better * Configure PIN - Use unique, strong PIN (different from other devices) * Wallets must have a PIN requirement or biometric factor required to access the wallet and approve transactions #### Key Generation * **Generate New Keys:** Generate new private keys on the device, do not import them from your computer or another device * **No Digital Storage:** Never export or store your private keys or seed phrases in any digital format, including pictures or in password managers * Generate seed following device instructions * Create accounts as needed #### Clear Signing Use Clear Signing support when available, but never rely on it alone - always fully verify transactions manually. ### Backup Device (For Critical Operations & Multisigs) Maintain a backup hardware wallet to avoid needing to access your seed phrase if your primary device fails. * Second hardware wallet with same seed phrase * Test both devices can create valid signatures * Store backup securely * Monthly verification that backup device functions correctly *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Wallet Security In cryptocurrency, the security of digital assets is directly tied to how control over the funds is protected. This section provides a technical deep-dive into wallet security, covering the range from fundamental concepts to advanced practices for safeguarding assets against theft, loss, and unauthorized access. The goal is to move beyond introductory concepts and provide actionable, technical knowledge for securely managing crypto assets. ### Table of Contents * [Custodial vs Non-Custodial](/wallet-security/custodial-vs-non-custodial) - Comparing custodial and non-custodial wallet solutions. * [Cold vs Hot Wallet](/wallet-security/cold-vs-hot-wallet) - Understanding the security trade-offs of online and offline wallets. * [Wallets For Beginners & Small Balances](/wallet-security/for-beginners-and-small-balances) - Recommended setups for users with non-critical funds. * [Wallets For Intermediates & Medium Funds](/wallet-security/intermediates-and-medium-funds) - Security upgrades for users with significant assets. * [Multisig Wallets For Advanced Users & High Funds](/wallet-security/secure-multisig-best-practices) - Best practices for setting up and managing multisig wallets. * [Account Abstraction Wallets](/wallet-security/account-abstraction) - Exploring the security features of smart contract wallets. * [Signing & Verification](/wallet-security/signing-and-verification/signing-verification) - An overview of secure transaction signing and verification. * [Verifying Standard Transactions (EOA)](/wallet-security/signing-and-verification/verifying-standard-transactions) - How to safely verify transactions from standard wallets. * [Multisig Signing Process](/wallet-security/signing-and-verification/secure-multisig-signing-process) - Detailed guide for secure multisig transaction signing. * [Using EIP-7702](/wallet-security/signing-and-verification/verifying-7702) - Enabling smart contract features for EOAs and mitigating new risks. * [Seed Phrase Management](/wallet-security/seed-phrase-management) - Best practices for securing your seed phrase. * [Tools & Resources](/wallet-security/tools-and-resources) - A curated list of security tools and resources. In this section you can learn: * Explore wallet fundamentals, analyzing the security trade-offs of hot vs. cold wallets and the ownership implications of custodial vs. non-custodial models. * Receive guidance on choosing the right wallet for your threat model, from basic setups to advanced configurations like Multisignature (Multisig) and Account Abstraction wallets. * Master transaction verification techniques, from basic smart contract interactions to the advanced verification. * Implement security best practices for private key and seed phrase management. Mastering wallet security is a critical skill for any developer, user, or organization operating in the web3 ecosystem. ![security](https://github.com/security-alliance/frameworks/assets/84518844/12e2cba3-f69e-4fde-85f1-8a235b9808af) [xkcd](https://xkcd.com/538/) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Secure Multisig Best Practices > Guidance for designing, operating, and auditing high-assurance multisigs. Use this as your single source for baseline > rules, setup guidance, and daily operations. ### Who This Is For Advanced technical users, developers, Decentralized Autonomous Organizations (DAOs), and organizations responsible for managing protocol treasuries, smart contract ownership, or significant personal/collective assets. ### Primary Goal The primary objective is to eliminate single points of failure and establish robust, distributed control over high-value assets and critical smart contract functions. ### Core Concept: M-of-N Scheme A multisignature (multisig) wallet is a smart contract that requires a predefined minimum number of approvals `M` from a total set of authorized signers `N` to execute a transaction. This is known as an `M-of-N` scheme (e.g., 2-of-3, 3-of-5). By distributing signing authority, a multisig ensures that the compromise of a single private key is insufficient to authorize the movement of funds or execute a privileged action. ### General Rules #### Thresholds & Configuration * Minimum of 3 signers * 50% signing threshold * 7+ signers for multisigs holding 1M+ in assets (USD equivalent) * Please see Classification Matrix in [Planning & Classification](/multisig-for-protocols/planning-and-classification#step-3-classification-matrix) for more information on threshold selection. * All signers must use hardware wallets * Multisigs managing assets on behalf of a DAO should set unlimited allowance with primary DAO agent * Signers on multisigs with critical protocol configuration or security roles are discouraged from using their addresses for other purposes. They should create a brand new wallet for that purpose instead. * All signing wallets should be monitored for any activity that is not directly related to multi-sig operations. * No multisigs should use modules/guards except those mentioned in [Setup & Configuration → Modules & Guards](/multisig-for-protocols/setup-and-configuration#modules--guards) unless clear justification and security review is provided * Threshold exceptions can be made for multisigs that are used in frequent operations but are highly constrained by smart contracts. For example, rate setting operations with tight bounds and a backup recovery mechanism to replace the multisig. ##### Threshold Selection Avoid `N-of-N` schemes, as the loss of a single key would result in a permanent loss of access to all funds. ##### Strategic Signer Distribution The security of a multisig depends entirely on the operational security (OpSec) of its individual signer keys. Storing multiple signer keys on the same device or in the same physical location negates the security benefits. Effective distribution strategies include: * Using different hardware wallet models and manufacturers. * Maintaining geographical separation for devices holding signer keys. * Assigning signer keys to different trusted individuals within an organization. * Using diverse client software to interact with the multisig to mitigate single-point-of-failure risks from a software vulnerability. ##### Signer Composition Requirements * **Role Diversity**: Signers should be diverse individuals to reduce risk of multiple compromised accounts - a mix of executives, developers, and operational roles is recommended * **Technical Expertise**: Include a high number of competent, well-vetted technical signers that will understand full transaction details and effects in your signing quorum * **External Parties**: Multi-sigs managing high value wallets and contracts should have at least 1 additional required signer that is external to the organization (such as a security partner or trusted advisor) #### Communication & Documentation * In the event of loss of access to keys or potential compromise of keys or communication channels, the signer must immediately notify the other multisig participants and email your security contact - [Incident Reporting](/multisig-for-protocols/incident-reporting) * Signers should use dedicated communication channels for multisig operations and maintain backup ways of reaching other signers * All multisigs should be documented in the protocol documenting its purpose, general operating rules, multisig wallet address, and list of signer addresses * Signers should verify their addresses by signing a message stating their affiliation and the multisig they intend to join (entity affiliation is ok) ##### Out-of-Band Verification for Admin Changes Any critical administrative action, such as adding or replacing a signer, must be verified through multiple, independent communication channels (e.g., a video call and a signed message) to prevent social engineering attacks. #### Signer rotation * Signers can be rotated, but detailed documentation should be maintained * Any changes to signer composition should be documented in the protocol documentation * Any signer change should not reduce the number of signers or decrease the threshold unless clear justification is given and documented ##### Updating signer addresses If the original key is accessible: * The signer proves ownership of a new address by signing a message with their existing address. * The signer must follow the steps in [Signer Verification process](/multisig-for-protocols/registration-and-documentation#signer-verification-process) If the original key is lost: * The signer must verify their identity to the other signers through alternative methods such as: * Authentication via a verified social media account. * A video call with other signers for confirmation. * Other sufficient methods. #### Training & Drills * All signers should complete training as outlined in the [Implementation Checklist](/multisig-for-protocols/implementation-checklist) * For multisigs that perform emergency operations like pausing, teams should have processes to regularly conduct drills to ensure operational readiness and signer availability ### Setup Best Practices See General Rules above for thresholds and signer distribution guidance. * **Practice on Testnet:** Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and owner management on a test network. * **Timelocks:** Enforce a mandatory delay between the approval of a transaction and its execution. This provides a critical window for the community or team to detect and react to malicious proposals. * **Veto Quorum:** Establish a smaller veto group separate from the confirmation quorum to review and confirm transaction legitimacy. Organizations can establish veto quorums to bypass time-locks in case of emergency. The standard quorum plus two additional signers should be required to bypass. * **Role-Based Access Control (RBAC):** Implement modules that grant specific, limited permissions to certain addresses (e.g., a "pauser" or "executor" role) without making them full owners, adhering to the principle of least privilege. * **Disaster Recovery Plan:** Establish a clear, documented process for what to do when a signer is compromised, the multi-signature UI is down, or other emergencies arise. These should be done at regular intervals. ### Operational Best Practices * **Signer Key Revocation and Replacement:** A feature of multisigs is the ability to add, remove, or replace signer keys. If a signer's key is compromised or lost, it can be revoked and replaced with a new, secure key through a transaction approved by the remaining owners, preserving the integrity of the wallet's assets without needing to migrate funds. * **Secure Signing Environment:** For maximum security, all signing activities should be performed on a dedicated, air-gapped, or hardened device running a secure OS. Using a primary work laptop significantly increases the risk of malware interference. * **Independent Transaction Verification:** Before signing, always verify the raw transaction data (target address, function call, parameters) to ensure it matches the intended operation. * **Out-of-Band Verification for Admin Changes:** Any critical administrative action, such as adding or replacing a signer, must be verified through multiple, independent communication channels (e.g., a video call and a signed message) to prevent social engineering attacks. * **Active Monitoring:** Implement monitoring and alerting systems to be immediately notified of any on-chain activity related to the multisig, including proposed transactions, new signatures, and owner changes (e.g., using tools like [Safe Watcher](https://github.com/Gearbox-protocol/safe-watcher) ). * **Documented Procedures:** Maintain clear, secure, and accessible documentation for all multisig procedures, including transaction creation, signing, and emergency recovery plans. * **General Signing Guidelines:** Use hardware wallets, dedicated signing profiles, and re-verify before execution. Require a "how to check" guide and communicate status after signing (e.g., "checked, signed, X more required"). Last signer executes when applicable. ### Contract-Level Security * **Invariant Enforcement:** Design contracts to enforce invariants and expected state changes such as token balance changes, ownership and administration, and proxy implementation addresses. Ensure contracts automatically revert transactions if any invariant is violated. * **Address Whitelisting:** Approved smart contract and wallet addresses must be added to a whitelist that is enforced at the contract-level. Interactions with all other addresses should be denied and revert the transaction. Updating the whitelist should require an extra signer in addition to the standard transaction approval quorum. For detailed configuration guidance, see [Setup & Configuration → Contract-Level Controls](/multisig-for-protocols/setup-and-configuration#contract-level-controls). ### Acknowledgements Some ideas were borrowed from the [EF's multisig SOP notes](https://notes.ethereum.org/@fredrik/multisig-sop) and [Manifold Finance multisig best practices](https://hackmd.io/@manifoldx/multisig-best-practices). *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Seed Phrase Management ### Private Key & Seed Phrase Management The **seed phrase** (or mnemonic phrase) is the master key to a non-custodial wallet, granting complete control over all its derived **private keys** and assets. The management of this phrase is the single most important aspect of self-custody security. > ⚠️ If you suspect for even a moment that your private key or seed phrase has been lost, viewed by another person, or > exposed digitally (e.g., shown on-screen, copied to a clipboard on a connected device), you must **consider it > compromised.** Immediately create a new, secure wallet and transfer all assets to it. #### Secure Storage Practices The goal is to protect the seed phrase from both physical threats (theft, fire, water damage) and digital threats (hacking, malware). The foundational principle is to keep your seed phrase offline at all times. As soon as a new wallet is created, back it up using one of the following offline methods. Wallet providers do not have access to your seed phrase and cannot help you recover it. * **Physical Written Copies**: Writing the phrase on paper or a notebook is a common starting point. To mitigate risks of loss or damage from fire or water, store multiple copies in secure, geographically separate locations (e.g., a personal safe, a trusted family member's home, a bank deposit box). * **Durable Metal Storage**: For superior protection against physical damage, etch or stamp your seed phrase onto a metal plate (e.g., steel, titanium). Commercial products are available for this purpose. These should also be stored in secure, separate locations. #### Enhanced security option For extra security, split seed into 3 pieces: * **Piece 1**: Words 1-16 * **Piece 2**: Words 9-24 * **Piece 3**: Words 1-8 and 17-24 ##### Storage locations: * Different secure locations (safe deposit box, home safe, trusted family) * Each piece stored with clear labeling system #### Tamper evident bags: Storing sensitive devices or documents in a tamper evident bag offers high confidentiality and integrity. You can sign & date these bags, and also take a picture of its serial number. ![Tamper evident bag example](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/tamper-evident-bag-example.png) **Use case:** You can put your Piece 1: Words 1-16 of your seed, inside a safe. Piece 2: Words 9-24 of your seed, somewhere safe (different location) in a tamper evident bag (could be at your parents place). Piece 3: Words 1-8 and 17-24 of your seed, somewhere safe (different location) in a tamper evident bag (could be somewhere else, at a family member or trusted friend). You can put your backup ledger while traveling inside this, in the safe of your hotel room to detect tampering. The main idea is to never have at the same place your 24 words, but still be able to recover your seed within 2 pieces of paper out of 3. You can find a useful [link here to our EthCC swag](https://drive.google.com/file/d/1L1CMiKRL3TXQBE5bWYNv6dfF94HSdZ8C/view?usp=sharing) that shows you how to easily split your seed in 3 as recommended. #### Prohibited Practices Under no circumstances should you ever store your seed phrase in any of the following ways: * Taking a digital photograph of it. * Uploading it to cloud storage (iCloud, Google Drive, Dropbox). * Sending it via text message or any messaging app. * Sending it in an email, even to yourself. * Storing it in a plain text file on a computer or phone. * Sharing it with anyone. Wallet providers will **never** ask for your seed phrase. * Password managers or digital storage * Traveling with seed phrases * Storing all pieces in same location * Using a device obtained from an untrusted source, such as a conference, hackathon, or third-party online marketplace, as it may be tampered with. ### Organizational Seed Phrase Security For organizations managing multisig wallets, seed phrase security requires additional properties beyond individual storage: #### Security Properties * **Disaster Resistant**: The seed phrase is either duplicated or split, with components/copies secured across multiple geographic locations. This way, if disaster strikes, keys can be recovered from other locations. * **Theft Resistant**: An attacker gaining access to one piece of physical storage media for the seed phrase would not allow them to rebuild the wallet on its own * **Operator Loss Resistant**: Reconstituting the seed phrase should be possible with the absence of one or more operators #### Seed Phrase Encryption > ⚠️ **Warning: Encryption adds recovery risk.** Only implement custom encryption schemes if you are sophisticated and > have robust documentation practices. If you forget your encryption method or passphrase, your funds are **permanently > inaccessible**—there is no recovery option. Many users and organizations face greater risk of locking themselves out > with custom encryption than from an attacker discovering a securely stored backup. Evaluate whether strong physical > security alone may be sufficient for your threat model. The reason to encrypt seed phrases is that if they are discovered unencrypted, the wallet is permanently compromised. However, if you encrypt your seed phrase, you are much more likely to forget the encryption when trying to restore the wallet. If you have stored the seed securely, it is unlikely to be discovered in the first place. Never store seed phrases in plain text or on an internet connected device. For additional protection, seed phrases can optionally be encrypted through some method. For example: * Seed phrases can be mixed in a randomly generated, recorded order * Have a 25th secret word * Require a passphrase to be imported into a wallet Regardless of the method, the related secret value should be stored in a password manager. (**Do not store your seed phrase in a password manager.**) #### Advanced Backup Options **Key Splitting:** Split the key into multiple shards and securely distribute them: * Use [Shamir's Secret Sharing algorithm](https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing) for N of M key shards * Consider using this [Shamir Secret Sharing implementation](https://github.com/privy-io/shamir-secret-sharing) * Seed phrases can be sharded using Shamir's Secret Sharing algorithm, with each shard recommended to be shared with a trusted guardian (3rd party custodian service, family members, password manager, personal physical media, etc.) **Multi-Share Backups:** Use device-supported multi-share backups where available: * [Trezor Multi-Share Backup](https://trezor.io/learn/a/multi-share-backup-on-trezor) **Secure Distribution:** Give shards to trusted family members, put in bank safe deposit boxes, and keep hidden around your house. > **Note**: If you're concerned about targeted attacks like kidnapping or home invasions, consider avoiding storing > any shards in your primary residence. #### Multisig Social Recovery **Optional Self-Recovery**: * Seed phrase backups are not strictly necessary with a healthy quorum * Multi-sig signing wallets should not be used for any other purpose and could be re-provisioned by existing quorum admins * Maintain a healthy enough signing pool that loss of access to a few accounts at once could be recovered from * Personal backup methods for admins are required to maintain access to on-chain assets in the event of loss of access to hardware wallets **Quorum Social Recovery**: If access to wallet is lost, the quorum can vote to edit members to replace the inaccessible wallet. #### Ongoing Security Hygiene **1. Periodic Security Audits:** On a recurring basis (e.g., every 6 months), conduct a security review by asking: * Do I know the physical location of all my seed phrase backups? * Are my storage methods still secure and uncompromised? * If my primary device were destroyed, do I have a clear plan to recover my assets? **2. Key Rotation:** While you can use the same keys for years, it is a best practice to periodically rotate them by moving assets to new wallets. **3. Succession Planning:** Establish a clear, secure protocol for a trusted next-of-kin to access your assets in case of incapacitation or death. This may involve sealed instructions stored with a lawyer or in a safe deposit box. ### Emergency access plan #### Trusted contacts * Designate 2-3 trusted individuals who can access backup locations * Clear instructions for emergency seed access * Regular check-ins with trusted contacts #### Recovery scenario example "Call \[trusted person] with code word \[predetermined phrase], tell them to get the metal plate from safe location A, they give you words 1-16 over the phone. Then call \[second person] with code word for location B to get words 9-24. Use both pieces to reconstruct seed immediately, then change all security settings." #### Documentation * Emergency contact information stored separately from seed * Code words/phrases for identity verification * Access instructions for trusted contacts * Regular testing of emergency procedures * Update procedures when contacts or locations change Remember: Your seed phrase security is the foundation of multisig security. Take time to implement proper storage procedures appropriate for your risk level. ## Signing Schemes import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Smart Contract Interaction Security > 🔑 **Key Takeaway**: Before interacting with any smart contract, verify the contract address, > simulate the transaction, review all approvals, and understand what you are signing. Most fund > losses come from user-side interaction mistakes, not wallet compromises. This page assumes you already have a properly secured wallet (see [Wallet Security overview](/wallet-security/overview)). For verifying contract addresses, transaction data, and signatures before signing, see [Signing & Verification](/wallet-security/signing-and-verification/signing-verification) and [Verifying Standard Transactions](/wallet-security/signing-and-verification/verifying-standard-transactions). For simulation and verification tools, see [Tools & Resources](/wallet-security/tools-and-resources). This page focuses on **approval management, permit risks, MEV protection, and common attack patterns**. ### Token Approval Hygiene Every `approve()` call grants a spender address permission to move your tokens. Most dApps request unlimited approval by default. * **Set exact amounts.** Approve only what the current transaction needs, not `type(uint256).max`. This limits exposure if the spender contract is later exploited. * **Revoke unused approvals.** Use [Revoke.cash](https://revoke.cash/) or the [Etherscan Token Approval Checker](https://etherscan.io/tokenapprovalchecker) to audit and revoke outstanding approvals. * **Audit approvals regularly.** Schedule periodic reviews, especially after heavy dApp usage. #### The `permit()` and EIP-2612 Risk EIP-2612 `permit()` allows approvals via off-chain signatures instead of on-chain transactions. This is more dangerous: no on-chain transaction is visible until the permit is submitted by a third party, and users can unknowingly authorize token transfers on phishing sites. A common pattern is a fake "login" prompt that is actually a permit signature request. **If a signature contains fields like `spender`, `value`, `nonce`, and `deadline`, you are signing a permit — not a login message.** ### Slippage and MEV Protection When trading on DEXes, your transactions are visible in the public mempool before execution, creating MEV (Maximal Extractable Value) attack opportunities. #### Slippage Tolerance * **Too high** (5–10%): You become a sandwich attack target. * **Too low** (0.1%): Transactions fail in volatile markets, wasting gas. * **Recommended**: 0.5–1% for liquid pairs. Adjust for volatile or low-liquidity tokens. #### MEV Protection * **Use private mempools.** [Flashbots Protect](https://protect.flashbots.net/) and [MEV Blocker](https://mevblocker.io/) route transactions through private channels invisible to MEV searchers. * **Set transaction deadlines.** Prevent stale transactions from executing at unfavorable prices. * **Inspect multi-hop routes.** Aggregators can route through intermediary tokens/pools you did not intend to touch. Verify the full path before signing, especially for illiquid or newly listed assets. ### Common Attack Patterns #### Address Poisoning An attacker sends tiny (often 0-value) transactions from an address resembling yours or a known recipient, polluting your transaction history. They may also airdrop scam tokens/NFTs that surface in explorers, Safe interfaces, or wallet UIs to bait bad copy-paste behavior. **Always verify the full address**, not just the first and last characters, and do not copy recipients from "recent activity" alone. #### Clipboard Malware Malware monitors your clipboard and replaces copied addresses with attacker-controlled ones. **Verify the pasted address character-by-character** in your wallet's confirmation screen. If you suspect clipboard hijacking, stop transacting immediately and move funds from a known-clean device after rotating credentials. #### Fake Airdrops and Approval Traps Unknown tokens appear in your wallet. Interacting with them (swapping or "claiming") triggers a malicious `approve()` or `setApprovalForAll()` granting the attacker control over your legitimate tokens. **Ignore unknown tokens.** #### Ice Phishing The victim signs an `approve()` setting the attacker as spender. Unlike credential phishing, this grants direct on-chain token access through a legitimate mechanism. The deception is in the social engineering, not the transaction itself. This pattern is commonly referred to as ["ice phishing"](https://www.microsoft.com/en-us/security/blog/2022/02/16/ice-phishing-on-the-blockchain/) in Microsoft threat research. ### Quick Reference Checklist * [ ] **Verify the contract address** — Cross-reference against official docs and block explorer labels (see [Verifying Standard Transactions](/wallet-security/signing-and-verification/verifying-standard-transactions)) * [ ] **Simulate the transaction** — Preview balance changes before signing (see [Tools & Resources](/wallet-security/tools-and-resources)) * [ ] **Check approval amounts** — Set exact amounts, not unlimited. Revoke approvals you no longer need. * [ ] **Read what you are signing** — Inspect EIP-712 domains, types, and values. If you don't understand it, don't sign it. * [ ] **Use MEV protection for DEX trades** — Route through Flashbots Protect or MEV Blocker. *** ## Software Wallets import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Tools & Resources This section provides a curated list of tools and resources to help users select wallets, practice safe signing habits, and verify transactions. Using these tools is a critical part of a robust security strategy. ### Wallet Selection Before choosing a wallet, it is essential to consult independent, community-trusted resources. * **[ethereum.org/wallets](https://ethereum.org/en/wallets/find-wallet/)**: The official, community-maintained list of wallets, filterable by features. A reliable starting point for discovering wallets. * **[Wallet Scrutiny](https://walletscrutiny.com/)**: An in-depth review site that focuses on transparency, verifiability, and reproducibility. It flags wallets that are closed-source or have other potential security concerns. * **[Wallet Security Ranking](https://www.coinspect.com/wallets/)**: Evaluates wallets by permissions, intent clarity, device security, and threat prevention to help users choose safer, more trustworthy options. * **[Wallet Beat](https://beta.walletbeat.eth.limo/wallet/summary/)**: Aims to provide a comprehensive list of wallets, their functionality, practices, and support for certain standards. ### Hardware Wallets Hardware wallets provide the highest level of security for storing cryptocurrency by keeping private keys offline and isolated from potentially compromised computers. * **[Top 9 Cryptocurrency Hardware Wallets for 2025](https://patrickalphac.medium.com/top-9-cryptocurrency-hardware-wallets-for-2025-security-researcher-review-9fcb16d771e0)**: A comprehensive security researcher review comparing the top hardware wallets, including analysis of security features, usability, and recommendations for different use cases. ### Wallet Applications #### Rabby Wallet * Install [Rabby wallet](https://rabby.io/) * Verify open source code * Enable pre-sign security checks (e.g. new address warnings) * Use built-in transaction simulation #### MetaMask with Security Snaps (Alternative) * Install [MetaMask](https://metamask.io/) * Install recommended security Snaps: * [Tenderly Snap](https://snaps.metamask.io/snap/npm/tenderly/metamask-snap/) - Allows you to easily simulate transactions before confirming them * [Forta Network Snap](https://snaps.metamask.io/snap/npm/forta-network/metamask-snap/) - Scam and malicious address detection ### Transaction Simulation Transaction simulators allow you to preview the exact outcome of a transaction before signing it, preventing errors and security risks. * **[Tenderly](https://tenderly.co/)**: A platform that allows you to simulate transactions and preview, helping to prevent transaction failures, security risks, and unnecessary gas costs. * **[Alchemy Simulation APIs](https://www.alchemy.com/docs/reference/simulation)**: An API suite that predicts the precise impact of a transaction before it reaches the blockchain. ### Monitoring & Alerting Implement continuous monitoring to detect unauthorized or suspicious activity on your multisig wallets. #### Multisig Monitoring * [Gearbox Safe Watcher](https://github.com/Gearbox-protocol/safe-watcher) or equivalent for monitoring and alerts * Connect to Telegram for notifications * Monitor for suspicious delegateCall transactions #### Solana Multisig Monitoring * **[TxScope](https://txscope.com)**: Pre-signing threat scanner for Solana Squads multisigs. Simulates pending proposals against mainnet state and generates plain-language threat reports with risk scoring, durable nonce detection, authority transfer alerts, and known attack pattern matching. #### Network Security For dedicated signing machines, implement network-level protections: * **[DeFi DNS Whitelist](https://github.com/0xKoda/defi-dns-whitelist/tree/main)**: A curated whitelist of legitimate DeFi domains that can be used as a firewall for dedicated signing machines * **[Little Snitch](https://www.obdev.at/products/littlesnitch/index.html)** (macOS): Active firewall and network monitoring * **[Lulu](https://objective-see.org/products/lulu.html)** (macOS): Free, open-source network monitor * **[Glasswire](https://www.glasswire.com/)** (Windows): Network monitoring with firewall capabilities For more on network security configuration, see [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec#network-security). ### Transaction Verification These tools are designed to help you independently verify the integrity of transaction data, especially for multisig operations. * **[Safe Multisig Transaction Hashes](https://github.com/pcaversaccio/safe-tx-hashes-util)**: A Bash script that locally calculates domain and message hashes using the EIP-712 standard. It allows you to generate the exact hash that your hardware wallet will display. * **[Cyfrin Safe TX Hashes](https://github.com/Cyfrin/safe-tx-hashes)**: for additional support without relying on Safe API. * **[Safe Utils](https://safeutils.openzeppelin.com/)**: A user-friendly web interface for calculating and verifying Safe transaction hashes. While convenient, remember the security advantages of using a local, offline tool like `safe-hash` for high-value transactions. * **[Foundry cast](https://book.getfoundry.sh/reference/cast/cast-decode-calldata)**: A powerful command-line tool for local, offline decoding. * **[safe-hash](https://github.com/Cyfrin/safe-hash-rs)**: A command-line tool for locally verifying Safe transaction data and EIP-712 messages before signing. It is designed to protect against phishing by allowing you to independently generate the hash your wallet will ask you to sign. * **[calldata.swiss-knife.xyz](https://calldata.swiss-knife.xyz/decoder)**: Web-based tool for quick decoding of transaction data. * **[Lido Safe TX Hashes Calculation](https://lido.mypinata.cloud/ipfs/bafybeibuhixxt7rdqxfbuw2tnv3lr6r4qeh4janh3setljbtvwqwtzepsa)**: IPFS hosted tool with simple hash calculation. #### Conversion & Utilities * **[Hex ↔ Decimal Converter](https://www.rapidtables.com/convert/number/hex-to-decimal.html)**: Handy for interpreting raw instruction bytes (e.g., Solana instruction data) when verifying simulations. ### Security Training These tools allow you to practice identifying threats in a safe, simulated environment. * **[The Phishing Dojo](https://www.phishingdojo.com/)**: An interactive threat simulation platform designed to train users to recognize real-world security risks. It offers realistic, in-browser scenarios covering phishing emails, fraudulent wallet signing requests, spoofed block explorer data, and malicious DApps, all without requiring any special setup or browser extensions. * **[Wise Signer](https://wise-signer.cyfrin.io/)**: An interactive platform that challenges users to identify safe and dangerous transactions before signing them. It is an excellent tool for learning to recognize common phishing attacks and deceptive transaction patterns without risking real assets. * **[Web3 Wallet Security Courses](https://updraft.cyfrin.io/career-tracks/web3-wallet-security/)**: Offers a structured curriculum for hands-on security training, guiding users from foundational concepts in "Web3 Wallet Security Basics" to advanced techniques. The advanced course covers critical topics like Safe multisig configuration, EIP-712 signature verification, and real-world hack analysis. * **[How to Multisig](https://howtomultisig.com/)**: A dedicated resource with best practices on how to implement secure standard operating procedures for multisig wallets. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Signing And Verification > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Signing Verification](/wallet-security/signing-and-verification/signing-verification) * [Verifying Standard Transactions](/wallet-security/signing-and-verification/verifying-standard-transactions) * [Secure Multisig Signing Process](/wallet-security/signing-and-verification/secure-multisig-signing-process) * [Safe Multisig Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) * [Squads Multisig Verification](/wallet-security/signing-and-verification/secure-multisig-squads-verification) * [Verifying EIP-7702 Transactions](/wallet-security/signing-and-verification/verifying-7702) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Safe Multisig: Step-by-Step Verification Hash verification protects against UI compromise attacks where malicious transactions are injected into the signing flow. The goal is to ensure that what you see in the UI matches what your hardware wallet actually signs. ### General Signing Guidelines #### Basic Rules * **Use hardware wallet** & back up the seed phrase * **Use a separate browser or browser profile for signing** to minimize extension/session cross-contamination and reduce attack surface on your primary profile * **Secure signing environment**: For maximum security, all signing activities should be performed on a dedicated, air-gapped, or hardened device running a secure OS. Using a primary work laptop significantly increases the risk of malware interference. * **Verify the address** according to the procedures on this page upon joining any multisig * **Check transactions** you see in the queue - if unclear what the transaction should do and why, don't sign it and ask for explanation * **Require "how to check" guide** for every transaction * **Verify addresses & sums** through third party sources (message from fellow multisig co-signer is not sufficient) * **Communicate transaction status**: Tell other signers whether the transaction can be executed right away or not * **Confirm after signing**: Communicate once you've checked and signed ("checked, signed, X more required") * **Last signer executes**: If the transaction can be executed right away, the last signer does it. If they can't execute, communicate with other signers * **Re-verify before execution**: If executing an already signed transaction, check it as if you were signing it ### Key Definitions (EVM) * Domain Hash (EIP-712 domain separator) * Message Hash (raw hash of transaction params) * SafeTxHash (combined domain + message hash) ### Recommended Tools Please see the [Tools & Resources](/wallet-security/tools-and-resources) page for a list of recommended tools. ### 1) Transaction Preparation * Use delegated proposer (recommended) * Ensure the transaction is proposed in the Safe API * Record Safe address, network, nonce ### 2) Simulation Testing * Run Tenderly simulation from Safe UI; verify expected events and transfers * If using a timelock, expect a staged transaction event rather than execution Warning: Simulations can be spoofed - always apply critical thinking and good judgement during transaction reviews since a simulation can display one thing and then do something else entirely when actually executed on chain ![Tenderly simulation setup](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/tenderly-simulation-setup.png) Manual simulation (when needed): 1. Paste the contract address in the contract field 2. Paste the calldata from the Safe UI or from the hash verification tool 3. Specify the Safe address as the From address Note: For complex batch transactions that include a delegateCall to multisend, manual simulations may not be feasible. ### 3) Hash & Calldata Verification **Using CLI tool:** ```bash ./safe_hashes.sh --network [NETWORK] --address [SAFE_ADDRESS] --nonce [NONCE] ``` The CLI tool pulls the queued transaction from the Safe API for verification. If Safe infrastructure is compromised, it's possible the tool will show a hash that matches the UI, but the transaction is still not what you intend to sign. However, if you also verify the calldata output by the tool, you can be sure you are signing the correct data. **Interactive mode** (no Safe API dependency): Use `--interactive` to enter all transaction details manually. Note that in interactive mode the tool does not decode the calldata, so it's important to perform the calldata verification in step 5. #### Using web UI (OpenZeppelin Safe Utils) 1. Navigate to OpenZeppelin Safe Utils 2. Enter Safe address (checksummed) 3. Select network and enter nonce 4. Review generated hashes and decoded calldata Important: Both tools require checksummed addresses: #### Checksummed address examples * ✅ Correct: `0xA79C6968E3c75aE4eF388370d1f142720D498fEC` * ❌ Incorrect: `0xa79c6968e3c75ae4ef388370d1f142720d498fec` * Interactive mode note: In interactive mode the CLI does not decode calldata; be sure to perform the calldata verification in step 5. ### 4) Hash Comparison * Message Hash on tools must match hardware wallet display * Domain Hash ensures correct Safe * SafeTxHash for nested Safe approvals ### 5) Calldata Review * Decode calldata (e.g., SwissKnife) * Verify functions, recipients, amounts; watch for risky operations #### Tool diversity recommendation Signers should not all use identical tools. Cross-verify results between multiple tools (CLI and web) for critical operations. ### Special Cases: Nested Safes * Use `--nested-safe-address` and `--nested-safe-nonce` to verify approveHash flows *** ### Related Documents * [Hardware Wallet Setup](/wallet-security/intermediates-and-medium-funds) * [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) * [Emergency Procedures](/multisig-for-protocols/emergency-procedures) * [Tools & Resources](/wallet-security/tools-and-resources) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Verifying Multisig Transactions The security of a multisig wallet relies on each signer independently verifying what they are signing. A compromised web interface could present a legitimate-looking transaction while tricking a hardware wallet into signing a malicious one. The verification process is divided into two distinct phases: signing the off-chain message and executing the on-chain transaction. ### Key Definitions (EVM) * **Domain Hash**: EIP-712 domain separator, unique to each Safe. Ensures signatures cannot be replayed on other networks or Safes. * **Message Hash**: Raw hash of transaction parameters. This appears on your hardware wallet. * **SafeTxHash**: Combined hash of domain + message hash. Used for nested Safe approvals. ### Phase 1: Signing the Off-Chain Message When you are the first signer or are adding your signature to a transaction that has not yet met its threshold, you are not sending an on-chain transaction. Instead, you are signing a structured, off-chain message that conforms to the **EIP-712** standard. **Goal**: To confirm that the cryptographic hash displayed on your hardware wallet exactly matches the hash of the transaction you intend to approve. #### Process 1. **Initiate Signing**: Start the signing process in the multisig wallet's web interface. 2. **Verify on Hardware Wallet**: Your hardware wallet will display an EIP-712 hash for you to sign. 3. **Compute Hash**: Use an independent, local tool to re-calculate the expected hash from the transaction's parameters (`nonce`, `to`, `value`, `data`, etc.). For a list of recommended options, see the [Transaction Verification Tools](/wallet-security/tools-and-resources) section. 4. **Compare Hashes**: Compare the `SafeTxHash` generated by the local tool with the hash displayed on your hardware wallet's screen. **They must match perfectly.** * All signers must verify transaction data on at least two independent devices * All signers must verify transaction data through at least two separate communication channels 5. **Simulate Transaction**: At least 2 signers must use transaction simulation tools to verify transaction effects. Simulation testing output should be shared with and reviewed by all signers before signing. * Warning: Simulations can be spoofed - always apply critical thinking and good judgement during transaction reviews since a simulation can display one thing and then do something else entirely when actually executed on chain 6. **Sign**: If the hashes match and simulation results are verified, you can confidently sign the message on your hardware wallet. This confirms you are approving the correct transaction, even if the web UI has been compromised. ### Phase 2: Executing the On-Chain Transaction Once a transaction has the required M-of-N signatures, it can be executed. This involves submitting a final on-chain transaction that calls the `execTransaction` function on the multisig contract, passing in all the previously signed data. **Goal**: To confirm that the on-chain transaction being sent correctly encapsulates the multisig transaction you and other signers approved. #### Process 1. **Initiate Execution**: In the multisig interface, start the execution of the fully signed transaction. 2. **Verify Calldata**: Your hardware wallet will prompt you to sign a new on-chain transaction. It will display the raw transaction data (calldata), which should show a call to the `execTransaction` function. 3. **Decode and Compare**: Use a calldata decoder (e.g.,[calldata.swiss-knife.xyz](https://calldata.swiss-knife.xyz/decoder)) to parse the data shown on your hardware wallet. 4. **Confirm Parameters**: Carefully check the decoded parameters within the `execTransaction` call, especially the internal destination address (`to`), `value`, and `data` payload. Ensure they match the original, intended transaction. 5. **Sign and Broadcast**: If the calldata is correct, sign the transaction on your hardware wallet to broadcast it to the network. ### Operational Best Practices > ⚠️ **Beware of `DELEGATECALL`**: In a smart contract multisig transaction, an `operation: 1 (DELEGATECALL)` is > dangerous if the target contract is not explicitly known and trusted. This opcode gives another contract full control > over your wallet's context and storage. * **Transaction Simulation**: Before signing, use a simulator like **[Tenderly](https://tenderly.co/)** or **[Alchemy](https://www.alchemy.com/docs/reference/simulation)** to preview the transaction's outcome. This helps confirm that it will not revert and will result in the expected state changes. * **Hardware Wallet Standard**: All multisig signers should use hardware wallets to protect their keys from online threats. Data shown in a browser extension wallet should be treated with the same skepticism as data in the web UI. * **Secure signing environment**: Use a dedicated, air-gapped, or hardened device. Avoid primary work laptops. * **Alternative Frontends**: To further reduce reliance on a single public UI, consider using an alternative or self-hosted multisig interface. * **Separate browser/profile for signing**: Use a dedicated browser or browser profile when interacting with signing UIs to reduce cross-extension/session risk. * **Require a "how to check" guide**: Every transaction should include explicit verification instructions for signers. * **Verify addresses and amounts via independent sources**: Do not rely solely on messages from co-signers. * **Check transactions in the queue**: If unclear what a transaction does and why, do not sign; ask for explanation. * **Communicate status**: After review, state whether a transaction is ready to execute and confirm after signing ("checked, signed, X more required"). * **Last signer executes**: If executable immediately, the last signer should execute; otherwise coordinate clearly. * **Re-verify before execution**: Treat execution as a fresh signing event and re-check parameters. * **Use checksummed addresses**: Always use checksummed format to prevent copy/paste or case errors. #### Simulation notes with timelocks When using a timelock, simulations may show the staging event rather than actual execution. Inspect the staged payload and verify cancellation/execution roles and parameters before proceeding. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Squads Multisig: Step-by-Step Verification Limited tooling is available for Solana verification compared to EVM. Exercise extra caution and cross-verify with team members. ### Workflow 1. Initial Proposal (SOL transfer, token transfer, signer/threshold change) 2. Simulation * Squads UI provides a simulation link after first signature * Simulation is helpful for transfers; configuration changes often fail, but you can still inspect data via explorer Warning: Simulations can be spoofed - always apply critical thinking and good judgement during transaction reviews since a simulation can display one thing and then do something else entirely when actually executed on chain ### SOL Transfer Verification ![SOL transfer transaction overview](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/sol-transfer-transaction-overview.png) [Transaction Link](https://app.squads.so/squads/e4knHMRYwCTQH879dRoTUvWwKR9jy5jE52kh2iy4kL2/transactions/2sAD1s2cpN8xkDKpsjF3mgpAZ5T6Ly4Zuattr6eMzmjG) [Simulation Link](https://explorer.solana.com/tx/inspector?signatures=%255B%25221111111111111111111111111111111111111111111111111111111111111111%2522%252C%25221111111111111111111111111111111111111111111111111111111111111111%2522%255D\&message=gAIAAgZwPe7Z%252FXshAtomCcciz6nV7UMyPHih06vc7yk9ty6UoAl%252BvEzOMR3HvSFhM2GWdWNVeRQBVmsO%252BMzLyKmaMKEz7jI0LiZeXnyTOKjFEy5Th61mABykSj2asFCSBK3vw7WMKRhm0xquPpdNaEAeFg%252FN30zo7KzBfmzdI3QlkLN55QMGRm%252FlIRcy%252F%252BytunLDm%252Be8jOW7xfcSayxDmzpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS9ir2PAxknA4YchoA50xsGOmMh%252FMWqcxS3WgQCJFjjgQEAAUBAAAEAAQABQLAXBUABQIBAgwCAAAAgJaYAAAAAAAFAgEDDAIAAABAS0wAAAAAAAA%253D) On the simulation page scroll down to **System Program Instruction** ![System Program Instruction details](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/system-program-instruction-details.png) This shows the destination address for the SOL (H2p…Kr) and the Instruction Data. The instruction data can be interpreted as follows. **Example instruction data interpretation:** ``` 02 00 00 00 80 96 98 00 00 00 00 00 ``` 1. **Split into bytes**: `02 00 00 00 80 96 98 00 00 00 00 00` 2. **First 4 bytes (transfer type)**: `02 00 00 00` = \[2, 0, 0, 0] ✅ (confirms this is a token transfer) 3. **Amount bytes (little-endian)**: `80 96 98 00 00 00 00 00` = \[128, 150, 152, 0, 0, 0, 0, 0] in decimal 4. **Convert from little-endian to decimal**: * Little-endian means least significant byte first * `80 96 98 00` = `0x00989680` in big-endian hex * `0x00989680` = 10,000,000 in decimal 5. **Convert lamports to SOL**: * 1 SOL = 1,000,000,000 lamports * 10,000,000 lamports ÷ 1,000,000,000 = 0.01 SOL ✅ Quick verification method: For the amount portion (`80 96 98 00 00 00 00 00`): * Reverse the order: `00 00 00 00 00 98 96 80` * Convert hex to decimal: `0x989680` = 10,000,000 * Divide by 1,000,000,000: 10,000,000 ÷ 1,000,000,000 = 0.01 SOL ### USDS Transfer Verification [Transaction Link](https://app.squads.so/squads/e4knHMRYwCTQH879dRoTUvWwKR9jy5jE52kh2iy4kL2/transactions/CpPSRtvsZjhYrQwXKg72JwnLYsFQEmCkKLLA1v97ggTF) [Simulation Link](https://explorer.solana.com/tx/inspector?signatures=%255B%25221111111111111111111111111111111111111111111111111111111111111111%2522%252C%25221111111111111111111111111111111111111111111111111111111111111111%2522%255D\&message=gAIABQmMKRhm0xquPpdNaEAeFg%252FN30zo7KzBfmzdI3QlkLN55Ql%252BvEzOMR3HvSFhM2GWdWNVeRQBVmsO%252BMzLyKmaMKEzxF5adOSOc03j8RtbcEMRZfSyDhZDpj%252Bf89egzdX3712eUpW3sOB32puEK85AjoAlc8KSleU8LnaIbhD8fK9eRgMGRm%252FlIRcy%252F%252BytunLDm%252Be8jOW7xfcSayxDmzpAAAAAjJclj04kifG7PRApFI4NgwtaE5na%252FxCEBI572Nvp%252BFnuMjQuJl5efJM4qMUTLlOHrWYAHKRKPZqwUJIEre%252FDtQcHMS0dQdpx8PsoDBZizWXr6y4IWcDLrj%252Fb3LJshuCvBt324ddloZPZy%252BFGzut5rBy0he1fWzeROoz1hX7%252FAKkVxPfrULPMJ%252BJHEroegjMTe9e7y7fbwd%252BuhToyuOMfEQQEAAUBAAAEAAQABQLAXBUABQYBAgYHCQgBAQgEAwcCAQoMQEIPAAAAAAAGAbqmLEkSumVVR1a24Yy6rkkWI1IASK6g1AQ30DXoTsREAAEF)) On the simulation page scroll down to **Associated Token Program: Create Idempotent** & **Token Program Instruction** ![Token Program Instruction details](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/token-program-instruction-details.png) This shows the destination address for the USDS in the Token Program Instruction (H2p…Kr) and the Instruction Data. The instruction data can be interpreted as follows. ``` 0c 40 42 0f 00 00 00 00 00 00 06 ``` 1. **Split into bytes**: `0c 40 42 0f 00 00 00 00 00 00 06` 2. **First byte (instruction type)**: `0c` = 12 in decimal ✅ (confirms this is TransferChecked instruction) 3. **Amount bytes (little-endian)**: `40 42 0f 00 00 00 00 00` = \[64, 66, 15, 0, 0, 0, 0, 0] in decimal 4. **Convert from little-endian to decimal**: * `40 42 0f 00` = `0x000f4240` in big-endian hex * `0x000f4240` = 1,000,000 in decimal 5. **Convert raw units to USDS**: * USDS has 6 decimals * 1,000,000 raw units ÷ 10^6 = 1.0 USDS ✅ 6. **Decimals verification**: Last byte `06` = 6 decimals ✅ (correct for USDS) ### Configuration Change Verification ![Configuration change transaction overview](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/configuration-change-transaction-overview.png) [Transaction Link](https://app.squads.so/squads/e4knHMRYwCTQH879dRoTUvWwKR9jy5jE52kh2iy4kL2/transactions/4KDPpv27fQmbWteQjSZLku8sGxNfoDqtYG4mZQp2zbiq) Simulation does NOT seem to work for configuration changes, but we have another way we can verify it! 1. Copy the transaction ID ([4KDPpv27fQmbWteQjSZLku8sGxNfoDqtYG4mZQp2zbiq](https://explorer.solana.com/address/4KDPpv27fQmbWteQjSZLku8sGxNfoDqtYG4mZQp2zbiq?signatures=%255B%25221111111111111111111111111111111111111111111111111111111111111111%2522%252C%25221111111111111111111111111111111111111111111111111111111111111111%2522%255D\&message=gAIABQmMKRhm0xquPpdNaEAeFg%252FN30zo7KzBfmzdI3QlkLN55Ql%252BvEzOMR3HvSFhM2GWdWNVeRQBVmsO%252BMzLyKmaMKEzxF5adOSOc03j8RtbcEMRZfSyDhZDpj%252Bf89egzdX3712eUpW3sOB32puEK85AjoAlc8KSleU8LnaIbhD8fK9eRgMGRm%252FlIRcy%252F%252BytunLDm%252Be8jOW7xfcSayxDmzpAAAAAjJclj04kifG7PRApFI4NgwtaE5na%252FxCEBI572Nvp%252BFnuMjQuJl5efJM4qMUTLlOHrWYAHKRKPZqwUJIEre%252FDtQcHMS0dQdpx8PsoDBZizWXr6y4IWcDLrj%252Fb3LJshuCvBt324ddloZPZy%252BFGzut5rBy0he1fWzeROoz1hX7%252FAKkVxPfrULPMJ%252BJHEroegjMTe9e7y7fbwd%252BuhToyuOMfEQQEAAUBAAAEAAQABQLAXBUABQYBAgYHCQgBAQgEAwcCAQoMQEIPAAAAAAAGAbqmLEkSumVVR1a24Yy6rkkWI1IASK6g1AQ30DXoTsREAAEF)) 1. This will take you to an 'account' page on the Solana explorer representing just this transaction 2. Click the [first transaction](https://explorer.solana.com/tx/36QYWYC9a5eCtd8QNkdjWmqUyY21wNYBNRtuQrtPqJRg1QbeL8rmVKume21VwrQRjJHZjkHVMMWA1sYWtF4wfZ6u) in the history of this 'transaction account' 3. Scroll down to **Squads Multisig Program: Config Transaction Create** 1. Expand all fields to view the decoded transaction data ![Squads Multisig Program details](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-multisig-program-details.png) ### Signing & Execution * Sign (do not execute) and confirm expected hash on hardware wallet * Execute after collecting all signatures * Once all signatures are collected, execute the transaction. import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Signing & Verification This section provides a guide to transaction verification, from basic EOA interactions to advanced multisig operations. The rule is to **never sign blindly**. Always take the time to verify what your wallet is asking you to approve. A compromised dApp front-end or a misunderstanding of a transaction's parameters can lead to a complete loss of funds, even with a wallet that is not compromised. ### Core Principles of Secure Signing Before diving into specific use cases, it's critical to adopt a security-first mindset built on these foundational principles: * **Verify, Don't Trust**: Never trust a user interface blindly. The raw transaction data is the ground truth of what you are authorizing. Always use independent tools to confirm that what you see is what you sign. * **Simulate Before Signing**: Before approving any non-trivial transaction, use a simulation tool. These tools act as a "sandbox," showing you the human-readable outcome before you commit, protecting you from unexpected results and malicious contracts. * Warning: Simulations can be spoofed - always apply critical thinking and good judgement during transaction reviews since a simulation can display one thing and then do something else entirely when actually executed on chain * **The Hardware Wallet is the Source of Truth**: Your hardware wallet's trusted display is your last line of defense against UI spoofing. If the information on your computer screen does not perfectly match what is on your hardware device, reject the transaction immediately. * **Demand Clear Signing**: Prioritize hardware and software that can decode and display a transaction's intent in a human-readable format. If a wallet requires "blind signing" (approving a raw, unreadable hash), you are accepting a significant level of risk. ### In This Section This chapter breaks down transaction verification into key areas: * **[Standard Transaction Verification](/wallet-security/signing-and-verification/verifying-standard-transactions)**: An overview of the foundational security principles that apply to all types of transactions. * **[Safe Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification)**: Concrete, end-to-end Safe verification flow (hashes, simulations, calldata review, nested Safes). * **[Squads Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-squads-verification)**: Concrete, end-to-end Squads verification flow (proposal anatomy, simulations, decoded program data). * **[Verifying Multisig Transactions](/wallet-security/signing-and-verification/secure-multisig-signing-process)**: Conceptual two-phase model (off-chain EIP-712 signing and on-chain execTransaction) and best practices. * **[Verifying EIP-7702 Transactions](/wallet-security/signing-and-verification/verifying-7702)**: An analysis of the new security considerations introduced by EIP-7702, which allows EOAs to temporarily act as smart contracts, with specific guidance for both users and developers. To apply these principles, this framework provides a curated list of verification and simulation tools in the **[Tools & Resources](/wallet-security/tools-and-resources)**. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Using EIP-7702 The Pectra network upgrade introduces **EIP-7702**, which allows a standard Externally Owned Account (EOA) to temporarily function like a smart contract wallet. This is achieved via a new transaction type (`0x04`) that lets an EOA delegate its authority to a smart contract's code for the duration of a transaction or until it's changed. ### Benefits of EIP-7702 This EIP unlocks several key user experience improvements: * **Transaction Batching**: Users can combine multiple operations (e.g., an ERC-20 `approve` and a `swap`) into a single, atomic transaction, saving on gas fees and reducing confirmation fatigue. * **Gas Sponsorship**: It enables third parties to pay for a user's transaction fees, which can simplify onboarding and abstract away gas management for the user. * **Privilege De-escalation**: Users can delegate to contracts that enforce specific permissions, such as daily spending limits or interactions with only certain dApps. ### Risks of EIP-7702 While powerful, this feature introduces a new attack vector. If an attacker tricks a user into signing a message that sets the wallet's code to a malicious contract, the attacker can gain full control and drain all assets. * **Phishing Attacks**: The primary threat is phishing sites or scams that trick users into signing a `SetCode` delegation to a malicious contract under the guise of a wallet "upgrade." * **Multi-Chain Replay Attacks**: A signature authorizing a delegation with `chain ID 0` can be replayed on other EVM chains. An attacker could deploy a malicious contract at the same address on a different chain and use the replayed signature to take control there. ### Guidance for Users * **Trust Your Wallet's Implementation**: Major wallets mitigate phishing risks by **hardcoding** the *only* valid delegation contract. This prevents malicious websites from tricking you into delegating to an unsafe contract. Only approve delegations to contracts vetted and integrated by your wallet provider. * **Verify Delegation Targets**: Only delegate your account to contracts that are well-known and audited. * **Understand Revocation**: You can revoke a delegation and return your account to a standard EOA by authorizing a new transaction that sets the delegation address to the zero address (`0x0000000000000000000000000000000000000000`). * **Protect Your Private Key**: Delegation does not eliminate the fundamental risk of a private key compromise. If your key is stolen, an attacker can still authorize delegations. * **Beware of Phishing**: Be skeptical of any request to "upgrade" or "enable" smart account features, especially if it comes from an external link or pop-up. > ⚠️ Wallets will only prompt you to switch to a smart account within the wallet's native. Any request to do so via > email, a website, or a direct message is a phishing scam. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Verifying Standard Transactions (EOA) When interacting with a dApp using a standard Externally Owned Account (EOA) via a wallet, you must verify several key components of the transaction request before signing. ### 1. Verify the Origin * **What to check**: The URL of the website initiating the transaction request. * **Why it's critical**: A malicious site can perfectly clone a legitimate dApp's interface to trick you into signing a malicious transaction. Always ensure you are on the correct, official domain. ### 2. Verify the Smart Contract Address * **What to check**: The contract address listed under a field like "Interacting With" in your wallet's transaction prompt. * **Why it's critical**: This is the actual on-chain address your transaction is being sent to. A malicious dApp will substitute a fraudulent contract address here. * **Verification Methods**: * **Official Documentation**: The most reliable source. Find the "Contract Addresses" or "Deployments" section in the protocol's official documentation and confirm the address matches. * **Block Explorer (Etherscan, Blockscout, etc.)**: Paste the address into a block explorer. Look for verification checkmarks, official labels, and a healthy transaction history. ### 3. Verify the Function and Parameters * **What to check**: The function name (e.g., `depositETH`) and the parameters in the "Data" tab of your wallet. * **Why it's critical**: This is the exact *action* you are authorizing the smart contract to perform. A malicious transaction might look legitimate on the surface but contain a harmful function call. * **Verification Methods**: * **Cross-reference with Documentation**: The protocol's developer documentation will define the function and what each parameter represents. * **Scrutinize Recipient Addresses**: For any function that directs assets (e.g., `onBehalfOf`, `recipient`, `to`), ensure the address is your own or the intended recipient. * **Understand Amounts**: Verify token amounts, paying attention to the number of decimals. ### 4. Sanity-Check the Network Fee (Gas) * **What to check**: The estimated gas fee for the transaction. * **Why it's critical**: An unusually high gas fee for a simple operation can be a red flag, potentially indicating an inefficient or malicious contract designed to waste user funds. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Bug Bounties Bug bounty programs incentivize security researchers to identify and report vulnerabilities in your project. They augment a security team and complement audits by allowing external security researchers to disclose vulnerabilities in your project in a way that should be a good experience for the security researcher. Depending on what the scope of the bug bounty program is, you may have a higher success rate having certain parts at different types of bug bounty as a service providers, as they generally have security researchers with different skill sets using their platforms. ### Bug Bounty as a Service #### Web3 * Immunefi * **Pros**: One of the largest bug bounty as a service platforms for web3 * Hackenproof * **Pros**: Provides end-to-end encryption for reports, ensuring only a project's security team can decrypt it using their own private keys. #### Web2 * HackerOne * Bugcrowd ### Pros and Cons of Running Your Own Bug Bounty Program #### Pros 1. Full control over the scope, rewards, and rules of the program. 2. Potentially lower cost. 3. Direct interaction with security researchers could build strong relationships. #### Cons 1. Requires significant time and resources to manage. 2. Need for skilled triage abilities to handle and prioritize reports. 3. Risk of being overwhelmed by reports, including false positives. ### Key Elements of a Successful Bug Bounty Program #### Scope 1. Clearly define the scope of the program, including in-scope and out-of-scope assets. 2. Regularly update the scope to include new features and exclude deprecated ones. #### Rewards 1. Offer competitive rewards based on the severity and impact of the vulnerabilities. 2. Be transparent about the reward structure and criteria for evaluating reports. #### Triage and Response 1. Have skilled personnel to triage incoming reports, assess severity, and prioritize responses. 2. Respond to reports promptly, acknowledging receipt and providing regular updates. #### Communication 1. Treat all reporters with respect and professionalism. 2. Provide feedback to researchers on the status of their reports and any actions taken. #### Legal and Ethical Considerations 1. Clearly state safe harbor provisions to protect researchers from legal action when acting in good faith. 2. Define your policy on public disclosure of vulnerabilities, including timelines and conditions. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Vulnerability Disclosure > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Vulnerability Disclosure](/vulnerability-disclosure/overview) * [Security Contact](/vulnerability-disclosure/security-contact) * [Bug Bounty Programs](/vulnerability-disclosure/bug-bounties) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Vulnerability Disclosure Vulnerability disclosure is the task that is done after a vulnerability has been identified and fixed, and means to make the vulnerability known to the larger public. Often, a vulnerability disclosure will come after a [bug bounty](/vulnerability-disclosure/bug-bounties) report has been filed and the vulnerability has been corrected, or from a team member that noticed a vulnerability which was then fixed. In the event that responsible disclosure of the vulnerability is not possible because the vulnerable code is actively or will imminently be exploited, [Safe Harbor](/safe-harbor/overview) may be applicable. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Security Contact Having a security contact provides a designated point of contact for security researchers to report vulnerabilities to. ### SECURITY.md File #### Importance A SECURITY.md file in your GitHub repository provides clear instructions on how to report security vulnerabilities. #### Example Content ``` # Security Policy We take the security of our project seriously. If you discover any security vulnerabilities, please report them responsibly. ## Reporting a Vulnerability Please email us at security@projectname.TLD with the details of the vulnerability. We will respond as soon as possible. We appreciate your help in improving the security of our project. ``` ### Security Email Address #### Importance Having a dedicated security email address (e.g., [security@projectname.TLD](mailto\:security@projectname.TLD)) ensures that vulnerability reports are directed to the appropriate team members. #### Setup * Dedicated Team: Ensure that the security email is monitored by a team with the expertise to handle vulnerability reports. * Prompt Responses: Aim to acknowledge receipt of vulnerability reports within 24 hours. ### .well-known/security.txt #### Importance The .well-known/[security.txt](https://securitytxt.org/) file is a standardized way to provide security contact information on your website. #### Example Content ``` Contact: mailto:security@projectname.TLD Encryption: https://projectname.TLD/pgp-key.txt Acknowledgements: https://projectname.TLD/hall-of-fame.html Policy: https://projectname.TLD/security-policy.html Preferred-Languages: en ``` #### Implementation * Standard Location: Place the security.txt file in the .well-known directory of your website (e.g., [https://projectname.TLD/.well-known/security.txt](https://projectname.TLD/.well-known/security.txt)). * Regular Updates: Keep the security.txt file updated with current contact information and policies. ### Managing Security Contacts #### Responsibilities * Triage: Assess and prioritize vulnerability reports based on severity and impact. * Communication: Maintain clear and respectful communication with reporters. Provide regular updates on the status of their reports. * Resolution: Work promptly to resolve reported vulnerabilities and update the reporter on the actions taken. ### Best Practices * Confidentiality: Treat all vulnerability reports as confidential until a fix is implemented. * Acknowledgement: Consider publicly acknowledging researchers who report vulnerabilities, with their permission. * Transparency: Be transparent about your vulnerability disclosure process and timelines. *** ## User and Team Security ## Phishing and Social Engineering ## Security-Aware Culture ## Security Training import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, } from "../../../components"; ## Custodial Treasury Security: Classification Framework Proper documentation and classification of custodial accounts is essential for institutional treasury security. This guide focuses on the security assessment and classification framework for crypto assets held with third-party custodians. > See also: [Registration Documents](./registration-documents) and [Enhanced Controls for High-Risk Accounts](./enhanced-controls) ### Classification Process Use this dual classification to determine appropriate security controls for each custodial account. #### Step 1: Impact Assessment Evaluate the consequences if this account is compromised or unavailable. ##### Financial Impact Calculate the total value at risk in this account: * Current market value of all assets held * Include value of any active positions (e.g., staked assets, DeFi deposits) * What is the financial impact if unavailable for 7 days? ##### Operational Impact Assess the consequences if this account becomes unavailable: * What specific operations require this account? * Do you have a secondary custody account that can handle these operations? * What is the reputational impact if this account is compromised or unavailable? ##### Regulatory Impact Evaluate regulatory and compliance consequences: * Are assets in this account subject to regulatory reporting requirements (SEC filings, audit requirements)? * Does this account hold regulated assets (e.g., stablecoins subject to reserves reporting)? * What are the regulatory deadlines that could be missed if this account is unavailable? ##### Impact Classification | Level | Financial Exposure (% of Total Assets) | Operational Dependency | Regulatory Impact | | ------------ | -------------------------------------- | -------------------------------------------- | ---------------------------------------------------- | | **Low** | \<1% | No critical operations depend on it | No regulatory reporting tied to this account | | **Medium** | 1% - 10% | Important but alternative funding available | Periodic reporting; delays manageable | | **High** | 10% - 25% | Critical operations, limited alternatives | Regular regulatory filings; delays cause violations | | **Critical** | >25% | Business-critical, no alternatives for weeks | Real-time reporting requirements; SEC filings; audit | #### Step 2: Operational Assessment Evaluate how frequently and urgently this account must be accessed. ##### Transaction Frequency Document typical transaction patterns: * Transactions per month * Typical transaction sizes * Predictability of transaction timing ##### Access Urgency Define response time requirements: * What is the maximum acceptable delay for routine transactions? * Are there scenarios requiring same-day execution? * What are the consequences of 24-hour, 72-hour, or 7-day delays? ##### Coordination Requirements Assess how transactions are executed: * How many approvers are needed for typical transactions? * Are transactions handled manually or through automated systems? * Do approvers need to coordinate across timezones? Note: Single-approver configurations should only be used for low-value operational accounts (\<0.1%) with additional compensating controls like strict spending limits and daily reconciliation. ##### Operational Classification | Type | Frequency | Response Window | Example Use Cases | | --------------------- | ------------- | --------------- | -------------------------------------------------- | | **Cold Vault** | \<5 tx/month | 48-72 hours | Long-term reserves, infrequent rebalancing | | **Warm Storage** | 5-50 tx/month | 4-24 hours | Scheduled payments, planned operations | | **Active Operations** | >50 tx/month | \<4 hours | Trading capital, frequent operational expenses | | **Time-Critical** | Unpredictable | \<2 hours | Collateral management, market-sensitive operations | #### Step 3: Security Control Matrix Combine impact and operational assessments to determine required controls. | Use Case | Impact | Operational | Approvers | MFA Requirement | Whitelist Delay | Additional Controls | | ----------------------------- | ----------- | ------------- | --------- | ------------------ | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Payments | Low | Active Ops | 2 | Standard TOTP | 6 hours | **Baseline (all accounts):** Dedicated devices for custody access, address whitelisting enabled, test small amount to new addresses before full transaction, transaction simulation. **Low-specific:** Per-transaction cap, monthly aggregate limit | | Operational Wallet | Medium | Active Ops | 2 | Hardware required | 12 hours | All Low controls + daily transaction caps, weekly reconciliation, monthly audit | | Liquidation Protection | Medium-High | Time-Critical | 2 | Hardware required | None | All Low/Medium controls + automated alerts for position health, real-time monitoring | | DeFi Positions | Medium-High | Warm Storage | 3 | Hardware mandatory | 24 hours | All Low/Medium controls + smart contract whitelist, position monitoring, daily reconciliation | | Trading Capital (variable) | High | Active Ops | 3 | Hardware mandatory | 6 hours | All Low/Medium controls + smart contract whitelist, real-time monitoring, daily reconciliation | | Active Treasury (5-10%) | High | Warm Storage | 3-4 | Hardware mandatory | 24 hours | All Low/Medium controls + transaction velocity limits, SIEM monitoring, multi-channel confirmation | | Secondary Reserve (10-25%) | Critical | Cold Vault | 4-5 | Hardware mandatory | 48 hours | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended | | Primary Reserve (>25% assets) | Critical | Cold Vault | 5-7 | Hardware mandatory | 72 hours | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended | #### Step 4: Document Your Decision * Record impact level and operational type with justification * Capture approver thresholds and required controls * Store links to relevant custody accounts and addresses Proceed to: [Registration Documents](./registration-documents) For Critical/High accounts, ensure you also review: [Enhanced Controls for High-Risk Accounts](./enhanced-controls) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, } from "../../../components"; ## Enhanced Controls for High-Risk Accounts For Critical and High impact custodial accounts, implement the following controls in addition to baseline measures. *** ### Transaction Verification * Test transactions: Send maximum $100 to new addresses before executing full transaction * Multi-channel confirmation: Request via one channel, approve via separate channel * Simulation requirement: All transactions must be simulated before execution * Address verification: Verify new addresses against three independent sources For DeFi interactions: refer to the [DeFi Risk Assessment Guide](https://entethalliance.org/specs/defi-risks/v1/) for recommended procedures. ### Access Security * Hardware security keys (FIDO2/WebAuthn) mandatory for all approvers * Secure fallback: Each approver must register a minimum of 2 hardware keys stored in separate secure locations * Key loss procedure: Temporary access via backup key + additional approver verification via multiple channels + mandatory key replacement within 48 hours * IP whitelisting with 24-hour change approval delay - if treasury software supports application-level IP whitelisting, restrict to VPN IP range only * Device fingerprinting with new device approval process * Session timeout and re-authentication for sensitive operations * Dedicated credentials: Use separate email addresses and passwords exclusively for custody access, not shared with other corporate systems ### Device Security * Dedicated secure workstations and mobile devices for custody access only (no general browsing, email, or other corporate activities) * Network isolation on separate VLAN/segment * VPN mandatory for all platform access; if treasury platform supports it, configure IP whitelisting to only allow access from VPN IP addresses * Full disk encryption with automatic screen lock * MDM-enforced security baseline with remote wipe capability * Mobile endpoint security monitoring (e.g., iVerify) for devices used as second factors or keystores, without requiring full MDM admin control ### MPC for Large Holdings For organizations managing >10% of total assets or >$10M equivalent in a single custodial account, consider using MPC: * Evaluate MPC (Multi-Party Computation) custody solutions that distribute key material across multiple parties * Consider threshold signature schemes (e.g., 3-of-5 or 5-of-9) where no single party controls sufficient key shares * Implement geographic distribution of key share holders across multiple jurisdictions * Establish clear key refresh and rotation procedures * Document recovery procedures and test annually #### Custody/MPC Policy Thresholds for Treasury Operations * Minimum of 3 distinct approvers across roles (e.g., Treasury, Security, Finance) * Target majority approval (≥50% of designated approver group; e.g., 3/5, 4/7) * Scale quorum size with assets-at-risk and operational blast radius * Enforce separation of duties: requester cannot be an approver; admins cannot unilaterally execute withdrawals Policy scope definitions (examples): * Emergency Freeze: Temporarily block withdrawals/policy changes across workspaces * Protocol Parameters: Custody/policy engine settings, risk rules, policy changes * Capital Allocation: Movements between accounts, exchanges, or strategies * Treasury – Large: Routine treasury transfers above internal threshold or rate limit * Treasury – Small: Routine operational transfers below internal threshold or rate limit * Constrained DeFi: Time-sensitive interactions with pre-approved protocols/contracts Suggested approver thresholds (treasury contexts): | Operation | Impact | Urgency | Approver Threshold | | ------------------- | -------- | -------------- | ----------------------- | | Emergency Freeze | Critical | Emergency | 2/4 | | Protocol Parameters | High | Routine | 4/7 (7/9+ for upgrades) | | Capital Allocation | High | Time-Sensitive | 3/5 | | Treasury - Large | High | Routine | 4/7 | | Treasury - Small | Medium | Routine | 3/5 | | Constrained DeFi | Medium | Time-Sensitive | 2/3 | ### Custody Policy Engine Rules Most custody/MPC platforms provide a policy engine that evaluates transaction rules and takes one of three actions: allow, block, or require additional approvals. Core rule elements: * Action: allow | block | escalate (require more approvers) * Asset selector: all assets or specific assets/tokens * Amount limits: per-transaction limit and optional rolling window aggregation * Source and destination selectors: account/wallet groups, internal vs external addresses, exchanges * Transaction type: transfers, contract interactions, approvals/signing * Initiators and approvers: who can initiate and who must authorize (with thresholds) * Rule identity and ordering: each rule has an ID; engines typically evaluate rules in order (first-match wins) ### Zero Trust Architecture Alternative A Zero Trust architecture involves continuous verification of user, device, and context, rather than reliance on a single perimeter or network location. Centralizing access through a secure environment (such as a bastion host or isolated cloud workspace) can support Zero Trust principles when combined with strong identity and device posture enforcement. * Bastion Host Approach: Deploy a hardened jump server that acts as the sole gateway to custody platforms. * All custody sessions route through the bastion with full session recording * Bastion enforces MFA, device posture checks, and approved software versions * No direct custody access from employee devices * Centralized patch management and security configuration * Cloud Workspace Isolation: Use browser-isolated or virtual workspace environments (e.g., Citrix, AWS WorkSpaces, Azure Virtual Desktop) * Custody access occurs only within a controlled virtual environment * Copy/paste and download restrictions prevent data exfiltration * Session timeout and automatic workspace destruction after use * Significantly reduces risk from compromised employee devices ### Security Monitoring & Logging For Critical and High impact accounts, implement centralized security monitoring: * SIEM Deployment: Deploy SIEM to centralize logs from custody platforms, authentication systems, and access devices. Create real-time correlation rules for suspicious patterns (failed authentication, geographic anomalies, policy changes). * Internal Incident Response: Build dedicated incident response capability for custody-related security events. Define clear escalation procedures, maintain 24/7 on-call rotation for Critical accounts, and establish playbooks for custody compromise scenarios. * Essential Log Sources: Authentication events, transaction attempts, policy modifications, access changes, whitelist updates, IP address changes, new device enrollments, and approval workflows. For Medium and Low impact accounts, leverage custodian's native audit logs with weekly manual review and automated alerting for critical events (new device enrollment, policy changes, transactions above threshold). *** #### See also * Classification: [Custodial Treasury Security: Classification Framework](./classification) * Templates: [Registration Documents](./registration-documents) {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Treasury Operations > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Treasury Operations Security](/treasury-operations/overview) * [Treasury Security Classification](/treasury-operations/classification) * [Custodial Account Registration](/treasury-operations/registration-documents) * [Enhanced Controls for High-Risk Accounts](/treasury-operations/enhanced-controls) * [Treasury Transaction Verification](/treasury-operations/transaction-verification) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, } from "../../../components"; ## Treasury Operations Security > 💡 Institutional-grade security frameworks for managing custodial treasury accounts and large cryptocurrency transfers ### What is Treasury Operations Security? Treasury operations security provides protocols and frameworks for organizations managing significant cryptocurrency holdings through custodial accounts. These guides help you classify accounts by risk, implement appropriate security controls, maintain proper documentation, and execute large transfers safely. ### Core Components #### [Classification Framework](./classification) Assess and classify custodial accounts based on financial impact and operational requirements. Determine appropriate security controls, approval thresholds, and monitoring levels for each account. #### [Registration Documents](./registration-documents) Standardized templates for registering custodial accounts, tracking access changes, documenting security configurations, and performing quarterly reviews. #### [Enhanced Controls](./enhanced-controls) Additional security measures for high-risk and critical accounts, including MPC recommendations, zero-trust architecture, and advanced monitoring. #### [Transaction Verification](./transaction-verification) Step-by-step protocols for receiving and sending large cryptocurrency transfers, including address verification, test transactions, and multi-party confirmation requirements. ### Getting Started 1. **Classify your accounts** using the [Classification Framework](./classification) to determine risk levels 2. **Register each account** using the [Registration Documents](./registration-documents) templates 3. **Implement controls** based on classification, with [Enhanced Controls](./enhanced-controls) for high-risk accounts 4. **Follow verification protocols** from [Transaction Verification](./transaction-verification) for all large transfers *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, } from "../../../components"; ## Registration Documents Use these standardized templates to register custodial accounts, track access changes, document security configurations, and perform quarterly reviews. > See also: [Classification Framework](./classification) and [Enhanced Controls for High-Risk Accounts](./enhanced-controls) *** ### Registration Template Use this template when initially documenting a custodial account. ``` CUSTODIAL ACCOUNT REGISTRATION Account Name: [Descriptive name] Custodian: [Provider name and legal entity] Account ID: [Custodian reference number] Network(s): [Bitcoin, Ethereum, etc.] Registration Date: YYYY-MM-DD Registered By: [Name] CLASSIFICATION Impact Level: [Low / Medium / High / Critical] Operational Type: [Cold Vault / Warm Storage / Active Operations / Time-Critical] Justification: - Financial exposure: $XXX,XXX,XXX - Operational dependency: [Description] - Recovery time objective: [X hours/days] ASSETS CONTROLLED Asset | Network | Value | Purpose --------|----------|-----------|------------------------------ BTC | Bitcoin | $XXX,XXX | [Reserve/Trading/Operations] ETH | Ethereum | $XXX,XXX | [Reserve/Trading/Operations] USDC | Ethereum | $XXX,XXX | [Reserve/Trading/Operations] CUSTODY MODEL Type: [Qualified Custodian / Co-managed / MPC Platform] Key Management: [MPC 3-of-5 / Multi-sig 2-of-3 / HSM] Key Control: [Custodian only / Co-managed / Client-controlled] Recovery Capability: [Yes - describe / No] INITIAL ACCESS SETUP Primary Administrator: [Name, added YYYY-MM-DD] Initial Approvers: [Names, added YYYY-MM-DD] Note: Complete access details documented in Access Change Template Note: Security configuration documented in Security Configuration Template ATTESTATION This account [meets / deviates from] security standards for its classification. [If deviation: Explain gap and compensating controls] CONTACTS Security Owner: [Name, email, phone] Backup Contact: [Name, email, phone] Custodian Support: [Name, email, phone] Last Updated: YYYY-MM-DD Updated By: [Name] ``` *** ### Access Change Template Use this template when modifying user access to a custodial account. ``` CUSTODIAL ACCOUNT ACCESS CHANGE Account Name: [Name] Custodian: [Provider] Account ID: [Reference] Change Date: YYYY-MM-DD Changed By: [Name] ACCESS MODIFICATIONS Additions: Name/Role | Access Level | MFA Method | Justification ----------|--------------|----------------|------------------------------ [Name] | [Approver] | [Hardware key] | [Reason for addition] Removals: Name/Role | Access Level | Removal Reason ----------|--------------|------------------------------- [Name] | [Approver] | [Personnel change / Security / Other] Permission Changes: Name/Role | Old Level | New Level | Justification ----------|-----------|-----------|--------------------------- [Name] | [Initiator] | [Approver] | [Reason for elevation] CURRENT ACCESS LIST (after changes) Name/Role | Level | MFA Method | Device ID ----------|-----------|---------------|--------- [Name] | Admin | Hardware key | [ID] [Name] | Approver | Hardware key | [ID] [Name] | Approver | Hardware key | [ID] [Name] | Initiator | TOTP | [ID] VERIFICATION [ ] All removed users confirmed deactivated in custodian platform [ ] All new users completed MFA setup [ ] Access permissions tested and verified [ ] Emergency contacts updated [ ] Documentation updated in [location] APPROVALS Requested By: _________________ Date: _______ Approved By: _________________ Date: _______ Security Review: _________________ Date: _______ Change Ticket: [Reference number if applicable] ``` *** ### Security Configuration Template Use this template to document detailed security settings. Complete this after initial account registration. ``` CUSTODIAL ACCOUNT SECURITY CONFIGURATION Account: [Name] Custodian: [Provider] Last Configuration Update: YYYY-MM-DD Configured By: [Name] AUTHENTICATION SETTINGS Multi-Factor Authentication: Role | Primary Method | Backup Method | Enrollment Status Administrator | Hardware key + biometric | Hardware key + PIN | [Active] Approver | Hardware key | TOTP + SMS | [Active] Initiator | Hardware key or TOTP | SMS | [Active] Viewer | TOTP | SMS | [Active] Session Controls: - Timeout: [X minutes] - Re-auth required for: [High-value transactions, policy changes, user management] - Concurrent sessions: [Allowed/Blocked] ACCESS CONTROL Current User List: Name/Role | Level | MFA Method | Device ID | Added Date ----------|----------|--------------|----------|------------ [Name] | Admin | Hardware key | [ID] | YYYY-MM-DD [Name] | Approver | Hardware key | [ID] | YYYY-MM-DD [Name] | Approver | Hardware key | [ID] | YYYY-MM-DD Note: Track all access changes using Access Change Template Approval Thresholds: Transaction Value (% of Total Assets) | Required Approvers | Time Delay | Additional Requirements <0.1% | 1 | None | MFA 0.1% - 1% | 3 | 4 hours | MFA 1% - 10% | 4 | 24 hours | Multi-channel confirmation, test transaction 10% - 25% | 5 | 24 hours | Multi-channel confirmation, test transaction >25% | 7 | 48 hours | Multi-channel confirmation, test transaction Separation of Duties: [ ] Initiators cannot approve own transactions [ ] Admins cannot unilaterally execute withdrawals [ ] Minimum [X] unique approvers required NETWORK RESTRICTIONS IP Whitelist: XXX.XXX.XXX.XXX - [Office Location] XXX.XXX.XXX.XXX - [VPN Range] XXX.XXX.XXX.XXX - [Backup Location] Change Approval: [24 hour delay / XX approvers required] Emergency Override: [Process description] VPN Requirement: [Mandatory / Optional] Geographic Restrictions: [Blocked countries/regions] Device Fingerprinting: [Enabled / Disabled] TRANSACTION POLICIES Address Whitelisting: Status: [Enabled / Disabled] Current Addresses: [XX addresses] Addition Process: [XX approvers, YY hour delay] Review Schedule: [Monthly / Quarterly] Transaction Limits: Limit Type | Amount | Override Process ------------------|----------|----------------- Single Transaction | $XXX,XXX | [Authorization required] Hourly Aggregate | $XXX,XXX | [Authorization required] Daily Aggregate | $XXX,XXX | [Authorization required] Weekly Aggregate | $XXX,XXX | [Authorization required] Monthly Aggregate | $XXX,XXX | [Authorization required] Time-Lock Settings: Change Type | Delay Period -------------------------------------|------------- New address addition | XX hours Policy modification | XX hours High-value transaction (>$XXX,XXX) | XX hours MONITORING & ALERTS Real-Time Alerts: Type | Enabled ---------------------------|-------- All outgoing transactions | [ ] New device login | [ ] Failed authentication attempts (>X) | [ ] Policy violations | [ ] Large transactions (>$XXX,XXX) | [ ] Unusual access times | [ ] New geographic location | [ ] Alert Routing: Severity | Contact | Method | Response Time ---------|------------------|-------------|-------------- Critical | [Name, phone] | SMS + Call | <15 min High | [Name, phone] | SMS + Email | <1 hour Medium | [Name, email] | Email | <4 hours VERIFICATION [ ] All settings tested and operational [ ] Alert routing verified [ ] User access confirmed [ ] Documentation stored in [location] Configured By: _________________ Date: _______ Reviewed By: _________________ Date: _______ Approved By: _________________ Date: _______ ``` *** ### Quarterly Review Template Use this template for regular security reviews of custodial accounts. ``` CUSTODIAL ACCOUNT QUARTERLY REVIEW Account: [Name] Custodian: [Provider] Review Period: [Q1/Q2/Q3/Q4 YYYY] Review Date: YYYY-MM-DD Reviewed By: [Name] ACCESS AUDIT Current Users: Name/Role | Level | Last Login | MFA Status | Action Required [Name] | Admin | YYYY-MM-DD | Active | None [Name] | Approver | YYYY-MM-DD | Active | None [Name] | Approver | Never logged in | Inactive | Remove access Access Changes This Quarter: [X additions, Y removals, Z modifications] Findings: [ ] All users still require current access level [ ] No dormant accounts (>90 days inactive) [ ] MFA functioning for all users [ ] No unauthorized access detected Actions Required: - [List any access to be removed/modified] - [List any policy updates needed] TRANSACTION REVIEW Transaction Volume: - Total transactions: [X] - Average per month: [Y] - Largest transaction: $XXX,XXX - Total outflow: $XXX,XXX Pattern Analysis: [ ] Transactions within expected parameters [ ] No unusual transaction patterns detected [ ] All large transactions properly authorized [ ] Test transactions performed correctly Anomalies Detected: - [List any unusual activity or violations] SECURITY CONFIGURATION Whitelist Review: - Current addresses: [X] - Addresses added this quarter: [Y] - Addresses to remove: [Z] - Review complete: [Yes/No] Spending Limits: Current | Actual Usage | Status Single: $XXX,XXX | Max: $XXX,XXX | [Appropriate / Adjust] Daily: $XXX,XXX | Avg: $XXX,XXX | [Appropriate / Adjust] Monthly: $XXX,XXX | Avg: $XXX,XXX | [Appropriate / Adjust] Findings: [ ] Limits appropriate for current usage [ ] No limit breaches this quarter [ ] IP whitelist current and accurate [ ] Time-locks functioning properly ALERT EFFECTIVENESS Alerts This Quarter: Type | Count | False Positive Rate Critical | [X] | [Y%] High | [X] | [Y%] Medium | [X] | [Y%] Response Times: Severity | Target | Actual Average | Status Critical | <15 min | [X min] | [Met/Missed] High | <1 hour | [X min] | [Met/Missed] Medium | <4 hours | [X hours] | [Met/Missed] Findings: [ ] Alert routing working correctly [ ] Response times meeting SLAs [ ] No missed critical alerts Actions Required: - [Adjust alert thresholds if needed] - [Update contact information] CUSTODIAN RELATIONSHIP SOC Reports: [Current / Expired - date] Security Incidents: [Any custodian-wide incidents this quarter] Service Quality: [Any issues or concerns] Communication: [Regular contact maintained] RISK ASSESSMENT UPDATE Classification Review: Current: [Impact Level / Operational Type] Still Appropriate: [Yes / No] If No, Recommended Change: New Classification: [Level / Type] Justification: [Explain change in risk profile] Asset Value Change: [% increase/decrease] Operational Change: [Any significant changes in usage] RECOMMENDATIONS Security Improvements: 1. [Recommendation] 2. [Recommendation] 3. [Recommendation] Operational Improvements: 1. [Recommendation] 2. [Recommendation] ATTESTATION This account [continues to meet / deviates from] security standards. [If deviation: Describe and provide remediation plan] APPROVALS Reviewer: _________________ Date: _______ Security Officer: _________________ Date: _______ Treasury Lead: _________________ Date: _______ Next Review Due: YYYY-MM-DD ``` *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, } from "../../../components"; ## Guide: Large Cryptocurrency Transfers ### Core Principles Large cryptocurrency transfers require rigorous verification because transactions are irreversible. This guide covers both receiving and sending significant amounts, with security measures scaling to transfer size. ### Part 1: Receiving Large Transfers #### Pre-Transfer Setup (48 Hours Before) ##### Choose Appropriate Deposit Address The address strategy depends on your custody model: **For Institutional Custody** (Coinbase, Anchorage, BitGo): * **Always generate a fresh deposit address** for large incoming transfers * **Verify you're on the correct website** - check URL carefully, bookmark the official site, watch for phishing lookalikes * Use the platform's "offline deposit address" or "new address" function * **Why fresh addresses?** Prevents counterparties from viewing your entire treasury balance/history and isolates each major transfer for clean audit trails **For Self-Custody Multisigs**: * **Use your established, proven multisig address** that has been successfully tested in prior transactions * **Never generate a fresh multisig for large transfers** - multisig setup is complex and a new deployment risks misconfiguration * The battle-tested multisig you've been using is safer than a newly created one * Document the multisig configuration: threshold (e.g., 3-of-5), signer addresses, and deployment transaction * Verify multisig configuration on block explorer before providing address to sender ##### Address Verification Protocol Have 2-3 team members independently verify the address: ``` 1. Retrieve address from custody platform or multisig interface 2. Person A: Verify via custody UI or block explorer (multisig configuration) 3. Person B: Independently verify via separate block explorer or multisig interface 4. Perform checksum validation: - Ethereum: EIP-55 checksum - Bitcoin: Bech32 checksum 5. For multisigs: Verify threshold and signer configuration match expected setup ``` **For transfers >$1M**: Require all verifiers to sign a document confirming they verified the address character-by-character. ##### Bidirectional Test Transaction This should occur **24-48 hours before the main transfer**. \*\*Phase 1: Sender → You (Incoming Test): \*\* ``` 1. Sender sends small amount (0.001 ETH or 0.0001 BTC) to your new address 2. Verify receipt through multiple sources: - Custody platform interface - Primary block explorer (Etherscan, Blockchain.com) - Secondary block explorer (redundancy check) 3. Document transaction hash and confirmation time ``` \*\*Phase 2: You → Sender (Outgoing Test): \*\* ``` 4. Send test amount BACK to another address you control 5. You confirm you received the return transaction ``` **Why bidirectional?** Proves address can both receive AND withdraw funds before large transfer arrives, and confirms both parties control their stated addresses. ##### Coordinate with Sender Provide via encrypted channel (PGP email or Signal): * Deposit address * Network specification (Ethereum mainnet chain ID 1, Bitcoin mainnet) * Test transaction hash (incoming only) * Video call scheduled time for live transfer Request from sender: * Source wallet addresses they'll send from * Approximate transfer timing: specific date and time window * Example: "Tuesday, March 15th, 2:00-6:00 PM EST" * This allows you to have all required personnel available and monitoring * Whether they'll use single or multiple transactions **Best practices for transaction splitting:** * **\<$10M**: Single transaction preferred (simpler, one confirmation cycle, cleaner records) * **>$10M**: Consider 2-3 separate transactions (reduces single-transaction risk, allows staged confirmation, provides pause points to verify each step) * **>$50M**: Multiple transactions strongly recommended with 30-minute intervals between each **Anti-Duress Protocols:** Since kidnapping and other forms of duress have been employed by criminals to steal cryptocurrency, organizations should prepare for this. Establish a duress word that indicates a transfer is not being made of your own free will. Once the duress word is mentioned during an exchange involving the transfer, law enforcement will be contacted and the transaction will not be processed. Procedures should be put in place with concrete runbooks for these situations. Safe words should not appear in runbooks or any digital format. **Anti-Social-Engineering Protocols:** Establish a code phrase during the initial verified meeting. Use this phrase to authenticate any address changes or unusual requests. Example: "What was the name of the restaurant where we finalized the agreement?" Exchange secondary contact numbers for key personnel - if primary contact requests changes, call secondary to confirm. Maintain out-of-band verification: if request comes via email, confirm via phone. **Red flags that should trigger immediate verification:** * Urgent requests to bypass procedures or claims of "emergency" * Requests to send to "temporary" or "new" address without proper verification * Pressure to skip test transactions or any rushed requests If anything feels wrong, STOP and verify through multiple channels. Urgency is an attacker's favorite tool - legitimate counterparties will understand security delays. #### Day of Transfer ##### Pre-Transfer Video Verification (30 minutes prior to transfer) Require a video call with a minimum of 2 *internal* people present. **Liveness and identity verification** (prevents AI deepfakes): ``` 1. Ask participant to hold up specific number of fingers (change unpredictably) 2. Ask them to wave their hand in front of their face 3. Request they state current date and time 4. Reference specific details from previous conversations only real participant would know 5. If anything seems off, halt the transfer and investigate ``` **Critical confirmations during call:** 1. **Address Reconfirmation** * Read deposit address character-by-character from your screen * Sender confirms they see identical address on their screen * **Critical: "Read ONLY from your custody platform or multisig interface (Safe, Zodiac, etc.)"** * **Do NOT copy from email, Etherscan, any block explorer, or any intermediary source** * **Only trust the address shown directly in your custody interface or multisig platform** * For multisigs: State the configuration (e.g., "3-of-5 multisig at address 0x...") * This prevents compromised email, address poisoning, and man-in-the-middle attacks from causing misdirection 2. **Test Transaction Review** * Display test transaction on block explorer during call * Confirm sender sees same transaction hash * Review the bidirectional test from 24-48 hours ago 3. **Amount and Network** * State total amount in native units and USD equivalent * Confirm network explicitly: "Ethereum mainnet, chain ID 1" (not testnet, not L2) * If ERC-20 tokens: State token name AND read out full contract address * Example: "Sending 100,000 USDC, contract address 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" * Verify contract address against official source (token website, CoinGecko) on call * Confirm no mistakes in decimal places or token contract ##### Live Monitoring **Understanding Blockchain Finality:** Wait for enough confirmations that a chain reorganization becomes economically infeasible or cryptographically impossible. **Monitoring phases:** ``` 1. Transaction Broadcast: Appears in mempool, verify correct parameters 2. First Confirmation: Included in a block 3. Progressive Confirmations: Each block makes reversal exponentially harder 4. Finality: Sufficient confirmations reached, transaction irreversible ``` **Confirmation requirements by chain:** * **Ethereum**: 2 epochs (\~12.8 minutes) * **Bitcoin**: 6 confirmations (\~60 minutes) * **Polygon**: 128 confirmations (\~5 minutes) * **Solana**: \~12.8 seconds **On-call updates from Technical Operator:** * "Transaction in mempool, parameters correct" * "Block 1 confirmed, no anomalies" * "Block 12 confirmed, \[X.XXX] ETH received and final" ##### Dual Confirmation Requirement Before ending call, verify through TWO sources: 1. Custody platform showing updated balance 2. Block explorer showing confirmed transaction ##### Post-Receipt Actions **Immediate (within 15 min):** * Document transaction hash, block number, timestamp * Record amount in native units and USD equivalent * Note all personnel involved **Within 30 minutes:** * Email confirmation to sender with transaction details ### Part 2: Sending Large Cryptocurrency Transfers #### Pre-Transfer Planning (72 Hours Before) ##### Authorization Document and obtain approvals: * Purpose of transfer * Recipient verification * Amount and timeline * Required signatures based on amount: * \<$100K: Treasury Manager * $100K-$1M: CFO + Security Officer * \>$1M: CFO + CEO ##### Recipient Address Verification Multi-source verification is critical: ``` STEP 1: Receive address through official channel ├─> Request via verified email/signed contract STEP 2: Independent verification through multiple sources (e.g., email, phone call) ├─> At least two team members independently confirm the recipient address using different communication channels (such as verified email and a direct phone call with the recipient) STEP 3: Mandatory test transaction ├─> Send $10-100 equivalent first ├─> Wait for recipient confirmation ├─> Recipient provides test transaction hash ├─> Verify hash matches your outbound transaction └─> Proves recipient controls address and communications secure ``` **Never skip the test transaction.** ##### Whitelist Addition (If Using Custody Platform) Most custody platforms support whitelisting: ``` 1. Submit whitelist request with justification 2. Wait mandatory cooling-off period: - Standard: 24-48 hours - High security: 72 hours 3. Different team member approves whitelist addition 4. Test transaction AFTER whitelist approval ``` **Why cooling-off periods?** Prevents attackers who gain account access from immediately adding malicious addresses and draining funds. Gives time for legitimate personnel to notice unauthorized changes. #### Day of Transfer ##### Final Verification Checklist (15 min before) Minimum 2 *internal* people present, verify: ``` □ Authorization documentation signed □ Recipient address verified by 2 independent sources □ Test transaction confirmed successful by recipient □ Whitelist cooling-off period complete (if applicable) □ Exact amount confirmed (recipient expects this amount) □ Network confirmed (mainnet, not testnet) □ Sufficient balance in source wallet (amount + fees + buffer) □ All required approvers available next 60 minutes ``` **For transfers >$1M**: Conduct formal video call with all approvers present. ##### Execution Protocol **Video Call Requirements**: ``` 1. Screen share custody interface or wallet 2. Primary operator reads transaction parameters aloud: - "Sending [X.XXXXX] ETH" - "To address: 0x[read full address character-by-character]" - "On network: Ethereum mainnet, chain ID 1" 3. Each approver independently verifies on their device: - Destination matches authorized recipient - Amount matches approved transfer - Network is correct 4. Approvers use MFA to approve: - Hardware security key, biometric, or authenticator app - For multisigs: Each signer verifies transaction details on their signing device - Verbally confirm: "I approve this transaction" 5. Final approval triggers broadcast to blockchain ``` ##### Post-Submission Monitoring Monitor transaction through finality: ``` 1. Copy transaction hash from custody platform 2. Enter into block explorer immediately 3. Verify parameters match intended transaction 4. Monitor confirmation progress: - Ethereum: Wait for 12 confirmations (~3 minutes) - Bitcoin: Wait for 6 confirmations (~60 minutes) 5. Watch for recipient confirmation of receipt ``` ##### Confirmation and Documentation After transaction reaches finality: ``` 1. Internal record (within 15 min): - Transaction hash and block number - Timestamp and confirmation count - Source wallet balance updated in records 2. Request receipt from recipient (within 30 min): - Formal acknowledgment they received funds 3. Permanent documentation: - Full transaction details (hash, block, timestamp, amount) - Authorization chain (who approved, when) - Personnel involved ``` *** ### Multi-Signature Best Practices See the Multisigs for Protocols guide. ## TODO: Add link to Multisigs for Protocols guide. AFTER IT IS MERGED ### Critical Risk Mitigations #### Address Verification **Multisig and custody interface verification:** * Always verify addresses directly from your custody platform or multisig interface (Safe, Zodiac, etc.) * For multisigs: Cross-check configuration (threshold, signers) on block explorer * Never trust copy-pasted addresses from email or chat * Verify entire address character-by-character **Address poisoning defense:** * Never copy from transaction history * Always copy from authoritative source * Use custody platform address books when available #### Communication Security **Email compromise prevention:** * Address confirmation during video call prevents MITM * Live verbal verification catches discrepancies * Code phrases for authentication **Social engineering defense:** * Never accept urgent bypass requests * Callback on known numbers to verify * Any request to skip verification triggers security review #### Multi-Party Controls **Prevents single-actor fraud:** * Multiple personnel * Video recording of approvals * Separation of duties: requester ≠ approver ≠ technical executor #### Transaction Parameter Security **Custody platform policy engines:** * Enforce withdrawal limits automatically * Block transactions to non-whitelisted addresses * Require elevated approvals above thresholds * Create circuit breakers if account compromised *** ### Key Principles Summary 1. **Test everything**: Small test transactions can catch human errors 2. **Verify independently**: Multiple people through different channels 3. **Never rush**: Urgency benefits attackers, not you 4. **Use multisig for self-custody**: Multiple signers prevent single points of failure 5. **Verify addresses live**: Always verify addresses during video calls from authoritative sources **In cryptocurrency, there are no chargebacks.** Every transaction is final. The procedures in this guide may seem extensive, but preventing a single mistake justifies significant operational overhead. The cost of verification is measured in minutes. The cost of a mistake is measured in millions. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Create and Maintain Threat Models Creating and maintaining threat models helps identify potential security risks and develop mitigation strategies to protect the project. ### Steps to Create a Threat Model 1. **Define the Scope** * Identify the contract, system, application, or component to be analyzed. * Determine the boundaries and interfaces of it. 2. **Identify Assets** * List all critical assets that need protection, such as funds, data, credentials, and infrastructure components. * Prioritize assets based on their importance and sensitivity. 3. **Identify Threats** * Use frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to identify potential threats. * Consider various attack vectors and threat actors that could target the system. 4. **Identify Vulnerabilities** * Analyze the system for potential vulnerabilities that could be exploited by threats. * Use vulnerability databases, past incident reports, and security assessments to identify common weaknesses. 5. **Create Attack Scenarios** * Develop detailed attack scenarios that describe how threats could exploit vulnerabilities to compromise assets. * Use diagrams and flowcharts to visualize the attack paths. 6. **Evaluate and Prioritize Risks** * Assess the likelihood and impact of each identified threat. * Prioritize risks based on their potential impact on the system and organization. 7. **Develop Mitigation Strategies** * Identify and implement controls to mitigate the identified risks. * Consider technical, administrative, and physical controls to reduce the risk. 8. **Document the Threat Model** * Create detailed documentation of the threat model, including all identified threats, vulnerabilities, attack scenarios, and mitigation strategies. * Use templates and standardized formats to ensure consistency. ### Maintaining Threat Models 1. **Regular Updates** * Update the threat model regularly to reflect changes in the system, new threats, and emerging vulnerabilities. * Schedule periodic reviews to ensure the model remains current. 2. **Continuous Monitoring** * Implement continuous monitoring to detect changes in the threat landscape and system environment. * Use automated tools to monitor for new vulnerabilities and threats. 3. **Collaboration** * Foster collaboration between development, security, and operations teams to keep the threat model up to date. * Encourage feedback and contributions from all stakeholders. 4. **Training and Awareness** * Provide training for team members on threat modeling concepts and techniques. * Raise awareness about the importance of threat modeling in maintaining security. ### Tools for Threat Modeling 1. **Microsoft Threat Modeling Tool** * A free tool that helps create threat models using the STRIDE framework. * Pros: Easy to use, integrates with Microsoft technologies. * Cons: Limited to Windows platforms. 2. **OWASP Threat Dragon** * An open-source threat modeling tool for creating diagrams and identifying threats. * Pros: Free, web-based, supports multiple platforms. * Cons: Limited features compared to commercial tools. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Identify and Mitigate Threats Identifying and mitigating threats is a crucial part of the threat modeling process. By understanding potential threats and developing strategies to address them, projects can help protect their systems and data from security incidents. ### Identifying Threats 1. **Threat Enumeration** * Use frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to systematically identify potential threats. * Consider various threat actors, including insiders, external attackers, and automated threats. 2. **Attack Surface Analysis** * Analyze the attack surface to identify all potential entry points for attackers. * Include smart contracts, wallets, external interfaces, APIs, third-party integrations, and user inputs in the analysis. 3. **Adversary Modeling** * Develop profiles of potential adversaries, including their capabilities, goals, and motivations. * Consider different threat actors, such as black hats and nation-state actors. 4. **Historical Data** * Review past security incidents and vulnerabilities to identify common attack patterns and weaknesses. * Use vulnerability databases and threat intelligence feeds to stay informed about emerging threats. ### Mitigating Threats 1. **Security Controls** * Implement security controls to mitigate identified threats. These can include technical controls, administrative controls (e.g., policies, procedures), and physical controls. 2. **Defense in Depth** * Apply the principle of defense in depth by implementing multiple layers of security controls. * Ensure that if one control fails, additional controls are in place to provide protection. 3. **Least Privilege** * Follow the principle of least privilege by granting users and systems the minimum level of access necessary to perform their functions. * Regularly review and adjust access permissions to reduce the risk of privilege escalation. 4. **Security by Design** * Incorporate security into the design and development processes from the outset. * Use secure coding practices, perform regular code reviews, and conduct security testing throughout the development lifecycle. 5. **Monitoring and Detection** * Implement continuous monitoring to detect and respond to security incidents in real time. 6. **Incident Response** * Develop and maintain an [incident response plan](/incident-management/overview) to quickly and effectively address security incidents. * Train team members on incident response procedures and conduct regular drills to ensure readiness. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Threat Modeling > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Threat Modeling](/threat-modeling/overview) * [Creating Threat Models](/threat-modeling/create-maintain-threat-models) * [Identify & Mitigate Threats](/threat-modeling/identity-mitigate-threats) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Threat Modeling Threat modeling is a structured approach to identifying and mitigating security threats to a system. It involves understanding potential threats, vulnerabilities, and attack vectors, and developing strategies to mitigate them. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Dependency Awareness > 🔑 **Key Takeaway:** Every dependency is code you did not write but are fully responsible for. Know exactly what is > in your tree, pin versions for anything security-critical, enforce your lockfile in CI, and treat every update as a > change that requires review. ### Fundamentals #### What Is a Dependency? A dependency is any external code your project relies on to build or run. When you add a library to your project, you are making a trust decision: you are choosing to run someone else's code as if it were your own, with all the access and privileges that implies. A modern Web3 project easily accumulates hundreds of dependencies. Most are never reviewed, many are maintained by a single developer, and some are actively targeted by attackers. A compromised package propagates to every project that depends on it, without any action required from the project owners. For details on specific attacks and how they exploited weak dependency practices, see [Supply Chain Threats](/supply-chain/web3-supply-chain-threats). #### Direct and Transitive Dependencies * **Direct dependencies** are the packages you explicitly add to your project (listed in your `package.json`, `Cargo.toml`, `go.mod`, `requirements.txt`, etc.). * **Transitive dependencies** are the dependencies of your dependencies, packages you never chose that get pulled in automatically. In most projects, transitive dependencies vastly outnumber direct ones. A single install command can bring in hundreds of packages you have never seen. This matters because: 1. **Vulnerabilities propagate silently.** A vulnerability buried deep in your dependency chain still affects your application. 2. **Attackers target transitive dependencies** precisely because they receive less scrutiny. Compromising a small, deeply nested utility package can affect thousands of downstream projects. 3. **You are responsible for all of them.** Your users do not care whether a vulnerability was in code you wrote or in a package five levels down your dependency tree. #### How Ecosystems Handle Dependency Locking When you declare a dependency like `"my-library": "^1.2.0"`, you are expressing a *range* of acceptable versions, not a single one. Without any locking mechanism, every time you or your CI pipeline runs an install command, the package manager resolves that range against whatever is currently published and may pick a different version. This means the same project can produce different builds on different machines or at different times and if an attacker publishes a malicious version within your accepted range, it gets pulled in silently. **Dependency locking** solves this by recording the exact versions (and often cryptographic checksums) that were resolved at a specific point in time. Once locked, every subsequent install reproduces that exact set of dependencies rather than re-resolving from scratch. This gives you: * **Reproducibility:** Every developer and every CI run gets the same dependency tree. * **Auditability:** Changes to dependencies show up as diffs in version control, making them reviewable. * **Protection against silent substitution:** A newly published malicious version cannot enter your project until someone explicitly updates the lock and that change is reviewed. Not every language or package manager implements locking the same way. Some use lockfiles, some use checksums or vendoring, and some barely address the problem at all. Understanding how your ecosystem works is the first step to securing it. | Ecosystem | Lockfile / Mechanism | What to Know | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Node.js (npm/pnpm/yarn)** | Three package managers, each with its own lockfile: `package-lock.json` (npm), `pnpm-lock.yaml` (pnpm), `yarn.lock` (yarn v1 and Berry). They are not interchangeable. | Switching package managers means regenerating the lockfile. Pick one and enforce it across the team. See [Lockfile Integrity](#lockfile-integrity) section below for how each one works. | | **Rust (Cargo)** | `Cargo.lock` records exact versions and checksums for every dependency. Cargo verifies these checksums automatically against `crates.io` on every build. | For libraries, `Cargo.lock` is often `.gitignore`d because downstream consumers resolve their own versions. For binaries and applications, always commit it. | | **Go** | No traditional lockfile. `go.sum` stores cryptographic checksums for every dependency, and the public checksum database (`sum.golang.org`) lets you verify that everyone gets the same code for a given version. The module proxy caches modules so they remain available even if the original source disappears. | Go's approach is verification-first rather than lock-first. `go.mod` declares minimum versions, `go.sum` verifies integrity, and `go mod tidy` is the primary way updates enter the dependency tree. | | **Python (pip/Poetry/PDM)** | pip has no built-in lockfile. You either generate a pinned `requirements.txt` with tools like `pip-compile`, or use Poetry (`poetry.lock`) or PDM (`pdm.lock`), which manage their own lockfile formats. | There is no single standard. Multiple competing tools solve this problem differently, and none of them are part of pip itself. Pick one approach for your project and enforce it across the team. | | **Java (Maven/Gradle)** | Maven has no lockfile at all and re-resolves versions on every build. Gradle supports lockfiles (`gradle.lockfile`) but requires you to opt in explicitly. Both rely on artifact checksums from the repository for integrity. | The lack of a default lockfile in Maven means two builds of the same project can pull different versions. If you use Maven, consider the [`maven-enforcer-plugin`](https://maven.apache.org/enforcer/maven-enforcer-plugin/) to enforce reproducibility. | | **Ruby (Bundler)** | `Gemfile.lock` records exact versions for every gem in the dependency tree. One of the earliest and most mature lockfile implementations across any ecosystem. | Commit it, and use `bundle install --frozen` in CI. | | **PHP (Composer)** | `composer.lock` records exact versions for every package. Works the same way as Bundler. | Commit the lockfile, use `composer install --no-update` in CI. | | **Solidity (Foundry/Hardhat)** | Foundry pins dependencies to specific git commits via submodules. Each submodule points at an exact SHA, so the version is locked by git itself.
Hardhat uses npm and produces a standard `package-lock.json`. | Mixing both in the same project means managing two entirely different dependency systems. Review submodule updates with the same care as lockfile changes. | The core principle is the same regardless of ecosystem: **you need a reproducible, verifiable record of exactly what code gets pulled into your project**. If your ecosystem provides a lockfile, commit it and enforce it. If it does not, look for checksum verification, vendoring, or commit-pinning as alternatives. ### Lockfile Integrity #### Node.js (npm / pnpm / yarn) The Node.js ecosystem is the most common in Web3 development: frontends, tooling (Hardhat, Foundry's companion scripts), and most Web3 libraries (ethers.js, viem, wagmi) all live here. It is also one of the most targeted ecosystems for supply chain attacks due to its massive registry, deep dependency trees, and install-time script execution. Each package manager handles installation differently: * **npm** installs into a flat `node_modules` where all packages can see each other, regardless of which package declared them as a dependency. * **pnpm** uses a content-addressable store with symlinks, so packages can only access their declared dependencies. This stricter isolation catches undeclared dependency usage that would silently work under npm. * **yarn v1** uses a flat layout like npm. **yarn Berry (v2+)** removes `node_modules` entirely in favor of Plug'n'Play, which maps dependencies directly without a `node_modules` folder. The lockfile (`pnpm-lock.yaml`, `yarn.lock`, or `package-lock.json`) is what actually determines which versions get installed. Without it, the same `package.json` can produce different dependency trees on different machines and at different times. An attacker could publish a malicious patch version, and any install without a lockfile would silently pick it up. 1. **Always commit your lockfile** to version control. 2. **Use frozen installs in CI.** This ensures CI installs exactly what is in the lockfile, failing if there is any discrepancy: ```bash pnpm install # pnpm uses --frozen-lockfile by default in CI npm ci # npm equivalent of frozen installs yarn install --frozen-lockfile # yarn v1 yarn install --immutable # yarn Berry (v2+) ``` > **Note:** pnpm automatically sets `--frozen-lockfile` to `true` when it detects a CI environment, so you do not > need to pass the flag explicitly. npm and yarn require the explicit flag or command. yarn Berry replaced > `--frozen-lockfile` with `--immutable`. 3. **Review lockfile changes in PRs.** Treat lockfile modifications with the same scrutiny as source code changes. 4. **Watch for lockfile-only PRs.** A PR that modifies only the lockfile without a corresponding change to `package.json` is a meaningful signal worth investigating. #### Cross-Ecosystem Reference The same principles apply beyond Node.js, though the specific commands and mechanisms differ: * **Rust:** Commit `Cargo.lock` for all binary and application projects. Cargo verifies checksums automatically, but review `Cargo.lock` diffs in PRs the same way you would a Node.js lockfile. * **Go:** Commit `go.sum` and run `go mod verify` in CI to confirm that downloaded modules match their recorded checksums. Go's checksum database adds a layer of tamper detection that most ecosystems lack. * **Python:** If using Poetry or PDM, commit the lockfile and use `poetry install --no-update` or `pdm install --frozen-lockfile` in CI. If using pip, generate a fully pinned `requirements.txt` (via `pip-compile` or `pip freeze`) and install with `pip install --require-hashes -r requirements.txt` for checksum verification. * **Solidity (Foundry):** Since Foundry uses git submodules, pin dependencies to specific commit SHAs rather than branch names. Review submodule updates as carefully as you would lockfile changes. A submodule pointing at `main` is the equivalent of using `"latest"` in npm. #### Install Scripts npm packages can define lifecycle scripts (`preinstall`, `postinstall`, `prepare`) that run automatically during installation. These scripts execute with the same permissions as the user running the install, which means a malicious package can run arbitrary code on your machine or CI server the moment you install it, before you ever import or use it. This is the primary execution mechanism behind most npm supply chain attacks, including [event-stream](https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident) and [ua-parser-js](/supply-chain/web3-supply-chain-threats#npm-package-compromise). 1. **Audit install scripts before adding new dependencies.** Before installing a package, download it without executing anything (`npm pack `, `pnpm pack `, or `yarn pack `) and inspect its `package.json` for `preinstall`, `postinstall`, or `prepare` entries. 2. **In high-assurance environments** or hardened CI pipelines, disable lifecycle scripts by default and explicitly allow only reviewed packages that require them. All three package managers support disabling lifecycle scripts. Set this in your `.npmrc` (read by both npm and pnpm) or `.yarnrc.yml` (yarn Berry): ```bash # .npmrc (npm and pnpm) ignore-scripts=true ``` ```yaml # .yarnrc.yml (yarn Berry) enableScripts: false ``` 3. **Allowlist packages that need scripts.** Some legitimate packages (native modules like `bcrypt`, build tools like `esbuild`) require install scripts to work. Rather than leaving all scripts enabled, keep them disabled globally and explicitly permit only the packages you have reviewed. pnpm supports this through `onlyBuiltDependencies` in `package.json`: ```json { "pnpm": { "onlyBuiltDependencies": ["bcrypt", "esbuild"] } } ``` 4. **Never run the install command with elevated privileges.** If a script requires `sudo`, that is a red flag. ### Version Pinning How you declare a dependency version determines how much control you have over what gets installed. The syntax varies by ecosystem, but the concept is universal: the more flexibility you allow, the more trust you place in upstream maintainers. #### Node.js (npm / pnpm / yarn) | Strategy | Example | Risk Level | When to Use | | ----------------- | ------------------- | ---------- | --------------------------------------------------------------------- | | **Exact version** | `"1.2.3"` | Lowest | Security-critical packages, wallet libraries, production dependencies | | **Patch range** | `"~1.2.3"` | Low | General dependencies where you trust patch releases | | **Minor range** | `"^1.2.3"` | Medium | Development dependencies, internal tools | | **Any version** | `"*"` or `"latest"` | Highest | Never use this in production | For any package that runs in a user's browser, interacts with a wallet, or handles signing, use exact versions and review every update as a deliberate decision. For development dependencies that do not reach production, patch or minor ranges are a reasonable tradeoff between security and maintenance overhead. `"*"` and `"latest"` have no place in a production dependency manifest. > **Important:** Even with exact versions in your direct dependencies, transitive dependencies still resolve through > semver ranges declared by the packages you depend on. This is why lockfile integrity matters: the lockfile is what > actually pins the full tree. #### Cross-Ecosystem Reference Each ecosystem has its own version range syntax and defaults. The principles are the same: pin tightly for anything security-critical, allow ranges only where the tradeoff is justified. | Ecosystem | How to Pin Exactly | How Flexible Ranges Work | | ------------------ | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Rust (Cargo)** | `=1.2.3` | By default, `1.2.3` allows compatible updates within the same major version. Use `=` for strict pinning. | | **Python (pip)** | `==1.2.3` | `~=1.2.3` allows patch updates only. Omitting a version specifier accepts anything, so always specify one. | | **Go** | Pinned via `go.sum` checksums | Go uses Minimum Version Selection (MVS): it always picks the *oldest* version that satisfies all requirements, not the newest. This is conservative by design but can delay security patches. | | **Java (Maven)** | `1.2.3` (exact by default) | Range syntax like `[1.2,1.3)` is available but rarely used. Avoid `LATEST` and `RELEASE` in production. | | **Ruby (Bundler)** | `= 1.2.3` | `~> 1.2` is the "pessimistic" operator. It allows patch updates within `1.2.x` but not `1.3.0`. | #### GitHub Actions SHA Pinning GitHub Actions are themselves a supply chain dependency. When you reference an action by tag (`uses: actions/checkout@v4`), the tag owner can move it to point at different code at any time. Pinning to a full commit SHA ensures that the action you run today is the same one you reviewed: ```yaml # Instead of this (mutable tag): - uses: actions/checkout@v4 # Use this (immutable commit SHA): - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1 ``` ### Trust and Verification Lockfiles and version pinning ensure you get the code you expect, but they do not help you decide whether to trust a package in the first place. Trust and verification are about evaluating packages *before* they enter your dependency tree, and ensuring that the packages you receive were published by who you think they were. #### Package Trust Signals Before adding a new dependency, evaluate it. No single signal is definitive, but taken together they form a reasonable picture of risk: * **Maintainer activity:** Is the package actively maintained? Are issues addressed? A package with no commits in two years and a pile of open issues may be abandoned, or it may be stable and complete. Context matters. * **Maintainer count:** A package maintained by a single developer is a single point of failure. If their account is compromised, so is every project depending on their packages. * **Download trends and community adoption:** Very low download counts for a supposedly popular package are a red flag. Compare against known-good alternatives. * **Scope and permissions:** Does the package do what it claims and nothing more? A date-formatting library that requests network access should raise questions. * **Dependencies of the dependency:** A minimal utility that itself pulls in 50 transitive dependencies introduces risk disproportionate to its value. * **Security posture:** Does the project have a security policy (`SECURITY.md`)? Do they use signed releases or provenance attestations? Do they assess known vulnerabilities quickly? #### OIDC and Trusted Publishers Traditional package publishing relies on long-lived API tokens stored in CI environments. If those tokens are leaked or the CI environment is compromised, an attacker can publish malicious versions of your package. OIDC-based Trusted Publishers eliminate this risk. **How it works:** Instead of storing a static npm (or PyPI) access token in your CI secrets, you configure the registry to trust your specific CI workflow. When the workflow runs, the CI provider (GitHub Actions, GitLab CI) and the registry negotiate a short-lived, cryptographically signed token that is scoped to that specific workflow, repository, and environment. The token cannot be extracted or reused. This approach was pioneered by [PyPI](https://docs.pypi.org/trusted-publishers/) and adopted by npm. If you maintain packages, this is one of the most impactful steps you can take: 1. **Configure Trusted Publishers** for your registry to eliminate long-lived tokens from CI. 2. **Use isolated CI workflows for publishing.** Separate build, verify, and publish into distinct jobs. Only the publish job should hold credentials, and those credentials should be short-lived OIDC tokens. 3. **Enable provenance attestation.** npm's `--provenance` flag generates a signed record of how and where a package was built and published, allowing consumers to verify the package's origin. 4. **Require 2FA for all publish actions.** Prefer WebAuthn/passkeys over TOTP where supported. Enable it for the entire scope or organization, not just individual accounts. > **For consumers:** When evaluating a package, check whether it publishes with provenance. On npmjs.com, packages with > provenance display a green checkmark linking to the specific CI workflow that built them. This is a strong trust > signal: it means the package was built from a known source repository through a verifiable pipeline. For an in-depth walkthrough of npm Trusted Publishers and secure publishing workflows, see [How to npm and Avoid Getting Rekt](https://blog.theredguild.org/how-to-npm-and-avoid-getting-rekt/) by [The Red Guild](https://theredguild.org/). #### Typosquatting Typosquatting attacks publish malicious packages with names deliberately close to popular ones, targeting developers who mistype a package name during installation. 1. **Double-check package names** before installing. Verify the exact spelling, publisher, and scope (`@org/package`). 2. **Check download counts and publish history.** Use `npm info ` to inspect locally or look it up on [npmjs.com](https://www.npmjs.com/). Red flags to look for are: very low download counts (for a supposedly popular package), a recent first publish date, no verified publisher, or a name that is one character off from a well-known package. 3. **Use scoped packages** when available. Scoped names (`@org/package`) are harder to typosquat than unscoped ones. 4. **Enable lockfile verification** in CI to prevent unexpected package name changes. 5. **Consider `minimumReleaseAge`** (pnpm) or equivalent policies. Delaying installations of newly published versions by a configurable period gives the community time to detect malicious releases before they reach your project. ### Vulnerability Scanning Most ecosystems provide built-in or community-standard tools for checking dependencies against known vulnerability databases. Run these in CI and fail builds on high or critical findings. | Ecosystem | Built-in / Standard Tool | Command | | ----------- | -------------------------- | ------------------------------- | | **Node.js** | `npm audit` / `pnpm audit` | `pnpm audit --audit-level=high` | | **Rust** | `cargo-audit` | `cargo audit` | | **Python** | `pip-audit` | `pip-audit -r requirements.txt` | | **Go** | `govulncheck` | `govulncheck ./...` | | **Ruby** | `bundler-audit` | `bundle audit check --update` | | **Java** | OWASP Dependency-Check | Gradle/Maven plugin | #### Cross-Ecosystem Tools * [Dependabot](https://github.com/dependabot) is a GitHub built-in tool that supports npm, pip, Cargo, Go modules, Maven, Bundler, Composer, and more. It monitors your dependencies for known vulnerabilities, opens security alerts on your repository, and when a fix is available, creates a PR to bump the affected dependency. It can also open PRs for general version updates on a schedule you configure. * [Snyk](https://snyk.io/) and [Grype](https://github.com/anchore/grype) go beyond single-ecosystem advisory databases, covering transitive dependencies and scanning against multiple vulnerability sources across many languages and package managers. * [OSV-Scanner](https://google.github.io/osv-scanner/) by Google queries the OSV (Open Source Vulnerabilities) database, which aggregates advisories from multiple ecosystems into a single, consistent format. > **Important:** None of these methods or tools make you more secure by themselves. They make you *aware* of > vulnerabilities and updates. The security value comes from reviewing those updates in depth, especially security > patches. ### Ecosystem-Specific Considerations #### Smart Contract Dependencies Smart contract dependencies carry unique risk because deployed code is immutable. Static analysis, testing strategies, and secure coding practices for Solidity are covered in depth in the [Security Testing](/security-testing/overview) and [Secure Software Development](/secure-software-development/overview) frameworks. For guidance on auditing contracts and their imported libraries, see [External Security Reviews for Smart Contracts](/external-security-reviews/smart-contracts/overview). ### Common Pitfalls 1. **Blindly merging dependency update PRs.** Always review what changed, especially across major versions. Check the changelog and release notes before merging. 2. **Using `*` or `latest` version ranges.** This hands control of your dependency tree to whoever publishes the next version. 3. **Ignoring transitive dependencies.** Your direct dependencies carry their own dependency trees, and a vulnerability three levels deep still affects your application. Vulnerability scanning tools surface these; running them in CI ensures the full tree is checked on every build. 4. **Installing from GitHub URLs instead of registries.** `"my-package": "github:user/repo"` bypasses registry integrity checks, removes version pinning, and pulls whatever is at the HEAD of a mutable branch at install time. Use published, versioned registry packages instead. 5. **Not reviewing changelogs before updating.** Major version bumps can introduce breaking changes or new dependencies. Review before updating. 6. **Publishing with long-lived tokens.** If you maintain packages, use OIDC Trusted Publishers when possible instead of static tokens stored in CI secrets. Where OIDC is not available, rotate tokens regularly and scope them to the minimum permissions needed. A leaked token means anyone can publish as you. 7. **Trusting packages without verification.** Download counts and GitHub stars are not security guarantees. Check provenance, maintainer history, and dependency footprint before adding a new package. ### Further Reading * [npm Security Best Practices](https://docs.npmjs.com/packages-and-modules/securing-your-code): Official npm security documentation * [How to npm and Avoid Getting Rekt](https://blog.theredguild.org/how-to-npm-and-avoid-getting-rekt/) by [The Red Guild](https://theredguild.org/): Covers npm Trusted Publishers, provenance, and secure publishing workflows * [PyPI Trusted Publishers](https://docs.pypi.org/trusted-publishers/): OIDC-based publishing for PyPI (the model npm adopted) * [Dependabot Documentation](https://docs.github.com/en/code-security/dependabot): GitHub's cross-ecosystem dependency update tooling * [OSV (Open Source Vulnerabilities)](https://osv.dev/): Aggregated vulnerability database spanning multiple ecosystems * [Snyk Vulnerability Database](https://security.snyk.io/): Searchable database of known vulnerabilities * [Cargo Security Advisories](https://rustsec.org/): Rust security advisory database and `cargo-audit` * [Go Vulnerability Database](https://vuln.go.dev/): Official Go vulnerability tracking and `govulncheck` * [Third-Party Script Security](/front-end-web-app/third-party-script-security): Runtime integrity controls (Content Security Policy, Subresource Integrity, self-hosting) that complement build-time dependency practices *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Supply Chain Incident Response > 🔑 **Key Takeaway:** Supply chain incidents move faster than direct compromises. You do not control the affected > code, the fix depends on an external maintainer, and the same attack may be hitting hundreds of other projects > simultaneously. Speed and a practiced response plan are what determine your outcome. When a dependency is compromised, the clock starts before you are aware of it. The Ledger Connect Kit attack in 2023 ran for several hours before widespread detection, long enough for significant user losses to occur. By the time most teams learned about it, the question was no longer whether they were affected but how many of their users had already interacted with the malicious version. Supply chain incidents have this character: they originate externally, propagate at ecosystem scale, and the window between compromise and discovery is often controlled by the attacker. For general incident response procedures, see the [Incident Management](/incident-management/overview) framework. This page focuses on the aspects unique to supply chain compromises. ### How Supply Chain Incidents Differ | Aspect | Direct Compromise | Supply Chain Compromise | | ---------------- | ---------------------------------- | --------------------------------------------------------------------------------- | | **Control** | You own the affected code | You depend on an external maintainer | | **Detection** | Internal monitoring catches it | Typically discovered externally: community, security researchers, registry alerts | | **Fix timeline** | You can patch immediately | You wait for the upstream fix or pin to a safe version | | **Blast radius** | Scoped to your systems | May affect every project in the ecosystem using that dependency | | **Attribution** | Attacker targeted you specifically | You are collateral in an ecosystem-wide attack | ### Detection Signals Watch for these indicators that a supply chain compromise may have occurred: * **Community alerts.** Security advisories, posts from researchers, messages in developer Discord servers are often the first signal. * **Unexpected dependency updates.** A package version appears in your lockfile that no one on the team updated. * **Behavioral anomalies.** Unexpected network requests from your application, unusual transaction prompts reported by users, or build output that changes between runs without corresponding source changes. * **Integrity check failures.** SRI hash mismatches or checksum discrepancies between expected and actual artifacts. * **Registry advisories.** npm sends security advisories when a package is flagged, though this can lag behind public disclosure. ### Response Scenarios #### Frontend Dependency Compromise This is the most common scenario: a compromised npm package serves malicious JavaScript to users through your frontend. * **Deploy a clean frontend immediately.** Revert to the last known good build or rebuild without the compromised dependency. * **Invalidate CDN caches.** A cached compromised version will continue to reach users even after you redeploy from clean source. * **Warn users.** Post on your official channels that users should not interact with the application until the clean version is confirmed live. * **Check for wallet drainer activity.** If the compromise targeted wallet signing flows, check on-chain for unauthorized transactions originating from your application's users during the exposure window. #### Smart Contract Dependency Compromise If a Solidity library used in your contracts is found to be vulnerable or malicious: * **Determine if the affected code is deployed.** Check whether the compromised library version was included in any deployed contracts. Library vulnerabilities that were not present in the version you used may not affect you. * **Consider pausing.** If your contracts have a pause mechanism and the vulnerability is actively exploitable, pause them while you assess. * **Plan migration if needed.** Evaluate whether the vulnerability is actively exploitable with your current configuration and plan a new deployment. #### CI/CD Pipeline Compromise If the compromised dependency ran during your build process: * **Assume build secrets are compromised.** Rotate all secrets accessible to the CI environment (API keys, deployment keys, npm tokens). * **Audit recent deployments.** Check if any build produced by the compromised CI was deployed to production. Binaries or contracts produced during the compromise window should be considered untrusted. * **Review CI logs.** Look for unexpected network calls or file system access during the build. * **Rebuild with clean dependencies.** Use `--frozen-lockfile` with a verified lockfile. ### Immediate Response Steps When a compromise is confirmed or credibly suspected: #### Assess Exposure * **Check your lockfile.** Is the compromised version present in `pnpm-lock.yaml`, `yarn.lock`, or `package-lock.json`? * **Check deployed artifacts.** Was the compromised version included in any build that reached production? * **Check CI history.** Did any CI run install the compromised version? If so, CI secrets may have been exposed. * **Identify the attack window.** When was the malicious version published, and when did you last install or build? #### Contain the Damage * **Lock dependencies** to the last known good version. Delete `node_modules` and rebuild from a verified lockfile using `--frozen-lockfile`. * **Do not deploy anything** built during the exposure window until the build is clean. * **Rotate exposed secrets.** If the compromised package ran during CI, assume that CI environment's secrets (API keys, deployment keys, npm tokens) are exposed and rotate them immediately. * **Take down compromised deployments.** If a compromised frontend was served to users, take it offline or deploy a clean version as fast as possible. A few minutes of unavailability is recoverable, continued exposure is not. #### Communicate * **Notify your team.** Ensure everyone knows not to install or deploy until the situation is resolved. * **Notify affected users.** If wallet-interacting code was affected, warn users on your official channels promptly and specifically: tell them what happened, what the risk is, and what action they should take. * **Coordinate with the maintainer.** Report the compromise to the package maintainer and to the registry (npm, crates, PyPI). ### Post-Incident Actions Once the immediate threat is contained: * **Document the timeline.** When the compromise occurred, when it was detected, how long it was in production, and what the impact was. This serves the retrospective and any user communication that follows. * **Strengthen monitoring.** Add the detection signals you missed to your monitoring setup. * **Review dependency practices.** Were versions pinned? Were lockfiles committed and verified in CI? Address any gaps the incident exposed. * **Update your response playbook.** Incorporate lessons learned so the next response is faster. ### Quick-Reference Checklist When a supply chain compromise is reported: * [ ] Is the compromised version in your lockfile? * [ ] Was it included in any build that reached production? * [ ] Did it run during CI? If so, rotate all CI secrets. * [ ] Lock to the last known good version and rebuild from clean state. * [ ] Delete `node_modules` / build cache and use `--frozen-lockfile`. * [ ] If user-facing: deploy clean version, invalidate CDN caches, notify users. * [ ] If wallet-interacting: check for unauthorized on-chain activity during the exposure window. * [ ] Rotate any secrets the package could have accessed. * [ ] Report to the registry and coordinate with the package maintainer. * [ ] Document the incident timeline and run a retrospective. ### Further Reading * [Incident Management](/incident-management/overview): General incident response procedures and team coordination * [Web3 Supply Chain Threats](/supply-chain/web3-supply-chain-threats): Real-world incidents that illustrate the attack patterns described here * [Dependency Awareness](/supply-chain/dependency-awareness): Preventive practices like version pinning and lockfile integrity that reduce exposure * [DevSecOps](/devsecops/overview): Integrating dependency scanning and build security into CI/CD pipelines *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Supply Chain > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Supply Chain Security](/supply-chain/overview) * [Supply Chain Levels for Software Artifacts](/supply-chain/supply-chain-levels-software-artifacts) * [Dependency Awareness](/supply-chain/dependency-awareness) * [Web3 Supply Chain Threats](/supply-chain/web3-supply-chain-threats) * [Vendor Risk Management](/supply-chain/vendor-risk-management) * [Supply Chain Incident Response](/supply-chain/incident-response-supply-chain) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Supply Chain Security > 🔑 **Key Takeaway:** Your software is only as secure as its weakest dependency. Supply chain security means knowing > what you depend on, verifying its integrity, and having a plan for when something in your chain is compromised. Supply chain security covers everything between your source code and your users. In traditional software, that mostly means npm packages and third-party libraries. In Web3, the chain is longer and the consequences are more severe: frontend code interacts directly with wallets, smart contracts hold real value, and infrastructure providers make decisions your contracts rely on. Attackers who understand this do not need to compromise your code directly. They target the libraries you import, the CDNs that serve your frontend, the RPC endpoints your app trusts, and the contractors your team onboards. These are not theoretical risks. Attacks targeting npm packages, wallet connector libraries, and compiler toolchains have resulted in hundreds of millions of dollars in losses across the Web3 ecosystem. ### What Makes Up a Web3 Supply Chain? A Web3 project's supply chain includes every external component between your source code and your users: * **Code dependencies:** npm packages, Solidity libraries, Rust crates, and their transitive dependencies * **Frontend delivery:** CDNs, hosting providers, wallet connector libraries, and the scripts served to users' browsers * **Build tooling:** Compilers (solc), development frameworks (Hardhat, Foundry), CI/CD pipelines * **Infrastructure providers:** RPC nodes, indexers, oracle networks, bridge relayers * **Hardware:** Signing devices, hardware wallets, HSMs * **Human supply chain:** Contractors, freelancers, open-source contributors A compromise at any point in this chain can affect your users. ### What This Framework Covers This framework provides practical guidance for securing each layer of your supply chain: 1. [Dependency Awareness](/supply-chain/dependency-awareness): Manage external packages securely, including version pinning, lockfile integrity, vulnerability scanning, and protection against typosquatting. 2. [Web3 Supply Chain Threats](/supply-chain/web3-supply-chain-threats): The specific threat vectors that affect Web3 projects, from frontend library hijacking to infrastructure compromise and hardware tampering. 3. [Supply Chain Levels for Software Artifacts](/supply-chain/supply-chain-levels-software-artifacts): Classify your components by risk level and apply proportional controls. 4. [Vendor Risk Management](/supply-chain/vendor-risk-management): Evaluate and monitor third-party providers including RPC services, oracle networks, security auditors, and contractors. 5. [Supply Chain Incident Response](/supply-chain/incident-response-supply-chain): What to do when a dependency or provider is compromised, including Web3-specific response scenarios. ### Related Frameworks Supply chain security intersects with several other areas covered in this project: * [DevSecOps](/devsecops/overview): Integrating dependency scanning and build security into CI/CD pipelines * [DPRK IT Workers](/dprk-it-workers/overview): Mitigating insider threats from the human supply chain * [Wallet Security](/wallet-security/overview): Hardware wallet supply chain integrity and key management * [External Security Reviews](/external-security-reviews/overview): Selecting and working with security auditors * [Incident Management](/incident-management/overview): General incident response procedures *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Supply Chain Levels for Software Artifacts > 🔑 **Key Takeaway:** Not every dependency carries the same risk. Apply your strictest controls to components that > touch user funds or signing operations, and scale down from there. Applying the same scrutiny to everything means > applying it effectively to nothing. Applying uniform security controls across an entire dependency tree is not practical and does not reflect how risk actually distributes. A smart contract library that handles value transfers carries fundamentally different risk than a test framework or a documentation generator. Classification frameworks exist to make this explicit: identify which components carry the most risk, then concentrate your strongest controls there and apply proportionally lighter measures to lower-risk artifacts. ### Risk Classification Framework #### Level 1: Critical Artifacts Components that directly handle value, signing operations, or core protocol logic. Smart contract libraries (OpenZeppelin Contracts), wallet interaction libraries (ethers.js, viem, web3.js), signing and cryptographic modules, and anything that constructs or validates transactions. Compromise of these components can directly drain funds or allow unauthorized transactions. These warrant the highest scrutiny. For specific practices, see [Dependency Awareness](/supply-chain/dependency-awareness), [Security Testing Framework](/security-testing/overview), and [External Security Reviews Framework](/external-security-reviews/smart-contracts/overview). #### Level 2: High-Risk Artifacts Components that are important to application function but do not directly handle funds. Authentication and authorization modules, API gateway and middleware components, database connectors, and oracle integration code fall in this category. Their compromise could enable data exposure, service disruption, or indirect fund loss, but would typically require additional exploitation steps. These benefit from regular vulnerability scanning and automated security testing in CI. For dependency management practices, see [Dependency Awareness](/supply-chain/dependency-awareness). For CI/CD pipeline security, see [DevSecOps](/devsecops/overview). #### Level 3: Moderate-Risk Artifacts High-usage components with limited blast radius. UI frameworks (React, Vue), general utility libraries (lodash, date-fns), data processing modules, and analytics libraries sit in this tier. User-facing frontend dependencies that influence wallet connection, transaction construction, signing flows, or security-critical UI should be treated as high-risk or critical, even if they are "just frontend libraries". Compromise could cause service degradation or facilitate phishing, but not direct fund loss. Standard update practices and periodic vulnerability scanning are sufficient. #### Level 4: Low-Risk Artifacts Components that do not run in production or have no access to sensitive data. Test frameworks (Jest, Mocha), linting and formatting tools, documentation generators, and local development utilities belong here. Basic security hygiene (trusted sources, occasional updates) is sufficient here. ### Further Reading * [Dependency Awareness](/supply-chain/dependency-awareness): Practical guidance on managing dependencies * [Web3 Supply Chain Threats](/supply-chain/web3-supply-chain-threats): Real-world attacks across the supply chain *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Vendor Risk Management > 🔑 **Key Takeaway:** Every provider, auditor, and contractor in your stack is a trust decision you are making on > behalf of your users. Assess that trust before onboarding, set expectations contractually, and review it regularly. Web3 projects are built on top of infrastructure and services they do not own. RPC providers relay every transaction. Oracle networks feed price data that contracts treat as ground truth. Auditors assess code that holds user funds. CDN providers serve the JavaScript that connects users to wallets. Each of these relationships represents a trust decision, and most teams make it informally, based on reputation, convenience, or whoever the previous developer used. Vendor risk management is the practice of making these trust decisions deliberately rather than by default. ### Categories of Third-Party Risk #### Infrastructure Providers * **RPC providers:** Every read and write your application makes to the blockchain goes through them. A compromised or misconfigured provider can return manipulated data, and a single-provider dependency means your application goes down when they do. * **Indexing services:** Applications that rely on indexed data for displaying balances, transaction history, or contract state are trusting that the index is accurate and up to date. Stale or incorrect results can mislead users or cause faulty transaction construction. * **Hosting and CDN:** Your frontend is served through these providers. If compromised, they can inject or modify the JavaScript that users execute in their browsers, including wallet interaction code. * **Domain registrars:** Control of your domain means control of where users are directed. An unauthorized transfer or DNS modification can redirect all traffic to a phishing clone. For DNS and hosting hardening, see [Domain & DNS Security Framework](/infrastructure/domain-and-dns-security/overview). For real-world incidents involving these providers, see [Web3 Supply Chain Threats](/supply-chain/web3-supply-chain-threats). #### Security Service Providers * **Smart contract auditors:** Audit quality depends on the auditor's domain expertise, methodology, and the time allocated relative to codebase complexity. Choosing the right auditor for your technology stack and protocol type is as important as the audit itself. * **Bug bounty platforms:** These sit between your project and the researchers who find vulnerabilities. Poor triage, slow response times, or mishandled disclosures can result in vulnerabilities going unpatched or being disclosed publicly before a fix is ready. * **Monitoring services:** Real-time alerting is only useful if it is accurate and actionable. Misconfigured monitoring produces alert fatigue, and missed detections leave exploits undetected during the critical early window. For guidance on selecting auditors, see [External Security Reviews](/external-security-reviews/overview). #### Human Supply Chain Contractors, freelancers, and pseudonymous open-source contributors all represent insider risk. In the Web3 industry this is not theoretical. The [DPRK IT Workers](/dprk-it-workers/overview) framework documents a specific and increasingly common pattern of state-affiliated actors gaining access to projects through legitimate-looking employment. Contractor vetting deserves the same rigor as any other vendor assessment. ### Ongoing Monitoring Vendor assessment is not a one-time event. Security postures change, ownership changes, and incidents happen. Reassess vendors periodically based on criticality, e.g., at a minimum annually, and quarterly for high-trust relationships. Subscribe to security advisories from your key providers and maintain a log of any vendor-related incidents or service degradations. Periodically audit the access each vendor holds and revoke anything unnecessary. For every critical vendor, have an exit plan: know which alternative you would migrate to, how long migration would take, and what data or configuration would need to move. Vendor lock-in becomes a critical risk when you need to move quickly during an incident. ### Common Pitfalls * **Assuming "decentralized" means "no vendor risk."** Even decentralized services have operators, maintainers, and infrastructure that can be compromised. * **Over-reliance on a single provider.** If your dApp stops working when one RPC provider goes down, you have a single point of failure. * **Skipping due diligence for well-known brands.** Reputation and security posture are related but not the same thing. Large providers have been compromised. * **No exit strategy.** Vendor lock-in becomes a critical risk when you need to move quickly during an incident. ### Further Reading * [Web3 Supply Chain Threats](/supply-chain/web3-supply-chain-threats): Real-world incidents involving infrastructure and service providers * [External Security Reviews](/external-security-reviews/overview): Selecting and working with security auditors * [DPRK IT Workers](/dprk-it-workers/overview): Mitigating insider threats from the human supply chain * [Infrastructure](/infrastructure/overview): Infrastructure hardening and DNS security *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Web3 Supply Chain Threats > 🔑 **Key Takeaway:** Supply chain attacks skip your code entirely. They compromise what your code depends on. A > single hijacked npm package, a manipulated compiler, or a spoofed RPC response can result in irreversible fund loss > with no exploit of your own contracts required. This page catalogs the specific threat vectors that target Web3 supply chains, with real incidents for each. For the broader context on why supply chain security matters, see the [Overview](/supply-chain/overview). ### Frontend Supply Chain Attacks The most common attack vector for end users is the JavaScript supply chain. Because wallet interactions happen through the browser, any code that runs on your frontend before a user signs a transaction is in a position to manipulate or redirect it. #### NPM Package Compromise Attackers gain control of popular npm packages through account takeovers, social engineering of maintainers, or publishing malicious packages with similar names. Once a compromised version is installed, malicious code executes in the user's browser. **Notable incidents:** * **npm registry attack (2025).** The largest npm supply chain attack to date. Attackers phished a maintainer's credentials via a fake 2FA reset email from `support@npmjs.help` and published malicious versions of 18 packages including `chalk`, `debug`, and `ansi-styles` (2.6 billion combined weekly downloads). The payload hooked `window.ethereum` to intercept wallet calls and overwrote `fetch`/`XMLHttpRequest` to reroute cryptocurrency transactions to attacker-controlled addresses. The compromise was detected and the malicious versions were removed within approximately two hours. * **Solana web3.js (2024).** Malicious versions (1.95.6 and 1.95.7) were published to npm containing code that exfiltrated private keys from any developer or user who installed those versions. * **ua-parser-js (2021).** A package with over eight million weekly downloads was briefly hijacked to inject a cryptominer and credential stealer into every project that ran `npm install` during the window. * **event-stream (2018).** A new maintainer was granted control of a package with over two million weekly downloads, then added a dependency specifically designed to steal keys from Copay Bitcoin wallet users. The attack ran undetected for weeks. For practices to defend against these attacks, see [Dependency Awareness](/supply-chain/dependency-awareness). For runtime integrity verification using Subresource Integrity and Content Security Policy, see [Third-Party Script Security](/front-end-web-app/third-party-script-security). #### Wallet Connector Library Hijacking Wallet connector libraries are a particularly high-value target because they sit at the exact point where user intent meets transaction construction. **Notable incidents:** * **Ledger Connect Kit (December 2023).** A former employee's npm credentials were used to publish a malicious version of `@ledgerhq/connect-kit`. The injected code rendered a fake wallet connection interface that redirected funds. Every dApp using the library was affected simultaneously. No vulnerability in any smart contract was involved. For wallet-specific security practices, see the [Wallet Security](/wallet-security/overview) framework. For browser-level controls that would have blocked execution of the tampered library, see [Third-Party Script Security](/front-end-web-app/third-party-script-security). #### CDN and Hosting Compromise An attacker who compromises your hosting provider or poisons a CDN cache can serve tampered JavaScript to all users without touching your repository. * **DNS hijacking** can redirect users to a phishing clone that looks identical to your dApp but replaces transaction signing with fund redirection. * **CDN cache poisoning** can serve malicious scripts even if your origin server is clean. For DNS hardening, registrar locks, and monitoring, see the [Domain & DNS Security](/infrastructure/domain-and-dns-security/overview) framework. For browser-level defenses against CDN and hosting compromise, including Content Security Policy, Subresource Integrity, and self-hosting strategies, see [Third-Party Script Security](/front-end-web-app/third-party-script-security). ### Smart Contract Dependency Risks Smart contracts inherit the risk of every library and tool in their build chain. While upgradeable proxy patterns allow post-deployment fixes, they add governance complexity and introduce their own attack surface. In either case, a compromised dependency that makes it into a deployment, whether upgradeable or not, has immediate on-chain consequences. #### Compiler Tampering The Solidity compiler itself is a dependency. Different `solc` versions produce different bytecode, and a compromised compiler binary could inject behavior that is invisible in source code review. Because developers typically trust the compiler implicitly, a tampered binary would affect every contract compiled with it without leaving any trace in the source. **Notable incidents:** * **Vyper reentrancy bug (2023).** A latent bug in the Vyper compiler (versions 0.2.15, 0.2.16, and 0.3.0) caused reentrancy guards to be incorrectly compiled at the bytecode level, despite appearing correct in source code. The bug had been present for over two years before attackers exploited it to drain approximately $69 million from multiple Curve Finance pools, Alchemix, JPEG'd, and Metronome. The contracts were not poorly written; the compiler produced faulty bytecode from correct source. #### Malicious Libraries and Plugins Build toolchains in Solidity projects (Hardhat, Foundry) rely on plugins, libraries, and Git-sourced dependencies. Each is an entry point. A malicious Hardhat plugin runs during compilation and deployment, meaning it could modify bytecode, exfiltrate private keys from the deployer's environment, or alter deployment scripts. Foundry's `forge install` pulls directly from Git repositories, so a compromised or mutable branch reference means the code you build against today may not be the code you reviewed yesterday. #### Unverified Deployments Source verification (via [Sourcify](https://sourcify.dev/) or Etherscan) is standard practice, but its absence is itself a supply chain risk. Without it, a build-time compromise leaves no detectable trace: the deployed bytecode cannot be compared against the reviewed source, and neither users nor auditors have a way to confirm what is actually running on-chain. Even with source verification, the guarantee only holds if the build is reproducible. If two developers compiling the same source with the same compiler version produce different bytecode (due to differing compiler settings, optimizer runs, or metadata hashes), there is no reliable way to confirm that the verified source matches the deployed contract. Deterministic, reproducible builds are a prerequisite for meaningful source verification. Tools like [Sourcify's full match](https://docs.sourcify.dev/docs/full-vs-partial-match/) (which requires identical bytecode including metadata) and pinned compiler versions in build configs (`solc` version in `foundry.toml` or `hardhat.config.js`) help close this gap. For practices to mitigate these risks, see [DevSecOps](/devsecops/overview), [Security Testing](/security-testing/overview), and [Dependency Awareness](/supply-chain/dependency-awareness). ### Governance Attacks Upgradeable smart contracts introduce a supply chain vector that exists entirely on-chain: governance. If a protocol uses a proxy pattern where the implementation contract can be swapped through a governance vote or a multisig transaction, then compromising the governance process is equivalent to compromising the code itself. The attacker does not need to find a bug or tamper with a dependency. They just need enough votes or enough signers. In upgradeable systems, governance is effectively part of the code delivery path. #### Malicious Governance Proposals An attacker who acquires sufficient voting power (through token purchases, flash loan voting, or social engineering of delegates) can submit a proposal that upgrades a proxy to a malicious implementation. If the proposal passes, the new implementation runs with the same address and the same state, but with entirely different logic. Users interacting with the protocol may not notice anything changed until funds are drained. **Notable incidents:** * **Tornado Cash governance takeover (May 2023).** An attacker submitted a proposal that appeared to be a routine update but contained hidden code granting the attacker 1.2 million fake TORN votes. With majority voting power, the attacker gained full control of governance and used it to drain locked TORN tokens from the governance contract. * **Beanstalk (April 2022).** An attacker used a flash loan to acquire enough STALK governance tokens to pass a malicious governance proposal in a single transaction. The proposal transferred all protocol assets to the attacker's address, draining approximately $182 million. The attack exploited the fact that governance voting and execution could happen in the same block with no time delay. ### Infrastructure Dependency Risks Web3 applications depend on external infrastructure that they do not control. A compromised or unreliable provider does not need to exploit your code; it just needs to feed it bad data or go offline at the wrong moment. #### RPC Provider Compromise RPC providers mediate every interaction between your app and the blockchain. A provider that returns manipulated data, whether due to compromise, misconfiguration, or deliberate malfeasance, can cause your application to display incorrect balances, construct transactions against stale state, or fail silently during high-value operations. A single-provider dependency also creates a single point of failure: if it goes down, your application goes dark. **Notable incidents:** * **Infura outage (November 2020).** Infura's nodes were running outdated Geth versions when a silently patched consensus bug caused a chain split. MetaMask (which defaults to Infura) stopped working for hours. Binance, Upbit, and other exchanges halted ETH withdrawals. Uniswap, MakerDAO, and Compound were all affected. No funds were stolen, but the incident demonstrated how a single provider dependency can take down large portions of the ecosystem. #### Oracle Manipulation Oracle networks are a direct and well-documented attack surface. Manipulated oracle data has been the root cause of hundreds of millions of dollars in DeFi losses. The typical pattern: an attacker manipulates a spot price on a low-liquidity pool, the oracle reports this manipulated price, and a lending protocol accepts it as ground truth, enabling the attacker to borrow against inflated collateral or liquidate positions that should not be liquidatable. Single-source oracles are especially vulnerable. If the only price feed comes from one exchange or one API, the attacker only needs to manipulate one data point. **Notable incidents:** * **Mango Markets (October 2022).** An attacker pumped MNGO spot price from $0.02 to $0.91 on thin-liquidity markets within ten minutes, then used the inflated collateral to drain $112 million from the protocol's treasury. * **Cream Finance (October 2021).** Flash loans totaling over $1.5 billion were used to manipulate the yUSD price oracle, inflating collateral value and draining $130 million in lending assets. * **bZx (February 2020).** The first major flash loan oracle attacks. The attacker used flash-loaned ETH to manipulate WBTC and sUSD prices on Uniswap, which bZx used as its sole price oracle. Two attacks within one week, approximately $1 million total. #### Block Explorer API Dependence Block explorer APIs (Etherscan, Basescan, and their equivalents) are often used to fetch ABIs, verify contract state, or display transaction history. These are third-party services with their own availability and integrity risks. An application that depends on a block explorer API for security-critical data (e.g. confirming transaction finality) is introducing a single point of failure into its trust model. Beyond availability, the source verification systems that block explorers provide are themselves an imperfect trust layer. In 2021, samczsun [demonstrated](https://samczsun.com/hiding-in-plain-sight/) that Etherscan's handling of bytecode metadata could be exploited to make verified source code not match the contract's actual behavior. The verification page would show clean, reviewed code while the deployed contract did something different. This was not a one-off bug. A 2024 academic study (["Abusing the Ethereum Smart Contract Verification Services for Fun and Profit"](https://www.ndss-symposium.org/ndss-paper/abusing-the-ethereum-smart-contract-verification-services-for-fun-and-profit/), NDSS 2024) systematically tested Etherscan, Sourcify, and Blockscout and found 19 vulnerabilities across the three services. 15 were confirmed by the vendors, 10 were fixed, and some remain open. The attacks ranged from metadata manipulation to compiler version mismatches that allowed verified source to diverge from deployed bytecode. The takeaway: a green checkmark on a block explorer means the submitted source compiled to matching bytecode under the conditions the verifier tested. It does not guarantee that the source faithfully represents what the contract does. Treat verified source as a useful signal, not a security guarantee, and cross-reference against independent verification services when the stakes are high. For a structured approach to evaluating and managing third-party providers, see [Vendor Risk Management](/supply-chain/vendor-risk-management). For infrastructure hardening, see the [Infrastructure](/infrastructure/overview) framework. ### Hardware Supply Chain Hardware wallets and signing devices introduce physical supply chain risks. A tampered device can be programmed to leak private keys on first use or to sign transactions differently from what is displayed on screen. Devices purchased through third-party resellers, second-hand markets, or unofficial channels may have been intercepted and modified before reaching the buyer. Firmware updates from unofficial sources carry the same risk: a malicious update could extract keys or alter signing behavior while appearing to function normally. **Notable incidents:** * **Trezor Safe 3 vulnerability (2025).** Ledger's security research team disclosed that the Trezor Safe 3 is vulnerable to voltage glitching attacks that can allow an attacker with physical access (during manufacturing or transit) to read and modify firmware without leaving detectable signs. No confirmed exploits in the wild, but the disclosure demonstrates that hardware supply chain attacks are practical, not theoretical. * **Ledger customer database breach (2020).** An unauthorized party accessed Ledger's e-commerce database via a misconfigured API key. Over 272,000 customers had their names, physical addresses, and phone numbers leaked. No private keys were compromised, but the exposed data fueled targeted phishing campaigns, extortion attempts, and credible physical threats against wallet holders. For hardware wallet security guidance, see the [Wallet Security](/wallet-security/overview) framework. ### Further Reading * Review your project's dependency tree with the practices described in [Dependency Awareness](/supply-chain/dependency-awareness) * Classify your components by risk level using the [Supply Chain Levels](/supply-chain/supply-chain-levels-software-artifacts) framework * Establish a vendor assessment process following the [Vendor Risk Management](/supply-chain/vendor-risk-management) guide * Track real-time exploit data and historical incidents on the [DeFiLlama Hacks Dashboard](https://defillama.com/hacks) * [Third-Party Script Security](/front-end-web-app/third-party-script-security): Runtime integrity controls (Content Security Policy, Subresource Integrity, self-hosting) that complement build-time dependency practices *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Formal Verification Formal verification is the act of proving or disproving a given property of a system using a mathematical model. While fuzz testing tries to break properties by throwing random data at your system, formal verification tries to break properties using mathematical proofs. This is the highest level of assurance you can achieve in smart contract testing - mathematical certainty that your code behaves correctly under all possible conditions. The downside, is that it is often the most time-consuming to get correct. ### What is Formal Verification? Think of formal verification as translating your code into a mathematical model and using formal reasoning to prove whether certain properties hold. Unlike fuzzing, which tests the program with many random inputs, formal verification explores the program’s behavior through modeling rather than relying on specific test cases. For example, if you want to prove that a function should never revert, formal verification will create mathematical representations of all possible code paths and determine if any input could cause a revert. ### Symbolic Execution The most popular technique for formal verification in smart contracts is **symbolic execution**. In a nutshell, symbolic execution explores **every possible execution path** mathematically. Here's how it works: #### 1. Explore All Possible Paths Consider this simple function: ```solidity function f(uint256 a) public pure returns (uint256) { return a + 1; } ``` If our property is "this function should never revert", symbolic execution will find two possible paths: * **Path 1**: `a < type(uint256).max` → returns `a + 1` * **Path 2**: `a == type(uint256).max` → overflows and reverts #### 2. Convert Paths to Mathematical Expressions These paths become boolean expressions: **Path 1**: `a < type(uint256).max` **Path 2**: `a == type(uint256).max AND a + 1 < a` #### 3. Feed to SMT/SAT Solver These expressions are converted to SMT-LIB format and sent to solvers like Z3: ```lisp ; Declare a symbolic integer variable 'a' (declare-const a (_ BitVec 256)) ; Path 2: Check if overflow is possible (assert (= a #xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff)) (assert (bvult (bvadd a (_ bv1 256)) a)) (check-sat) ``` If the solver returns `sat` (satisfiable), it found an input that breaks your property! ### Real-World Example: Complex Math Functions Here's where formal verification really shines - catching bugs in complex mathematical code that would be nearly impossible to find manually or through testing. Consider this [intentionally confusing contract with custom operators](https://github.com/Cyfrin/sc-exploits-minimized/blob/main/src/invariant-break/FormalVerificationCatches.sol): *It has been truncated for space here:* ```solidity // Custom type with confusing operator overloads type Int is uint256; using {add as -} for Int global; // - actually does division! using {div as +} for Int global; // + actually does multiplication! using {mul as / } for Int global; // / actually does subtraction! using {sub as *} for Int global; // * actually does addition! function add(Int a, Int b) pure returns (Int) { return Int.wrap(Int.unwrap(a) / Int.unwrap(b)); // Division } contract FormalVerificationCatches { function hellFunc(uint128 numberr) public view returns (uint256) { // Extremely complex math with many nested conditions // and confusing operator overloads... // (hundreds of lines of complex mathematical operations) } } ``` #### Formal Verification Test with Halmos We can use [Halmos](https://github.com/a16z/halmos) (a symbolic execution tool) to verify this function never reverts: ```solidity import {Test} from "forge-std/Test.sol"; import {FormalVerificationCatches} from "../src/FormalVerificationCatches.sol"; contract HalmosTest is Test { FormalVerificationCatches fvc; function setUp() public { fvc = new FormalVerificationCatches(); } // Symbolic execution test with Halmos // Run with: halmos --function check_hellFunc_doesnt_revert_halmos function check_hellFunc_doesnt_revert_halmos(uint128 num) public view { (bool success,) = address(fvc).staticcall( abi.encodeWithSelector(fvc.hellFunc.selector, num) ); assert(success); } } ``` #### The Power of Formal Verification When you run this test, Halmos will output: ```bash [FAIL] check_hellFunc_doesnt_revert_halmos(uint128) (paths: 10/18, time: 3.05s) Counterexample: p_num_uint128 = 0x0000000000000000000000000000000000000063 (99) ``` **Formal verification found that input `99` causes the function to revert!** This bug would be difficult to find through: * Manual review (very complex to trace) * Unit testing (would need to test that exact input) * Fuzz testing (might miss this specific edge case) But formal verification explored all mathematical paths and proved the bug exists. ### Limitations Formal verification is not a silver bullet: #### Path Explosion Problem Complex contracts can have too many execution paths for tools to explore in reasonable time. #### Significant Effort Required Often, to get this right, this technique requires significant effort to be used. You need to understand how they work, their limitations, and how to help them. #### Specification Challenge You must clearly define what properties you want to prove. If your specification is wrong, verification is useless. #### Solver Limitations Sometimes solvers cannot find solutions to complex mathematical problems within reasonable timeouts. ### Tools and Frameworks **Symbolic Execution Tools:** * [Halmos](https://github.com/a16z/halmos) - Symbolic testing for Foundry * [HEVM](https://github.com/ethereum/hevm) - Haskell EVM with symbolic execution * [certora prover](https://github.com/Certora/CertoraProver) **SMT/SAT Solvers:** * [Z3](https://github.com/Z3Prover/z3) - Microsoft's theorem prover * [CVC4](https://cvc4.github.io/) - Automatic theorem prover **Built-in Options:** * Solidity SMT Checker - Built into the compiler ### References This document was inspired by [this article](https://patrickalphac.medium.com/formal-verification-symbolic-execution-the-security-silver-bullet-38e0ac9072eb) and the [Cyfrin Updraft formal verification curriculum](https://updraft.cyfrin.io/courses/formal-verification). *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Fuzz Testing Fuzz testing (or fuzzing) is when you supply random data to your system in an attempt to break it. Most of the time, hacks come from scenarios you didn't think about or write a test for. What if I told you that you could write one test that would check for almost every possible scenario? ### What is Fuzz Testing? For example, if a balloon was our system/code, it would involve doing random stuff to the balloon to break it. * Punch it * Squeeze it * Throw it * etc Why would we want to do all that? Let's look at an example. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract MyContract { uint256 public shouldAlwaysBeZero = 0; uint256 private hiddenValue = 0; function doStuff(uint256 data) public { if (data == 2) { shouldAlwaysBeZero = 1; } if (hiddenValue == 7) { shouldAlwaysBeZero = 1; } hiddenValue = data; } } ``` Let's say we have this function named `doStuff`, which takes an integer as input. We additionally have a variable named `shouldAlwaysBeZero` that we want always to be zero. The fact that this variable should always be zero is known as our **invariant**, or "property of the system that should always hold." **Invariant**: The property of the system that should always hold. Our invariant in this contract is that: **Invariant: `shouldAlwaysBeZero` MUST always be 0** ### Why Normal Unit Tests Aren't Enough Let's look at a normal unit test: ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import {MyContract} from "../src/MyContract.sol"; import {Test} from "forge-std/Test.sol"; contract MyContractTest is Test { MyContract exampleContract; function setUp() public { exampleContract = new MyContract(); } function testIsAlwaysZeroUnit() public { uint256 data = 0; exampleContract.doStuff(data); assert(exampleContract.shouldAlwaysBeZero() == 0); } } ``` With this single unit test `testIsAlwaysZeroUnit`, we might think our code has enough coverage, but if we look at the `doStuff` function again, we can see that if our input is `2`, our variable will not be zero. ```solidity function doStuff(uint256 data) public { // WHAT IS THIS IF STATEMENT??? // 👇👇👇👇👇👇 if (data == 2) { shouldAlwaysBeZero = 1; } // 👆👆👆👆👆👆 // Ignore this one for now if (hiddenValue == 7) { shouldAlwaysBeZero = 1; } hiddenValue = data; } ``` This seems obvious with our example function, but more often than not, you'll have a function that's much more complex with numerous edge cases that are impossible to manually test. ### Stateless Fuzz Tests In Foundry, you'd write a fuzz test like so: ```solidity function testIsAlwaysZeroFuzz(uint256 randomData) public { exampleContract.doStuff(randomData); assert(exampleContract.shouldAlwaysBeZero() == 0); } ``` Foundry will automatically input semi-random values to `randomData` and over many runs, input them to the `doStuff` function and check that the assertion holds. This would be equivalent to writing many tests where `randomData` had different values, all in one test! Now I say "semi-random" because the way your fuzzer (in our case, Foundry) picks the random data isn't truly random, and should be somewhat intelligent with the random numbers it picks. Foundry is smart enough to see the `if data == 2` conditional, and pick `2` as an input. If we run our fuzz test, it tells us exactly what input fails our test: ```bash $ forge test -m testIsAlwaysZeroFuzz Failing tests: Encountered 1 failing test in test/MyContractTest.t.sol:MyContractTest [FAIL. Reason: Assertion violated Counterexample: calldata=0x47fb53d00000000000000000000000000000000000000000000000000000000000000002, args=[2]] testIsAlwaysZeroFuzz(uint256) (runs: 6, μ: 27070, ~: 30387) ``` We can see that it found out if it passed `args=[2]` to the test, it was able to break our `assert(exampleContract.shouldAlwaysBeZero() == 0)`. So now, we can go back into our code, and realize we need to fix the edge case where `data == 2`, and now we are safe from the exploit! ### Stateful vs Stateless Fuzzing #### The Hidden Bug Now you may notice that there is another scenario where our code could have an issue, and that's when `hiddenValue == 7`. In order for this revert to happen, you have to: 1. First call `doStuff` with the value `7` (which sets `hiddenValue` to `7`) 2. Then call this function again with any other number It takes **2 calls** for our invariant to be broken: 1. Call `doStuff` with `7` 2. Call `doStuff` with any other number Our fuzz test written above will never be able to find this example because as it's currently written, our test is what's known as a **"stateless fuzz test."** **Stateless Fuzzing**: Fuzzing where the state of a previous run is discarded for the next run. #### Stateful Fuzz Tests (Invariant Tests) So, in smart contract testing, we can do **"stateful fuzzing"** instead. **Stateful Fuzzing**: The state of our previous fuzz run is the starting state of our next fuzz run. To write a stateful fuzz test in Foundry, you'd use the `invariant` keyword, and it requires a little more setup: ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import {MyContract} from "../src/MyContract.sol"; import {Test} from "forge-std/Test.sol"; import {StdInvariant} from "forge-std/StdInvariant.sol"; contract MyContractTest is StdInvariant, Test { MyContract exampleContract; function setUp() public { exampleContract = new MyContract(); targetContract(address(exampleContract)); } function invariant_testAlwaysReturnsZero() public { assert(exampleContract.shouldAlwaysBeZero() == 0); } } ``` Instead of just passing random data to function calls, a stateful fuzz test (invariant test) will automatically call random functions with random data. We use the `targetContract` function to tell Foundry that it can use any of the functions in `exampleContract`. There is just one function for this example, so it will just call `doStuff` with different values across multiple calls. If we run this test, we can see it finds out that if you call `doStuff` twice (once with the value `7`), it will break our invariant! ```bash $ forge test -m invariant_testAlwaysReturnsZero Failing tests: Encountered 1 failing test in test/MyContractTest.t.sol:MyContractTest [FAIL. Reason: Assertion violated] [Sequence] sender=0x000000000000000000000000000000000000018f addr=[src/MyContract.sol:MyContract]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=doStuff(uint256), args=[7] sender=0x0000000008ba49893f3f5ba10c99ef3a4209b646 addr=[src/MyContract.sol:MyContract]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=doStuff(uint256), args=[2390] ``` Perfect! It shows us the exact sequence of calls that broke our invariant. ### Real-World Smart Contract Invariants In an actual smart contract, your invariants won't be that a balloon shouldn't pop or some function should always be zero; they'll be something like: * New tokens minted \< inflation rate * There should only be 1 winner of a random lottery * Someone shouldn't be able to take more money out of the protocol than they put in * The protocol must always be over-collateralized * Total supply should equal sum of all balances ### Fuzz Testing Tools * [Foundry](https://github.com/foundry-rs/foundry/) * [Echidna](https://github.com/crytic/echidna) * [Medusa](https://github.com/crytic/medusa) ### Best Practices 1. **Start with Unit Tests**: Build your foundation with comprehensive unit tests first 2. **Identify Invariants**: Clearly define what properties must always hold 3. **Use Stateful Fuzzing**: Most real bugs require multiple function calls to trigger 4. **Bound Your Inputs**: Use realistic parameter ranges in handlers 5. **Document Invariants**: Make your invariants clear in comments and documentation ### References Much of this document was inspired by the [Cyfrin Updraft fuzzing](https://patrickalphac.medium.com/fuzz-invariant-tests-the-new-bare-minimum-for-smart-contract-security-87ebe150e88c) curriculum. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Security Testing > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Security Testing](/security-testing/overview) * [Unit Testing](/security-testing/unit-testing) * [Integration Testing](/security-testing/integration-testing) * [Fuzz Testing](/security-testing/fuzz-testing) * [Static Analysis](/security-testing/static-analysis) * [Formal Verification](/security-testing/formal-verification) * [Mutation Testing](/security-testing/mutation-testing) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Integration Testing While unit tests verify individual functions work in isolation (often with mocked dependencies), integration tests verify that your smart contracts work correctly with real external systems. In Web3, this primarily means testing with **fork tests** - running your contracts against real blockchain state. In unit tests, we `mock` interactions with external systems; integration tests, however, actually work with those systems by running as: * Fork tests * Testnet Tests * Inexpensive Mainnet Tests (Be careful here!) In smart contract development, this means testing your contracts against real protocols, oracles, and blockchain state rather than mocked versions. ### What are Fork Tests? Fork tests involve creating a local copy of the blockchain state at a specific block height, allowing you to run your smart contracts against real data and interactions. This is crucial for testing how your contracts will behave in production conditions, especially when they rely on external systems like oracles or other protocols. In foundry, you can run a fork test just by passing in a URL to fork: ```bash forge test --fork-url ``` ### Why Fork Testing Matters Most smart contract security issues arise from unexpected interactions with external systems. Fork testing helps you catch these issues before deployment by testing against real-world conditions. ### How to Implement Fork Tests Running a fork test can be as straightforward as pointing to contract addresses on a forked network. You can see a full example from the [Cyfrin Updraft foundry-fund-me curriculum.](https://github.com/Cyfrin/foundry-fund-me-cu/blob/main/test/integration/InteractionsTest.t.sol) ### References This document incorporates knowledge from: * [Cyfrin Updraft Security Testing Curriculum](https://updraft.cyfrin.io) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ### What is Mutation Testing? Mutation testing is a technique used to evaluate the quality of a test suite by introducing small changes (mutations) to the code and checking if the tests catch these changes. Each change, called a "mutant," simulates a potential bug. If your tests fail when a mutant is introduced, the mutant is "killed," indicating your tests are effective. If the tests pass, the mutant "survives," revealing a potential gap in your test coverage. ### How does it work? The exact behavior varies depending on the tool used, but the general flow looks like this: 1. **Mutant Generation**: The mutation testing tool automatically modifies your source code in small ways (e.g., changing a `+` to a `-`, or replacing a `<` with a `=<`). 2. **Test Execution**: The full test suite is run against each mutant version of the code. 3. **Result Analysis**: If the tests fail for a mutant, it is considered "killed." If the tests pass, the mutant "survives," indicating that the test suite did not detect the change. 4. **Mutation Score**: The effectiveness of your tests is measured by the mutation score, calculated as the percentage of mutants killed by the test suite. ### Types of Mutants There is a wide range of mutations that you can have, ranging from common software engineering ones to solidity-specific ones, for example: **Common Types:** * **Arithmetic Operator Replacement**: Changes `+` to `-`. * **Relational Operator Replacement**: Alters `==` to `!=`. * **Logical Operator Replacement**: Modifies `&&` to `||`. * **Conditional Boundary Changes**: Adjusts `>=` to `>`. * **Constant Replacement**: Replaces `0` constants with `1`. * **Statement Removal**: Removes or skips statements to simulate missing logic. **Solidity specific:** * **Data Location Keyword Replacement:** Changing `memory` to `storage` and vice versa. * **Call Type Replacement:** Changing `delegatecall()` to `call()`. * **Modifier Deletion or Insertion:** Removing or inserting for example `onlyOwner()` modifier. * **Exception Handling Deletion:** Remove `require()` statements. ### Selecting mutations Depending on the framework you use and the protocol you are building, you will have to pick appropriate mutators. The balance is the following: * More mutations -> Longer execution time -> Potentially more coverage * Less mutations -> Quicker execution time -> Potentially less coverage Here are some examples of types of issues that mutation testing is particularly effective at spotting and types of operators you should consider using: * **Logic Errors:** [Off-by-one errors](https://en.wikipedia.org/wiki/Off-by-one_error), incorrect comparison operators, wrong arithmetic operations, and logical operator mistakes. * **Edge Case Failures:** Boundary condition bugs, empty value handling, Overflow/underflow issues. * **Validation:** Missing access controls, Insufficient validation. What it's NOT good at: * Design-level architectural flaws * Complex integration bugs requiring multiple components * Performance issues not related to logic * Documentation or specification mismatches ### Modifier Mutation Example Let's say you have this simple Token Vault that allows users to withdraw funds: ```solidity contract TokenVault { mapping(address => uint256) public balances; address public owner; modifier onlyOwner() { require(msg.sender == owner, "Not authorized"); _; } // assume there is a deposit function as well here function withdraw(uint256 amount) external onlyOwner { require(balances[msg.sender] >= amount, "Insufficient balance"); balances[msg.sender] -= amount; payable(msg.sender).transfer(amount); } } ``` Let's now use [SuMo](https://github.com/MorenaBarboni/SuMo-SOlidity-MUtator), as they have their modifier list easily available. We could apply the following mutation to this code: * Remove `onlyOwner` modifier, using `MOD` operator. → Tests should fail when non-owner calls withdraw. * Change `>=` to `>`, using the `BOR` operator. To be mindful, this will produce a lot of mutations with other operators as well. → Tests should fail for exact balance withdrawals. * Change `-=` to `+=`, using `AOR` operator. Similarly to `BOR` will produce a lot of mutations. → Tests should fail (balance increases instead of decreases). * Remove the `require` statement, using the `EHD` operator. → Tests should fail when withdrawing more than the balance. The tool will produce a report, where survived and killed mutations will be highlighted. The next step would be to investigate whether any mutations have survived and, if so, whether testing for that case makes sense, or if there is a bug in the code. ### Best Practices and things to keep in mind #### 1. Make sure your Line and Branch coverage is already very high, close to 100% Mutation testing is essentially a "meta-test" of your test suite. If your tests don't even execute certain lines of code (low line coverage), then mutations in those lines will always survive because the tests never run that code path. This makes mutation testing ineffective and misleading; hence, improving line and branch coverage first is the priority before attempting mutation testing. #### 2. Achieving a 100% mutation score might not be feasible A 100% mutation score indicates that no mutants have survived the test. Fundamentally, it is the end goal, but can be sometimes infeasible and unnecessary, especially as the codebase grows in size. Instead, 100% should be the target, and every survived mutant carefully examined to see if that mutation makes sense and if the test should cover it. #### 3. Consider using only a subset of the mutators available Not all mutation operators are equally useful for every project. Some may generate mutants that are irrelevant or impossible to kill due to language constraints or business logic. A larger subset of mutators will also take significantly longer to run, especially if there are many replacements per mutation. #### 4. Consider using cloud infrastructure if your codebase is reasonably large Due to how mutation testing works, the larger the codebase size, naturally, the more mutants there will be, which increases the runtime of the test suite. Let's say you have 2k LoC, and you want to mutate `>` operator, you might have 100 occurrences of that operator, where each will be mutated 4 times, leaving you already with 400 variations of the codebase, where you have to run the whole test suite on. So it is not unusual for mutation testing to take multiple hours to run. Hence, having a remote cloud setup for such testing is advisable. ### Limitations * Mutation testing is a time-consuming process and is only as good as the mutations it generates. Therefore, selecting the key mutations is a crucial step. * Mutation testing is only as good as your existing test suite. If your tests are fundamentally flawed, mutation testing won't help identify the real issues. * Focuses primarily on unit-level testing and may miss integration-level or system-level bugs that require broader context. In summary, mutation testing is a great tool if used correctly, but it is not a silver bullet for ensuring code quality. While it can significantly improve test quality by identifying gaps in your test suite, it requires careful configuration and interpretation of results. ### Tools and Frameworks * [SuMo](https://github.com/MorenaBarboni/SuMo-SOlidity-MUtator) by MorenaBarboni * [vertigo-rs](https://github.com/RareSkills/vertigo-rs) by RareSkills * [Gambit](https://github.com/Certora/gambit) by Certora * [UniversalMutator](https://github.com/sambacha/universalmutator/tree/new-solidity-rules) by sambacha. However, it is a generalized mutation testing framework, which may lack the Solidity-specific mutators that the others contain. ### References This guide was heavily inspired by the following: 1. [RareSkills Solidity Mutation Testing](https://rareskills.io/post/solidity-mutation-testing#gdvnie-100-line-and-branch-coverage-is-important-for-mutation-testing) 2. [Metana Solidity Mutation Testing](https://metana.io/blog/solidity-mutation-testing/) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Security Testing The objective of Security testing, while most likely impossible, is to ensure that applications and systems are resilient to attacks and free from vulnerabilities. This section covers various security testing methodologies, including dynamic and static application security testing, fuzz testing, and security regression testing. There are several types of testing: * **Unit Testing**: Tests individual components or functions of the codebase. * **Integration Testing**: Tests the interaction between different components or systems. * **Fuzz Testing**: Tests the application by providing random or unexpected inputs to identify vulnerabilities. * **Static Analysis**: Analyzes the code without executing it to find potential vulnerabilities. * **Formal Verification**: Uses mathematical methods to prove the correctness of algorithms and protocols. Some types of testing overlap, for example, a unit test could also be a fuzz test. We will focus on testing and how it applies to smart contracts, and use solidity as an example. ### Goal The goal of security testing is to identify vulnerabilities and weaknesses in the codebase, while also making sure that the code behaves the same way even after changes. Different types of testing can help achieve this goal in different ways. There is no "one size fits all" solution, and the choice of testing methodology depends on the specific requirements and constraints of the project. ### Smart Contracts For smart contracts in particular, here is when to use each type of testing: * **Unit Testing**: Always. And aim for high "code coverage" (i.e. unit test as many paths as possible) * **Integration Testing**: Always. This can also be combined with fork testing. * **Fuzz Testing**: Always. Most unit tests can be fuzz tests. * **Static Analysis**: Always. Use tools like [Slither](https://github.com/crytic/slither) and [Aderyn](https://github.com/Cyfrin/aderyn) to analyze the code for vulnerabilities. * **Formal Verification**: Dependent. Anywhere functions are math heavy, stateless, or functionality matches another system, this should be used. ### Evaluating your test suite To ensure you're meeting the goals of security testing, it's essential to evaluate the quality and completeness of your test suite. This can be done through several approaches: * **Coverage Analysis**: High code and branch coverage helps assess how thoroughly your test suite exercises different execution paths. Aim for comprehensive coverage to reduce blind spots. * **Mutation Testing**: This technique measures the effectiveness of your test suite. It works by introducing small changes (or "mutations") to the code and checking whether the tests detect and fail on those changes. If a mutation doesn’t cause a failure, it may indicate a gap in your test logic. Together, methods like these can give a more complete picture of how well your tests validate both expected and unexpected behaviors. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Static Analysis At a high level, static analysis examines the structure, syntax, and patterns of your code without executing it. There are many forms of static analysis, and compilers like solc rely on these techniques. From a security perspective, static analysis can help identify potential vulnerabilities and code quality issues. Some static analysis tools are helpful for finding bugs too. Unlike dynamic testing (unit tests, fuzz tests, integration tests), these bug-finding-focused static analysis tools examine your code's structure, syntax, and patterns to identify potential vulnerabilities and code quality issues. You can think of these static analysis as being an automated code reviewer that never gets tired and knows common vulnerability patterns. ### Static Analysis in Practice Static analysis tools parse your source code and analyze it against known vulnerability patterns, coding standards, and best practices. They can quickly identify issues like: * **Known vulnerability patterns** (reentrancy, integer overflow, etc.) * **Code quality issues** (unused variables, dead code) * **Style violations** (naming conventions, formatting) * **Logic errors** (unreachable code, incorrect assertions) For example, this code has a classic reentrancy vulnerability: ```solidity contract VulnerableContract { mapping(address => uint256) public balances; function withdraw() public { uint256 amount = balances[msg.sender]; (bool success,) = msg.sender.call{value: amount}(""); require(success, "Transfer failed"); balances[msg.sender] = 0; // ❌ State update after external call } } ``` A static analysis tool will automatically detect this reentrancy pattern and flag it as a high-severity issue. ### Static Analysis Tools * [Aderyn](https://cyfrin.gitbook.io/cyfrin-docs/aderyn-cli/readme) * [Slither](https://github.com/crytic/slither) * [Solhint](https://github.com/protofire/solhint) ### References This document incorporates knowledge from: * [Cyfrin Updraft Security Testing Curriculum](https://updraft.cyfrin.io) * [Trail of Bits secure contracts](https://secure-contracts.com/program-analysis/slither/docs/src/api/static_analysis.html) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Unit Testing Unit testing is the foundation of smart contract security testing. While fuzz tests can find edge cases and integration tests verify system interactions, unit tests ensure that individual functions behave correctly under expected conditions. Every smart contract should have comprehensive unit test coverage before moving to more advanced testing methodologies. ### Overview Unit testing involves testing individual components or functions of your codebase in isolation. In smart contract development, this means testing each function with known inputs to verify expected outputs and state changes. **Why Unit Tests Matter for Security:** * Catch basic logic errors before they become vulnerabilities * Ensure access controls work as expected * Verify arithmetic operations don't have overflow/underflow issues * Document expected behavior for auditors and future developers * Provide a safety net when refactoring code ### The Foundation of Security Testing As mentioned in your security testing strategy, unit testing should **always** be implemented with high code coverage. Think of unit tests as your first line of defense against bugs that could become security vulnerabilities. ```solidity // Example: Simple token contract contract SimpleToken { mapping(address => uint256) public balances; uint256 public totalSupply; function transfer(address to, uint256 amount) public { require(balances[msg.sender] >= amount, "Insufficient balance"); require(to != address(0), "Cannot transfer to zero address"); balances[msg.sender] -= amount; balances[to] += amount; } } ``` ### Writing Effective Unit Tests #### Basic Unit Test Structure Here's how you'd test the transfer function above using Foundry: ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import {SimpleToken} from "../src/SimpleToken.sol"; import {Test} from "forge-std/Test.sol"; contract SimpleTokenTest is Test { SimpleToken token; address alice = address(0x1); address bob = address(0x2); function setUp() public { token = new SimpleToken(); // Give Alice some initial balance vm.store( address(token), keccak256(abi.encode(alice, 0)), // balances[alice] slot bytes32(uint256(1000)) ); token.setTotalSupply(1000); } function testTransferSuccess() public { vm.prank(alice); token.transfer(bob, 100); assertEq(token.balances(alice), 900); assertEq(token.balances(bob), 100); } function testTransferFailsInsufficientBalance() public { vm.prank(alice); vm.expectRevert("Insufficient balance"); token.transfer(bob, 2000); // More than Alice has } function testTransferFailsZeroAddress() public { vm.prank(alice); vm.expectRevert("Cannot transfer to zero address"); token.transfer(address(0), 100); } } ``` #### Security-Focused Test Cases For each function, you should test: 1. **Happy Path**: Normal expected usage 2. **Edge Cases**: Boundary conditions (zero values, maximum values) 3. **Access Control**: Who can and cannot call the function 4. **Failure Cases**: Invalid inputs that should revert 5. **State Changes**: Verify all expected state modifications occur #### From Unit Test to Fuzz Test You can easily convert a unit test to a fuzz test: ```solidity // Unit test function testTransferAmount() public { uint256 amount = 100; vm.prank(alice); token.transfer(bob, amount); assertEq(token.balances(bob), amount); } // Fuzz test version function testTransferAmountFuzz(uint256 amount) public { amount = bound(amount, 0, 1000); // Bound to valid range vm.prank(alice); token.transfer(bob, amount); assertEq(token.balances(bob), amount); } ``` ### Mocking External Dependencies Unit tests should test your contract logic in isolation. When your contracts depend on external systems like oracles, other protocols, or complex state, you should mock these dependencies to create predictable, fast, and controlled test conditions. #### Why Mock in Unit Tests? **Problems with real external dependencies in unit tests:** * **Slow**: Network calls and complex state slow down tests * **Unpredictable**: External state changes make tests non-deterministic * **Expensive**: RPC calls cost money and hit rate limits * **Complex**: Hard to test edge cases with real systems **Benefits of mocking:** * **Fast**: No network calls or complex state * **Predictable**: You control exactly what the mock returns * **Comprehensive**: Easy to test all edge cases and failure scenarios * **Isolated**: Test only YOUR contract logic, not external systems #### Example Mock For example, if you are interacting with an ERC20 that has very odd functionality, an easier way to test working with it would be to make a mock of that contract. ```solidity // SPDX-License-Identifier: UNLICENSED pragma solidity ^0.8.0; import "openzeppelin-contracts/contracts/token/ERC20/ERC20.sol"; contract MockERC20 is ERC20 { constructor(string memory name, string memory symbol) ERC20(name, symbol) {} function mint(address account, uint amount) external { _mint(account, amount); } } ``` Then, use that mock in your tests: ```solidity import {MockERC20} from "../mocks/MockERC20.sol"; contract MyContractTest is Test { MockERC20 mockToken; function setUp() public { mockToken = new MockERC20("Mock Token", "MTK"); mockToken.mint(address(this), 1000); // Mint some tokens for testing } } ``` #### When NOT to Mock **Don't mock when:** * Testing the integration between YOUR contracts * The external dependency is simple and deterministic * You're specifically testing the interaction with the external system ### Best Practices #### 1. Achieve High Code Coverage Aim for 90%+ line coverage and 100% branch coverage on critical functions: ```bash # Run coverage with Foundry forge coverage ``` #### 2. Test All Access Controls ```solidity function testOnlyOwnerCanMint() public { vm.prank(alice); // Alice is not owner vm.expectRevert("Ownable: caller is not the owner"); token.mint(alice, 100); vm.prank(owner); token.mint(alice, 100); // Should succeed assertEq(token.balances(alice), 100); } ``` #### 3. Test Arithmetic Operations ```solidity function testNoOverflowOnMint() public { // Set total supply to near max uint256 uint256 nearMaxSupply = type(uint256).max - 100; token.setTotalSupply(nearMaxSupply); vm.prank(owner); vm.expectRevert(); // Should revert on overflow token.mint(alice, 200); } ``` #### 4. Use Descriptive Test Names ```solidity function testTransferFailsWhenRecipientIsZeroAddress() public { // Clear what this test does } function testMintIncreasesTotalSupplyAndRecipientBalance() public { // Tests multiple related behaviors } ``` #### 5. Arrange, Act, Assert Pattern ```solidity function testTransfer() public { // Arrange uint256 initialBalance = 1000; uint256 transferAmount = 100; // Act vm.prank(alice); token.transfer(bob, transferAmount); // Assert assertEq(token.balances(alice), initialBalance - transferAmount); assertEq(token.balances(bob), transferAmount); } ``` ### Common Smart Contract Tools and Frameworks * [Foundry (Solidity)](https://github.com/foundry-rs/foundry): * [Hardhat (Solidity)](https://hardhat.org/) * [Moccasin (Vyper)](https://github.com/Cyfrin/moccasin) * [Anchor (Rust)](https://www.anchor-lang.com/docs) ### References This document incorporates knowledge from: * [Cyfrin Updraft Security Testing Curriculum](https://updraft.cyfrin.io) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Compliance Checks Automating compliance checks helps projects ensure that they adhere to security policies, standards, and potential regulatory requirements consistently. Automated compliance tools can continuously monitor, assess, and report on the compliance status of systems and applications. ### Benefits of Automated Compliance Checks 1. **Continuous Monitoring** * Automated tools provide continuous monitoring of systems to ensure ongoing compliance. * Reduces the risk of non-compliance due to configuration drift or changes. 2. **Efficiency** * Automates repetitive compliance tasks, freeing up security teams to focus on more strategic activities. * Speeds up the compliance assessment process. 3. **Accuracy** * Reduces human error in compliance assessments. * Provides consistent and repeatable compliance checks. ### Tools for Automated Compliance Checks 1. **AWS Config** * A service that continuously monitors and records AWS resource configurations and allows automated compliance checks based on predefined rules. * Pros: Deep integration with AWS services, customizable rules. * Cons: Limited to AWS environments. 2. **Azure Policy** * A service that enables the creation, assignment, and management of policies to enforce organizational standards and assess compliance at scale. * Pros: Integrated with Azure services, supports custom policies. * Cons: Limited to Azure environments. 3. **HashiCorp Sentinel** * A policy-as-code framework for defining and enforcing policies across infrastructure as code and cloud environments. * Pros: Flexible and extensible, integrates with Terraform and other HashiCorp tools. * Cons: Requires knowledge of policy language. 4. **OpenSCAP** * An open-source tool for implementing and enforcing security policies and compliance checks. * Pros: Supports various compliance frameworks (e.g., NIST, CIS), open-source. * Cons: Requires configuration and management. ### Best Practices 1. Integrate compliance checks into the CI/CD pipeline to ensure that code changes and deployments comply with security policies. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Security Automation > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Security Automation](/security-automation/overview) * [Threat Detection & Response](/security-automation/threat-detection-response) * [Automated Compliance Checks](/security-automation/compliance-checks) * [Infrastructure as Code Security](/security-automation/infrastructure-as-code) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Infrastructure as Code Infrastructure as Code (IaC) is the management and provisioning of computing infrastructure through machine-readable definition files, rather than manual configuration or interactive configuration tools. Automating security within IaC helps ensure that infrastructure is configured securely and consistently. ### Benefits of Automating Security in IaC 1. **Consistency** * Ensures that infrastructure is provisioned and configured consistently across environments. * Reduces the risk of configuration drift and security misconfigurations. 2. **Scalability** * Enables scalable deployment of secure infrastructure. * Simplifies management of large-scale environments. 3. **Version Control** * Treats infrastructure configurations as code, allowing version control and change tracking. * Facilitates rollback to previous configurations if issues arise. ### Best Practices for Secure IaC 1. **Use Trusted Modules** * Use trusted and verified modules or templates for infrastructure provisioning. * Avoid using unverified or outdated modules that may contain vulnerabilities. 2. **Implement Least Privilege** * Ensure that infrastructure components have the minimum necessary permissions. * Use role-based access control (RBAC) to manage permissions. 3. **Automate Security Scans** * Integrate security scanning tools into the IaC pipeline to automatically detect and remediate vulnerabilities. * Use tools like Checkov, tfsec, and Terrascan to scan Terraform configurations for security issues. 4. **Encrypt Sensitive Data** * Encrypt sensitive data at rest and in transit within the infrastructure. * Use managed encryption services provided by cloud providers. 5. **Regularly Update IaC Templates** * Keep IaC templates and modules up to date with the latest security patches and best practices. * Regularly review and update configurations to address new security threats. ### Tools for Automating Security in IaC 1. **Terraform** * A widely used IaC tool that allows for the automated provisioning of infrastructure across various cloud providers. * Supports integration with security scanning tools like tfsec and Checkov. 2. **AWS CloudFormation** * An IaC service provided by AWS for modeling and setting up AWS resources. * Supports AWS Config rules for automated compliance checks. 3. **Azure Resource Manager (ARM) Templates** * IaC templates for deploying and managing Azure resources. * Integrates with Azure Policy for enforcing security policies. 4. **Ansible** * An open-source automation tool for configuration management and application deployment. * Supports security roles and playbooks for automating security configurations. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Security Automation Security automation involves using technology to perform security tasks with minimal human intervention. By automating repetitive and complex security processes, teams can improve efficiency, reduce the risk of human error, and respond to threats more quickly. This section covers best practices and tools for automating various aspects of security, including compliance checks, infrastructure as code, and threat detection and response. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Threat Detection and Response Threat detection and response is a critical aspect of maintaining the security of your project. It involves identifying potential threats, monitoring for signs of malicious activity, and responding effectively to mitigate any identified risks. By implementing robust threat detection and response strategies, you can protect your project from security breaches and minimize the impact of any incidents that do occur. ### Guidelines for Threat Detection and Response 1. **Implement Continuous Monitoring**: Use automated tools to continuously monitor your systems for signs of suspicious activity. This can help you detect threats early and respond quickly. 2. **Establish Clear Response Protocols**: Develop and document clear protocols for responding to different types of security incidents. Ensure that all team members are familiar with these protocols and know their roles in the response process. 3. **Conduct Regular Threat Assessments**: Regularly assess your systems for potential vulnerabilities and update your threat detection and response strategies accordingly. 4. **Use Threat Intelligence**: Leverage threat intelligence sources to stay informed about the latest threats and trends in the security landscape. This can help you anticipate and prepare for new types of attacks. 5. **Train Your Team**: Provide regular training for your team on threat detection and response best practices. This can help ensure that everyone is prepared to act quickly and effectively in the event of a security incident. ### Example Best Practice One effective approach to threat detection and response is to use a Security Information and Event Management (SIEM) system. A SIEM system collects and analyzes data from various sources within your network, helping you to identify and respond to potential threats in real-time. By integrating a SIEM system into your security strategy, you can improve your ability to detect and respond to threats, ultimately enhancing the overall security of your project. ### Incident Example Imagine that your SIEM system detects unusual login activity from an IP address located in a different country than your usual operations. This could be an indication of a potential security breach. ### Sample Process 1. **Detection**: The SIEM system flags the unusual login activity and generates an alert. 2. **Analysis**: A security analyst reviews the alert and examines the login activity to determine if it is indeed suspicious. 3. **Containment**: If the activity is confirmed to be malicious, the analyst takes steps to contain the threat, such as blocking the IP address and disabling the compromised account. 4. **Eradication**: The analyst investigates the extent of the breach and removes any malicious software or unauthorized access points. 5. **Recovery**: The affected systems are restored to normal operation, and any necessary security patches or updates are applied. 6. **Lessons Learned**: A post-incident review is conducted to identify any gaps in the threat detection and response process and to implement improvements for future incidents. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Code Reviews and Peer Audits Code reviews and peer audits help identifying and mitigating security vulnerabilities in software. They involve systematically examining code to ensure it adheres to the security standards and best practices of the project. ### Best Practices for Code Reviews 1. **Regular Reviews** * Conduct code reviews regularly to identify and fix security vulnerabilities early in the development process. * Integrate code reviews into the development workflow to make them a routine part of the process. 2. **Review Checklists** * Use review checklists to ensure that all security aspects are covered during the review. * Checklists should include common security issues such as input validation, error handling, and authentication. 3. **Automated Tools** * Use automated code analysis tools to assist in identifying potential security vulnerabilities. * Tools like SonarQube, Checkmarx, and Snyk can help in detecting issues that might be missed during manual reviews. 4. **Peer Audits** * Encourage peer audits where team members review each other's code. * Peer audits provide a fresh perspective and can help identify issues that the original developer might overlook. ### Conducting Effective Code Reviews 1. **Focus on Security** * Prioritize security issues during code reviews. * Ensure that code follows secure coding standards and guidelines. 2. **Collaborative Approach** * Foster a collaborative environment where reviewers and developers work together to improve code quality. * Provide constructive feedback and encourage open communication. 3. **Document Findings** * Document all findings from code reviews and track their resolution. * Use issue tracking systems to manage identified vulnerabilities and ensure they are addressed. 4. **Continuous Improvement** * Continuously improve the code review process based on feedback and lessons learned. * Regularly update review checklists and practices to keep up with evolving security threats. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Secure Software Development > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Secure Software Development](/secure-software-development/overview) * [Secure Coding Standards & Guidelines](/secure-software-development/secure-coding-standards-guidelines) * [Code Reviews & Peer Audits](/secure-software-development/code-reviews-peer-audits) * [Secure Code Repositories & Version Control](/secure-software-development/secure-code-repositories-version-control) * [Threat Modeling & Secure Design](/secure-software-development/threat-modeling-secure-design-principles) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Secure Software Development Secure software development is the practice of integrating security measures throughout the entire software development lifecycle (SDLC). This approach ensures that software is designed, developed, and maintained with security in mind, protecting against vulnerabilities and threats. This section provides guidelines and best practices for secure software development, including code reviews, secure coding standards, version control, and threat modeling. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Secure Code Repositories and Version Control Managing secure code repositories and having version control practices helps protect your project from unauthorized access and ensuring the integrity of your project. ### Best Practices for Secure Code Repositories 1. **Access Control** * Implement strict access controls to limit who can view, modify, and commit code. * Use role-based access control (RBAC) to grant permissions based on the user's role within the organization. 2. **Multi-Factor Authentication (MFA)** * Require MFA for all users accessing the code repository to add an extra layer of security. * Use hardware tokens or authentication apps for stronger security. 3. **Branch Protection** * Enable branch protection rules to prevent unauthorized changes to critical branches such as main/master. * Require code reviews and approvals by another person before changes can be merged into the main/master branch. 4. **Audit Logs** * Enable audit logging to track all activities within the repository. * Regularly review logs to detect any suspicious activities or unauthorized access attempts. ### Secure Version Control Practices 1. **Commit Signing** * Require developers to sign their commits with GPG keys to verify the authenticity of the code changes. * Enforce commit signing policies in the version control system. 2. **Regular Backups** * Regularly back up the code repository to prevent data loss. * Store backups in a secure, offsite location. 3. **Continuous Integration/Continuous Deployment (CI/CD)** * Integrate security checks into the CI/CD pipeline to automatically scan code for vulnerabilities. * Ensure that only tested and approved code is deployed to production. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Secure Coding Standards and Guidelines Using secure coding standards and guidelines increases the likelihood of you being resilient to security threats. Having these type of standards can help developers avoid common vulnerabilities, and help ensure that security is considered at every stage of development. ### Secure Coding Standards 1. **Input Validation** * Validate all inputs to ensure they conform to expected formats and ranges. * Use whitelisting (allowing only known good inputs) rather than blacklisting. 2. **Output Encoding** * Encode output data. * Use libraries and frameworks that provide built-in encoding functions. 3. **Authentication and Authorization** * Implement strong authentication mechanisms to verify user identities. * Ensure proper authorization checks are in place to control access to resources based on user roles. 4. **Error Handling** * Handle errors gracefully without revealing sensitive information. * Log errors securely and provide generic error messages to users. ### Guidelines for Secure Coding 1. **Use Secure Libraries and Frameworks** * Use libraries and frameworks that have been vetted for security and are regularly updated. * Avoid using deprecated or unmaintained libraries. 2. **Follow Principle of Least Privilege** * Grant the minimum level of access necessary for code to function. * Avoid running code high privileges. 3. **Secure Data Storage** * Encrypt sensitive data both at rest and in transit. * Use secure storage mechanisms for credentials and secrets. 4. **Regular Code Reviews** * Conduct regular code reviews to identify and fix security vulnerabilities. * Use automated tools to complement manual code reviews. 5. **Continuous Security Training** * Provide ongoing security training for developers to keep them informed about the latest threats and best practices. * Encourage participation in security communities and events. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Threat Modeling and Secure Design Principles Threat modeling and secure design principles help identify and mitigating potential security threats during the design phase of software development. T ### Threat Modeling 1. **Identify Assets** * Determine the valuable assets that need protection, such as user funds, sensitive data, user credentials, and intellectual property. 2. **Identify Threats** * Identify potential threats to the assets using models like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). 3. **Assess Risks** * Evaluate the risks associated with each identified threat based on its likelihood and potential impact. 4. **Develop Mitigations** * Design and implement security controls to mitigate the identified threats. Prioritize mitigations based on the assessed risks. 5. **Validate and Iterate** * Regularly validate the threat model and update it as the application evolves. Continuously assess and improve security measures. ### Secure Design Principles 1. **Principle of Least Privilege** * Grant users and systems the minimum level of access necessary to perform their functions. Reduce the attack surface by limiting permissions. 2. **Defense in Depth** * Implement multiple layers of security controls to protect against different types of threats. Ensure that security is not reliant on a single control. 3. **Fail Securely** * Design systems to fail in a secure manner. Ensure that errors and failures do not expose sensitive information or create security vulnerabilities. 4. **Secure Defaults** * Configure systems with secure default settings. Require users to opt into less secure configurations rather than opting into secure ones. 5. **Separation of Duties** * Separate critical functions to prevent a single individual or system from having excessive control. Implement checks and balances. 6. **Secure by Design** * Integrate security into the design and architecture of the application. Consider security implications during every stage of the design process. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Safe Harbor > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [SEAL Whitehat Safe Harbor](/safe-harbor/overview) * [Safe Harbor Self-Checklist](/safe-harbor/self-checklist) * [Safe Harbor Self-Adoption Guide](/safe-harbor/self-adoption-guide) * [Safe Harbor Scope Terms](/safe-harbor/scope-terms) * [Safe Harbor On-Chain Adoption Guide](/safe-harbor/on-chain-adoption-guide) * [Whitehat Rescue Guide](/safe-harbor/whitehat) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## On-Chain Adoption Guide This guide explains how protocols can register their Safe Harbor adoption on-chain. Registering ensures your adoption is **public, verifiable, and enforceable**. ### Why On-Chain Adoption Matters On-chain registration: * Makes your Safe Harbor adoption **public and transparent**. * Signals to whitehats that your protocol is officially covered under the agreement. * Publishes your terms (scope, bounty, contacts) on-chain in a way that's **traceable and verifiable**, even if updated later. ### How On-Chain Adoption Works The process involves **two steps**: 1. **Create your Agreement contract** via the AgreementFactory (containing your scope details) 2. **Register the agreement** with the Safe Harbor Registry ### Three Ways to Deploy and Register **Important Note:** * The address that registers **represents your protocol on-chain**. * Most protocols use **multisigs** or **DAOs** for the registration step - Be sure to set the `owner` of the agreement to your multisig or DAO address if you are registering with them. * The simplest workflow is to use the SEAL Self-Adoption Tool to deploy your agreement and register it with your multisig/DAO. #### 1. SEAL Self-Adoption Website + Script/Multisig Registration 1. Navigate to the [SEAL Self-Adoption Tool](https://safeharbor.securityalliance.org/adoption). 2. Fill in your scope details (Asset Recovery Address, Assets Under Scope, Bounty Terms, etc.). * **WARNING**: Be sure to set the `owner` of the agreement to your multisig or DAO address if you're registering with them. 3. Choose one of the following: * **Generate an Agreement** to deploy your Agreement contract via the SEAL tool * **Export JSON** for use in Foundry scripts 4. **Deploy your agreement** using the generated parameters 5. **Register separately** using either: * Foundry script (see method 3 below) * Multisig registration (see method 2 below) #### 2. Multisig Registration (Gnosis Safe) If your protocol uses a multisig, you can register on-chain securely after deploying your agreement. **Steps:** 1. **First, create your Agreement contract**: * Use the SEAL Self-Adoption Tool to generate the deployment parameters * Deploy via the AgreementFactory using your preferred method * **WARNING:** Be sure to set the `owner` of the agreement to your multisig address 2. **Register with your multisig**: * Open your Gnosis Safe and go to the **Transaction Builder** app * Enter the **Safe Harbor Registry address**: `0x326733493E143b8904716E7A64A9f4fb6A185a2c` * Select the method: `adoptSafeHarbor(address agreementAddress)` and input your deployed Agreement contract address * Add the transaction and simulate it: * You should see a `SafeHarborAdoption` event with your multisig as the `adopter` * Collect signatures and execute #### 3. Foundry Script / Custom Code If you prefer deploying and registering via code or need custom integrations, you can use SEAL's Foundry script or write your own. **Using SEAL's Foundry Script:** * Repository: [security-alliance/safe-harbor](https://github.com/security-alliance/safe-harbor) * Script: `registry-contracts/script/AdoptSafeHarbor.s.sol` **Steps:** 1. Generate your **scope JSON** via the SEAL tool or manually prepare it using `registry-contracts/examples/agreementDetails.json` as a template 2. Paste the JSON into: `registry-contracts/agreementDetails.json` 3. Run the script: * By default, the script will set the deployer as the owner of the agreement * You can change this by setting `AGREEMENT_OWNER` in your `.env` file to your desired owner address * By default, the script will not register the agreement - you can change this by setting `ADOPT_TO_REGISTRY` to `true` in your `.env` file * The script can handle both deployment and registration **Manual Method:** 1. Create your agreement: Call `AgreementFactory.create(AgreementDetails memory details, address chainValidator, address owner, bytes32 salt)` 2. Register it: Call `SafeHarborRegistry.adoptSafeHarbor(address agreementAddress)` ### V3 Contract Addresses V3 contracts are deployed via [CreateX](https://github.com/pcaversaccio/createx) with deterministic addresses across all supported EVM chains. | Contract | Address | Description | | -------------------------- | -------------------------------------------- | ---------------------------------------- | | **SafeHarborRegistry** | `0x326733493E143b8904716E7A64A9f4fb6A185a2c` | Main registry for protocol adoptions | | **ChainValidator** (proxy) | `0xd01C76ccE414d9B0a294abAFD94feD2e0B88675D` | Validates CAIP-2 chain IDs | | **AgreementFactory** | `0xcf317fE605397bC3fae6DAD06331aE5154F277fF` | Factory for creating Agreement contracts | > **Note:** These addresses are the same on all supported EVM chains due to CREATE3 deployment. > The V3 contracts have been audited by [Cyfrin](https://www.cyfrin.io/). > The smart contracts are bytecode equivalent to the > [audited hash](https://github.com/security-alliance/safe-harbor/tree/0b0abb8b627eff87e2f7b52bf8ec484cd6ce0e32). > The audit report is available in the > [Cyfrin audit PDF](https://github.com/security-alliance/safe-harbor/blob/main/documents/2026-01-13-cyfrin-safe-harbor-v2.0.pdf). *** If you ever need help or have any questions, don't hesitate to reach out! 📬 Contact us at: [safe-harbor@securityalliance.org](mailto\:safe-harbor@securityalliance.org) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, } from "../../../components"; ## SEAL Whitehat Safe Harbor SEAL Whitehat Safe Harbor logo - DeFi exploit protection framework > 💡 An industry-standard framework, letting your protocol pre-authorize whitehats to rescue funds during active > exploits
### What is Safe Harbor? > When your protocol is under attack, every second counts. Safe Harbor gives you a way to fight back. Safe Harbor is a legal and technical framework that lets your protocol pre-authorize whitehats to step in during active exploits, rescue funds, and return them - fast, safely, and with clear legal protection for everyone involved. By adopting Safe Harbor, protocols allow: * Empower whitehats to act immediately during an exploit * Remove legal ambiguity and delays * Boost the odds of recovering user funds ### Why we started Safe Harbor > 💡 We started Safe Harbor after the Nomad hack, where over $190M was drained over the course of hours while whitehats > stood by, willing to help, but unable to act without legal protection. With Safe Harbor, our goal is to make sure that > never happens again and to empower whitehats to rescue funds. ### Vetted by industry leaders and top Web3 lawyers > Safe Harbor was developed over two years with direct input and rigorous legal review from experts at a16z Crypto, > Cooley, Debevoise & Plimpton, Filecoin Foundation, MetaLeX, Paradigm, Piper Alderman, Powerhouse, and more. Law firms that reviewed Safe Harbor: a16z Crypto, Cooley, Debevoise & Plimpton, Paradigm, and others ### Who's Adopted Safe Harbor > Safe Harbor is already protecting $68B+ in assets across leading DeFi protocols. It has been adopted by 20+ protocols. > Current adopters include Uniswap, Aave, Pendle, PancakeSwap, Balancer, Silo Finance, Zksync, and more. See the > [full up-to-date list](https://safeharbor.securityalliance.org/). | Uniswap - Safe Harbor adopter | Pendle - Safe Harbor adopter | zkSync - Safe Harbor adopter | Balancer - Safe Harbor adopter | | :----------------------------------------------------------------------------------------------------------------------------------------------------: | :--------------------------------------------------------------------------------------------------------------------------------------------------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------: | | **Uniswap**
[Gov Proposal](https://www.tally.xyz/gov/uniswap/proposal/79) | **Pendle**
Non-DAO Adoption | **zkSync**
[Gov Proposal](https://www.tally.xyz/gov/zksync/proposal/35395412545014978447594654620386134175315194219985614464693911512436668500487?govId=eip155:324:0x496869a7575A1f907D1C5B1eca28e4e9E382afAb) | **Balancer**
[Gov Proposal](https://snapshot.box/#/s\:balancer.eth/proposal/0x8c3fd2550184ec28653c46e959782f1a3127ca8aa6a5652494a9c29ad77d9b55) | ### How Safe Harbor Protects Your Protocol * **Protocols pre-authorize rescues:** You clearly define when and how whitehats are allowed to step in - covering what assets are protected, where to return funds, and what bounty terms apply, etc * **Whitehats act only during active exploits:** Safe Harbor **only** applies when an exploit is already in progress or imminent - e.g., in the mempool, or after initial funds have been drained. It's *not* for bug bounty reports, and it does not protect blackhats. Only whitehats who rescue funds without initiating the exploit are covered. * **Funds are returned, bounty is automatic:** Whitehats must send rescued funds to your official recovery addresses within 72 hours. Bounties are enforceable and pre-defined - no negotiation, no chaos. **Other key protections:** * You can choose to allow anonymous whitehats or require KYC. * Whitehats must follow established guidelines for responsible intervention * You define exactly which contracts, and chains are protected. * The agreement is only valid if funds are returned and the protocol's rules are followed ### How to Adopt Safe Harbor (3 Options) Adopting Safe Harbor is fast, simple, and works whether you're a DAO or a centralized team. You can complete the whole process in under an hour. Here are a few options: #### 1. Get White-Glove Onboarding (Free) For protocols that want hands-on support, [SEAL](https://securityalliance.org) offers guided onboarding at no cost. We'll walk you through scoping, governance language, on-chain registration, and more. → [Apply for Guided Onboarding](https://form.typeform.com/to/QF3YjWno) > Space is limited - we prioritize high-impact protocols and critical infrastructure #### 2. Self-Adopt Using Our Guide For teams that want to do it themselves, we provide a clear step-by-step guide, including templates for scope definitions, template DAO proposals, and on-chain registration instructions. → [View the Self-Adoption Guide](/safe-harbor/self-adoption-guide) #### 3. Adopt Through a Third-Party Provider Safe Harbor is also supported by select ecosystem partners who offer adoption workflows as part of their existing services. → [Adopt via Immunefi](https://docs.google.com/forms/d/e/1FAIpQLSehHw_KyNfSr9YbnO1AB3OZ4cvVS2oInIxdveCPguR9GSxZFQ/viewform) Safe Harbor doesn't require a legal entity, legal counsel, or new infrastructure. Just define your terms, publish your scope, and your protocol is protected. > Whether you're a DAO or not, adopting Safe Harbor is a low-lift way to enable real-time defense and recover funds > during live exploits. ### Proven Results: Whitehats Have Recovered $150M+ > 💡 [SEAL911](/incident-management/playbooks/seal-911-war-room-guidelines) and the broader whitehat community have > already helped protocols recover over $150M from live attacks - proving that fast, responsible intervention is > possible. ### FAQ
What counts as an active exploit? An *active exploit* is one that's already in progress or imminent - for example, a malicious transaction sitting in the mempool or a vulnerability that's already being exploited. Safe Harbor only applies when immediate action is required to prevent or stop fund loss. It does **not** apply to situations where there is no imminent threat and where responsible disclosure can prevent fund loss.
How is it different than a Bug Bounty? Bug bounties reward whitehats for responsibly disclosing vulnerabilities *before* they're exploited. Safe Harbor kicks in *after* an exploit is underway - when there's no time for disclosure, and whitehats need legal cover to intervene and recover funds in real time.
What are the risks? There is little to no risk. The status quo is that the protocol is hacked and the hacker gets 100% of the funds. But with Safe Harbor, we unlock the upside of whitehats stepping in and rescuing funds. So the worst case scenario is the status quo, while the best case scenario is all funds are rescued by the protocol. Whitehats only receive protection if they follow every requirement. If no exploit happens, nothing changes. If they do not follow Safe Harbor, they're a blackhat
Can DAOs adopt it? Yes. Safe Harbor was built with DAOs in mind. No legal entity is required - just a governance vote and public on-chain registration. Many protocols who have adopted are DAOs (ex: Uniswap, Balancer, Zksync)
Can Non-DAOs adopt it? Yes. Centralized teams and foundations can also adopt Safe Harbor by publishing their scope and adoption terms. No DAO is required. Many protocols who have adopted are centralized teams (Pendle, Polymarket)
Who is the agreement with? The Safe Harbor agreement is structured as a **public unilateral offer -** a legally binding offer made by your protocol to *any whitehat* who acts under the published terms. There's no need to know or pre-approve the individual. If a whitehat follows your rules (e.g. intervenes during an active exploit, returns funds to the recovery address, meets any KYC requirements), the agreement becomes binding. No signatures or formal negotiation required.
Do we need to sign a legal contract (like DocuSign)? Nope. Safe Harbor uses on-chain registration and public adoption details - no signatures or lawyers required. If you're a DAO, a governance vote is enough.
What if a blackhat initiates a hack with one account, then "whitehats" it with another account to get the bounty? They're not covered. Safe Harbor protections **only** apply to whitehats who are fully independent from the original exploit. If someone initiates a hack and then tries to "rescue" the funds with another address, they're still considered a blackhat - **no bounty, no legal protection, and fully liable**. To reduce this risk even further, we recommend protocols set their Safe Harbor bounty cap **at or below** their existing bug bounty. This way, there's no financial incentive to attempt an exploit - it's easier, safer, and more profitable to report the bug through your standard disclosure process than to fake a whitehat rescue under legal risk.
Can we modify the Safe Harbor legal contract? We strongly discourage protocols from modifying the legal language of the Safe Harbor agreement. The framework is designed as a **standard** across the industry, so whitehats can understand the rules quickly and act confidently during emergencies. That said, the agreement is built with flexibility where it matters: you define your scope - such as which contracts are covered, Asset Recovery Addresses, bounty terms, and KYC requirements. These parameters are designed to give you control without breaking the shared standard that makes Safe Harbor effective.
Should our legal team review the Safe Harbor agreement? It's optional. The agreement has already been vetted by leading law firms (Cooley, Debevoise & Plimpton, Piper Alderman) and adopted by top-tier protocols like Uniswap, Balancer, and Pendle. That said, if your legal team wants to review it for extra peace of mind, they absolutely can. Just keep in mind: the agreement is a community standard designed for consistency, so major edits aren't recommended (and usually unnecessary).
*** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Safe Harbor Scope Terms When adopting Safe Harbor, you'll define specific parameters that control what's covered and how whitehat rescues work. Below is an explanation of each term with tips and best practices. ### 1. Asset Recovery Address The address where whitehats must return rescued funds after an exploit. **Tips:** * Use a highly secure smart contract wallet (e.g., Gnosis Safe or governance-controlled address). * Ensure it can handle large inflows, potentially a significant portion of your TVL. * Please refer to [this framework on Wallet Multisig Security](/wallet-security/secure-multisig-best-practices) ### 2. Security Contact The person or team whitehats must notify after completing a rescue. **Tips:** * Provide multiple points of contact (email, Signal, Telegram) for redundancy. * Make sure these methods of notification are checked in case of an active exploit. Whitehats should reach out within 6 hours of a rescue ### 3. Assets Under Scope The on-chain contracts or accounts that whitehats can legally interact with under Safe Harbor. **Chain IDs (CAIP-2 format):** V3 uses CAIP-2 chain identifiers (e.g., `eip155:1` for Ethereum, `eip155:137` for Polygon). **Scope Options:** * **All:** Covers the listed address and all child contracts, both existing and future. * **ExistingOnly:** Covers the address and child contracts deployed before adoption. * **FutureOnly:** Covers the address and child contracts deployed after adoption. * **None:** Covers only the listed address. **Examples:** * All: Use for factories or deployer addresses that create vaults, pools, or markets. Covers all current and future instances. * None: Use for single vault contracts where funds are concentrated and no child contracts exist. * ExistingOnly / FutureOnly: Very rarely used; typically for protocols with legal or operational constraints on future contracts. **Tips:** * If your protocol deploys many contracts, include your deployer address EOA/Multisig/Governance Addresses with All. This avoids the need for updates. * Keep this list current - if you launch new deployments and they aren't covered, whitehats can't legally intervene. ### 4. Bounty Terms Defines how whitehats are rewarded for successful intervention. #### 4.1 Bounty Calculation FYI,, the formula to determine the bounty payout to the whitehats is: `bounty = min(bountyPercentage × recoveredAmount, bountyCapUSD)` Predefining this ensures no post-hack negotiation and prevents delays. #### 4.2 Bounty Percentage The percentage of recovered funds that a whitehat receives. **Recommendation:** * 10% is standard in the industry. * Set equal to your bug bounty program's critical exploit payout percentage #### 4.3 Bounty Cap (USD) The maximum bounty amount for a single whitehat, in USD. **Recommendation:** * Match or set equal to your bug bounty program's max payout to avoid incentives for malicious behavior. #### 4.4 Aggregate Bounty Cap (USD) The maximum total bounty payout across all whitehats for a single incident. Bounties will be distributed pro-rata. **Rule:** * If you set an Aggregate Bounty Cap, you must set retainable to false so all funds return to the protocol first, then bounties are distributed. #### 4.5 Retainable Whether whitehats keep their bounty directly or return everything first. * **True**: Whitehat deducts bounty before returning funds. * **False**: Whitehat returns all funds; protocol pays bounty afterward. **Rule:** * Cannot set retainable to true if Aggregate Bounty Cap is enabled. ### 5. Identity Verification Determines whether whitehats must verify their identity. **Options:** * **Anonymous**: No KYC (most crypto-native option). * **Pseudonymous**: Requires a pseudonym. * **Named**: Legal name verification (KYC required). **Tips:** * Most protocols choose Named (KYC) for compliance. * Some opt for crypto-native option of protecting the whitehat's anonymity. ### 6. Diligence Requirements Additional compliance checks for whitehats before bounty payout (applies only if identity = Named). Generic Template: ` requires all eligible whitehats to undergo Know Your Customer (KYC) verification and be screened against global sanctions lists, including US, UK, and EU regulations. This process ensures that all bounty recipients are compliant with legal and regulatory standards before qualifying for payment.` *** If you ever need help or have any questions, don't hesitate to reach out! 📬 Contact us at: [safe-harbor@securityalliance.org](mailto\:safe-harbor@securityalliance.org) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Self-Adoption Guide This guide walks you through the full process of self-adopting the SEAL Safe Harbor Agreement for your protocol. The goal is to provide whitehats with legal clarity and confidence to rescue funds when it matters most. To do this effectively, protocols should cover all public and legal bases: defining a clear scope, obtaining DAO approval (if applicable), registering on-chain, updating their terms of service, and making a public announcement. ### 1. Scope Definition The first step is defining the **scope**. This information informs whitehats about how and when they can intervene. It includes which assets are covered, where to send rescued funds, how to contact your team, what bounties apply, and any identity requirements. * Refer to the scope walkthrough: [Scope Definitions & Tips](/safe-harbor/scope-terms) * DAO Template: [DAO Scope Template](https://docs.google.com/document/d/1zsyutbSpQrwkmEA_XicABoRkSR25IQr92tOPgZOixN4/edit) * Non-DAO Template: [Non-DAO Scope Template](https://docs.google.com/document/d/1kcgeq2GmmuSHyMzbl0mlgRhMHag-av4B4TdLZFqdoSE/edit) ### 2. DAO Proposal (If applicable) If you are a DAO, this is a critical step. It formalizes permission from the community and provides legitimacy to the adoption. * DAOs do **not** need a legal entity. Safe Harbor was designed to allow on-chain communities to adopt the agreement natively. * Use the DAO Proposal draft from Step 1 where you defined the scope. Feel free to edit the proposal to reflect your DAO's tone and format. * Push your proposal through governance, temp check → formal proposal → Snapshot/Tally/etc. * (Optional) Include the **on-chain adoption call** in the proposal itself for a full end-to-end flow. ### 3. On-Chain Adoption Whether you're a DAO or a centralized team, you'll need to publish your adoption on-chain. This ensures your terms are publicly visible and enforceable. **If you are NOT doing on-chain via DAO proposal:** * Follow the guide: [SEAL Safe Harbor On-Chain Adoption](/safe-harbor/on-chain-adoption-guide) **If you ARE doing this in your DAO proposal:** * On-chain adoption involves two parts: 1. Creating the Agreement contract via the AgreementFactory (the "terms" container) 2. Registering it in the Safe Harbor Registry (this is what matters for whitehats) * The DAO proposal should handle **step 2**, while step 1 can be done beforehand by following the guide: [SEAL Safe Harbor On-Chain Adoption](/safe-harbor/on-chain-adoption-guide) (**IMPORTANT**: Be sure to set the `owner` of the agreement to your DAO address) ### 4. Update Terms of Service & Docs To ensure all users are informed and legally covered, update your Terms of Service and documentation. #### Terms of Service (TOS) Add the following language to your TOS: > User Agreement to be Bound By Agreement, Consent to Attempted Eligible Funds Rescues and Payment of Bounties > > The User hereby acknowledges and agrees to, and consents to be bound by the terms and conditions of, that certain Safe > Harbor Agreement for Whitehats, adopted by the Protocol Community on \[INSERT DATE HERE] (the "Whitehat Agreement"), > available here > [https://bafkreiernns2f4nv2uzvwtzjc2jboyivsu2mixz33y3xo7cvtllsuao6jy.ipfs.w3s.link](https://bafkreiernns2f4nv2uzvwtzjc2jboyivsu2mixz33y3xo7cvtllsuao6jy.ipfs.w3s.link), > as a "User" and member of the "Protocol Community" thereunder. Without limiting the generality of the foregoing: > > * the User hereby consents to Whitehats attempting Eligible Funds Rescues of any and all Tokens deposited into the > Protocol by the User and the deduction of Bounties out of User's deposited Tokens to compensate Eligible Whitehats for > successful Eligible Funds Rescues; > * the User acknowledges and agrees that Tokens may be lost, stolen, suffer diminished value, or become disabled or > frozen in connection with attempts at Eligible Funds Rescues, and assumes all the risk of the foregoing; > * the User acknowledges and agrees that payment of the Bounty as a deduction from User's Tokens to an Eligible > Whitehat may constitute a taxable disposition by the User of the deducted Tokens, and agrees to assume all risk of > such adverse tax treatment; and > * the User agrees to hold the other Protocol Community Members harmless from any loss, liability or other damages > suffered by the User in connection with attempted Eligible Funds Exploits under the Whitehat Agreement. This is also found in Exhibit D in the legal agreement #### Documentation Under your documentation's "Security" or "Bug Bounty" section, include: > "This protocol has adopted the SEAL Safe Harbor Agreement for Whitehats, which empowers approved security researchers > to intervene during active exploits to rescue funds. Full adoption details, scope, and bounty terms are publicly > available \[here]." Replace `[here]` with your actual registry listing or agreement address. ### 5. Announcement Once everything is live, it's time to communicate publicly. This signals to whitehats, users, and the broader ecosystem that your protocol is protected. * Use Twitter, Discord, forums, and governance portals. * Highlight your on-chain registration, bounty terms, and any DAO vote. * Example announcement: > Today, we're proud to announce that \[Protocol Name] has officially adopted the @\_seal\_org Safe Harbor Agreement - > a legal and technical framework that empowers whitehats to rescue funds during active exploits. > > This move brings us into alignment with some of the most security-forward protocols in the space - Uniswap, > Pendle, Balancer - as we take real steps to defend our community and user funds. * Feel free to coordinate with SEAL - we're happy to co-announce and amplify it. *** If your protocol ever needs help with adoption, SEAL is happy to help answer any questions, walk you through adoption, amplify announcements, etc 📬 Contact us at: [safe-harbor@securityalliance.org](mailto\:safe-harbor@securityalliance.org) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Safe Harbor Eligibility Checklist Use this checklist to evaluate whether adopting the **SEAL Whitehat Safe Harbor Agreement** makes sense for your protocol. ### Can Safe Harbor Help Your Protocol? * [ ] **Do you hold user funds in smart contracts?** Without Safe Harbor, whitehats who could save your users' funds might hesitate to act due to legal uncertainty around unauthorized access. * [ ] **Do you want whitehats to help during active attacks?** Safe Harbor gives ethical hackers legal protection to intervene immediately, before attackers can drain your protocol. * [ ] **Do you already have a bug bounty or security disclosure program?** Safe Harbor fills the critical gap your bug bounty can't cover - live attacks happening right now when disclosure timelines don't matter. * [ ] **Do you want to increase the odds of recovering funds?** Safe Harbor encourages rescue attempts by trusted whitehats. If you checked any of the above - you can benefit from adopting our Safe Harbor. ### What Does Adoption Involve? 1. Define your scope (what's covered, where funds go, bounty %, etc.) 2. (If DAO) Pass a governance proposal 3. Register on-chain 4. Update your Terms of Service and documentation 5. Make a public announcement to inform users and whitehats It's fast, flexible (DAO or non-DAO), and aligns with industry standards. ### Ready to Get Started? You have 3 ways to adopt: 1. **Self-adopt using our guide:** → [Self-Adoption Guide](/safe-harbor/self-adoption-guide) 2. **Get help from SEAL (free):** → [Apply for onboarding](https://form.typeform.com/to/QF3YjWno) 3. **Adopt via a third-party:** → Immunefi: [Immunefi Integration Form](https://docs.google.com/forms/d/e/1FAIpQLSehHw_KyNfSr9YbnO1AB3OZ4cvVS2oInIxdveCPguR9GSxZFQ/viewform) Find out more about [Safe Harbor](/safe-harbor/overview) *** If you ever need help or have any questions, don't hesitate to reach out! Contact us at: [safe-harbor@securityalliance.org](mailto\:safe-harbor@securityalliance.org) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Safe Harbor for Whitehats ### Why You Should Care {/* TODO: link not found (./key-terms.md#active-exploit)*/} Safe Harbor lets whitehats intervene during active exploits to help secure protocol funds. It does so by providing a legal framework that outlines what whitehats can and can't do, how they ought to operate, and protects abiding whitehats in the event of legal action taken by the protocol. In addition to the legal protections, Safe Harbor also helps whitehats by giving them the following information: 1. What assets are owned by a protocol {/*TODO: link not found (./key-terms.md#asset-recovery-address)*/} 2. What the protocol's asset recovery address is {/* TODO: (../security-contact.md) is this link this: /vulnerability-disclosure/security-contact ? */} 3. Who the security contact is 4. What KYC requirements (if any) protocols impose onto whitehats 5. What bounty terms whitehats will be awarded under Safe Harbor This information is all neatly cataloged in the Safe Harbor Registry {/*TODO: link not found (./key-terms.md#safe-harbor-registry)*/} - an on-chain registry cataloging all protocol adoptions and their adoption details. For more details, review the Safe Harbor for Protocols {/*TODO: link not found (./protocol.md)*/} document. It has also been compiled by Skylock at the [Safe Harbor Database](https://skylock.xyz/safeharbor/database). ### Whitehat Adoption If a whitehat reads and understands the entire legal framework, they may later be eligible to participate in a whitehat rescue. These rescues should only be taken in very specific circumstances, and it is important to reiterate the following: * The framework only applies to active exploits, and it is a violation of the agreement if the whitehat initiates an exploit themselves. * The protocol is not responsible for ensuring the whitehat follows the law, and the whitehat can not be protected from criminal charges outside the agreement's scope. * There are nuances that can affect the agreement's enforceability, and whitehats will assume many legal risks by becoming involved. * If the whitehat decides to proceed with a whitehat rescue, they must follow the process specified in the agreement. This includes transferring rescued funds to the protocol's "Asset Recovery Address" and promptly notifying the protocol of the fund recovery. The whitehat may keep (or later receive) a reward, based on the terms of the agreement. Safe Harbor may also apply to generalized frontrunner / arbitrage bots. The rules of conduct enforced by Safe Harbor for Prospective and Retrospective whitehats differ in a few key areas. ### In the Event of a Hack #### Pre-Intervention In the event of a hack targeting a protocol that has adopted Safe Harbor, whitehats are permitted to take broad actions to secure the protocol's funds. Before taking action, review the following checklist (also present in the Safe Harbor Technical Summary): * Is this an active, urgent exploit? * Are you unable to responsibly disclose the exploit (e.g. via a bug bounty program) due to time constraints or other reasons? * Can you reasonably expect your intervention to be net beneficial, reducing total losses to the protocol and associated entities? * Are you experienced and confident in your ability to manage execution risk, avoiding unintentional loss of funds? * Will you avoid intentionally profiting from the exploit in any way other than through the reward granted by the protocol? * Are you and anyone with whom you directly cooperate during the funds rescue, as well as all funds and addresses used in said rescue, free from OFAC sanctions and/or other connections to sanctioned parties? * Have you confirmed the agreement has been duly adopted by the protocol community? * Are you fully aware of the risks associated with your actions, including but not limited to accidental loss of funds, claims and liabilities outside this agreement's scope, and the unclear extent of this agreement's enforceability? In the event that all the above applies, you may choose to take action to protect the protocol's assets. How you do this depends on the situation - perhaps offensively white-hat hacking a protocol with a proven exploit, or returning funds recovered by your MEV bot from an incident it front-ran. #### Post-Intervention After the funds have been recovered, it is your responsibility to ensure their safe return to the owner protocol. We strongly recommend contacting [SEAL911](/incident-management/playbooks/seal-911-war-room-guidelines) immediately to advise on the fund recovery process and to assist with KYC, protocol communications, and bounty collection. You must also contact the protocol's posted security contact and return all recovered funds to the protocol's asset recovery address within 6 hours of the event, or 48 hours if reason is provided and the protocol has been made aware. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Data Removal Services Removing your personal data from online platforms can help protect your privacy and reduce the risk of identity theft. Here are some steps and services to help you remove your data from the internet. ### Steps to Remove Your Data 1. **Identify Where Your Data Is** * Conduct a search of your name and information on search engines to identify where your data is located. * Review your social media accounts, online forums, and public records for any personal information. 2. **Request Data Removal** * Contact websites directly to request the removal of your data. Most sites have a contact form or email for privacy concerns. * Use online tools and forms provided by search engines like Google to remove specific results. 3. **Opt-Out of Data Brokers** * Data brokers collect and sell personal information. Opt-out of their databases using their online forms. * Some common data brokers include Spokeo, Whitepages, and PeopleFinder. ### Data Removal Services 1. **DeleteMe** * A subscription service that removes your data from data brokers and online databases. * Pros: Comprehensive removal, regular monitoring. * Cons: Costly subscription model. 2. **PrivacyDuck** * Offers manual removal services from various websites and databases. * Pros: Thorough and personalized service. * Cons: Expensive, manual process. 3. **OneRep** * Automated removal service that targets over 100 data broker sites. * Pros: Automated process, extensive reach. * Cons: Subscription fee required. 4. **JustDeleteMe** * A directory of direct links to delete your account from web services. * Pros: Free, easy to use. * Cons: Requires manual effort. ### Best Practices 1. Regularly check and update the privacy settings on your online accounts. 2. Be mindful of the information you share online and with whom. 3. Use pseudonyms for accounts that don't require your real name. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Digital Footprint Your digital footprint is the trail of data you leave behind while using the internet. ### Understanding Your Digital Footprint 1. **Active Footprint** * Information you intentionally share online, such as social media posts, blog comments, and online profiles. 2. **Passive Footprint** * Information collected without your explicit consent, such as tracking cookies, IP addresses, and browsing history. ### Managing Your Digital Footprint 1. **Audit Your Online Presence** * Regularly search your name and personal information on search engines. * Review your social media profiles and privacy settings. 2. **Limit Information Sharing** * Be cautious about the personal information you share online. * Avoid sharing sensitive information such as your home address, phone number, and financial details. 3. **Use Privacy Settings** * Adjust privacy settings on social media platforms to control who can see your information. * Enable two-factor authentication for added security. 4. **Delete Unused Accounts** * Remove accounts you no longer use to minimize the amount of personal information available online. 5. **Opt-Out of Data Collection** * Use tools and browser extensions to block tracking cookies and ads. * Opt-out of data collection by data brokers and online advertisers. ### Tools for Managing Your Digital Footprint 1. **Privacy Badger** * A browser extension that blocks tracking cookies and ads. * Pros: Free, easy to use. * Cons: May block some legitimate content. 2. **Ghostery** * A browser extension that blocks trackers and enhances privacy. * Pros: Detailed tracker information, customizable. * Cons: Some features require a subscription. 3. **Deseat.me** * A tool to find and delete your old accounts. * Pros: Simple interface, effective. * Cons: Requires access to your email. ### Best Practices 1. Conduct regular audits of your online presence to identify and remove unwanted information. 2. Protect your accounts with strong, unique passwords. 3. Keep up-to-date with privacy news and updates to stay informed about new threats and tools. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Encrypted Communication Tools Encrypted communication tools are essential for maintaining privacy and security in digital communications. These tools ensure that your messages and calls are protected from eavesdropping and unauthorized access. ### Popular Encrypted Communication Tools 1. **Signal** * An encrypted messaging app that provides end-to-end encryption for messages, calls, and video chats. * Pros: Strong encryption, open source, user-friendly. * Cons: Requires a phone number for registration. 2. **WhatsApp** * A widely-used messaging app that offers end-to-end encryption for messages, calls, and media. * Pros: Easy to use, large user base, supports various media types. * Cons: Owned by Facebook, requires a phone number. 3. **Telegram** * A messaging app that offers optional end-to-end encryption through its "Secret Chats" feature. * Pros: Cloud-based, supports large groups and channels, feature-rich. * Cons: End-to-end encryption is not enabled by default, requires a phone number. 4. **Wire** * A secure messaging app that provides end-to-end encryption for messages, calls, and file sharing. * Pros: Strong encryption, open source, supports multiple devices. * Cons: Requires an email or phone number for registration. 5. **Threema** * A privacy-focused messaging app that offers end-to-end encryption for messages, calls, and media. * Pros: No phone number or email required, strong encryption, anonymous usage. * Cons: Paid app, smaller user base. ### Best Practices for Encrypted Communication 1. **Verify Contacts** * Always verify the identity of your contacts through security codes or other verification methods to ensure you are communicating with the intended person. 2. **Keep Apps Updated** * Regularly update your encrypted communication apps to ensure you have the latest security patches and features. 3. **Use Strong Passwords** * Protect your accounts with strong, unique passwords and enable two-factor authentication where possible. 4. **Be Cautious with Metadata** * Be aware that while the content of your messages may be encrypted, metadata such as timestamps and contact information may still be accessible. 5. **Educate Yourself and Others** * Stay informed about the latest security practices and educate your contacts on the importance of using encrypted communication tools. ### Additional Resources 1. **Electronic Frontier Foundation (EFF)** * Provides guides and resources on secure communication and privacy tools. 2. **PrivacyTools.io** * Offers recommendations and reviews of privacy-focused tools and services. 3. **ProtonMail Blog** * Features articles on privacy, security, and encrypted communication. By using encrypted communication tools and following best practices, you can significantly enhance the privacy and security of your digital communications. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Financial Privacy Services Maintaining financial privacy is often seen as important for people in the Web3 ecosystem, and it can help prevent personal and financial information from unauthorized access and fraud. ### Tools for Financial Privacy 1. **Cash** * Using cash for transactions can help maintain privacy by avoiding digital records. * Pros: Anonymous, widely accepted. * Cons: Not practical for online transactions, physical security risks. 2. **Prepaid Cards** * Use prepaid debit cards for purchases to avoid linking transactions to your bank account. * Pros: Anonymity, control over spending. * Cons: Fees, limited acceptance. 3. **Privacy.com** * A service that allows you to create virtual credit cards for online purchases. * Pros: Protects your real credit card information, easy to use. * Cons: Limited to US users. ### Strategies for Financial Privacy 1. **Limit Data Sharing** * Be cautious about sharing financial information online. * Use secure methods for sharing sensitive information, such as encrypted emails. 2. **Monitor Your Accounts** * Regularly review your cryptocurrency wallets, bank and credit card statements for unauthorized transactions. * Set up alerts for suspicious activity. 3. **Use Secure Connections** * Ensure that your internet connection is secure when conducting financial transactions. * Use a VPN to encrypt your internet traffic. 4. **Shred Financial Documents** * Shred any physical documents containing financial information before disposing of them. * Store important documents in a secure location. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Privacy > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Privacy](/privacy/overview) * [Secure Browsing](/privacy/secure-browsing) * [Data Removal Services](/privacy/data-removal-services) * [Managing Your Digital Footprint](/privacy/digital-footprint) * [Encrypted Communication Tools](/privacy/encrypted-communication-tools) * [Financial Privacy Services](/privacy/financial-privacy-services) * [Privacy-Focused Operating Systems](/privacy/privacy-focused-operating-systems-tools) * [VPNs](/privacy/vpns) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Privacy Privacy is a fundamental aspect of security. Protecting your personal information and your team's information from unauthorized access and exposure is crucial. This section provides guidelines and resources for maintaining privacy, managing your digital footprint, and utilizing privacy-focused tools and services. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Privacy-Focused Operating Systems and Tools Using privacy-focused operating systems and tools can significantly enhance your digital privacy. These systems and tools are designed to protect your data and minimize your digital footprint. ### Privacy-Focused Operating Systems 1. **Tails** * A live operating system that you can start on any computer from a USB stick or DVD. * Pros: Leaves no trace on the computer, comes with built-in privacy tools. * Cons: Requires a USB stick or DVD, limited software availability. 2. **Qubes OS** * An open-source operating system designed for security through isolation. * Pros: Strong isolation, supports running multiple virtual machines. * Cons: Requires fairly powerful hardware, steep learning curve. 3. **Whonix** * A security-focused operating system that runs in a virtual machine and uses Tor to anonymize internet traffic. * Pros: Strong anonymity, easy to use. * Cons: Slower internet speeds due to Tor, requires a virtual machine. ### Privacy-Focused Tools 1. **Tor Browser** * A web browser designed for anonymous browsing using the Tor network. * Pros: Strong anonymity, easy to use. * Cons: Slower browsing speeds, some websites block Tor traffic. 2. **Signal** * An encrypted messaging app for secure communication. * Pros: End-to-end encryption, open source. * Cons: Requires a phone number for registration. 3. **KeePass** * An open-source password manager for securely storing and managing passwords. * Pros: Strong encryption, no cloud storage. * Cons: Requires manual setup, less user-friendly than some alternatives. 4. **VeraCrypt** * A disk encryption software for creating secure, encrypted volumes. * Pros: Strong encryption, supports hidden volumes. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Secure Browsing Secure browsing is essential to protect your privacy and personal information while using the internet. ### Best Practices for Secure Browsing 1. **Use HTTPS** * Always use HTTPS to ensure that your connection to websites is encrypted. Look for the padlock icon in the browser address bar. * Most browsers now enforce HTTPS by default. Otherwise, use browser extensions like HTTPS Everywhere to enforce HTTPS connections. 2. **Avoid Public Wi-Fi** * Avoid using public Wi-Fi for sensitive activities. If you must use it, ensure you connect through a VPN to encrypt your internet traffic. 3. **Disable Third-Party Cookies** * Disable third-party cookies in your browser settings to prevent tracking by advertisers and other third parties. 4. **Use Private Browsing Mode** * Use private browsing mode to prevent your browser from storing your browsing history, cookies, and temporary files. 5. **Keep Your Browser Updated** * Regularly update your browser to ensure you have the latest security patches and features. ### Tools for Secure Browsing 1. **Tor Browser** * A browser designed for anonymous browsing using the Tor network. * Pros: Strong anonymity, easy to use. * Cons: Slower browsing speeds, some websites block Tor traffic. 2. **Brave Browser** * A privacy-focused browser that blocks ads and trackers by default. * Pros: Fast, blocks ads and trackers, built-in Tor support. * Cons: Limited extensions compared to other browsers. 3. **uBlock Origin** * A browser extension that blocks ads, trackers, and malware. * Pros: Highly configurable, efficient. * Cons: Requires setup for optimal use. 4. **Privacy Badger** * A browser extension that blocks tracking cookies and ads. * Pros: Easy to use, protects privacy. * Cons: May block some legitimate content. ### Secure Search Engines 1. **DuckDuckGo** * A search engine that does not track your searches or store your personal information. * Pros: Strong privacy, no tracking. * Cons: Less personalized search results. 2. **Start-page** * A search engine that uses Google’s search results but protects your privacy. * Pros: Google search results, strong privacy. * Cons: Slower than Google. ### Best Practices 1. Regularly clear your browsing history, cookies, and cache to remove any stored data. 2. Only install trusted browser extensions and regularly review their permissions. 3. Use a password manager to create and store strong, unique passwords for each website. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Attack Surfaces on Public Networks Public and open Wi-Fi networks (airports, hotels, coffee shops) introduce specific risks: ### Common Risks * **Rogue hotspot (evil twin)** — Attackers set up networks mimicking legitimate ones. Devices auto-reconnect to the stronger, attacker-controlled SSID. * **Captive-portal credential harvesting** — Login pages on captive portals ask for email, phone, or OAuth tokens that can be sold or used in phishing. * **Lateral scanning** — Open client-to-client traffic allows anyone to probe SMB, AirDrop, SSH, and other exposed services. * **Malicious updates** — Man-in-the-middle positions allow tampering with insecure update channels. * **Long-term device fingerprinting** — MAC randomization has been defeated by browser and protocol fingerprinting and stable radio attributes. ### Less Frequent Risks * **DNS spoofing / rogue DHCP** — Attackers respond to DNS or DHCP requests faster than legitimate servers, pushing a malicious resolver or gateway. * **SSL stripping / downgrade** — Intercepting HTTP-to-HTTPS redirects. Modern browsers display warnings or block this, but outdated or weakened browsers remain vulnerable. * **Session hijack / cookie theft** — Sniffed session cookies might allow attackers to replay your authenticated state. ### Unsecure Browsers and Captive Portals When connecting to a network with a captive portal, your OS fires a plain-HTTP request to a hard-coded URL. If it receives anything other than the expected response, it launches a minimal browser (mini-browser) to display the portal. These mini-browsers often lack the security features of full browsers — no extension support, limited certificate validation, and reduced script blocking. Similarly, in-app browsers (WebViews) used by social media and messaging apps can inject JavaScript, share cookies with the host app, and lack address bars for verifying origins. Both scenarios weaken the protection HTTPS normally provides. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## HTTPS vs VPN A common misconception is that HTTPS makes VPNs unnecessary. They solve different problems: * **HTTPS** encrypts the content of a single connection between your browser (or app) and a specific server. It operates at the application layer — each connection is independently wrapped. * **VPN** wraps all your device's traffic at the network layer into a single encrypted tunnel to a gateway you trust. Every app, every protocol, every DNS query goes through it. They overlap on encryption but diverge on almost everything else: | Aspect | HTTPS | VPN | | ----------------------------------- | -------------------------------------------------- | ---------------------------------------------------------- | | What is encrypted | Content of a single connection | All traffic from the device | | Who sees the destination | Your ISP, local network, anyone on path (via SNI) | Only the VPN provider | | Who sees your IP | Every server you connect to | Only the VPN provider | | DNS queries | Typically unprotected unless DoH/DoT is configured | Tunneled through the VPN (if properly configured) | | Metadata (timing, volume, patterns) | Fully visible to the local network | Hidden from the local network, visible to the VPN provider | ### The Metadata Gap Even with HTTPS everywhere, significant metadata leaks by default: #### SNI Leakage The domain name is sent in plaintext during the TLS handshake. Anyone on your local network can see that you are connecting to a specific domain, even if they cannot see the page content. Encrypted Client Hello (ECH) aims to fix this but is not yet widely deployed. #### DNS Query Exposure Unless you have explicitly configured DNS over HTTPS (DoH) or DNS over TLS (DoT), every domain you resolve is broadcast as a plain UDP packet on port 53. Your local network and ISP see every lookup. #### Traffic Analysis Packet sizes, timing, and burst patterns are often enough to infer what you are doing. Loading a video, sending a message, or browsing a specific site all have recognizable signatures. #### IP as Identity Every server you connect to over HTTPS sees your real public IP, which is tied to your ISP account, approximate location, and in many jurisdictions, your legal identity. *** If you only care about someone reading your messages, HTTPS is enough. If you care about someone knowing what you are doing — where you go, when, and how often — that is where a VPN earns its place. {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## VPNs > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [VPN Services](/privacy/vpns/overview) * [HTTPS vs VPN](/privacy/vpns/https-vs-vpn) * [Attack Surfaces on Public Networks](/privacy/vpns/attack-surfaces-public-networks) * [When to Use a VPN](/privacy/vpns/when-to-use-vpn) * [VPN Limitations](/privacy/vpns/vpn-limitations) * [VPN Providers and Tools](/privacy/vpns/vpn-providers-and-tools) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## VPN Services Virtual Private Networks (VPNs) encrypt your internet traffic and route it through a remote server, hiding your IP address from the websites you visit and shielding your activity from anyone on your local network. But a VPN is not a magic shield — it solves specific problems, and understanding those problems is essential before choosing to use one. This section covers the key aspects of VPN usage, from understanding why HTTPS alone is not enough, to evaluating providers and configuring tools that match your threat model. *** ### Subtopics * **[HTTPS vs VPN](/privacy/vpns/https-vs-vpn)** — Why HTTPS does not make VPNs unnecessary. How metadata leaks even with encrypted connections, and what a VPN actually hides. * **[Attack Surfaces on Public Networks](/privacy/vpns/attack-surfaces-public-networks)** — Specific risks on open Wi-Fi networks: rogue hotspots, captive portals, DNS spoofing, and insecure mini-browsers. * **[When to Use a VPN](/privacy/vpns/when-to-use-vpn)** — A threat-model-based decision framework. Includes how to choose a VPN service that fits your needs. * **[VPN Limitations](/privacy/vpns/vpn-limitations)** — What a VPN cannot protect you from: provider trust, DNS leaks, TunnelVision, browser fingerprinting, and endpoint compromise. * **[VPN Providers and Tools](/privacy/vpns/vpn-providers-and-tools)** — Recommended no-logs providers, plus tools organized by network, DNS, device, and browser level. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## VPN Limitations A VPN is not infallible. Consider these factors in your threat model: * **Provider can log or get raided** — If police serve a warrant or the company folds under subpoena, your traffic metadata can leak. * **DNS and IP leaks still happen** — Misconfigured clients, IPv6 routes, or split-tunnel mistakes send lookups to your ISP in the clear. * **TunnelVision and rogue-route attacks** — Can force traffic outside the tunnel if the local gateway manipulates DHCP or routes. * **Browser fingerprinting survives** — Device fonts, canvas/WebGL, and TLS quirks still identify you even with a new IP. * **Malicious or free VPN apps** — Many no-cost Android VPNs bundle adware or spyware. * **Streaming and firewalls detect and block exits** — Popular services blacklist known VPN ranges. * **Kill-switch failure reveals your real IP** — If the tunnel drops and no kill switch is active, traffic falls back to the raw internet. * **Protocol metadata** — WireGuard stores client IPs on the server for handshakes, a privacy trade-off. * **Government blocking and legality** — Some countries throttle, detect, or criminalize unapproved VPNs. * **Endpoint still vulnerable** — Malware on your laptop records keystrokes before encryption. A VPN cannot fix a compromised device. ### DNS Leaks HTTPS encrypts what you are saying, but not who you are talking to, when, how often, or how much data you are exchanging. A DNS leak occurs when your DNS queries bypass the VPN tunnel and go directly to your ISP's resolver, revealing the domains you visit. You can test for DNS leaks using tools like [dnsleaktest.com](https://dnsleaktest.com/). *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## VPN Providers and Tools ### Recommended VPN Services These providers are commonly recommended by privacy-focused communities. Evaluate each against your own threat model: 1. **MullvadVPN** — Strong privacy policy, no-logs (audited), fast speeds, WireGuard support, account-number-only registration (no email required). 2. **ProtonVPN** — Strong focus on privacy, no-logs policy, free tier available, Secure Core architecture routes traffic through privacy-friendly jurisdictions, open-source apps. 3. **IVPN** — No-logs (audited), WireGuard and OpenVPN support, account-number-only registration, privacy-first business model. > Avoid free VPNs — they often come with data caps, slower speeds, and may monetize your data or bundle malware. ### Tools and Measures Select tools that match your threat model. You do not need all of these. #### Network Level * **Portable travel router** — Devices like the GL.iNet Beryl or Slate run OpenWrt, let you force all traffic through a VPN before it leaves your pocket, and isolate your devices from untrusted networks. * **Pi-hole** — A DNS sinkhole that blocks ads and trackers at the network level. Pair it with Unbound for local recursive DNS resolution. * **Curated VPN providers** — Check [Privacy Guides](https://www.privacyguides.org/en/vpn/) recommended providers and their selection criteria. * **PiVPN or Algo** — If you do not trust any VPN provider, run your own. Algo by Trail of Bits deploys a WireGuard server on any cloud VM in minutes. #### DNS Level * **DoH or DoT** — Configure encrypted DNS at the OS level so it applies to all apps, not just your browser. * **Cloudflare WARP (1.1.1.1)** — Free app that encrypts DNS queries and device traffic through Cloudflare's network. Not a full VPN (does not anonymize or spoof location). * **Mullvad DNS** — Available at 100.64.0.2 (with ad/tracker blocking) or via their DoH endpoint. No account needed. * **AdGuard DNS** — Similar to Mullvad's offering with configurable filter lists and DoH/DoT support. Free tier available. * **NextDNS** — Granular custom blocklists with query logging (optional). Free up to 300k queries per month. #### Device Level * **Force HTTPS-Only mode** — Safari, Firefox, Chrome, and Brave all support this. Prevents accidental HTTP connections. * **iCloud Private Relay** — Apple's two-hop proxy for Safari traffic. Not a VPN, not Tor, but separates who you are from where you are going. Only works in Safari on iCloud+ plans. * **Disable WPAD** — On Windows, disable "Automatically detect settings" in proxy config. WPAD lets a local network push a proxy configuration to your machine without asking. * **Turn off auto-join for open networks** — On iOS and Android, disable the setting that auto-connects to known open SSIDs. #### Browser Level * **Tor Browser** — The only browser that truly defeats fingerprinting. Use it when anonymity matters. * **Mullvad Browser** — A fork of Tor Browser with the Tor network removed, designed to be paired with a VPN or used standalone. Trades network-level anonymity for a general-purpose privacy-hardened browser. * **Brave** — Fingerprint randomization on by default, built-in ad blocking, and optional Tor windows. * **Firefox with hardening** — Enable `privacy.resistFingerprinting`, HTTPS-Only mode, and a content blocker like uBlock Origin. #### Verification Tools * [EFF Cover Your Tracks](https://coveryourtracks.eff.org/) — Shows your browser fingerprint uniqueness. * [amiunique.org](https://amiunique.org/) — Detailed fingerprint breakdown. * [IPLeak.net](https://ipleak.net/) — Checks IP, DNS, WebRTC, and torrent IP leaks. * [BadSSL](https://badssl.com/) — Tests your browser's TLS and certificate handling. * [DNS Leak Test](https://dnsleaktest.com/) — Checks whether your DNS queries are leaking outside the VPN tunnel. ### Resources * [Are VPNs really necessary? Is HTTPS enough?](https://blog.theredguild.org/are-vpns-really-necessary-is-https-enough/): The Red Guild article on HTTPS vs VPN, metadata leakage, and threat modeling. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## When to Use a VPN Use this mental model to decide: 1. **Public Wi-Fi, low risk** — HTTPS and modern browsers already block most real attacks. A VPN is optional. 2. **Public Wi-Fi, privacy matters** — HTTPS plus encrypted DNS (DoH or DoT) is the baseline most people overlook. Add a VPN if you want to hide metadata from the local network. 3. **Hiding metadata from your network** — Add a VPN you trust, with a kill switch and no leaks. This hides destinations, DNS queries, and traffic patterns from your ISP and local network. 4. **You are a real target** — HTTPS and commercial VPNs are table stakes, not solutions. Focus on endpoint security, compartmentalization, and protocol-level privacy. The mistake is not "not using a VPN." The mistake is not knowing what you are defending against or adopting technologies without understanding why, assuming one tool solves everything. If you do not define the threat, every tool looks like protection. ### Choosing a VPN Service When selecting a VPN service, consider the following factors: 1. **No-logs policy** — Ensure the VPN provider does not store information about your online activities. Look for providers that have undergone independent audits to verify this claim. 2. **Encryption standards** — Look for VPNs that use strong encryption (AES-256-GCM or ChaCha20-Poly1305) with modern protocols like WireGuard, which typically outperforms OpenVPN. 3. **Kill switch** — A kill switch ensures your internet connection is cut off if the VPN connection drops, preventing your data from being exposed. 4. **DNS and IP leak protection** — Verify the VPN tunnels DNS queries and prevents IPv6 or WebRTC leaks. 5. **Server locations** — A wide range of server locations allows you to access content from different regions and improves connection speeds. 6. **Provider trust model** — A VPN shifts trust from your ISP to the VPN provider. Evaluate the jurisdiction, ownership structure, and track record of the provider. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Continuous Improvement & Metrics Operational security is not a static state but rather a continuous process of assessment, improvement, and adaptation. This section outlines approaches to continuously improve security practices and measure their effectiveness. ### Post-Mortem & Lessons Learned Learning from security incidents and near-misses to strengthen security posture. #### Key Components 1. **Post-Incident Analysis**: Comprehensive review of security incidents 2. **Root Cause Analysis**: Identifying underlying causes, not just symptoms 3. **Near-Miss Analysis**: Learning from events that could have led to incidents 4. **Control Effectiveness Review**: Assessing how well existing controls performed 5. **Improvement Identification**: Determining specific changes needed #### Implementation Steps 1. Conduct post-mortem analysis for all significant security incidents 2. Involve relevant stakeholders in the analysis process 3. Focus on systemic issues rather than individual blame 4. Document findings and recommendations 5. Develop action plans for implementing improvements 6. Follow up to ensure changes are implemented effectively #### Web3-Specific Considerations 1. **Smart Contract Post-Mortems**: Analyzing exploits and vulnerabilities 2. **Protocol Upgrade Assessments**: Learning from upgrade successes and failures 3. **Community Involvement**: Balancing transparency with security in post-mortems 4. **Cross-Project Learning**: Applying lessons from incidents in other projects 5. **Technical Debt Management**: Addressing security-related technical debt ### Security KPIs & Reporting Measuring security effectiveness through key performance indicators (KPIs) and regular reporting. #### Key Security Metrics 1. **Time to Detect**: How quickly incidents are identified 2. **Time to Respond**: How quickly incidents are addressed 3. **Mean Time to Recovery**: Average time to restore normal operations 4. **Security Control Coverage**: Percentage of systems with appropriate controls 5. **Vulnerability Management**: Time to patch known vulnerabilities 6. **Training Compliance**: Percentage of team members completing security training 7. **Security Incidents**: Number and severity of security events 8. **Security Debt**: Backlog of security issues requiring remediation #### Implementation Steps 1. Identify the most relevant metrics for your organization 2. Establish baseline measurements for each metric 3. Define targets and thresholds for improvement 4. Implement processes for regular data collection 5. Develop reporting formats for different stakeholders 6. Review and refine metrics periodically to ensure relevance #### Web3-Specific Metrics 1. **Smart Contract Audit Coverage**: Percentage of code reviewed by auditors 2. **Key Management Compliance**: Adherence to key management procedures 3. **Blockchain Security Monitoring**: Coverage and effectiveness of monitoring 4. **Security Bounty Program Metrics**: Submissions, time to fix, reward efficiency 5. **Governance Participation**: Engagement in security-related governance decisions ### Continuous Assessment Regularly evaluating security practices and controls to identify improvement opportunities. #### Assessment Types 1. **Self-Assessment**: Internal review of security controls and practices 2. **Peer Review**: Review by colleagues from other teams or functions 3. **External Assessment**: Evaluation by third-party security experts 4. **Red Team Exercises**: Simulated attacks to test security controls 5. **Compliance Audits**: Formal evaluation against standards or regulations #### Implementation Steps 1. Develop an assessment schedule covering different types of evaluations 2. Establish clear assessment criteria and methodologies 3. Ensure assessments cover both technical and procedural controls 4. Document assessment findings and recommendations 5. Develop and implement remediation plans 6. Follow up to verify that improvements have been made #### Web3-Specific Assessments 1. **Smart Contract Audits**: Regular review of contract code 2. **Blockchain Security Assessment**: Evaluation of blockchain-specific risks 3. **Cryptographic Implementation Review**: Specialized assessment of cryptography 4. **Decentralized Governance Assessment**: Evaluation of governance security 5. **Cross-Chain Security Review**: Assessment of risks across multiple blockchains ### Security Program Maturity Evaluating and advancing the maturity of the overall security program. #### Maturity Models 1. **Initial**: Ad-hoc security practices with limited formalization 2. **Developing**: Basic security controls with some standardization 3. **Defined**: Documented security policies and procedures 4. **Managed**: Security metrics and continuous improvement processes 5. **Optimizing**: Proactive security measures with automation and integration #### Implementation Steps 1. Assess current security program maturity 2. Identify gaps and improvement opportunities 3. Develop a roadmap for advancing maturity levels 4. Implement changes in prioritized, manageable increments 5. Regularly reassess maturity and adjust improvement plans #### Web3-Specific Maturity Considerations 1. **Blockchain Security Integration**: How well blockchain security is integrated 2. **Smart Contract Security Maturity**: Sophistication of contract security practices 3. **Decentralized Security Governance**: Maturity of security governance in DAOs 4. **Cross-Chain Security Maturity**: Sophistication of cross-chain security measures 5. **DeFi-Specific Security Maturity**: Advanced security for decentralized finance ### Building a Security-Conscious Culture Fostering an organizational culture that values and prioritizes security. #### Key Components 1. **Leadership Support**: Visible commitment to security from leadership 2. **Clear Expectations**: Defined security responsibilities for all roles 3. **Positive Reinforcement**: Recognition for good security practices 4. **Continuous Learning**: Ongoing security education and awareness 5. **Open Communication**: Encouraging reporting of security concerns #### Implementation Steps 1. Secure visible support from organizational leadership 2. Integrate security into organizational values and principles 3. Implement recognition programs for security contributions 4. Provide regular security updates and awareness materials 5. Create safe channels for reporting security concerns 6. Lead by example through leadership security practices #### Web3-Specific Cultural Considerations 1. **Balancing Transparency and Security**: Finding the right balance in open communities 2. **Security in Decentralized Teams**: Building security culture across distributed teams 3. **Community Security Engagement**: Involving the wider community in security efforts 4. **Security-Conscious Development Culture**: Integrating security into development practices 5. **Responsible Disclosure Culture**: Fostering appropriate vulnerability disclosure Continuous improvement in security requires a systematic approach to learning, measuring, and adapting. By implementing robust metrics, assessment processes, and a culture of security awareness, organizations can evolve their security practices to address emerging threats and changing environments. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Opsec > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Operational Security](/opsec/overview) * [Secure Operating Systems](/opsec/secure-operating-systems) * [Security Improvement Metrics](/opsec/continuous-improvement-metrics) * [Appendices](/opsec/appendices) * [Browser](/opsec/browser) * [Control Domains](/opsec/control-domains) * [Core Concepts](/opsec/core-concepts) * [Endpoint](/opsec/endpoint) * [Google](/opsec/google) * [Integration](/opsec/integration) * [Mfa](/opsec/mfa) * [Passwords](/opsec/passwords) * [Travel](/opsec/travel) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Operational Security Operational Security (OpSec) is a systematic approach to identifying critical information, determining threats to that information, analyzing vulnerabilities, assessing risks, and implementing countermeasures to protect sensitive data and operations. This framework provides comprehensive guidance for implementing effective operational security practices in Web2 and Web3 environments. ### Core Components This framework is organized into several interconnected components: 1. OpSec Core Concepts: * [Security Fundamentals](/opsec/core-concepts/security-fundamentals) – Core principles that form the foundation of effective operational security * [Operational Implementation Process](/opsec/core-concepts/implementation-process) – Step-by-step actions for applying operational security in practice * [Web3 Considerations](/opsec/core-concepts/web3-considerations) – Unique challenges and security practices for decentralized environments 2. [Endpoint Security](/opsec/endpoint/overview): Securing Workstations 3. [Browser Security](/opsec/browser/overview): Browsing Safely 4. [Multi-Factor Authentication](/opsec/mfa/overview): Hardening Authentication 5. [Password Management](/opsec/passwords/overview): Password Robustness 6. [Google Workspace Security](/opsec/google/overview): Google Workspace Hardening 7. [Control Domains Overview](/opsec/control-domains/overview): Key areas requiring specific security controls and practices 8. [Continuous Improvement Overview](/opsec/continuous-improvement-metrics): Learning from incidents and evolving security practices 9. [Integration & Mapping to Other Frameworks](/opsec/integration): Integrate OpSec with other security domains and frameworks ### Additional contents * [While Traveling](/opsec/travel/overview) * [TL;DR](/opsec/travel/tldr) * [Guide](/opsec/travel/guide) * [Appendices](/opsec/appendices) ### What is Operational Security? Operational Security is a systematic process that: 1. Maps and secures critical information and assets 2. Identifies and analyzes relevant threats 3. Discovers and addresses exploitable vulnerabilities 4. Evaluates risks in a business context 5. Deploys targeted controls to mitigate identified risks The goal is to prevent unauthorized access to systems and information that, if compromised, could lead to operational, financial, or reputational harm. To achieve this, modern Operational Security frameworks should adopt zero trust security model, which assumes no user, or device is inherently trustworthy. Instead, every access request must be explicitly verified, regardless of origin or credentials. ### Security Fundamentals The following fundamentals form the foundation of effective operational security: * **Layered Protection**: Implementing multiple overlapping security controls so that if one mechanism fails, others will continue to protect your assets. * **Minimal Access Scopes**: Granting users, systems, and processes only the specific permissions they need to perform their required functions and nothing more. * **Information Flow Control**: Ensuring sensitive information is only accessible to those with a legitimate need to know, with restrictions on how that information can be shared and used. * **System Isolation**: Segmenting systems and networks into isolated zones to contain security breaches and limit lateral movement. * **Continuous Visibility**: Maintaining ongoing awareness of your security posture through active monitoring, testing, and continuous improvement. Check the [Security Fundamentals](/opsec/core-concepts/security-fundamentals) for practical application guidance. ### Operational Implementation Process 1. **Critical Asset Identification**: Map and document the assets that would cause significant harm to your organization if compromised. 2. **Practical Threat Analysis**: Identify specific, relevant threat actors and their tactics based on your organization's profile. 3. **Actionable Vulnerability Assessment**: Systematically identify and validate weaknesses in your environment through practical testing. 4. **Contextual Risk Evaluation**: Analyze identified risks in the context of your business to drive informed decision-making. 5. **Targeted Control Deployment**: Implement security controls that address prioritized risks while minimizing operational friction. Check out the [Operational Implementation Process](/opsec/core-concepts/implementation-process) for detailed implementation actions. ### Web3-Specific Considerations In Web3 environments, operational security must address unique challenges: * **Transparency vs. Privacy**: Balancing blockchain transparency with the need for operational secrecy * **Decentralized Operations**: Securing operations across distributed teams and systems * **Cryptocurrency Security**: Protecting digital assets and private keys * **Smart Contract Vulnerabilities**: Addressing the immutable nature of deployed code * **Community Dynamics**: Managing security in open, community-driven projects Check out [Web3 considerations](/opsec/core-concepts/web3-considerations) for more details on these topics. ### Using This Framework Organizations should adapt this framework to their specific needs, considering their size, resources, and risk profile. Start with the fundamentals and gradually implement more advanced controls as your security program matures. The guidance provided here is designed to be practical and actionable, with specific recommendations that can be implemented by Web3 teams of all sizes. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Secure Operating Systems > 🔑 **Key Takeaway:** Use compartmentalized operating systems to isolate sensitive operations from everyday > browsing. Qubes OS for desktop, GrapheneOS for mobile, Tails for ephemeral sessions. Infostealer malware is among the most common initial access vectors in Web3 compromises. A single infected machine can exfiltrate browser sessions, wallet keys, SSH credentials, and authentication tokens in seconds. Standard operating systems such as Windows, macOS, and mainstream Linux distributions provide meaningful security controls, but they usually offer less compartmentalization by default than systems designed around strong isolation. In practice, a compromised app or user session can still expose a wide range of credentials, tokens, and sensitive workflows if those activities share the same device and user environment. Secure operating systems address this through **isolation**: sensitive operations run in separate compartments that cannot see each other, so a compromised browser cannot reach your wallet or signing keys. ### When to Use a Secure OS No single operating system is correct for every role. Match the setup to the user's exposure: signing, development, incident response, mobile approval, travel, or general staff work. | Role | Recommended setup | Why | | -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Treasury signers / high-value key holders | **Dedicated signing machine** (preferred), or **Qubes OS** with a dedicated signing qube and strict workflow separation | These users need the strongest isolation from browsing, chat, email, and development activity. Their setup should minimize exposure, reduce key-material crossover, and make compromise of one activity less likely to endanger signing operations. | | Developers with production or deployment access | **Qubes OS**, or a **hardened, managed macOS/Linux workstation** with strong browser/app separation | These users routinely touch untrusted code, dependencies, links, and developer tooling. Their risk is less about storing seed phrases and more about preventing a compromised dev workflow from reaching credentials, sessions, deploy keys, or privileged infrastructure. | | Security engineers / incident responders | **Clean managed workstation** or **Qubes OS** for primary response; **Tails** as a supplemental clean environment for emergency access, threat research, or communications | Incident response needs evidence preservation, reliable tooling, and clean operator workflows. Tails can help for ephemeral access and clean communications, but it is not a substitute for a controlled forensic or response workstation. | | Mobile wallet users / executives who approve from phones | **GrapheneOS on a dedicated Pixel device** for sensitive mobile operations | Mobile users face high phishing and app-abuse risk. GrapheneOS improves isolation, hardening, and exploit resistance, especially when the device is separated from day-to-day personal use. | | General team members | **Hardened, managed macOS/Linux/Windows device** with endpoint protection, least privilege, and browser hygiene | Most staff do not need exotic operating systems, but they do need a baseline that resists common infostealers, malicious browser extensions, session theft, and credential abuse. | | Contractors / short-term contributors | **Managed workspace or VDI** when possible; otherwise a **restricted, hardened standard OS setup** with scoped access | The main control here is limiting blast radius. Short-term contributors usually benefit more from strong access boundaries and managed work environments than from being told to adopt a specialized OS. | | Travel / high-risk travel contexts | **Dedicated travel device**; optionally **Tails on hardware you control and trust** for clean, low-persistence sessions | Travel risk is as much about physical access, coercion, and device seizure as malware. A reduced-trust travel setup is useful, but Tails does not make borrowed or potentially tampered hardware safe. | | Anonymous research / sensitive browsing | **Tails** or another dedicated low-persistence environment on trusted hardware | This is where Tails fits best: short-lived sessions, low persistence, and network privacy — not as a universal replacement for a primary secure workstation. | ### Desktop: Qubes OS [Qubes OS](https://www.qubes-os.org/) is a security-focused operating system built around strong compartmentalization. It runs different activities in isolated virtual machines ("qubes"), allowing teams to separate browsing, communications, development, and sensitive operations on the same device. Qubes is best suited for high-risk desktop users who benefit from strong workflow separation, such as treasury signers, developers with privileged access, and security-sensitive operators. Its main advantage is not just "being more secure" in the abstract, but reducing the chance that a compromise in one activity can immediately spread into another. #### Why It Matters for Web3 * **Wallet isolation**: Run your hardware wallet interface in a dedicated qube with no network access. Even if your browser qube is compromised, the attacker cannot reach your signing environment. * **Infostealer containment**: Malware in your browsing qube cannot access files, credentials, or clipboard contents in other qubes. * **DPRK threat model**: North Korean threat actors target Web3 developers with trojanized packages and fake job offers. Qubes prevents lateral movement from a compromised development environment to signing infrastructure. #### Recommended Qube Layout for Web3 Teams | Qube | Purpose | Network | Notes | | ----------- | --------------------------------- | ------------------ | ------------------------------------ | | `vault` | GPG keys, passwords, seed backups | None | Air-gapped, no network ever | | `signing` | Hardware wallet interface | None or restricted | Only connects to hardware wallet USB | | `work` | Email, Slack, general browsing | Firewalled | Standard daily driver | | `dev` | Code, git, IDE | Firewalled | Isolated from signing | | `untrusted` | Clicking unknown links, testing | Disposable | Destroyed after use | #### Getting Started 1. Check [hardware compatibility](https://www.qubes-os.org/doc/system-requirements/) — Qubes requires VT-x/VT-d and at least 6GB RAM (16GB recommended for comfortable multi-qube usage) 2. Download from [qubes-os.org](https://www.qubes-os.org/downloads/) and verify the signature 3. Install on a dedicated machine (not a VM) 4. Create qubes following the layout above, adjusting to your workflow #### Limitations * **Hardware requirements**: Needs a powerful machine with Intel VT-d support. Not all laptops are compatible. * **Learning curve**: Managing multiple qubes takes practice. Budget a week for initial setup and adaptation. * **Performance**: Running multiple VMs uses more resources than a standard OS. * **No macOS/Windows apps**: Qubes runs Linux and Windows VMs, but macOS applications are not available. ### Mobile: GrapheneOS [GrapheneOS](https://grapheneos.org/) is a hardened Android OS for Google Pixel devices. It provides strong sandboxing and exploit mitigations while maintaining Android app compatibility. #### Why It Matters for Web3 * **App sandboxing**: Each app runs in a hardened sandbox. A malicious app cannot access other apps' data, clipboard, or files without explicit permission. * **Verified boot**: Cryptographic verification ensures the OS has not been tampered with — detectable via remote attestation. * **Reduced attack surface**: Disables NFC, Bluetooth, and USB data transfer when locked. Native debugging is disabled for all apps. * **User profiles**: Create separate profiles for personal use and crypto operations. Each profile has its own isolated app data and encryption keys. #### Setup Recommendations * [ ] Use a **dedicated Pixel device** for crypto operations (not your daily phone) * [ ] Create a **separate user profile** for wallet apps — keep it isolated from messaging and browsing * [ ] **Disable network access** for wallet apps that don't need it (GrapheneOS supports per-app network toggles) * [ ] Enable **auto-reboot** after a period of inactivity to clear RAM * [ ] Use a **strong alphanumeric passcode**, not a PIN or pattern * [ ] Keep the device updated — GrapheneOS ships security patches within days of upstream releases #### Limitations * **Pixel-only**: GrapheneOS only supports Google Pixel devices (Pixel 4a and newer; Pixel 6+ recommended for Titan M2 hardware security). * **No Google Play Services by default**: Sandboxed Google Play is available as an option, but some apps may not work without it. ### Ephemeral Sessions: Tails [Tails](https://tails.net/) is a live operating system that boots from a USB drive, routes traffic through Tor, and minimizes local persistence by default. Its main value is providing a clean, low-persistence software environment for short-lived sessions. Tails is best used for clean emergency access, anonymous research, high-risk travel on hardware you control, or limited recovery workflows where reducing persistence matters. It is not a substitute for a primary secure workstation, and it does not make untrusted or potentially tampered hardware safe. #### When to Use Tails Tails is useful when you need a clean, ephemeral software environment on hardware you already control or reasonably trust. It does not make untrusted or potentially tampered hardware safe. * **Clean emergency access**: Accessing communications or recovery resources from a known-clean ephemeral environment * **Travel**: Reducing persistence and local data exposure on a device you control for high-risk travel * **Anonymous research**: Investigating threats or active incidents without tying activity to your normal identity * **Compromise recovery support**: Performing limited triage or coordination from a fresh environment while a primary workstation is treated as untrusted #### Key Properties * **Amnesia**: All state is lost on shutdown (unless you explicitly configure persistent storage) * **Tor by default**: All network traffic is routed through Tor * **No installation**: Boots entirely from USB — the host machine's disk is never touched #### Limitations * **Not for daily use**: The amnesia property means you lose everything on reboot. * **Tor performance**: Network connections are slower due to Tor routing. * **Limited hardware support**: Some Wi-Fi adapters and GPUs may not work. * **Not a substitute for Qubes**: Tails provides ephemeral isolation, not persistent compartmentalization. ### Decision Matrix | Factor | Qubes OS | GrapheneOS | Tails | Hardened standard OS | | ------------------------------------ | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | **Platform** | Desktop / laptop | Mobile (Pixel only) | USB-booted live desktop session | macOS, Linux, or Windows | | **Primary security model** | Strong compartmentalization through isolated qubes / VMs | Hardened mobile OS with strong app sandboxing and exploit mitigations | Ephemeral, low-persistence session with Tor-by-default | General-purpose OS with hardening, least privilege, and endpoint controls | | **Persistence** | Yes | Yes | No by default | Yes | | **Best fit** | High-risk desktop users: signers, sensitive developers, security-heavy roles | Dedicated mobile wallet / approval device | Clean emergency access, anonymous research, limited recovery workflows | Most staff, day-to-day work, lower-friction secure baseline | | **Main strength** | Strong separation between browsing, communications, development, and sensitive workflows | Best practical hardened mobile option with strong isolation | Leaves little local trace and starts from a clean software state each session | Most usable and operationally realistic for teams at scale | | **Main weakness** | Hardware compatibility, learning curve, and operational overhead | Pixel-only, mobile-only, not a desktop replacement | Does not make untrusted hardware safe; poor fit for persistent work | Weaker isolation by default; compromise of one user environment can expose more of the workflow | | **Use as a daily driver?** | Yes, for users willing to accept the learning curve | Yes, on a dedicated or carefully separated device | No | Yes | | **Good for key management?** | Good, especially with dedicated signing qubes and strict workflow separation | Limited; better for mobile approvals than primary key custody | Only for narrow recovery / emergency use, not primary key operations | Only with strong procedural separation; not ideal for highest-risk signing roles | | **Good for incident response?** | Good as a controlled response workstation | Limited | Useful as a supplemental clean environment for comms / triage / emergency access | Good if centrally managed and kept clean, but less isolated | | **Hardware / ecosystem constraints** | Requires compatible hardware and enough RAM | Requires supported Pixel device | Requires USB boot and hardware you control or trust | Works with standard enterprise/device fleets | | **Operational burden** | High | Medium | Medium for occasional use, high if overused | Low to medium | | **Recommended users** | Treasury custodians, signers, high-risk developers, security leads | Executives or operators approving actions from mobile, dedicated mobile wallet users | Incident support, high-risk travel, sensitive research | General team members, contractors with scoped access, most business roles | ### Hardening Standard Operating Systems For most teams, the right baseline is not a specialized operating system but a well-managed standard one. A hardened macOS, Linux, or Windows device with full-disk encryption, timely patching, least privilege, endpoint protection, and strong browser hygiene is a practical and effective default for day-to-day work. This setup does not provide the same compartmentalization as Qubes OS or the same low-persistence properties as Tails, but it is usually the most scalable and supportable option for general staff, lower-risk roles, and organizations that need consistent fleet management. The options below solve different problems: Qubes focuses on desktop compartmentalization, GrapheneOS on hardened mobile usage, Tails on clean low-persistence sessions, and hardened standard operating systems on practical day-to-day security at team scale. #### macOS * [ ] Enable [FileVault](https://support.apple.com/guide/mac-help/protect-data-on-your-mac-with-filevault-mh11785/mac) full-disk encryption * [ ] Enable the built-in firewall (System Settings > Network > Firewall) * [ ] Keep macOS and all applications updated * [ ] Use a non-admin account for daily work * [ ] Disable automatic login and require password on wake * [ ] Review and restrict app permissions (Full Disk Access, Accessibility, Input Monitoring) #### Linux * [ ] Enable full-disk encryption (LUKS) at install time * [ ] Use a distribution with timely security updates (Fedora, Debian Stable, Ubuntu LTS) * [ ] Enable a firewall (`ufw` or `firewalld`) * [ ] Use [Firejail](https://firejail.wordpress.com/) or Flatpak sandboxing for browser and untrusted applications * [ ] Disable SSH password authentication — use key-based only * [ ] Consider [Kicksecure](https://www.kicksecure.com/) as a hardened Debian derivative #### Windows * [ ] Enable BitLocker full-disk encryption * [ ] Keep Windows and drivers fully updated * [ ] Use Microsoft Defender with tamper protection enabled * [ ] Use a standard user account for daily work * [ ] Disable or restrict unnecessary remote access services * [ ] Review browser extensions and installed applications regularly ### Further Reading > **Note:** For a general overview of privacy-focused operating systems and tools (including Whonix, > Tor Browser, VeraCrypt), see > [Privacy-Focused Operating Systems and Tools](/privacy/privacy-focused-operating-systems-tools). > This page focuses on Web3-specific threat models and deployment configurations. * [Qubes OS Documentation](https://www.qubes-os.org/doc/) * [GrapheneOS Features](https://grapheneos.org/features) * [Tails Documentation](https://tails.net/doc/) * [NIST SP 800-123: Guide to General Server Security](https://csrc.nist.gov/pubs/sp/800/123/final) (OS hardening reference) * [DPRK IT Workers](/dprk-it-workers/overview) — Threat context for why OS isolation matters in Web3 import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Personal security travel guide — full Travel introduces unique security risks to your digital assets and sensitive information. Proper preparation before, vigilance during, and careful review after travel creates a comprehensive defense strategy that balances security with practical usability. When we travel, our normal security routines are disrupted, and we face elevated risks from physical theft, digital surveillance, border inspections, and social engineering. Web3 professionals face additional challenges when traveling with crypto assets or access to treasury funds. The resources in this guide provide practical guidance for maintaining operational security while traveling. > 🔑 Key Takeaway: Minimize data exposure by carrying only essential devices with full-disk encryption and updated > software. Secure accounts with backup 2FA methods, avoid biometrics at borders, use trusted networks with VPNs, and > never leave devices unattended. Guard against USB attacks, shoulder surfing, and hidden cameras. For crypto, use > strong passphrases and never travel with seed phrases. Upon returning, scan devices for malware and consider resetting > high-risk devices. {/* separator */} > ❗ This is not, by any means, an extensive guide on this subject or expected to be followed at its core. Its intention > is to guide and provide hints as to where to apply security. This will vary depending on case to case, or, in other > words, the risks you expose yourself to, by specifically traveling. This guide is categorized into four sections: 1. **Before traveling:** All the things you could do before you depart, such as hardening some devices or making sure you have a backup of the data you’ll be traveling with, even letting know someone you’ll be calling in case of an emergency and how to identify you. This does not necessarily mean that if you’re reading this while traveling you cannot do anything from that list, only that it might be more challenging to execute depending on your context. 2. **While traveling:** All the things you have to pay attention to or take care of while on the move. Is it necessary to connect to that conference’s Wi-Fi? Have you checked if there is a camera that might be recording your keystrokes? Leaving your computer unattended or just running whatever software your hackathon teammate asks you to download in order for your promising project to win. 3. **Returning home:** Not in the literal sense of it, but directed toward all the things you have to do after your travels. From updating your processes based on experience to wiping exposed devices before rejoining them to your networks. 4. **Additional information for high-profile targets:** If you are a high-profile target, you’ll evidently realize that some of these initial suggestions fall short within your threat model. This section provides a hint toward profiles like yours. ### Before traveling > 💡**Remove or securely store** any data, devices, printed files, and documents **you don’t absolutely need on the > trip**. The less sensitive information and fewer critical assets you carry, the lower the risk and impact if loss, > theft, or inspection occurs. Minimize your digital and physical footprint by leaving backups and originals securely at > home or in trusted locations, and encrypt what must travel with you. This principle applies to laptops, phones, > hardware wallets, paper backups, and any portable storage media. #### **Perform a quick threat model** Even if you are already traveling, take 5 minutes to map out your risks. Identify **what assets** you're carrying (laptops, phones, hardware wallets, seed phrases, account access), **who might target them** (thieves, cybercriminals, border agents, etc.), and **how attacks might happen** (device theft, tampering, malware, coercion). For each threat, plan a mitigation. For example, if you're carrying a hardware wallet, a threat is pickpocketing – mitigation could be keeping it attached to yourself (just don't use Ledger's necklace visibly) and securing it with a secure PIN/passphrase (no patterns, not repeated across devices). This exercise keeps security measures proportionate to your situation. #### **Secure devices with encryption & updates** Enable full-disk encryption on all devices (laptops, phones, tablets) to protect data if lost or stolen. Most modern OSes have this by default (e.g. BitLocker for Windows, FileVault for MacOS, LUKS for Linux, or Android/iOS encryption – just ensure a strong password/PIN is set). Use popular devices like iPhones and Pixels. Install the latest OS and app updates since these patch security vulnerabilities. This does not mean that using the latest versions is the safest take, but usually there's a balanced trade-off when they got security patches. You can also consider to install — only trustworthy — mobile security applications, which try to add a layer of control and also reminds you of important security updates. **Note:** On iOS, due to sandboxing, apps can't scan the entire OS for malware, so many security apps focus on VPN, phishing web protection, breach alerts, etc. If you must bring high-risk confidential data, consider encrypting those files individually using tools like VeraCrypt, FileVault, BitLocker, LUKS/dm-crypt, and more. #### **Back up and prepare for loss** Back up your devices before travel (and ensure cloud backups like iCloud/Google are up to date). This way, if a device is lost or confiscated, you won’t lose important information. Record device details (make, model, serial numbers, IMEI for phones) and keep that list separate – it will help in filing reports or remote-wipe commands. If your company uses Mobile Device Management (MDM) on phones or laptops, verify the device is enrolled and you know how to trigger a remote wipe or “lost mode.” Test “Find My” or equivalent device-finding services so you can use them if needed. Pack chargers and cables so you won’t need to borrow unknown ones (which could be malicious). #### **Protect Accounts with 2FA redundancy** Plan for how you'll access accounts that use two-factor authentication if your main device is unavailable. For authenticator apps (TOTP codes), **export backup codes** for your important accounts and keep them **securely** in services like 1Password or NordPass (you can check passwordmanager.com for more information on which one to pick). Alternatively, consider storing them elsewhere physically. If your 2FA is tied to a phone number (SMS or voice), **disable SMS for 2FA**. For technologies that are unfortunately dependent on phone numbers, use a separate line (not your personal one) from services like Google Voice, Burner App or SLYFONE. Transfer your number to an eSIM since [they are harder to physically steal or swap than a physical SIM](https://support.apple.com/en-ca/118227#:~\:text=Use%20eSIM%20while%20traveling%20internationally,obtain%2C%20carry%2C%20and%20swap). Ensure your password manager is accessible – many like 1Password have a *Travel Mode* that removes sensitive vaults from your device while you travel (you can restore them later). This limits exposure if your [device is searched or seized](https://www.schneier.com/blog/archives/2025/04/cell-phone-opsec-for-border-crossings.html). You can also register a backup or alternative 2FA method, like a secondary phone (the device) or a PIN-protected hardware key to be used as a passkey. Be responsible with the use of software passkeys, particularly in situations where you are using a password manager to store both your passwords and passkeys, as this creates a single point of failure. #### **Secure your wallets and keys** **Hardware wallets (e.g. Ledger, Trezor):** Update the firmware and test the device before you leave, don't do this while traveling. **Do NOT bring any written seed phrases** under any circumstance – seed backups are unencrypted keys that are far easier to steal or copy than a hardware device. Leave seed backups in a secure place, travel only with your hardware wallet if necessary. Enable all security features on the device (set a strong PIN, and use a BIP39 passphrase for example, if supported) so that even if the device is stolen, the amount of required information to access your crypto, is high. Carry hardware wallets and security keys **in your carry-on or under your sight**, not in checked luggage, to avoid loss or tampering. **Yubikeys and 2FA tokens:** Bring them to protect logins and make sure they're enabled on your critical accounts. Keep them on your person or in a separate bag from your laptop/phone so that a thief or snoop can't easily steal both at once. If you have a **spare hardware wallet or Yubikey**, you might leave one at home as a backup in case the one you carry is lost. Add, when possible, an extra layer of security to the token, such as a PIN code. #### **Lock down phones** On your smartphone, take advantage of security settings **before** you travel. Set a strong passcode (not just a 4-digit PIN or pattern). Consider **disabling Touch ID/Face ID** if you might face situations where someone could force-unlock your device using your biometrics – in many jurisdictions, authorities can compel a fingerprint or face scan more easily than a memorized password [.](https://www.schneier.com/blog/archives/2025/04/cell-phone-opsec-for-border-crossings.html#:~\:text=deactivate%20biometric%20security%20and%20require,10%20failed%20PIN%20unlock%20attempts) At a minimum, know how to quickly and [**temporarily disable biometrics**](https://news.ycombinator.com/item?id=43630624); for example, on an iPhone, [holding the side button and a volume button will trigger an emergency mode that requires the passcode to unlock](https://www.themacguys.com/essential-travel-security-tips-for-apple-devices/). On Android, use *Lockdown* mode if available (which only temporarily disables biometrics and is different from iOS Lockdown Mode). If you have an iPhone, enable **Lockdown Mode** (extreme protection on iOS) even if you are not at [high risk or traveling to a high-threat region](https://www.themacguys.com/essential-travel-security-tips-for-apple-devices/#:~\:text=This%20mode%20is%20ideal%20when,or%20dealing%20with%20sensitive%20data) – but be aware [it restricts many features](https://support.apple.com/en-gb/105120), though totally worth it. Disabling or restricting USB debugging on Android and using iOS USB restricted mode helps prevent unauthorized physical USB access and reduces risks from malicious cables or compromised charging stations. If your phone is managed by work (MDM), inform your IT team of your travel so they can assist with any location-based security policies and ensure you have the latest security profile. Finally, consider using a **dedicated eSIM/local SIM** for travel data. This can protect your primary phone number (you can keep your main line on eSIM and turn it off, while using a local data eSIM for mobile internet) and avoids physical SIM issues. **Configure additional phone protections:** On iOS devices, disable Control Center and Notification Center access from the lock screen (Settings > Face ID & Passcode) to prevent thieves from seeing notifications or enabling Airplane Mode without unlocking. Disable USB accessory connections when locked to prevent unauthorized connections. For device recovery, ensure Find My iPhone is enabled with "Send Last Location" and "Find Network" options activated so tracking continues even if the device is powered off. On Android, similar protections can be configured: disable notifications on lock screen (Settings > Notifications > On lock screen > Don't show notifications), and enable "Find My Device" with all location services. **Pay special attention apps security**: many financial apps default to PIN verification instead of biometrics, which means a thief who has your phone and knows your PIN could potentially access your financial accounts even if they can't bypass Face ID/Touch ID. Use unique PINs for banking apps that differ from your device PIN, or where possible, configure these apps to require biometric verification for every login. #### **Minimize digital footprint & social visibility** It's not just cyber threats – **operational security** matters. **Avoid announcing your travel plans publicly** [on social media](https://blackcloak.io/social-media-and-travel-be-careful-of-what-you-share/) and be careful with real-time updates. Posts about being away from home can signal to criminals that you (and possibly valuable devices or even your house) are vulnerable. Consider sharing trip photos and crypto conference highlights **after** you return or only with trusted contacts. Ensure your social media privacy settings are tightened so strangers can't see your travel posts. When registering for events, use privacy-focused tools like iOS's **Hide My Email** or create burner emails through providers like Tuta. ProtonMail has had some controversy lately, but could still be a good alternative. If you don't need to keep the inbox at all, just create a throwaway mail, there are plenty of options out there. Avoid giving out personal details unnecessarily during registration—use minimal, generic info to reduce your digital footprint. **Discretion** is key: if possible, [don't advertise that you work in crypto](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~\:text=,or%20clothing%20with%20bitcoin%20logos) or carry cryptocurrency. For example, **remove or cover any crypto stickers on laptops or bags**, and avoid wearing company swag or Bitcoin/Ethereum logos while in transit. These can be neon signs attracting thieves or unwanted attention ("I have valuable data or wallets!"). If asked about your work or luggage by curious strangers, have a **cover story** (e.g. "I work in finance/IT") rather than "I manage a crypto fund". High-profile team members might travel under pseudonyms or at least not list their company on luggage tags to stay low-profile. Also, be wary that you might be traveling with someone with these characteristics, so don't give them away. #### **Plan emergency and incident responses** Before departure, know what you'll do if something goes wrong. Have a **fallback plan** in case of device loss: who will you notify & how (have safe words and beware of deepfakes or impersonations); how will you revoke access to sensitive accounts; and how will you continue working (e.g., a backup laptop or a colleague who can step in). If traveling to [countries with strict tech](https://www.perplexity.ai/search/countries-that-list-cryptopgra-bBSItefPSUi7HP2lTNekjA) or [encryption laws](https://it.cornell.edu/security-and-policy/travel-internationally-technology#:~\:text=Some%20countries%20have%20restrictions%20on,Consider%20requesting%20a%20loaner%20laptop) (e.g., China, Russia, UAE), devices like VPNs, encrypted messaging apps (Signal, or Telegram with Secret Chats only), hardware wallets (Ledger, Trezor), Yubikeys, or encryption software (VeraCrypt, BitLocker) may be flagged by border authorities. Research local laws beforehand. Consider carrying a travel letter from your organization explaining the professional need for these tools, or use sanitized loaner devices to avoid issues at border controls. Share your itinerary and contact information with a trusted peer so they can assist or monitor for any issues. Finally, schedule critical work (especially high-value transactions) for **before or after** your trip if possible, so you’re not forced to do ultra-sensitive actions on the road. Criminals usually play with the “time-sensitive factor,” trying to trick you into doing something quick and urgent, by committing something reckless. ### While traveling #### **Network safety – avoid untrusted Wi-Fi & Bluetooth** Treat **every network as potentially hostile**. Whenever possible, use a **cellular connection or a personal hotspot** instead of public Wi-Fi – your mobile data is encrypted and safer than an open café or hotel network. If you must use public Wi-Fi (hotel, airport, conference), verify the network name with staff and [**disable auto-connect**](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf) features so your devices don't join networks without prompting you. **Turn off Wi-Fi and Bluetooth** on your phone and laptop when you're not using them; this reduces the risk of unsolicited connections or Bluetooth-based attacks. Also, disable any device-to-device sharing like **AirDrop** or **Nearby Share** [to prevent strangers from sending you files](https://www.cypherock.com/blogs/post-safe-vacation-tips-while-traveling-with-crypto#:~\:text=Switch%20off%20any%20shared%20networks). **Use a trustworthy VPN** for an extra layer of encryption for your internet traffic, although in most cases by using an updated device, safe hardcoded DNS records, and ensuring SSL while browsing (enforce HTTPS-only-modes or adding “http\://\*” to your uBlock list, might be enough. A reputable, non-logging VPN (or your company’s VPN) helps protect against snooping on public networks, especially if you’re handling highly sensitive work and using several communication channels. Using a personal portable router combined with a trusted VPN adds a strong layer of security when connecting to public Wi-Fi networks. This setup creates a private, encrypted tunnel between your devices and the internet, minimizing exposure to malicious actors on shared networks. Whenever possible, prefer mobile data over Wi-Fi, as cellular networks provide better encryption and isolation by default. If you must use Wi-Fi, disable automatic connections and ensure you connect only to verified, trusted networks to reduce risk. #### **Device handling – keep them close and protected** Never leave your devices (laptops, phones, hardware wallets) **unattended or unsecured** in public. Keep them on your person or within sight whenever possible. In a conference or cafe, use a cable lock for your laptop if you must step away briefly, take it with you or get someone you trust to watch it over for you. In hotels/Airbnbs, **use the room safe** for small devices when you're out. These safes can easily be opened by an experienced thief or rogue/malicious staff. Consider a portable travel safe/bag you can lock to a fixed object. A [**portable door lock**](https://www.travelandleisure.com/sabre-portable-door-lock-review-7643179#:~\:text=schedule%20and%20explore%20fascinating%20destinations,star%20ratings%20at%20Amazon) or door jammer for your room can add an extra barrier against intruders (useful in rentals without chain locks). This simple gadget prevents anyone (even with a key) from opening your door while you're inside, giving you peace of mind at night. When out and about, be mindful of pickpockets – use bags that zip and consider a subtle anti-theft backpack for expensive gadgets or important assets. For hardware wallets or Yubikeys, a good practice is to **separate them** from the device they authenticate: e.g. don't carry your Yubikey on the same keychain as your laptop bag key; keep it hidden on you. And, of course, **keep devices powered off** or locked when not in use – [enable short auto-lock timeouts](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~\:text=%E2%80%A2%20%20%20%20,Some%20devices%20will) on your phone/laptop so they aren't unlocked if snatched[.](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~\:text=%E2%80%A2%20%20%20%20,Some%20devices%20will) #### **Beware of public USB charging** Avoid plug-and-play charging stations at airports or malls. The risk of ["**juice jacking**"](https://www.cypherock.com/blogs/post-safe-vacation-tips-while-traveling-with-crypto?srsltid=AfmBOopuzAsUtNwqCqfUBteTEyH4MOTvIaRhoXoIUyNHH8Yv5XzILrSr#:~\:text=Stay%20away%20from%20Public%20charger,stations), although small, is that a malicious charging kiosk or cable can inject malware or siphon data when you connect via USB. Depending on your profile risk, you might encounter technologies that mimic different kinds of cables and accessories with the same purpose. These exist out of the box, and have been widely used by red-teamers and pentesters (re OMG cable). Stick to using your own charger plugged into a power outlet, or use a **USB data blocker** (a little adapter that only passes power, not data). Similarly, do not plug unknown USB drives into your laptop – if someone hands you a free USB stick at an event, assume it could be a trap. [**USBGuard**](https://github.com/USBGuard/usbguard#:~\:text=USBGuard%20is%20a%20software%20framework,may%20interact%20with%20the%20system) software (for Linux) or equivalent can be used to restrict USB device access on your computer, allowing only whitelisted devices. This tool can prevent an unknown USB from automatically tampering with your system by requiring authorization for new devices. At a minimum, disable any "USB autorun" features and consider locking down ports if your OS allows. #### **Screen privacy and social engineering** Practice situational awareness when working in public spaces. [**Shoulder surfing**](https://www.trio.so/blog/shoulder-surfing-in-computer-security) is a real threat – someone nearby could be watching you enter passwords or PIN codes. Use a **privacy screen filter** on your laptop or phone to narrow the viewing angle. This makes it much harder for anyone not directly in front of your screen to read it. Sit with your back to a wall when possible, and shield the keypad with your body or hand when typing sensitive info. In crowded conferences or airports, be cautious if someone you don't know strikes up conversation — might be trying to distract you or talk about crypto; scammers might engage you to glean info or even attempt to get you to unlock your device. **Don't log in to critical accounts in front of others** – you never know who's looking. Also be mindful of **phishing attempts**: traveling users are prime targets for fake "urgent" emails or messages. Double-check any unusual prompts before entering credentials, especially if you're on [untrusted Wi-Fi](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~\:text=banking%2C%20or%20sensitive%20work%2C%20using,using%20a%20public%20wireless%20network) (use your VPN and look for HTTPS). #### **Maintain OpSec in public** While traveling, **blend in and stay discreet**. Refrain from discussing sensitive matters in public areas where eavesdropping is possible, or directly sharing things like where you are staying to people you don't know. Even hotel lobbies or rideshares might not be secure for private discussions. When meeting people, don't give your phone to others to type down their socials, and remember to disable default options like Telegram's sharing phone number when adding a contact. Remember that **hidden cameras or microphones** could exist in unfamiliar environments. It's rare but not unheard of, especially in [Airbnbs or rented spaces](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/#:~\:text=On%20the%20kitchen%20table%2C%20he,activate%20the%20camera%20tucked%20inside) – malicious hosts have hidden cameras in items like smoke detectors, clock radios, or USB chargers [.](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/#:~\:text=On%20the%20kitchen%20table%2C%20he,activate%20the%20camera%20tucked%20inside) Give your accommodations a scan: look for odd or [extra devices plugged in](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/) (especially facing beds or desks) and cover or unplug them if suspicious. You can also play ambient noise (or use a noise generator app) during confidential conversations to thwart any listening devices. **Keep a low profile**: as mentioned, [don't flaunt crypto wealth or gear.](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~\:text=,or%20clothing%20with%20bitcoin%20logos) For example, if attending a blockchain conference, consider using an alias on your name badge that doesn't explicitly say your company or title, and don't display that badge outside the venue. When moving around, secure your laptop in a nondescript sleeve or bag (instead of one with a well-known conference brand). The goal is to avoid drawing the attention of both petty thieves and more organized attackers by limiting the signals that you're a high-value crypto target. Don't rely on security through obscurity. Going "stealth" doesn't make you immune to attacks. The suggestions in this section are meant to complement, not replace, the other security measures. #### **Traveling with high-value crypto or duties** If you *must* make crypto transactions or access sensitive systems while on the road, do so with caution. Use trusted hardware and networks: e.g. if you need to send a transaction, use your hardware wallet on your own laptop (never a shared computer), on a secured connection. Be aware of **surveillance at events** – attackers have been known to watch for people handling sensitive info. If you need to access a seed or enter a recovery phrase, do it in a private, secure setting (never over public Wi-Fi or in view of anyone, including cameras). Consider that [**everyone knows you own crypto at a crypto event**](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~\:text=If%20you%27re%20traveling%20to%20an,in%20your%20belongings%20while%20traveling), so your threat profile is elevated[.](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~\:text=If%20you%27re%20traveling%20to%20an,in%20your%20belongings%20while%20traveling) Adjust your security: for instance, **enable a passphrase or a pin on any single-signature wallet** you carry so that even if someone obtains your hardware wallet, they can't access funds without that passphrase. For large amounts, rely on multi-sigs, verifying payloads before signing – you might carry one key on you and leave another key(s) with trusted parties so no single person has all signing power while traveling. In short, treat any on-trip crypto operations with more care than you would in the office or at home. #### While presenting or doing public appearances One often overlooked risk is the exposure caused by presenting or hosting technical workshops in public. Without properly hardening or isolating your computer before setting up, you may unintentionally expose network services to hostile environments or reveal sensitive information on-screen. Always prepare a clean, minimal environment and verify no confidential data or open ports are accessible before connecting to unfamiliar networks or projecting your screen. #### **Physical safety and common sense** Operational security also has a physical aspect. **Trust your instincts** and normal travel safety rules: stick to well-lit and populated areas if carrying devices at night, don’t let strangers “shoulder surf” your ATM or credit card PIN (check for skimmers, fake interfaces), and keep your travel documents secure since identity theft can be as damaging as device theft. Use hotel lockers at conferences if provided (for example, some events offer secure charging lockers – use them rather than leaving devices out only). Beware of the classic “evil maid” scenario in hotels (where someone might tamper with your laptop in your room): using tamper-evident tape or seals on your laptop case can help detect this, though it’s mostly a concern for high-risk targets. If you have tamper-evident stickers or tamper-evident bags, you can seal your device in them overnight – any attempt to open or remove the device will leave a visible trace. While not foolproof against a determined adversary, it raises the bar and can deter casual snooping. Petty thieves may look beyond obvious valuables. Simply locking items in a dorm safe or hiding them at home might deter casual theft, but savvy criminals often search inside books, behind electrical outlets, or within patterns on walls or furniture to find hidden stashes. Consider unconventional hiding spots and avoid predictable storage methods. Layer your physical security measures with tamper-evident seals or discreet decoy containers to raise the effort required for unauthorized access. Above all, maintain an **alert posture**: be aware of who’s around when you’re working, and if something feels off (like someone persistently hovering or a device acting strangely), don’t ignore it. You can always relocate, power down your device, or otherwise cut off exposure at the first sign of trouble. ### Returning home #### **Secure your accounts and passwords** Once you're back, if you suspect that any account credentials you used while abroad *might* have been exposed (especially if you had to log in over a hotel or conference Wi-Fi), address the issue. Change the passwords for any accounts you accessed unsafely during the trip – but if you don't feel is necessary, sometimes you pose a greater risk at doing so. Do this from a *trusted* device/network (ideally wait till you're on your home or office network, not the airport Wi-Fi). Use this opportunity to upgrade weak passwords and ensure 2FA is still working on those accounts. Check your email filters and crypto account settings for any unauthorized changes (attackers sometimes add forwarding rules or new withdrawal addresses if they did get access). Essentially, **rotate secrets** that may have been used under less-secure conditions. #### **Inspect and clean your devices** After traveling, give your devices a thorough once-over. Run a reputable anti-malware scan on laptops and phones. Look for any unusual apps, processes, or device behavior (for example, unusual battery drain could indicate malware). If you were in a high-risk environment or your device was out of your control at any point, consider wiping the device and restoring it from your pre-trip backup (or factory-resetting a phone) [to ensure it's clean](https://architectsecurity.org/2017/10/mobile-device-security-for-international-travelers-part-3-how-to-clean-up-your-mobile-devices-after-international-travel/#:~\:text=Assume%2C%20whether%20correct%20or%20not%2C,and%20must%20be%20rebuilt%20anew)[.](https://architectsecurity.org/2017/10/mobile-device-security-for-international-travelers-part-3-how-to-clean-up-your-mobile-devices-after-international-travel/#:~\:text=The%20goal%20after%20travel%20is,to%20a%20%E2%80%9Cknown%20good%E2%80%9D%20state) This is especially recommended for "burner" devices used on the trip – you can safely restore your data onto your main device and decommission the travel device. For hardware wallets, verify they weren't tampered with: check the device seals if any, and when you connect, confirm the firmware is still legitimate (if the manufacturer provides verification software). If you have any suspicion that a device (or hardware wallet) was compromised, *do not continue using it for sensitive transactions*. Transfer crypto assets to new wallets (using your seed backups in a new device if necessary) once you're on a secure network and device. It's also a good idea to **disable or remove any travel-specific eSIMs or accounts** you used on the trip – for example, remove that foreign cellular plan from your phone if you no longer need it, and uninstall any travel or conference apps that are no longer required. #### **Post-travel review** Now that you're home, **reflect on the trip** and note any security incidents or close calls. If any device was lost, stolen, or **even taken out of your sight and potentially tampered** (like held by airport security for a long inspection), inform your organization's IT or security team immediately. They may assist with forensic checks or account monitoring. Also inform colleagues if any work data might have been exposed so they can be vigilant. This is not about blame – it's about mitigating any damage early. Re-enable any data or accounts you put in "travel mode." For instance, if you used 1Password Travel Mode to hide vaults, log in and turn those vaults back on. If you created throwaway emails or burner chat accounts for the trip, decide if you'll deactivate them now. **Update your threat model** based on your experience: did any new threats emerge, or did some precautions prove unnecessary? Use that to improve future travel prep. Finally, share key lessons with your team. Sharing what you've learned from each trip and tweaking your security practices contributes to a stronger security culture for everyone! ### Additional precautions for high-risk travelers *This section is for Web3 professionals who have **elevated privileges or profiles** – for example, access to multisig treasury keys, leadership roles, or possession of sensitive organizational secrets. These users may be targeted more deliberately by criminals or even nation-states. In addition to all the precautions above, high-risk travelers should take further steps:* For high-profile or recognizable individuals, keeping a low profile is essential. Beyond avoiding branded merchandise, a simple yet effective tactic is wearing an N95 mask or similar face covering. It's socially accepted, draws no attention, and helps protect your identity — making it harder for adversaries to target or track you during public events. #### **Use loaner or "burner" devices** If feasible, travel with clean devices that **don't contain sensitive data**. Leave your primary laptop/phone at a protected location (assuming you also have security in place as well), and bring a wiped, minimal laptop or a cheap travel phone with only the basics. Log into what you absolutely need (through secure channels) and nothing more. Treat these devices as expendable – assume they *will* be compromised and plan to wipe them afterward. For example, a senior developer might bring a laptop with no source code on it and use a VPN or VDI (virtual desktop) to access company systems when necessary, leaving no data on the local disk. A hardware wallet keyholder might carry a **secondary hardware wallet** with lower privileges (or a single key to a multisig instead of full access). Keep your primary keys secured in a location that is not accompanying you. Remember, a nearly empty device can raise suspicion at some borders, so don't make it obvious – load some innocuous data (music, generic files) so it looks used, but nothing that would be harmful if inspected. #### **Plan for customs and border checks** High-risk individuals may face increased scrutiny or device searches at borders due to the sensitive nature of their data or their roles (e.g., journalists). **Before crossing borders**, purge or secure sensitive information. Turn off devices before landing (some experts even recommend **encrypting and then powering down** devices – [a powered-off device with strong encryption is extremely hard to access](https://www.reddit.com/r/technology/comments/1jl9dxg/how_to_lock_down_your_phone_if_youre_traveling_to)). Disable cloud auto-sync of sensitive data; you don’t want customs inadvertently accessing company cloud drives if they inspect your laptop. If asked to unlock devices, having them powered off gives you an opportunity to state that it’s encrypted and requires a passphrase (which you should have memorized, not written down). It’s wise for high-risk travelers to **disable biometrics entirely before travel** – use PIN/password only, as mentioned – so you cannot be compelled or tricked via fingerprint/face. Know your legal rights in the countries you transit; in some places you can refuse to unlock (though it may mean the device is held or you are denied entry), while in others you might face penalties. This is a personal risk decision – but the best case is to carry *nothing* truly incriminating or irreplaceable across a checkpoint. For ultra-sensitive data, use secure communication channels to retrieve it at destination rather than carrying it. For instance, an executive could store confidential files in a secure cloud drive they access over VPN once abroad, rather than carrying them on a laptop. Border checks/immigration checks often require you to share your travel plans, including hotel information and airline details. Having a physical copy of them (printouts, ingress-egress) means you do not need to access your devices in front of agents or potential cameras while being scrutinized. This will also prevent the need to let them peek at them to provide information, thereby risking the disclosure of sensitive personal information. Since COVID, many nations have moved to digital immigration paperwork. This often requires the use of an email address. You should consider a dedicated email address for interaction with government agencies, instead of an email address that might have a public/open-source affiliation with cryptocurrency (or other sensitive topics). #### **Enhanced device protections** High-risk users should layer additional defenses. **Lockdown Mode** (on iOS) or Android’s equivalent secure modes should be enabled if there’s any chance of targeted spyware (these modes disable exploit-prone services and attachments). Use messaging apps with end-to-end encryption and disappearing messages (NOT Telegram, Signal is a good example) for any sensitive communications – assume that standard SMS or emails could be monitored. Consider using a **Faraday bag** for phones when not in use, if you suspect active tracking or exploitation (this prevents any signals in or out, though use sparingly as it also blocks your calls). If you leave a device in your hotel, you can put it in a tamper-evident bag and seal it, or at least take measures like noting the exact placement or taking a photo, so you can detect if it was disturbed. Some high-risk individuals even **weigh their devices** before and after travel to detect the addition of hardware implants (a change in weight could indicate something like a chip added) – this is an extreme step, but shows the level of caution possible. At the very least, physically inspect your devices for new scratches, screws that look tampered with, or unexpected behavior. #### **Protect crypto keys with multi-party controls** If you have access to significant crypto funds (exchanges, DAO treasury, etc.), implement policies that prevent a single point of failure while you’re traveling. For example, if you’re one of N-of-M multisig signers, consider temporarily **requiring an extra signer** for transactions while you’re away (so if normally 2-of-3 can move funds, bump it to 3-of-3 or add a 4th backup signer) so that a compromised key or coerced action cannot alone execute a transfer. If you hold hardware keys, keep them **geographically split** – e.g. bring one key device with you, leave the backup key in a safe place at home, and perhaps give a third key to a colleague, so that even a forced disclosure cannot result in an immediate loss of funds without collaboration. Use duress codes if your hardware supports it (some wallets allow a secondary PIN that opens a decoy account with minimal funds, the same can also be made with encryption volumes). In general, **assume a determined adversary could target you** specifically for your role: use confidential communication to stay in touch with your team (so they know you’re safe daily), and establish a code word or protocol for emergencies. High-risk travelers might also arrange a “check-in” schedule with their security team or colleagues – if you don’t check in by a certain time, they can take pre-agreed actions (like disabling your accounts or alerting authorities). This kind of planning is an extra safety net when the stakes are especially high. #### **Post-trip device rebuilding** For highly targeted individuals, the safest course after returning is to **treat every device as compromised** and rebuild it, **especially before reaching your safe zone (home, work office).** This involves wiping devices to factory settings, flashing firmware if necessary, and restoring data from known-good backups made before the trip. Consider using **read-only operating systems** or booting from trusted live media during travel to reduce risk exposure. Before your trip, you can create a **cloned disk image** of a clean system state, so after traveling you can restore your device to that exact low-level copy — starting fresh with a known secure baseline. This approach helps eliminate stealthy malware or spyware that may have been implanted. Additionally, review system logs if available (security apps or MDM solutions often report unusual access or configuration changes during your absence). As always, report any suspicious incidents promptly. High-risk roles may require a debrief with your security officer — be transparent about any odd encounters or possible security lapses to mitigate threats that could have followed you home. ### Conclusion Travel OpSec isn't about fear, it's about intention. You decide what to bring, what to leave behind, and how much risk you're willing to carry. The less you expose, the less you have to defend. Harden what matters, strip everything else, and stay aware of your surroundings. Security on the road isn't a checklist you tick once. It's a posture you maintain. Updates, encryption, strong authentication, minimal data, trusted paths—these are your baseline. From there, you layer additional controls according to your context. Some trips need burner devices and strict compartmentalization. Others just need good hygiene and awareness. The point is to make those decisions consciously, not out of habit or convenience. When you return, assume that anything exposed has to be re-evaluated. Rotate credentials, wipe or rebuild if needed, and adjust your threat model based on what you experienced. Each trip should make you sharper, not more complacent. \-- Part of the contents were inspired and based on some of the following articles. * CISA Cybersecurity While Traveling – official tips on device updates, Wi-Fi safety, and physical device security | [cisa.gov](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~\:text=%E2%80%A2%20%20%20%20,And%20Bluetooth) [cisa.gov](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~\:text=%E2%80%A2%20%20%20%20,networks%20when%20you%20want%20to). * Cornell University IT Security – international travel security checklist (device encryption, using loaner devices, minimizing data) | [it.cornell.edu](https://it.cornell.edu/security-and-policy/travel-internationally-technology#:~\:text=%2A%20,computers%2C%20tablets%2C%20mobile%20phones%2C%20etc) | [it.cornell.edu](https://it.cornell.edu/security-and-policy/travel-internationally-technology#:~\:text=%2A%20,you%20need%20for%20your%20trip). * Cypherock Blog – "Safe Vacation Tips while Traveling with Crypto" (advice on MFA keys, avoiding public Wi-Fi and chargers, not carrying seed phrases) | [cypherock.com](https://www.cypherock.com/blogs/post-safe-vacation-tips-while-traveling-with-crypto?srsltid=AfmBOopuzAsUtNwqCqfUBteTEyH4MOTvIaRhoXoIUyNHH8Yv5XzILrSr#:~\:text=Implement%20MFA%20on%20sensitive%20accounts,and%20apps) | [cypherock.com](https://www.cypherock.com/blogs/post-safe-vacation-tips-while-traveling-with-crypto?srsltid=AfmBOopuzAsUtNwqCqfUBteTEyH4MOTvIaRhoXoIUyNHH8Yv5XzILrSr#:~\:text=Stay%20away%20from%20Public%20charger,stations). * Schneier on Security (comments) – community OPSEC suggestions for border crossings (burner phones, no biometrics, 1Password Travel Mode) | [schneier.com](https://www.schneier.com/blog/archives/2025/04/cell-phone-opsec-for-border-crossings.html#:~\:text=match%20at%20L598%20Burner,phrase%20or%20two%20to%20retrieve). * The MacGuys – Apple device travel tips (Lockdown Mode, separate eSIM for travel, disabling Face ID in emergencies) | [themacguys.com](https://www.themacguys.com/essential-travel-security-tips-for-apple-devices/#:~\:text=Use%20a%20Separate%20eSIM%20for,Travel) | [themacguys.com](https://www.themacguys.com/essential-travel-security-tips-for-apple-devices/#:~\:text=Know%20How%20to%20Disable%20Biometric,Unlock). * Unchained Capital – "7 Tips for Traveling with Bitcoin Keys" (don't advertise crypto holdings, leave seed backups at home, use passphrases/multisig for travel) | [unchained.com](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~\:text=,or%20clothing%20with%20bitcoin%20logos) | [unchained.com](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~\:text=If%20you%27re%20traveling%20to%20an,in%20your%20belongings%20while%20traveling). * BlackCloak – Dangers of oversharing travel on social media (real-time posts can invite burglaries or attacks) | [blackcloak.io](https://blackcloak.io/social-media-and-travel-be-careful-of-what-you-share/#:~\:text=The%20Risks%20of%20Oversharing%20on,Social%20Media). * Trio Security Blog – Shoulder surfing and visual hacking (use privacy screens and be mindful of surroundings) | [trio.so](https://www.trio.so/blog/shoulder-surfing-in-computer-security/#:~\:text=,the%20keypad%20with%20your%20hand). * Washington Post – Portable door locks for travelers (added security in accommodations) | [travelandleisure.com](https://www.travelandleisure.com/sabre-portable-door-lock-review-7643179#:~\:text=schedule%20and%20explore%20fascinating%20destinations,star%20ratings%20at%20Amazon) and finding hidden cameras in rentals | [washingtonpost.com](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/#:~\:text=On%20the%20kitchen%20table%2C%20he,activate%20the%20camera%20tucked%20inside). * GitHub USBGuard – tool to enforce USB device policies on laptops (helps block malicious USB devices) | [github.com](https://github.com/USBGuard/usbguard#:~\:text=USBGuard%20is%20a%20software%20framework,may%20interact%20with%20the%20system). *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Travel > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Operational Security While Traveling](/opsec/travel/overview) * [Travel Security Guide](/opsec/travel/guide) * [Travel Security Quick Reference](/opsec/travel/tldr) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Operational Security while traveling > 🔑 **Key Takeaway**: Travel introduces unique security risks to your digital assets and sensitive information. Proper > preparation before, vigilance during, and careful review after travel creates a comprehensive defense strategy that > balances security with practical usability. When we travel, our normal security routines are disrupted, and we face elevated risks from physical theft, digital surveillance, border inspections, and social engineering. Web3 professionals face additional challenges when traveling with crypto assets or access to treasury funds. The resources in this section provide practical guidance for maintaining operational security while traveling: * [OpSec Travel Guide](/opsec/travel/guide) - A comprehensive resource covering all aspects of travel security with in-depth explanations and implementation details * [Too Long; Did not Read version](/opsec/travel/tldr) - A condensed checklist format for quick security planning before and during travel ### Three-phase Security Approach Our travel security framework is organized into three critical phases: 1. **Pre-travel preparation**: Risk assessment, device hardening, backup creation, and contingency planning 2. **On-trip vigilance**: Network security, physical device protection, social engineering awareness, and maintaining operational security 3. **Post-travel review**: Device inspection, account security verification, and lessons learned documentation Additional considerations are provided for high-risk travelers who may face targeted threats due to their role or access to valuable assets. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Personal security travel guide — concise version > 🔑 Key Takeaway: Protect your digital assets while traveling through minimizing sensitive data, using encrypted > devices, avoiding public networks, securing hardware wallets, maintaining physical control of devices, being cautious > with USB connections, practicing social discretion, and sanitizing devices upon return. ### Before traveling * Remove or securely store any data, devices, or documents not essential for the trip. Less sensitive material reduces risk if lost or stolen. * Perform a quick threat model: list what you carry, who may target you, and how. Plan mitigations accordingly. * Enable full-disk encryption on all devices; update OS, firmware, and apps before departure. * Back up devices, record serial numbers and IMEI, and verify Mobile Device Management (MDM) enrollment and "Find My" functionality. * Print or securely store backup 2FA codes; disable SMS-based 2FA if possible. Use eSIM or secondary numbers for authentication. * Use password manager travel modes to hide sensitive vaults while away. * Update and test hardware wallets; never travel with written seed phrases. * Carry hardware wallets and 2FA tokens on your person; keep spares securely at home. * Use strong phone passcodes; disable biometrics in risky scenarios; enable Lockdown Mode if available. * Minimize your digital footprint: avoid public travel announcements and crypto branding. * Prepare an emergency plan: who to notify if devices are lost or compromised, and how to revoke access quickly. * Research local laws on encryption and tech; carry travel letters or sanitized devices if needed for border crossings. ### While traveling * Prefer cellular data or personal hotspots over public Wi-Fi; disable automatic Wi-Fi connections. * Use a trusted VPN and consider a portable router to encrypt traffic on public networks. * Turn off Wi-Fi, Bluetooth, AirDrop, and Nearby Share when not in use to reduce attack surface. * Keep devices on you or locked; use cable locks and hotel safes (though note they can be easily opened by experienced thieves). * Be cognizant of what you are posting on Social Media in real time. Delay posting a location by 1-2 days to avoid anyone tracking you. * Avoid public USB charging stations ("juice jacking"); use your own charger or a USB data blocker. * Use privacy screens on laptops and phones; be mindful of shoulder surfing and phishing attempts. * Don't discuss sensitive information publicly; be alert for hidden cameras or microphones in accommodations. * Use passphrases on wallets and multisig setups for large crypto holdings. * Separate hardware wallets and keys from the devices they authenticate. * Consider portable door locks and tamper-evident bags to secure your room and devices overnight. * When presenting or doing public appearances, prepare a clean, isolated environment and verify no confidential data or open ports are accessible before connecting to unfamiliar networks. ### Returning home * Change passwords and verify 2FA on accounts accessed during travel, preferably from trusted devices and networks. * Scan devices for malware and unusual behavior; factory reset if you suspect compromise. * Inspect hardware wallets for tampering; transfer funds if compromised or suspicious. * Remove travel-specific SIMs, accounts, or apps no longer needed. * Report incidents to your security or IT team; share lessons learned to improve future security. ### High-risk traveler extras * Use burner or loaner devices with minimal data; assume they may be compromised and plan to wipe them post-trip. * Power down and encrypt devices before border crossings to limit data exposure. * Disable biometrics completely pre-travel to avoid compelled unlocks. * Enable Lockdown Mode and use end-to-end encrypted messaging apps (e.g., Signal). * Use Faraday bags and tamper-evident seals to prevent tracking and unauthorized device access. * Physically inspect devices before and after travel for signs of tampering or implants. * Increase multisig signer requirements while traveling; geographically split key custody. * Use duress codes if supported by hardware wallets. * Establish secure emergency check-ins and code words with your team for rapid response. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## The Five Steps of the OpSec Process > 🔑 **Key Takeaway**: OpSec is built on five critical steps: identifying what needs protection, analyzing potential > threats, assessing vulnerabilities, evaluating risks, and implementing appropriate countermeasures. If we were to summarize the most crucial and important steps of Operational Security, whether it is for an individual or an organization, we would do as follows. These are not step-by-steps, but can serve as a kick-off process to be further improved after its first iteration. ### 1. Identification of Critical Information Determine what information, if obtained by adversaries, could harm your organization or operations. > **🔗 Related Framework:** This step aligns with [Asset Inventory](/infrastructure/asset-inventory) practices and > informs [Data Protection](/opsec/old/data-protection/overview) strategies. #### Implementation 1. Create an inventory of all sensitive information assets 2. Classify information based on sensitivity and impact if compromised 3. Document where critical information is stored, processed, and transmitted 4. Identify the owners and authorized users of each information asset 5. Regularly review and update your critical information inventory ### 2. Threat Analysis Identify potential adversaries, their capabilities, and their interest in your critical information. > **🔗 Related Framework:** For detailed approaches, see [Understanding Threat > Vectors](/awareness/understanding-threat-vectors) and [Threat Modeling](/opsec/old/threat-modeling-overview) frameworks. #### Implementation 1. Research known threat actors relevant to your industry or organization 2. Analyze adversaries' motivations, resources, and methods 3. Consider both external threats (hackers, competitors) and internal threats (insiders) 4. Stay informed about emerging threats and attack techniques 5. Document threat scenarios specific to your organization's context ### 3. Vulnerability Assessment Analyze how your critical information might be exposed through vulnerabilities in your systems, processes, or personnel. > **🔗 Related Framework:** This connects with [Security Testing](/security-testing/overview) framework, including > Static Application Security Testing and Dynamic Application Security Testing, and vulnerability management practices. #### Implementation 1. Conduct technical vulnerability scans of systems and networks 2. Review processes and procedures for security gaps 3. Assess personnel security awareness and adherence to security policies 4. Examine physical security controls protecting critical assets 5. Evaluate third-party and supply chain vulnerabilities that could impact your organization ### 4. Risk Assessment Evaluate the likelihood and potential impact of various threats exploiting identified vulnerabilities. > **🔗 Related Framework:** For comprehensive approaches, see [Governance](/governance/overview) and > [Risk Management](/governance/risk-management) frameworks. #### Implementation 1. Calculate risk based on threat probability and potential impact 2. Prioritize risks based on severity and criticality to operations 3. Document acceptable risk thresholds for different types of assets 4. Consider cascading effects of security compromises 5. Present risk assessments in clear terms for executive decision-making ### 5. Countermeasure Implementation Develop and deploy security controls to mitigate identified risks, considering cost, effectiveness, and operational impact. > **🔗 Related Framework:** Implementation connects with [Security Automation](/security-automation/overview) and > various control frameworks like [Infrastructure](/infrastructure/overview) and [Identity and Access > Management](/iam/overview). #### Implementation 1. Select appropriate technical, administrative, and physical controls 2. Implement controls based on risk prioritization 3. Test controls to ensure they function as intended 4. Document procedures for maintaining and updating controls 5. Train personnel on new security measures and their importance *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Principles & Concepts Overview Operational Security (OpSec) is built upon foundational principles and processes that help organizations protect sensitive information and critical assets. This section covers the essential concepts that form the basis of an effective operational security program. ### What is Operational Security? Operational Security is a process that: 1. Identifies critical information and assets 2. Analyzes threats to those assets 3. Assesses vulnerabilities that could be exploited 4. Determines risks and potential impacts 5. Implements countermeasures to mitigate risks The goal is to prevent adversaries from gaining access to information that could be harmful if disclosed or compromised. ### Core Principles The following principles form the foundation of operational security: * **Defense in Depth**: Implementing multiple layers of security controls so that if one fails, others will provide protection. * **Principle of Least Privilege**: Granting users, systems, and processes only the minimum access rights necessary to perform their functions. * **Need-to-Know Basis**: Restricting information access to only those who require it to perform their duties. * **Compartmentalization**: Dividing information and systems into isolated segments to limit the impact of a breach. * **Continuous Monitoring and Improvement**: Regularly assessing security measures and adapting to evolving threats and vulnerabilities. ### The Five Steps of the OpSec Process 1. **Identification of Critical information**: Determine what information, if obtained by adversaries, could harm your organization or operations. 2. **Threat Analysis**: Identify potential adversaries, their capabilities, and their interest in your critical information. 3. **Vulnerability Assessment**: Analyze how your critical information might be exposed through vulnerabilities in your systems, processes, or personnel. 4. **Risk Assessment**: Evaluate the likelihood and potential impact of various threats exploiting identified vulnerabilities. 5. **Countermeasure Implementation**: Develop and deploy security controls to mitigate identified risks, considering cost, effectiveness, and operational impact. ### Web3-Specific Considerations In Web3 environments, operational security must address unique challenges: * **Transparency vs. Privacy**: Balancing blockchain transparency with the need for operational secrecy * **Decentralized Operations**: Securing operations across distributed teams and systems * **Cryptocurrency Security**: Protecting digital assets and private keys * **Smart Contract Vulnerabilities**: Addressing the immutable nature of deployed code * **Community Dynamics**: Managing security in open, community-driven projects *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Operational Security Principles > 🔑 **Key Takeaway**: Effective OpSec relies on five core principles: layered defenses, minimal access rights, > need-to-know information sharing, system compartmentalization, and continuous monitoring—all working together to > protect sensitive information from adversaries. The goal is to prevent adversaries from gaining access to information that could be harmful if disclosed or compromised. > **Practical Example: Web3 Organization** > > Consider a Web3 project managing a DeFi protocol with a treasury of $10M in assets. Proper operational security would > involve: > > * **Multiple security layers**: Hardware wallets for cold storage, multi-signature requirements for transactions, > regular security audits, and continuous monitoring > * **Access control**: Only specific team members have access to deployment keys, with different permission levels for > development, testing, and production environments > * **Compartmentalized information**: Private keys for multi-signature wallets are distributed among trusted team > members with no single person having access to all keys, and sensitive incident response procedures are only shared > with the security team > * **Regular threat assessment**: The team conducts quarterly reviews of potential attack vectors, from smart contract > vulnerabilities to [social engineering](/awareness/understanding-threat-vectors) attempts targeting team members ### 1. Defense in Depth Defense in Depth is the practice of layering security controls throughout your systems and processes, so that if one control fails, others will provide protection. > **🔗 Related Framework:** This principle is applied across multiple frameworks including > [Infrastructure](/infrastructure/overview) with [Zero-Trust Principles](/infrastructure/zero-trust-principles) and > [Network Security](/infrastructure/network-security). #### Implementation 1. Deploy multiple security controls that address the same risk in different ways 2. Implement security at various layers: physical, technical, administrative, and human 3. Ensure no single point of failure exists in your security architecture 4. Review the effectiveness of security layers regularly to identify gaps 5. Foster a [security-aware mindset](/awareness/cultivating-a-security-aware-mindset) across all team members ### 2. Principle of Least Privilege The Principle of Least Privilege dictates that users, systems, and processes should have only the minimum access rights necessary to perform their functions. > **🔗 Related Framework:** For comprehensive implementation, see [Identity and Access Management](/iam/overview) and > [Role-Based Access Control](/iam/role-based-access-control). #### Implementation 1. Grant the minimum level of access required for users to perform their duties 2. Review and adjust access rights when roles change 3. Implement role-based access control (RBAC) to standardize permissions 4. Use time-limited and just-in-time access for administrative privileges 5. Regularly audit access rights to identify and remove excessive permissions 6. Establish a thorough offboarding process to immediately revoke access when team members leave 7. Remove credentials for deactivated accounts, as these can become security liabilities even when dormant ### 3. Need-to-Know Basis Information should only be shared with individuals who require that information to perform their duties. > **🔗 Related Framework:** This principle is supported by practices in [Data > Protection](/opsec/old/data-protection/overview) and aspects of [Privacy](/privacy/overview). #### Implementation 1. Classify information based on sensitivity and restrict access accordingly 2. Compartmentalize sensitive information to limit exposure in case of a breach 3. Implement clear data handling and sharing policies 4. Train team members on proper handling and sharing of sensitive information through regular \[security training] {/*TODO: "/awareness/security-training" is this link this: /awareness/cultivating-a-security-aware-mindset ? */} 5. Use secure communication channels for sensitive information ### 4. Compartmentalization Dividing information and systems into isolated segments to limit the impact of a breach. #### Implementation 1. Segment networks and systems based on functionality and sensitivity 2. Isolate critical assets from general-purpose systems 3. Separate development, testing, and production environments 4. Use separate accounts and access methods for different security domains 5. Implement firewalls and access controls between segments ### 5. Continuous Monitoring and Improvement Security is not a one-time implementation but a continuous process of monitoring, evaluating, and improving. > **🔗 Related Framework:** For implementation details, see the [Monitoring](/monitoring/overview) framework, including > [Guidelines](/monitoring/guidelines) and [Thresholds](/monitoring/thresholds). Also relevant is > [Incident Management](/incident-management/overview) for response to detected issues. #### Implementation 1. Establish security metrics to measure the effectiveness of controls 2. Implement monitoring systems to detect security events and anomalies 3. Conduct regular security assessments and penetration tests 4. Learn from security incidents and near-misses 5. Update security controls based on new threats, vulnerabilities, and technologies 6. Ensure team members are [staying informed and continuously learning](/awareness/staying-informed-and-continuous-learning) about evolving security threats 7. Utilize available [security resources](/awareness/resources-and-further-reading) to keep your security practices current *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Web3-Specific OpSec Considerations > 🔑 **Key Takeaway**: Web3 environments require specialized security approaches that balance blockchain transparency > with privacy, address immutability risks, manage self-custody responsibilities, secure decentralized operations, > mitigate smart contract vulnerabilities, and navigate community-driven security challenges. In addition to traditional OpSec principles, Web3 environments require consideration of unique challenges. Many organizations claim to be backed only by decentralized technologies, but they later realize that part of their process is dependant on technologies that are not. {/* > **🔗 Related Framework:** Explore the dedicated [Web3-Specific OpSec](../operational-security/web3-specific-opsec/) framework for comprehensive guidance. */} ### Transparency vs. Privacy Balancing the transparent nature of blockchain with the need for operational privacy. #### Implementation 1. Understand what information is publicly visible on-chain 2. Develop strategies to maintain operational privacy while utilizing public blockchains 3. Use privacy-enhancing technologies where appropriate ### Immutability and Finality Recognizing that blockchain transactions are generally irreversible, requiring heightened security before execution. #### Implementation 1. Implement robust verification procedures before executing transactions 2. Use multi-signature requirements for high-value transactions 3. Deploy transaction simulation tools to verify outcomes before execution ### Self-Custody Responsibility Managing private keys and digital assets with appropriate security controls. > **🔗 Related Framework:** For detailed guidance on wallet security practices, see the [Wallet > Security](/wallet-security/overview) framework. #### Implementation 1. Develop clear procedures for wallet security 2. Implement separation of duties for transaction approval 3. Balance security with operational efficiency 4. [Stay up-to-date](/awareness/staying-informed-and-continuous-learning) with best practices in wallet security and custody solutions ### Decentralized Operations Securing operations across distributed teams and systems. #### Implementation 1. Establish clear security protocols for remote team members 2. Use secure communication channels for sensitive discussions 3. Implement strong authentication for all team members 4. Create guidelines for secure collaboration in a distributed environment ### Smart Contract Vulnerabilities Addressing the immutable nature of deployed code. #### Implementation 1. Conduct thorough code reviews and security audits before deployment 2. Implement upgradability patterns where appropriate 3. Use formal verification where possible 4. Maintain comprehensive testing environments 5. Consider timelocks and circuit breakers for critical functions ### Community Dynamics Managing security in open, community-driven projects. #### Implementation 1. Develop clear security guidelines for community contributors 2. Establish review processes for community-submitted code 3. Create security awareness programs for the community 4. Balance transparency with operational security needs *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Passwords > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Password Management](/opsec/passwords/overview) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Password Management Placeholder for Password Management content import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Core OpSec Principles Operational security is built on fundamental principles that guide the implementation of security controls and practices. These principles provide a foundation for developing a comprehensive security posture that protects your organization's assets, operations, and reputation. > **Practical Example: Web3 Organization** > > Consider a Web3 project managing a DeFi protocol with a treasury of $10M in assets. Proper operational security would > involve: > > * **Multiple security layers**: Hardware wallets for cold storage, multi-signature requirements for transactions, > regular security audits, and continuous monitoring > * **Access control**: Only specific team members have access to deployment keys, with different permission levels for > development, testing, and production environments > * **Compartmentalized information**: Private keys for multi-signature wallets are distributed among trusted team > members with no single person having access to all keys, and sensitive incident response procedures are only shared > with the security team > * **Regular threat assessment**: The team conducts quarterly reviews of potential attack vectors, from smart contract > vulnerabilities to social engineering attempts > targeting team members ### Defense in Depth Defense in Depth is the practice of layering security controls throughout your systems and processes, so that if one control fails, others will provide protection. > **🔗 Related Framework:** This principle is applied across multiple frameworks including > [Infrastructure](/infrastructure/overview) with [Zero-Trust Principles](/infrastructure/zero-trust-principles) and > [Network Security](/infrastructure/network-security). #### Implementation 1. Deploy multiple security controls that address the same risk in different ways 2. Implement security at various layers: physical, technical, administrative, and human 3. Ensure no single point of failure exists in your security architecture 4. Review the effectiveness of security layers regularly to identify gaps 5. Foster a [security-aware mindset](/awareness/cultivating-a-security-aware-mindset) across all team members ### Principle of Least Privilege The Principle of Least Privilege dictates that users, systems, and processes should have only the minimum access rights necessary to perform their functions. > **🔗 Related Framework:** For comprehensive implementation, see [Identity and Access Management](/iam/overview) and > [Role-Based Access Control](/iam/role-based-access-control). #### Implementation 1. Grant the minimum level of access required for users to perform their duties 2. Review and adjust access rights when roles change 3. Implement role-based access control (RBAC) to standardize permissions 4. Use time-limited and just-in-time access for administrative privileges 5. Regularly audit access rights to identify and remove excessive permissions 6. Establish a thorough offboarding process to immediately revoke access when team members leave 7. Remove credentials for deactivated accounts, as these can become security liabilities even when dormant ### Need-to-Know Basis Information should only be shared with individuals who require that information to perform their duties. > **🔗 Related Framework:** This principle is supported by practices in [Data > Protection](/opsec/old/data-protection/overview) and aspects of [Privacy](/privacy/overview). #### Implementation 1. Classify information based on sensitivity and restrict access accordingly 2. Compartmentalize sensitive information to limit exposure in case of a breach 3. Implement clear data handling and sharing policies 4. Train team members on proper handling and sharing of sensitive information through regular \[security training] {/* TODO: /awareness/security-training is this link this: /awareness/cultivating-a-security-aware-mindset ? */} 5. Use secure communication channels for sensitive information ### Threat Modeling for OpSec Threat modeling involves systematically identifying potential threats, vulnerabilities, and attack vectors to prioritize security controls. > **🔗 Related Framework:** For detailed methodology and implementation, see the [Threat > Modeling](/threat-modeling/overview) framework, including guides on how to [Create and Maintain Threat > Models](/threat-modeling/create-maintain-threat-models) and [Identify and Mitigate > Threats](/threat-modeling/identity-mitigate-threats). #### Implementation 1. Identify critical assets and operations that need protection 2. Enumerate potential threats and their impact on your organization 3. Assess vulnerabilities that could be exploited 4. Evaluate existing controls and their effectiveness 5. Develop a prioritized plan to address identified risks 6. Maintain awareness of common [threat vectors](/awareness/understanding-threat-vectors) relevant to your organization ### Risk Assessment and Management Systematic evaluation and prioritization of security risks to guide resource allocation and security decision-making. > **🔗 Related Framework:** For comprehensive risk management strategies, refer to [Governance](/governance/overview) > and [Risk Management](/governance/risk-management). #### Implementation 1. Identify and categorize assets based on their value and criticality 2. Assess threats and vulnerabilities relevant to those assets 3. Determine the likelihood and potential impact of security incidents 4. Implement controls based on risk levels 5. Regularly reassess risks as the environment and threats evolve ### Continuous Monitoring and Improvement Security is not a one-time implementation but a continuous process of monitoring, evaluating, and improving. > **🔗 Related Framework:** For implementation details, see the [Monitoring](/monitoring/overview) framework, including > [Guidelines](/monitoring/guidelines) and [Thresholds](/monitoring/thresholds). Also relevant is [Incident > Management](/incident-management/overview) for response to detected issues. #### Implementation 1. Establish security metrics to measure the effectiveness of controls 2. Implement monitoring systems to detect security events and anomalies 3. Conduct regular security assessments and penetration tests 4. Learn from security incidents and near-misses 5. Update security controls based on new threats, vulnerabilities, and technologies 6. Ensure team members are [staying informed and continuously learning](/awareness/staying-informed-and-continuous-learning) about evolving security threats 7. Utilize available [security resources](/awareness/resources-and-further-reading) to keep your security practices current ### Web3-Specific OpSec Principles In addition to traditional OpSec principles, Web3 environments require consideration of: > **🔗 Related Framework:** Explore the dedicated [Web3-Specific OpSec](/opsec/old/web3-specific-opsec/overview) > framework for comprehensive guidance. #### Transparency vs. Privacy Balancing the transparent nature of blockchain with the need for operational privacy. ##### Implementation 1. Understand what information is publicly visible on-chain 2. Develop strategies to maintain operational privacy while utilizing public blockchains 3. Use privacy-enhancing technologies where appropriate #### Immutability and Finality Recognizing that blockchain transactions are generally irreversible, requiring heightened security before execution. ##### Implementation 1. Implement robust verification procedures before executing transactions 2. Use multi-signature requirements for high-value transactions 3. Deploy transaction simulation tools to verify outcomes before execution #### Self-Custody Responsibility > **🔗 Related Framework:** For detailed guidance on wallet security practices, see the [Wallet > Security](/wallet-security/overview) framework. #### Implementation 1. Develop clear procedures for wallet security 2. Implement separation of duties for transaction approval 3. Balance security with operational efficiency 4. [Stay up-to-date](/awareness/staying-informed-and-continuous-learning) with best practices in wallet security and custody solutions By adhering to these core principles, organizations can build a strong foundation for operational security that addresses both traditional and Web3-specific security challenges. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Governance & Program Management Effective operational security requires a structured approach to governance and program management. This section outlines how to establish and maintain security policies, roles, and responsibilities within your organization. ### Security Policies & Roles Security policies provide the foundation for an organization's security posture, while clearly defined roles ensure accountability and proper implementation of those policies. #### Key Security Policies 1. **Information Security Policy**: The overarching policy that defines the organization's approach to information security 2. **Acceptable Use Policy**: Guidelines for appropriate use of organizational resources 3. **Access Control Policy**: Rules for granting, reviewing, and revoking access to systems and data 4. **Incident Response Policy**: Procedures for identifying, reporting, and responding to security incidents 5. **Data Classification Policy**: Framework for categorizing data based on sensitivity and criticality 6. **Password Policy**: Requirements for password complexity, rotation, and management 7. **Remote Work Policy**: Security requirements for team members working remotely #### Essential Security Roles 1. **Security Lead/Officer**: Oversees the security program and strategy 2. **Security Champions**: Representatives from different teams who advocate for security 3. **Incident Response Team**: Individuals responsible for handling security incidents 4. **Policy Owners**: Those responsible for developing and maintaining specific policies 5. **Compliance Manager**: Ensures adherence to relevant regulations and standards #### Implementation Steps 1. Develop policies that align with your organization's risk profile and regulatory requirements 2. Ensure policies are clear, concise, and accessible to all team members 3. Define roles and responsibilities with specific accountability metrics 4. Provide training to ensure understanding of policies and roles 5. Regularly review and update policies to address emerging threats and changes in the organization ### Third-Party/Vendor Governance Managing security risks associated with third-party vendors and partners is critical for maintaining a strong security posture. #### Key Components 1. **Vendor Risk Assessment**: Process for evaluating the security posture of potential vendors 2. **Security Requirements**: Clear security expectations for vendors accessing or processing your data 3. **Contractual Safeguards**: Security and privacy clauses in vendor contracts 4. **Ongoing Monitoring**: Continuous assessment of vendor security practices 5. **Incident Response Coordination**: Procedures for joint handling of security incidents #### Implementation Steps 1. Develop a vendor classification system based on the criticality of services and data access 2. Establish minimum security requirements for each vendor category 3. Implement a formal vendor onboarding process that includes security assessments 4. Regularly audit high-risk vendors for compliance with security requirements 5. Develop procedures for addressing security concerns with vendors ### Web3-Specific Considerations In Web3 environments, governance and program management must address unique challenges: 1. **Decentralized Teams**: Managing security across geographically distributed teams, often with contractors or part-time contributors 2. **Open-Source Components**: Governance of security for open-source dependencies and contributions 3. **DAO Structures**: Aligning security governance with decentralized autonomous organization models 4. **Regulatory Uncertainty**: Navigating evolving regulatory landscapes in different jurisdictions 5. **Community Involvement**: Balancing community participation with centralized security oversight #### Best Practices for Web3 Organizations 1. Implement security governance that complements rather than conflicts with decentralized structures 2. Clearly define security responsibilities, particularly for critical functions like treasury management 3. Develop policies that address Web3-specific risks like private key management and smart contract deployments 4. Create transparent security reporting channels that align with community values 5. Establish clear incident response protocols that consider the public nature of blockchain activities Effective governance and program management provide the structure needed to implement operational security measures consistently across your organization, adapting traditional approaches to the unique challenges of Web3 environments. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Incident Response & Recovery Even with strong security controls, incidents can occur. This section outlines how to prepare for, respond to, and recover from security incidents effectively. ### Playbooks for Common Incidents Predefined procedures for responding to specific types of security incidents help ensure consistent and effective responses. #### Device Loss or Theft 1. **Immediate Actions**: * Report the incident to security team * Remotely wipe device if possible * Change passwords for accounts accessible from the device * Revoke authentication tokens and certificates 2. **Investigation Steps**: * Determine what data was on the device * Assess potential access to systems and accounts * Review logs for any access after loss/theft 3. **Recovery Actions**: * Issue replacement device with clean installation * Restore necessary data from backups * Document the incident and update procedures if needed #### Account Compromise 1. **Immediate Actions**: * Isolate the affected account * Reset credentials and revoke sessions * Review activity for signs of lateral movement * Notify relevant stakeholders 2. **Investigation Steps**: * Determine the attack vector (phishing, credential stuffing, etc.) * Identify all actions taken by the attacker * Assess impact on data and systems 3. **Recovery Actions**: * Implement additional security controls * Restore affected systems to known good state * Conduct security awareness training if needed #### Malware Infection 1. **Immediate Actions**: * Isolate affected systems from the network * Preserve evidence for analysis * Activate incident response team * Notify relevant stakeholders 2. **Investigation Steps**: * Identify the malware type and capabilities * Determine the infection vector * Assess the scope of the infection * Identify data and systems potentially affected 3. **Recovery Actions**: * Clean or reimage affected systems * Restore data from clean backups * Implement additional security controls * Update anti-malware signatures and protections #### Web3-Specific Incidents ##### Private Key Compromise 1. **Immediate Actions**: * Transfer assets to secure wallets if possible * Revoke permissions associated with the key * Notify relevant stakeholders 2. **Investigation Steps**: * Determine how the key was compromised * Review blockchain transactions for unauthorized activity * Assess impact on assets and systems 3. **Recovery Actions**: * Generate new keys using secure procedures * Update key management practices * Conduct security awareness training if needed ##### Smart Contract Exploit 1. **Immediate Actions**: * Pause contract functions if possible * Alert users and stakeholders * Implement circuit breaker if available 2. **Investigation Steps**: * Analyze the exploit and vulnerability * Assess impact on assets and users * Determine remediation options 3. **Recovery Actions**: * Deploy fixed contract * Implement recovery plan for affected assets * Update development and testing procedures ### Containment, Eradication & Recovery Steps General process for responding to security incidents regardless of type. #### Containment Limiting the impact and spread of the incident. 1. **Immediate Containment**: Taking urgent actions to stop the incident from spreading 2. **Evidence Preservation**: Capturing necessary information for investigation 3. **Communication Control**: Managing information flow about the incident 4. **Stakeholder Notification**: Informing those who need to know about the incident #### Eradication Removing the cause of the incident. 1. **Root Cause Identification**: Determining how the incident occurred 2. **Threat Removal**: Eliminating malware, vulnerabilities, or other causes 3. **Verification**: Ensuring the threat has been completely removed 4. **Enhanced Monitoring**: Implementing additional monitoring to detect recurrence #### Recovery Restoring systems and operations to normal. 1. **Staged Restoration**: Gradually restoring systems in order of priority 2. **Security Validation**: Verifying security controls before full restoration 3. **Operational Verification**: Ensuring systems function correctly 4. **User Notification**: Informing users when systems are restored ### Web3-Specific Considerations Incident response in Web3 environments requires additional considerations: 1. **Immutability Challenges**: Addressing the irreversible nature of blockchain transactions 2. **Community Communication**: Managing public disclosure in decentralized communities 3. **Cross-Chain Impacts**: Addressing incidents that affect multiple blockchains 4. **Governance Activation**: Utilizing governance mechanisms for incident response 5. **Post-Incident Compensation**: Developing approaches for making affected users whole ### Documentation and Reporting Maintaining appropriate records throughout the incident response process. 1. **Incident Timeline**: Documenting the sequence of events and actions taken 2. **Evidence Collection**: Preserving relevant logs, artifacts, and other evidence 3. **Impact Assessment**: Documenting the effects of the incident 4. **Response Evaluation**: Assessing the effectiveness of the response 5. **Formal Reporting**: Creating required reports for management, regulators, or others ### Post-Incident Activities Actions to take after an incident has been resolved. 1. **Lessons Learned**: Identifying what worked well and what could be improved 2. **Control Updates**: Implementing new or enhanced security controls 3. **Procedure Refinement**: Updating incident response procedures 4. **Training Updates**: Incorporating lessons into security training 5. **Threat Intelligence Sharing**: Contributing to community knowledge when appropriate Effective incident response requires preparation, practice, and continuous improvement. By developing comprehensive playbooks and procedures, organizations can respond quickly and effectively to security incidents, minimizing their impact and facilitating rapid recovery. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Monitoring & Detection Effective security monitoring and detection are critical components of operational security. This section outlines approaches to implement monitoring systems that can identify security threats and anomalies in real-time. ### Log Management & SIEM Centralized logging and security information and event management (SIEM) systems provide visibility into security events across the organization. #### Key Components 1. **Log Collection**: Gathering logs from systems, applications, and network devices 2. **Log Normalization**: Standardizing log formats for consistent analysis 3. **Log Correlation**: Identifying relationships between events across different sources 4. **Log Retention**: Preserving logs for compliance and investigation purposes 5. **Security Analytics**: Analyzing logs to identify threats and anomalies #### Implementation Steps 1. Identify critical log sources based on security requirements 2. Implement centralized log collection infrastructure 3. Configure proper log retention periods based on policy and compliance 4. Implement log correlation and analysis capabilities 5. Establish log review procedures for security events 6. Ensure logs include appropriate detail without capturing sensitive data #### Web3-Specific Considerations 1. **Blockchain Logs**: Monitoring blockchain events and transactions 2. **Smart Contract Events**: Capturing and analyzing events emitted by contracts 3. **Node Operation Logs**: Monitoring blockchain node performance and security 4. **Gas Usage Anomalies**: Detecting unusual transaction fee patterns 5. **Bridge Activity**: Monitoring cross-chain bridge operations for anomalies ### Alert Thresholds & Dashboards Establishing appropriate alert thresholds and dashboards to effectively monitor security status and respond to incidents. #### Key Components 1. **Alert Thresholds**: Defining conditions that trigger security alerts 2. **Alert Prioritization**: Categorizing alerts based on severity and impact 3. **Alert Routing**: Directing alerts to appropriate personnel 4. **Security Dashboards**: Visual representations of security status 5. **Metric Tracking**: Monitoring key security performance indicators #### Implementation Steps 1. Define alert thresholds based on baseline activity and risk assessment 2. Implement alert prioritization to focus on the most critical issues 3. Establish alert routing procedures to ensure proper response 4. Create dashboards that provide actionable security insights 5. Regularly review and tune alert thresholds to reduce false positives 6. Develop procedures for escalating and responding to alerts #### Web3-Specific Considerations 1. **Transaction Monitoring**: Alerting on unusual blockchain transactions 2. **Smart Contract Monitoring**: Detecting potential exploits or vulnerabilities 3. **Governance Monitoring**: Tracking governance proposals and voting 4. **Price Oracle Monitoring**: Detecting anomalies in price feed data 5. **Liquidity Monitoring**: Alerting on significant liquidity changes ### Threat Detection Approaches Various approaches to detecting security threats through monitoring and analysis. #### Signature-Based Detection Identifying known threat patterns based on signatures or indicators of compromise. 1. **Implementation**: Deploy solutions with threat intelligence feeds 2. **Strengths**: Effective against known threats with clear signatures 3. **Limitations**: Cannot detect novel or sophisticated attacks 4. **Best Practices**: Regularly update signature databases and threat intelligence #### Behavioral Detection Identifying anomalies based on deviations from normal behavior patterns. 1. **Implementation**: Deploy solutions that establish baselines and detect deviations 2. **Strengths**: Can detect previously unknown threats and insider activities 3. **Limitations**: Requires tuning to reduce false positives 4. **Best Practices**: Establish accurate baselines during low-threat periods #### Heuristic Detection Using rules and algorithms to identify suspicious activities based on behavior characteristics. 1. **Implementation**: Deploy solutions with customizable detection rules 2. **Strengths**: Balance between signature and behavioral approaches 3. **Limitations**: Requires ongoing rule refinement 4. **Best Practices**: Regularly review and update detection rules #### Threat Hunting Proactively searching for threats that have evaded automated detection. 1. **Implementation**: Establish dedicated threat hunting capabilities 2. **Strengths**: Can identify sophisticated threats and APTs 3. **Limitations**: Resource-intensive and requires skilled personnel 4. **Best Practices**: Develop hypothesis-driven hunting processes ### Web3-Specific Monitoring Specialized monitoring approaches for Web3 environments. #### On-Chain Monitoring Monitoring blockchain transactions and smart contract interactions. 1. **Transaction Monitoring**: Tracking unusual transaction patterns 2. **Smart Contract Events**: Monitoring events emitted by contracts 3. **Token Transfers**: Tracking movement of tokens and assets 4. **Gas Usage Analysis**: Identifying unusual gas consumption patterns 5. **Governance Actions**: Monitoring governance proposals and votes #### Off-Chain Monitoring Monitoring infrastructure, applications, and services supporting blockchain operations. 1. **Node Monitoring**: Tracking performance and security of blockchain nodes 2. **API Security Monitoring**: Detecting suspicious API usage 3. **Frontend Application Monitoring**: Identifying unusual user interactions 4. **Infrastructure Security Monitoring**: Tracking security events in supporting infrastructure 5. **Team Member Activity Monitoring**: Detecting unusual access or activities Effective monitoring and detection enable organizations to identify security threats quickly, reducing the potential impact of security incidents. By implementing comprehensive monitoring across both traditional and Web3-specific environments, organizations can maintain visibility into their security posture and respond promptly to emerging threats. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Operational Security Operational security, often abbreviated as **OpSec** provides a range of practices and measures designed to safeguard an organization's sensitive information, assets, and operations from unauthorized access, espionage, disruption, or compromise. Operational security is not just a concern for large corporations or government agencies; it is relevant to any project that handles sensitive information, including personal data or digital assets. The consequences of failing to implement robust OpSec measures can be severe, ranging from financial losses to reputational damage, and legal liabilities. The level of Operational Security to apply will differ greatly depending on the risk appetite the team is willing to accept. ### Framework Contents {/* TODO: check what to do with links: 1. [Core OpSec Principles](./core-opsec-principles.md) - Foundational security concepts and methodologies 2. [Human-Centered Security](./human-centered-security/README.md) - Security measures focused on the human element 3. [Digital Identity and Access Management](./digital-identity-access/README.md) - Managing digital identities and controlling access 4. [Device and Endpoint Security](./device-endpoint-security/README.md) - Securing individual devices and endpoints 5. [Network and Communication Security](./network-communication/README.md) - Securing networks and communications channels 6. [Data Protection](./data-protection/README.md) - Safeguarding sensitive data throughout its lifecycle 7. [Cloud and Third-Party Security](./cloud-third-party/README.md) - Securing cloud environments and third-party relationships 8. [Physical Security](./physical-security/README.md) - Protecting physical assets and environments 9. [Incident Response and Recovery](./incident-response-recovery.md) - Responding to and recovering from security incidents 10. [Compliance and Governance](./compliance-governance.md) - Meeting regulatory requirements and establishing governance 11. [Web3-Specific OpSec](./web3-specific-opsec/README.md) - Operational security considerations unique to Web3 12. [Resources and Tools](./resources-tools.md) - Useful tools, templates, and further reading */} *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Risk Management > 🔑 **Key takeaway**: Risk management transforms threat information into actionable priorities. It helps you determine > which threats matter most, where to allocate resources, and how to make security trade-offs that align with business > goals. Effective risk management builds upon threat modeling to assess, prioritize, and mitigate identified security risks. While threat modeling identifies what needs protection and potential attack vectors, risk management determines which threats warrant immediate attention and resources. ### Risk Assessment Process {/* ![Risk Management Process](../assets/risk-management-process.png)*/} > **🔗 Related Framework:** This process builds directly on outputs from [Threat > Modeling](/opsec/old/threat-modeling-overview). #### Key Components 1. **Impact Analysis**: Estimating the potential consequences of a security incident 2. **Likelihood Determination**: Assessing the probability of a threat exploiting a vulnerability 3. **Risk Calculation**: Combining impact and likelihood to determine risk levels 4. **Risk Prioritization**: Determining which risks to address first #### Implementation Steps 1. For each threat scenario identified in threat modeling, assign impact ratings based on financial, operational, and reputational factors 2. Determine likelihood based on threat intelligence and historical data 3. Calculate risk scores (typically Risk = Impact × Likelihood) 4. Prioritize risks based on scores and organizational context #### Prioritization Methodology Not all risks require the same level of attention. Prioritize based on: | Factor | Description | | --------------------------- | ---------------------------------------------------------------- | | **Risk Level** | Focus on high and critical risks first | | **Asset Value** | Prioritize risks to your most valuable assets | | **Mitigation Feasibility** | Consider how easily and cost-effectively a risk can be addressed | | **Regulatory Requirements** | Address risks with compliance implications | | **Strategic Alignment** | Focus on risks that align with strategic security initiatives | ### Trade-off Analysis Security decisions often involve trade-offs between security, usability, cost, and other factors. Trade-off analysis helps make informed decisions. #### Key Considerations | Trade-off | Description | | --------------------------------------- | -------------------------------------------------- | | **Security vs. Usability** | More security controls often mean less convenience | | **Cost vs. Risk Reduction** | Security measures must be cost-effective | | **Speed vs. Security** | Fast implementation may compromise security | | **Centralization vs. Decentralization** | Control vs. resilience | | **Transparency vs. Security** | Open information vs. operational secrecy | #### Decision-Making Framework 1. **Define**: Clearly articulate the security challenge and objectives 2. **Identify**: Enumerate all viable options 3. **Analyze**: Evaluate each option against established criteria 4. **Select**: Choose the option that best balances competing priorities 5. **Implement**: Execute the chosen option 6. **Review**: Assess the effectiveness of the decision and adjust as needed ### Web3-Specific Considerations In Web3 environments, risk management must address unique challenges: #### Unique Risk Factors | Risk Factor | Description | | ---------------------------------- | ---------------------------------------------------- | | **Smart Contract Vulnerabilities** | Immutable code with potential security flaws | | **Private Key Management** | Securing cryptographic keys that control assets | | **Decentralized Governance** | Distributed decision-making for security matters | | **Protocol Inter-dependencies** | Risks from connected protocols and services | | **Regulatory Uncertainty** | Evolving legal landscape for blockchain technologies | #### Best Practices for Web3 Organizations | Practice | Implementation | Primary Risk Addressed | | --------------------------- | --------------------------------------------------------------------------------- | ------------------------ | | **Key Management** | Implement multi-signature wallets, hardware security, and key rotation procedures | Private key compromise | | **Smart Contract Security** | Conduct thorough code audits, formal verification, and staged deployments | Contract vulnerabilities | | **Incident Response** | Develop cryptocurrency-specific incident plans with predefined actions | All attack vectors | | **Security Governance** | Establish clear security roles even in decentralized organizations | Governance gaps | | **Dependency Monitoring** | Regularly audit connected protocols and dependencies | Supply chain attacks | | **Regulatory Compliance** | Stay informed about evolving regulations across jurisdictions | Legal/regulatory risks |
⬇️ Collapsable Example: Risk Assessment for Pinnipeds Inc. #### Pinnipeds Inc. Risk Assessment Building on the threat vectors identified during threat modeling, Pinnipeds Inc. conducted a risk assessment: ##### Risk Calculation Methodology | Rating | Impact | Likelihood | | ------ | -------- | -------------- | | **1** | Minimal | Rare | | **2** | Minor | Unlikely | | **3** | Moderate | Possible | | **4** | Major | Likely | | **5** | Severe | Almost Certain | **Formula:** Risk Score = Impact × Likelihood ##### High Risk Threats (Score 15-25) | Threat Scenario | Likelihood | Impact | Risk Score | Reasoning | | -------------------------- | ---------- | ------ | ---------- | ------------------------------------------------------------------------------------------------------------------- | | Treasury wallet compromise | 4 | 5 | 20 | High impact due to direct financial loss; relatively high likelihood given frequency of attacks on crypto companies | | Source code theft | 3 | 5 | 15 | High impact due to IP loss and potential backdoor insertion; medium likelihood based on industry intelligence | | Phishing of employees | 5 | 3 | 15 | Medium impact as most employees have limited access; very high likelihood based on attack trends | ##### Medium Risk Threats (Score 8-14) | Threat Scenario | Likelihood | Impact | Risk Score | Reasoning | | ---------------------- | ---------- | ------ | ---------- | --------------------------------------------------------------------- | | Client data breach | 3 | 4 | 12 | Major impact to reputation; moderate likelihood based on API exposure | | DDoS on infrastructure | 4 | 3 | 12 | Moderate impact on operations; likely to occur given industry trends | | AWS credentials leaked | 2 | 5 | 10 | Severe impact if exploited; unlikely due to current controls | ##### Mitigation Decision Process | Factor | Approach | | ------------------------------ | -------------------------------------------------------------------------------------------- | | **Resource allocation** | 60% of security budget allocated to high-risk threats | | **Implementation timeline** | High-risk mitigations scheduled for completion within 30 days | | **Control selection criteria** | Controls evaluated based on cost, operational impact, effectiveness, and implementation time | This risk-based approach allowed Pinnipeds Inc. to make informed decisions about which security controls to implement first, focusing resources where they would have the greatest risk-reduction impact.
### Further Reading & Tools * [NIST Risk Management Framework](https://csrc.nist.gov/projects/risk-management) * [ISO 31000:2018 Risk Management Guidelines](https://www.iso.org/standard/65694.html) * [FAIR (Factor Analysis of Information Risk) Framework](https://www.fairinstitute.org/) * [OWASP Risk Rating Methodology](https://owasp.org/www-community/OWASP_Risk_Rating_Methodology) * Tools: [Eramba](https://www.eramba.org/) (open source GRC) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Threat Modeling Overview > 🔑 **Key takeaway**: Think of threat modeling as your security roadmap. It's how you understand what you need to > protect, who might try to steal it, and how they might do it. From random hackers to state actors, knowing your > potential attackers helps you build defenses that actually matter. It's about being smart with your security resources > and focusing on what really needs protection. Effective security requires understanding **what you're protecting and who you're protecting it from**. Without a structured threat model, security efforts become unfocused and inefficient. Different entities face different threats based on their assets, visibility, and technological footprint. ### Why is it important Failure to implement threat modeling has led to catastrophic security breaches: * [How Threat Modeling Could Have Prevented the 1.5B ByBit Hack](https://blog.trailofbits.com/2025/02/25/how-threat-modeling-could-have-prevented-the-1.5b-bybit-hack/) * [North Korea's Lazarus Group stole $620 million from Axie Infinity's Ronin bridge (2022)](https://home.treasury.gov/news/press-releases/jy0768) through a sophisticated attack targeting blockchain infrastructure * [The Nomad bridge lost $190 million (2022)](https://medium.com/nomad-xyz-blog/nomad-bridge-hack-root-cause-analysis-875ad2e5aacd) through a critical vulnerability that allowed attackers to bypass transaction validation * [The 2020 Twitter compromise](https://blog.twitter.com/en_us/topics/company/2020/an-update-on-our-security-incident) resulted in hijacked high-profile accounts being used for cryptocurrency scams #### Common pitfalls & examples * **Tunnel vision**: The Colonial Pipeline attack (2021) succeeded through a legacy VPN account without MFA, while the company focused security resources on operational technology * **Unrealistic scenarios**: Many organizations over-invested in zero-day defense while leaving basic phishing vulnerabilities open * **Static models**: Equifax's 2017 breach occurred partly because threat models weren't updated to reflect new attack patterns * **Insider blindness**: The 2020 Twitter compromise of high-profile accounts happened when internal admin tools weren't included in threat modeling Organizations that implement threat modeling can focus limited security resources on their most significant risks, avoiding both over-protection of low-value assets and under-protection of critical systems. A DeFi protocol that fails to properly identify potential attack vectors, might focus extensively on their website and marketing infrastructure while overlooking smart contract security. Effective threat modeling ensures security teams can identify and document all potential attack paths - enabling risk management teams to later assess and prioritize these threats effectively. Without threat modeling, organizations often distribute security resources evenly across all assets regardless of risk levels. ### Practical guidance > **🔗 Related Framework:** For detailed approaches, see [Understanding Threat > Vectors](/awareness/understanding-threat-vectors) and [Threat Modeling](/threat-modeling/overview) frameworks. #### Asset inventory 1. **Digital value stores**: Document cryptocurrencies, tokens, NFTs, and any assets directly convertible to monetary value 2. **Credentials & access information**: Catalog passwords, API keys, recovery seeds/phrases, private keys, and other non-physical authentication data 3. Identify all **Hardware & physical devices**: * **Computing devices**: Computers, phones, tablets, servers * **Security hardware**: Hardware wallets, YubiKeys, MFA devices, HSMs * **Physical security**: Office equipment, security systems, physical access controls 4. **Infrastructure & systems**: Map cloud resources, development environments, network equipment, and third-party services 5. **Sensitive information & intellectual property**: Track code repositories, proprietary algorithms, customer data, business documents, email archives, and backup files 6. **Legal & compliance assets**: Identify digital certificates, identity documents, contracts, and regulatory compliance documentation For these, you can use technologies such as: * Configuration Management Databases (CMDBs) * Specialized asset tracking software * GRC (Governance, Risk, and Compliance) platforms with asset inventory modules
⬇️ Collapsible Example: Pinnipeds Inc. asset inventory #### Pinnipeds Inc. Asset Inventory Pinnipeds Inc. is a small company with 15 employees. Here's how they categorized their assets: | Asset Category | Items | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Digital value stores** | • Company treasury holding 5 BTC and 50 ETH for operations
• Client tokens held in custody during project development
• Test tokens on various testnets for development purposes | | **Credentials & access information** | • Multi-signature wallet configuration (3-of-5 signers)
• Password manager company accounts for all employees
• Recovery seed phrases (stored separately from devices)
• SSH keys for server access
• API keys for third-party services | | **Hardware & physical devices** | **Computing devices:**
• 15 developer laptops with encrypted drives
• 5 company mobile phones for executives
• 2 physical servers for internal development
**Security hardware:**
• Hardware wallets for each founding member (3)
• YubiKeys for all developers for GitHub access
• Biometric access readers
**Physical security:**
• Office security system with cameras
• Card readers for building access
• Secure storage for sensitive documents | | **Infrastructure & systems** | • AWS cloud infrastructure for production environments
• GitHub organization with private repositories
• CI/CD pipeline tools (Jenkins, GitHub Actions)
• Company VPN for remote work
• Slack and Discord for internal and client communications | | **Sensitive information & IP** | • Custom smart contract code for clients
• Internal research on blockchain optimization
• Client database with contact and project information
• Financial records and business strategy documents
• Employee personal information | | **Legal & compliance assets** | • Company incorporation documents
• Client contracts and NDAs
• Regulatory compliance documentation for different jurisdictions
• SSL certificates for company websites
• Code audit reports and security assessments |
#### Adversary analysis 1. **Classify potential attackers by tiers**: * **Tier 1 (Opportunistic)**: Random cybercriminals, script kiddies, automated scanners * **Tier 2 (Targeted)**: Organized crime groups, corporate competitors, angry ex-employees * **Tier 3 (Advanced)**: Nation-state actors, APT groups, sophisticated criminal syndicates 2. **Document adversary capabilities and motivations**: * Technical capabilities and resources * Financial motivations or strategic goals * Persistence level (hit-and-run vs. long-term compromise)
⬇️ Collapsible Example: Analysis of adversaries targeting Pinnipeds Inc. #### Pinnipeds Inc. Adversary Analysis | Adversary Tier | Characteristics | Examples & Techniques | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Tier 1 (Opportunistic)** | **Who**: Individual hackers, script kiddies, automated scanners/bots
**Motivations**: Quick financial gain, building reputation, opportunistic theft
**Capabilities**: Using public exploits, basic phishing, automated scanning tools
**Targets**: Public-facing infrastructure, employee email accounts, known vulnerabilities | • Crypto wallet draining scams
• Generic phishing campaigns
• Website defacement
• Automated vulnerability scanning | | **Tier 2 (Targeted)** | **Who**: Organized criminal groups, competitors, disgruntled former employees
**Motivations**: Financial theft, competitive advantage, sabotage, revenge
**Capabilities**: Custom malware, spear phishing, social engineering, persistent attacks
**Targets**: Company treasury wallets, intellectual property, client data, employee credentials | • Targeted social engineering of specific developers
• Custom exploits for Pinnipeds' systems
• Extended reconnaissance operations
• Sophisticated phishing campaigns | | **Tier 3 (Advanced)** | **Who**: Nation-state actors, sophisticated criminal syndicates, APT groups
**Motivations**: Strategic intelligence, large-scale financial theft, disruption
**Capabilities**: Zero-day exploits, supply chain attacks, long-term persistence, stealth techniques
**Targets**: Crypto treasury, proprietary algorithms, strategic business information, infrastructure access | • Lazarus Group's systematic targeting of cryptocurrency organizations
• Supply chain compromises
• Advanced persistent threats with long dwell times
• Multi-stage attack campaigns |
#### Attack vector mapping 1. **Map potential attack vectors**: * Technical: Zero-day exploits, vulnerability exploitation, network attacks * Social: Phishing, social engineering, insider threats * Physical: Device theft, office intrusion, hardware tampering * Operational: SIM swapping, supply chain compromise, third-party breaches 2. **Document potential attack scenarios** for each critical asset 3. **Link attack vectors to adversary capabilities** identified in your adversary analysis
⬇️ Collapsible Example: Attack Vector Mapping for Pinnipeds Inc. #### Pinnipeds Inc. Attack Vector Analysis ##### Critical Asset: Treasury Wallet (Financial) | Attack Vector | Description | Relevant Adversary | | ----------------------- | -------------------------------------------- | ------------------ | | Phishing | Targeted emails to obtain wallet credentials | Tier 1-2 attackers | | Social engineering | Manipulating employees to gain access | Tier 2 attackers | | Supply chain compromise | Compromised wallet software | Tier 3 attackers | | Insider threat | Disgruntled employee with access | Tier 2 attackers | ##### Critical Asset: Source Code (Intellectual Property) | Attack Vector | Description | Relevant Adversary | | ---------------------------- | --------------------------------------- | ------------------ | | GitHub account compromise | Targeting developer credentials | Tier 1-3 attackers | | CI/CD pipeline injection | Injecting malicious code during build | Tier 3 attackers | | Code repository breach | Direct attack on GitHub infrastructure | Tier 3 attackers | | Developer machine compromise | Targeting local development environment | Tier 2-3 attackers | ##### Critical Asset: Client Data (Customer Information) | Attack Vector | Description | Relevant Adversary | | ---------------------------- | ----------------------------------------- | ------------------ | | Database exploitation | SQL injection or other DB vulnerabilities | Tier 1-2 attackers | | AWS credential theft | Stolen cloud access credentials | Tier 2 attackers | | API vulnerabilities | Insecure API endpoints | Tier 1-2 attackers | | Data in transit interception | Man-in-the-middle attacks | Tier 2-3 attackers |
### Implementation details | When to implement | Description | | ------------------- | ---------------------------------------------------------------- | | Initial development | Create baseline threat model before launching any crypto project | | Regular reviews | Update quarterly or when significant changes occur | | After incidents | Revise after any security breach or near-miss | | Team changes | Review when onboarding and offboarding key personnel | **Role-specific considerations:** * **Security specialists**: Lead the threat modeling process, provide intelligence on current threats * **Operations**: Contribute infrastructure knowledge and implement technical controls * **Developers**: Identify code-level vulnerabilities and secure development practices * **HR/Management**: Address insider threat risks and security awareness training * **Community/Marketing**: Consider reputation risks and public-facing attack surfaces ### Practical Frameworks and Tools After completing the asset inventory, adversary analysis, and attack vector mapping, organizations can leverage established frameworks and visualization techniques to systematize their threat modeling approach. These tools help translate the theoretical understanding of threats into practical, actionable security measures. #### STRIDE Threat Categorization Framework The STRIDE framework, developed by Microsoft in the late 1990s, offers a systematic approach to identifying and categorizing threats. It maps directly to key security properties that must be protected in any system: | STRIDE Category | Security Property Violated | Description | Example in Web3 | Common Mitigations | | -------------------------- | -------------------------- | -------------------------------------------- | -------------------------------------------------------- | ------------------------------------------------------ | | **S**poofing | Authentication | Impersonating something or someone else | Phishing attacks to steal wallet credentials | Strong MFA, hardware security keys, signing operations | | **T**ampering | Integrity | Modifying data or code | Smart contract manipulation through vulnerable functions | Integrity checks, code signing, immutable audit logs | | **R**epudiation | Non-repudiation | Denying performed actions | Disputing transaction authorization | Blockchain transaction signing, comprehensive logging | | **I**nformation disclosure | Confidentiality | Exposing sensitive data | Private key extraction from insecure storage | Encryption, proper key management, minimal privilege | | **D**enial of service | Availability | Disrupting availability for legitimate users | Network congestion attacks, high gas fees | Rate limiting, redundancy, circuit breakers | | **E**levation of privilege | Authorization | Gaining unauthorized access | Exploiting admin functions in contracts | Least privilege, strict role separation, multi-sig | Organizations can apply STRIDE systematically to each component identified in their asset inventory to ensure comprehensive threat coverage. #### Attack Trees: Visualizing Attack Paths Attack trees provide a structured method to visualize potential attack scenarios against critical assets. They help security teams understand the relationship between different attack vectors and identify the most critical paths requiring mitigation: ``` Goal: Steal crypto assets ├── Compromise user wallet │ ├── Phishing attack │ │ └── Mitigate: Security awareness training │ └── Malware infection │ └── Mitigate: Endpoint protection ├── Attack exchange │ ├── API key theft │ │ └── Mitigate: IP restrictions, 2FA │ └── Credential stuffing │ └── Mitigate: Unique passwords, MFA └── SIM swapping └── Mitigate: Hardware keys, non-SMS 2FA ``` ### Further Reading & Tools #### Frameworks & References * [NIST SP 800-154: Guide to Data-Centric System Threat Modeling](https://csrc.nist.gov/publications/detail/sp/800-154/draft) * [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) * [Microsoft STRIDE Model](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats) * [MITRE ATT\&CK Framework](https://attack.mitre.org/) #### Visualization & Modeling Tools * [Microsoft Threat Modeling Tool](https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling), * [OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Web3-Specific Operational Security Web3 introduces unique operational security challenges that require specialized approaches beyond traditional security measures. This section focuses on the specific security considerations for organizations operating in the blockchain and decentralized ecosystem. ### Introduction Web3 operational security addresses the distinct threats and vulnerabilities associated with blockchain technologies, decentralized applications, smart contracts, and cryptocurrency operations. The immutable and often public nature of blockchain transactions, combined with the self-custodial responsibility of managing cryptographic assets, creates a security landscape that requires specialized knowledge and techniques. ### Key Components This section covers the following aspects of Web3-specific operational security: {/* TODO: check what to do with links: 1. [Wallet Security](./wallet-security.md) - Securing cryptocurrency and NFT wallets 2. [Smart Contract Operational Security](./smart-contract-opsec.md) - Operational considerations for deploying and managing smart contracts 3. [Blockchain Transaction Security](./transaction-security.md) - Securing blockchain transactions against various threats 4. [Decentralized Identity Management](./decentralized-identity.md) - Managing identities in decentralized systems 5. [DAO Security Operations](./dao-security.md) - Operational security considerations for Decentralized Autonomous Organizations 6. [Validator and Node Security](./validator-node-security.md) - Securing blockchain nodes and validators */} ### Risk-Based Approach Web3 operational security should be implemented based on the value of assets being managed and the criticality of on-chain operations: 1. Inventory all blockchain assets, wallets, and contracts 2. Classify these assets based on value and criticality to operations 3. Implement appropriate security controls based on risk levels 4. Regularly audit security practices and adapt to emerging threats ### Intersection with Traditional Security While Web3 introduces unique security challenges, it does not replace the need for traditional security measures. This section highlights where Web3-specific controls should be integrated with: * Traditional identity and access management * Device and endpoint security * Network and communication security * Human-centered security approaches By combining Web3-specific security measures with traditional operational security practices, organizations can build a comprehensive security posture suitable for the decentralized ecosystem. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Risk Management > 🔑 **Key takeaway**: Risk management transforms threat information into actionable priorities. It helps you determine > which threats matter most, where to allocate resources, and how to make security trade-offs that align with business > goals. Effective risk management builds upon threat modeling to assess, prioritize, and mitigate identified security risks. While threat modeling identifies what needs protection and potential attack vectors, risk management determines which threats warrant immediate attention and resources. ### Section Outline * [Risk Assessment & Prioritization](/opsec/old/risk-management/risk-assessment-prioritization) — convert threat intelligence into ranked action plans. * [Trade-off Analysis](/opsec/old/risk-management/trade-off-analysis) — balance security investment against usability, speed, and cost. ### Risk Assessment Process {/* ![Risk Management Process](../../assets/risk-management-process.png) */} > **🔗 Related Framework:** This process builds directly on outputs from [Threat > Modeling](/opsec/old/threat-modeling-overview). #### Key Components 1. **Impact Analysis**: Estimating the potential consequences of a security incident 2. **Likelihood Determination**: Assessing the probability of a threat exploiting a vulnerability 3. **Risk Calculation**: Combining impact and likelihood to determine risk levels 4. **Risk Prioritization**: Determining which risks to address first #### Implementation Steps 1. For each threat scenario identified in threat modeling, assign impact ratings based on financial, operational, and reputational factors 2. Determine likelihood based on threat intelligence and historical data 3. Calculate risk scores (typically Risk = Impact × Likelihood) 4. Prioritize risks based on scores and organizational context #### Prioritization Methodology Not all risks require the same level of attention. Prioritize based on: | Factor | Description | | --------------------------- | ---------------------------------------------------------------- | | **Risk Level** | Focus on high and critical risks first | | **Asset Value** | Prioritize risks to your most valuable assets | | **Mitigation Feasibility** | Consider how easily and cost-effectively a risk can be addressed | | **Regulatory Requirements** | Address risks with compliance implications | | **Strategic Alignment** | Focus on risks that align with strategic security initiatives | ### Trade-off Analysis Security decisions often involve trade-offs between security, usability, cost, and other factors. Trade-off analysis helps make informed decisions. #### Key Considerations | Trade-off | Description | | --------------------------------------- | -------------------------------------------------- | | **Security vs. Usability** | More security controls often mean less convenience | | **Cost vs. Risk Reduction** | Security measures must be cost-effective | | **Speed vs. Security** | Fast implementation may compromise security | | **Centralization vs. Decentralization** | Control vs. resilience | | **Transparency vs. Security** | Open information vs. operational secrecy | #### Decision-Making Framework 1. **Define**: Clearly articulate the security challenge and objectives 2. **Identify**: Enumerate all viable options 3. **Analyze**: Evaluate each option against established criteria 4. **Select**: Choose the option that best balances competing priorities 5. **Implement**: Execute the chosen option 6. **Review**: Assess the effectiveness of the decision and adjust as needed ### Web3-Specific Considerations In Web3 environments, risk management must address unique challenges: #### Unique Risk Factors | Risk Factor | Description | | ---------------------------------- | ---------------------------------------------------- | | **Smart Contract Vulnerabilities** | Immutable code with potential security flaws | | **Private Key Management** | Securing cryptographic keys that control assets | | **Decentralized Governance** | Distributed decision-making for security matters | | **Protocol Inter-dependencies** | Risks from connected protocols and services | | **Regulatory Uncertainty** | Evolving legal landscape for blockchain technologies | #### Best Practices for Web3 Organizations | Practice | Implementation | Primary Risk Addressed | | --------------------------- | --------------------------------------------------------------------------------- | ------------------------ | | **Key Management** | Implement multi-signature wallets, hardware security, and key rotation procedures | Private key compromise | | **Smart Contract Security** | Conduct thorough code audits, formal verification, and staged deployments | Contract vulnerabilities | | **Incident Response** | Develop cryptocurrency-specific incident plans with predefined actions | All attack vectors | | **Security Governance** | Establish clear security roles even in decentralized organizations | Governance gaps | | **Dependency Monitoring** | Regularly audit connected protocols and dependencies | Supply chain attacks | | **Regulatory Compliance** | Stay informed about evolving regulations across jurisdictions | Legal/regulatory risks | Effective risk management enables organizations to allocate security resources efficiently, focusing on the most significant risks while making informed trade-offs between competing priorities. In the Web3 space, this approach must be adapted to address the unique challenges and risk profiles of blockchain-based operations.
Example: Risk Assessment for Pinnipeds Inc. #### Pinnipeds Inc. Risk Assessment Building on the threat vectors identified during threat modeling, Pinnipeds Inc. conducted a risk assessment: ##### Risk Calculation Methodology | Rating | Impact | Likelihood | | ------ | -------- | -------------- | | **1** | Minimal | Rare | | **2** | Minor | Unlikely | | **3** | Moderate | Possible | | **4** | Major | Likely | | **5** | Severe | Almost Certain | **Formula:** Risk Score = Impact × Likelihood ##### High Risk Threats (Score 15-25) | Threat Scenario | Likelihood | Impact | Risk Score | Reasoning | | -------------------------- | ---------- | ------ | ---------- | ------------------------------------------------------------------------------------------------------------------- | | Treasury wallet compromise | 4 | 5 | 20 | High impact due to direct financial loss; relatively high likelihood given frequency of attacks on crypto companies | | Source code theft | 3 | 5 | 15 | High impact due to IP loss and potential backdoor insertion; medium likelihood based on industry intelligence | | Phishing of employees | 5 | 3 | 15 | Medium impact as most employees have limited access; very high likelihood based on attack trends | ##### Medium Risk Threats (Score 8-14) | Threat Scenario | Likelihood | Impact | Risk Score | Reasoning | | ---------------------- | ---------- | ------ | ---------- | --------------------------------------------------------------------- | | Client data breach | 3 | 4 | 12 | Major impact to reputation; moderate likelihood based on API exposure | | DDoS on infrastructure | 4 | 3 | 12 | Moderate impact on operations; likely to occur given industry trends | | AWS credentials leaked | 2 | 5 | 10 | Severe impact if exploited; unlikely due to current controls | ##### Mitigation Decision Process | Factor | Approach | | ------------------------------ | -------------------------------------------------------------------------------------------- | | **Resource allocation** | 60% of security budget allocated to high-risk threats | | **Implementation timeline** | High-risk mitigations scheduled for completion within 30 days | | **Control selection criteria** | Controls evaluated based on cost, operational impact, effectiveness, and implementation time | This risk-based approach allowed Pinnipeds Inc. to make informed decisions about which security controls to implement first, focusing resources where they would have the greatest risk-reduction impact.
### Further Reading & Tools * [NIST Risk Management Framework](https://csrc.nist.gov/projects/risk-management) * [ISO 31000:2018 Risk Management Guidelines](https://www.iso.org/standard/65694.html) * [FAIR (Factor Analysis of Information Risk) Framework](https://www.fairinstitute.org/) * [OWASP Risk Rating Methodology](https://owasp.org/www-community/OWASP_Risk_Rating_Methodology) * Tools: SimpleRisk, RiskLens, IriusRisk *** ## Risk assessment & prioritization ## Trade-off analysis import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Physical Security Physical security is an often overlooked but crucial aspect of operational security, especially for individuals and organizations involved in cryptocurrency. This section provides guidelines on how to protect yourself, your digital assets, and your organization from physical threats and attacks. ### Best Practices 1. Random USB storage devices should not be plugged into your devices. Dropping malicious USB sticks and hoping for someone to pick them up and insert them into their computer is a [real threat](https://www.pcmag.com/how-to/dont-plug-it-in-how-to-prevent-a-usb-attack). On the subject of USB, do not plug in your device into an untrusted charger (e.g., on a bus or airplane) without a data blocker. 2. Do not click on links from untrusted sources, as they may lead to malicious websites or legitimate websites that have been compromised. In the event that you’re asked to take action on a website through, for example, email, visit the website manually (e.g., discord.com) rather than clicking the link. 3. Avoid scanning QR codes as they could potentially contain exploits. 4. Be wary of websites pushing pop-ups that make it seem that you need to install software to upgrade or secure your computer, these are often malware. 5. If you receive a suspicious message, try reaching out to the person via a different channel. ### Secure Traveling #### Preparation 1. Travel with the minimum number of devices necessary. Leave non-essential devices at home. 2. Backup all important data before traveling. Store backups in secure, separate locations. 3. Remove sensitive data from devices before traveling. Consider using travel-specific devices with minimal data depending on the country you're visiting. #### During Travel 1. Keep your devices with you at all times. Use secure storage options when necessary. 2. Avoid using public Wi-Fi networks. If necessary, use a VPN to secure your connection. 3. Avoid using untrusted charging stations. Use a USB data blocker or carry a portable charger. #### Border Security 1. Encrypt your devices to protect data in case they are inspected or seized. 2. Carry minimal data across borders. Be aware that some countries may require decryption of devices. 3. Be prepared for device inspections. Consider using travel-specific accounts and removing sensitive information. ### Preventing "Wrench Attacks" A "wrench attack" refers to the scenario where an attacker uses physical force or coercion to gain access to your assets. #### Mitigation Strategies 1. Use multi-signature wallets that require multiple parties to authorize transactions. 2. Distribute parts of cryptographic keys among trusted individuals or locations. 3. Use decoy wallets with small amounts of cryptocurrency to satisfy attackers without compromising significant assets. 4. Establish clear policies for responding to physical threats in your project, including non-compliance and emergency contacts. ### Home Security 1. Use strong locks, security doors, and window bars to prevent unauthorized entry. 2. Install security cameras and alarm systems. Monitor the premises regularly. 3. Use safes or locked cabinets to store devices and sensitive documents. ### Device Protection #### Hardware Security 1. Use laptop locks and secure your devices to immovable objects when in public or shared spaces. 2. Use tamper-evident seals on devices to detect unauthorized access attempts. 3. Regularly check devices for signs of tampering or unauthorized access. #### Environmental Considerations 1. Protect hardware wallets or other devices from extreme temperatures, humidity, and physical shocks. 2. Store hardware wallets or other important devices in fire-resistant safes and ensure that your environment has appropriate fire detection and suppression systems. ### Emergency Contacts Maintain a list of emergency contacts, including law enforcement, cybersecurity experts, and team contacts. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Network and Communication Security Securing your organization's networks and communication channels is crucial for protecting sensitive information, maintaining business operations, and preventing unauthorized access to resources. ### Introduction Network and communication security encompasses the technologies, policies, and practices that protect the integrity, confidentiality, and availability of data as it travels across networks and communication systems. In today's interconnected world, organizations must address a wide range of threats that target communication channels, from traditional network attacks to sophisticated threats against encrypted communications. ### Key Components This section covers the following aspects of network and communication security: {/*TODO: link not found: */} 1. [Secure Messaging and Communication](/opsec/old/network-communication/telegram) - Best practices for secure messaging platforms, including Telegram 2. [Wireless Network Security](/opsec/old/network-communication/wireless-security) - Securing WiFi and other wireless networks 3. \[Virtual Private Networks (VPNs)] {/*TODO: link not found: ./vpn-security.md */} - Implementing and using VPNs securely 4. \[Secure Remote Access] {/*TODO: link not found: ./remote-access.md */} - Approaches for secure remote access to organizational resources 5. \[Network Monitoring and Defense] {/*TODO: link not found: ./network-monitoring.md */} - Tools and techniques for monitoring network activity and detecting threats ### Risk-Based Approach Network and communication security should be implemented based on the sensitivity of the data being transmitted and the criticality of the communication channels: 1. Identify critical communication channels and the types of data transmitted 2. Assess the potential impact of communication interception or disruption 3. Implement appropriate security controls based on risk levels 4. Regularly test and audit communication security measures ### Web3 Considerations In Web3 environments, network and communication security includes additional considerations: * The role of public blockchain networks in your communications infrastructure * The security of RPC endpoints and node connections * Protection against blockchain-specific network attacks * Balancing transparency with confidentiality in blockchain communications The guidance in this section addresses both traditional and Web3-specific network and communication security considerations. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Telegram Refer to Community Management's [Telegram section](/community-management/telegram) for more information. ### 1. Use Two-Step Verification * **Enable Two-Step Verification:** Protect your account with an additional password to ensure that even if someone has your phone number, they cannot access your account without the additional password. * Go to **Settings** > **Privacy and Security** > **Two-Step Verification** and set up a password. ### 2. Enable End-to-End Encryption for Secret Chats * **Use Secret Chats:** For sensitive conversations, use Telegram's Secret Chats, which are end-to-end encrypted and not stored on Telegram’s servers. * Start a new secret chat by selecting a contact, tapping on their name at the top, and choosing **Start Secret Chat**. ### 3. Set Self-Destruct Timers for Messages * **Self-Destruct Timers:** In Secret Chats, set a self-destruct timer for messages, which automatically deletes messages after a set period of time. * Tap the clock icon in the message input bar within a secret chat to set the timer. ### 4. Control Your Online Presence * **Manage Last Seen and Online Status:** Control who can see your last seen and online status by adjusting your privacy settings. * Go to **Settings** > **Privacy and Security** > **Last Seen & Online** and select who can see your status. ### 5. Limit Who Can Add You to Groups * **Group and Channel Privacy:** Restrict who can add you to groups or channels to prevent being added to unwanted or potentially malicious groups. * Go to **Settings** > **Privacy and Security** > **Groups & Channels** and select your preferences. ### 6. Use a Strong Passcode Lock * **Enable Passcode Lock:** Set a passcode to lock the Telegram app, adding an extra layer of security. * Go to **Settings** > **Privacy and Security** > **Passcode Lock** and set up a passcode. ### 7. Review Active Sessions Regularly * **Active Sessions:** Monitor and terminate any unauthorized active sessions to ensure no one else is accessing your account. * Go to **Settings** > **Privacy and Security** > **Active Sessions** to review and manage your sessions. ### 8. Avoid Clicking on Suspicious Links * **Beware of Phishing:** Do not click on suspicious links sent by unknown contacts. These could lead to phishing attempts or malware. ### 9. Control Data Sharing * **Manage Contact Syncing:** Disable contact syncing if you want to prevent Telegram from accessing your contact list. * Go to **Settings** > **Privacy and Security** > **Data Settings** > **Contacts** and toggle off **Sync Contacts**. ### 10. Be Cautious with Public Channels and Bots * **Join Public Channels Wisely:** Only join public channels and interact with bots from trusted sources, as they can collect your data. * **Review Bot Permissions:** Be cautious about giving bots access to your account information. ### 11. Regularly Update the App * **Keep Telegram Updated:** Ensure you are using the latest version of Telegram to benefit from the latest security patches and features. * Check your app store regularly for updates or enable automatic updates. ### 12. Avoid Using Third-Party Telegram Apps * **Use the Official App:** Stick to the official Telegram app for the best security and privacy protections. * Download from the official Telegram website or your device's official app store. ### 13. Backup Your Two-Step Verification Password * **Store Your Password Safely:** Ensure you store your two-step verification password in a secure password manager to avoid being locked out of your account. ### 14. Disable Automatic Media Download * **Control Media Download:** Disable or limit automatic media downloads to prevent unwanted files from being stored on your device. * Go to **Settings** > **Data and Storage** > **Automatic Media Download** and adjust your preferences. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Wireless Security Wireless networks offers convenience and flexibility. However, they also present unique security challenges. ### Key Components of Wireless Security #### Secure Network Configuration 1. Use WPA3 (Wi-Fi Protected Access 3) for the highest level of security. If WPA3 is not available, use WPA2 with AES encryption. 2. Disable SSID broadcasting to hide the network from casual discovery, although it's still visible by scanners. Use a non-identifiable SSID that does not reveal the project’s name or purpose. 3. Segment the wireless network from the wired network, if you have critical devices connected via the wired network that does not require someone to access it from the wireless network. Use VLANs to separate different types of traffic and limit access to sensitive resources. #### Access Control 1. Use strong, unique passwords for network access. Never use default passwords provided by the manufacturer. 2. Consider implementing MAC address filtering to restrict network access to authorized devices only. Regularly update the list of allowed devices. 3. Consider using enterprise-grade authentication methods, such as 802.1X with RADIUS, to authenticate users before granting network access. #### Monitoring and Intrusion Detection 1. Deploy WIDS to monitor for suspicious activities, unauthorized devices, and rogue access points, especially if built into the wireless network system of your choice. 2. Monitor network traffic for unusual patterns that may indicate a security breach or attack, which can be enabled on some wireless network devices. #### Device Security 1. Regularly update the firmware of wireless access points and routers to patch security vulnerabilities. 2. Disable unnecessary services and features on wireless devices to reduce the attack surface. Implement strong access controls and change default settings. 3. Secure wireless access points in locked enclosures to prevent tampering and unauthorized access. ### Best Practices for Wireless Security #### Network Security 1. Consider the security implications of someone obtaining access into your network via an activated inbound VPN connection, and make configurations to prevent a disaster should this happen, if inbound VPN must be enabled. 2. Create a secure wireless network for your work, and use a less safe wireless network for other devices such as IoT devices, TVs, and other types of non-work related devices that is on a restricted network. #### Guest Networks 1. Set up a separate guest network for friends and temporary users. Ensure it is isolated from the main corporate network. 2. Restrict guest network access to the internet only. Implement bandwidth limits and usage policies to prevent abuse. *** ## Alert Thresholds & Dashboards ## Log Management & SIEM ## Countermeasure Selection & Implementation ## Identify Information & Assets import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## OpSec Lifecycle The Operational Security Lifecycle provides a structured approach to implementing and maintaining security controls. This section outlines the key phases of this lifecycle and how they work together to create a comprehensive security program. ### Overview of the OpSec Lifecycle The Operational Security Lifecycle consists of five interconnected phases: 1. **Identify Information & Assets**: Determine what needs protection 2. **Threat Modeling & Analysis**: Identify potential threats 3. **Vulnerability Assessment**: Identify weaknesses that could be exploited 4. **Risk Assessment & Prioritization**: Evaluate and prioritize risks 5. **Countermeasure Selection & Implementation**: Deploy appropriate security controls This lifecycle is not a one-time process but rather a continuous cycle of assessment, implementation, and improvement. ### Section Outline * [Identify Information & Assets](/opsec/old/lifecycle/identify) — map critical systems, data, and relationships. * [Threat Modeling & Analysis](/opsec/old/lifecycle/threat-modeling) — catalogue realistic adversaries and attack paths. * [Vulnerability Assessment](/opsec/old/lifecycle/vulnerability-assessment) — measure weaknesses across people, process, and tech. * [Risk Assessment & Prioritization](/opsec/old/lifecycle/risk-prioritization) — score risks to focus mitigations. * [Countermeasure Selection & Implementation](/opsec/old/lifecycle/countermeasures) — choose and deploy the right safeguards. ### Phase 1: Identify Information & Assets The first phase involves identifying the critical information and assets that require protection. This includes: * Sensitive data and information * Critical systems and infrastructure * Key personnel and their roles * Operational processes and procedures * Intellectual property and proprietary information By identifying what needs protection, organizations can focus their security efforts on their most valuable assets. ### Phase 2: Threat Modeling & Analysis Once critical assets are identified, the next phase involves analyzing potential threats to those assets. This includes: * Identifying potential threat actors (hackers, insiders, competitors, etc.) * Analyzing their capabilities, motivations, and methods * Mapping potential attack vectors and scenarios * Considering both technical and non-technical threats * Evaluating the evolving threat landscape Effective threat modeling provides insights into the specific threats that an organization faces, enabling more targeted security measures. ### Phase 3: Vulnerability Assessment The vulnerability assessment phase identifies weaknesses that could be exploited by threats. This includes: * Technical vulnerabilities in systems and applications * Weaknesses in security processes and procedures * Gaps in security awareness and training * Physical security vulnerabilities * Supply chain and third-party vulnerabilities By identifying vulnerabilities, organizations can understand where their defenses may be inadequate. ### Phase 4: Risk Assessment & Prioritization The risk assessment phase evaluates the likelihood and potential impact of threats exploiting vulnerabilities. This includes: * Assessing the probability of successful attacks * Evaluating the potential impact on operations, finances, and reputation * Calculating risk levels based on likelihood and impact * Prioritizing risks based on severity and resource constraints * Considering risk acceptance, mitigation, transfer, or avoidance options Risk assessment enables organizations to focus their security resources on the most significant risks. ### Phase 5: Countermeasure Selection & Implementation The final phase involves selecting and implementing security controls to address identified risks. This includes: * Choosing appropriate technical, procedural, and physical controls * Implementing controls based on risk priorities * Testing the effectiveness of implemented controls * Training staff on new security measures * Documenting the implementation and configuration of controls Effective countermeasure implementation transforms security planning into practical protection. ### Continuous Improvement The OpSec Lifecycle is not a linear process but a continuous cycle of improvement: * Regular reassessment of assets, threats, vulnerabilities, and risks * Monitoring the effectiveness of implemented controls * Adapting to changes in the threat landscape and organizational environment * Learning from security incidents and near-misses * Updating security measures based on new technologies and best practices Through continuous improvement, organizations can maintain an effective security posture in the face of evolving threats. ### Web3-Specific Considerations In Web3 environments, the OpSec Lifecycle must address unique considerations: * **Asset Identification**: Including cryptocurrency holdings, smart contracts, and private keys * **Threat Modeling**: Addressing blockchain-specific threats like 51% attacks and MEV * **Vulnerability Assessment**: Considering smart contract vulnerabilities and consensus mechanisms * **Risk Assessment**: Evaluating the immutable nature of blockchain transactions * **Countermeasures**: Implementing controls specific to cryptocurrency and blockchain operations By adapting the OpSec Lifecycle to these considerations, Web3 organizations can develop security programs that address their unique risk profiles. *** ## Risk Assessment & Prioritization ## Threat Modeling & Analysis ## Vulnerability Assessment ## Containment, Eradication & Recovery ## Playbooks import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Detecting and Mitigating Insider Threats Insider threats, whether intentional or unintentional, pose a significant risk to any project. These threats can come from current or former employees, contractors, or business associates who have inside information concerning the project's security practices, data, and computer systems. Effective detection and mitigation strategies are crucial for safeguarding your project against these risks. ### What Are Insider Threats? Insider threats can be categorized into three main types: 1. **Malicious Insiders**: Individuals who intentionally cause harm to the project by stealing data, sabotaging systems, or leaking sensitive information. 2. **Negligent Insiders**: Team members who unintentionally cause security breaches through careless actions, such as falling for phishing attacks or mishandling sensitive data. 3. **Compromised Insiders**: Team members whose accounts or systems are compromised by external threat actors and used to gain access to the project's resources. ### Understanding Insider Threat Motivations Understanding what motivates insider threats is crucial for detection and prevention: #### Financial Motivations * Financial gain is one of the most common motivations * Employees may be offered substantial bribes to compromise systems * In the blockchain space, the potential rewards can be particularly high #### Coercion and Social Engineering * External actors may blackmail or threaten employees to gain cooperation * Social engineering techniques can manipulate employees into providing access * As reported by Krebs on Security, employees at domain registrars have been targeted by threat actors who persuaded them to modify DNS records or provide unauthorized access to high-value domains[^1] #### Ideological or Political Reasons * Some insiders act based on political beliefs or ideological disagreements * They may believe they're exposing perceived wrongdoing or supporting a cause #### Personal Grievances * Disgruntled employees seeking revenge for perceived mistreatment * Former employees with lingering access and unresolved issues #### Lack of Awareness * Some insiders don't realize the value of what they're compromising * They may not understand the security implications of their actions #### Some Examples * The 2020 Twitter breach exemplifies compromised insiders - employees with legitimate access were socially engineered to provide their credentials, allowing attackers to take control of high-profile accounts[^2]. While the employees didn't intend harm, they became unwitting insider threats after being manipulated. * Similarly, the 2022 Ronin Network hack ($625 million) began with social engineering of a Sky Mavis senior engineer. This employee became a compromised insider, giving attackers access to four validator nodes. Combined with a third-party validator, this allowed the massive cryptocurrency theft[^3]. This demonstrates how social engineering creates insider threats even when employees have no malicious intent. * The 2019 SIM-swapping attacks represent a more direct insider threat scenario. Mobile carrier employees were bribed or socially engineered to transfer victims' phone numbers to attacker-controlled SIMs. In Michael Terpin's case against AT\&T, an employee allegedly accepted payment to compromise his account, leading to $24 million in cryptocurrency theft[^4]. This represents both compromised insiders and potentially malicious insiders who knowingly participated in exchange for payment. These examples highlight the intersection of social engineering and insider threats, where external attackers manipulate employees to gain unauthorized access. [^1]: Brian Krebs, "How Paypal and GoDaddy Got Hijacked: A Cautionary Tale," Krebs on Security, 2019. [^2]: Twitter Support, "An update on our security incident," Twitter Blog, July 2020. [^3]: Ronin Network, "Ronin Network Breach Postmortem," April 2022. [^4]: "Cryptocurrency investor sues AT\&T for $224 million over SIM-swap fraud," Reuters, August 2018. ### Detecting Insider Threats #### Monitoring and Analytics 1. Implement systems to monitor team member's activity and identify unusual behavior patterns. This includes tracking logins and on-chain transactions related to the project. 2. Use anomaly detection to establish a baseline of normal user behavior and detect deviations that may indicate malicious activity. #### Access Controls 1. Implement RBAC to ensure that employees have access only to the information and systems necessary for their job functions. 2. Enforce the principle of least privilege, granting users the minimum level of access required to perform their duties. 3. Conduct regular reviews of user access permissions to ensure they are still appropriate for their current roles. #### Training and Awareness 1. Conduct regular security training sessions to educate employees about the risks of insider threats and the importance of following security protocols. 2. Run (spear) phishing simulations to test employees' awareness and response to potential (spear) phishing attacks. ### Mitigating Insider Threats #### Incident Response Plan 1. Create a detailed [incident response plan](/incident-management/overview) that outlines the steps to be taken in the event of an insider threat incident. 2. Clearly define roles and responsibilities for the incident response team to ensure a coordinated and effective response. #### Technical Controls 1. Require MFA for access to critical systems and sensitive data to add an extra layer of security. 2. Encrypt sensitive data both at rest and in transit to protect it from unauthorized access. #### Project Policies 1. Establish clear policies and procedures for handling sensitive information and responding to security incidents. 2. Be aware that malicious organizations/countries may try to obtain access to your project for reasons of financial or technology theft. Conduct thorough background checks on new employees and contractors to identify potential risks. 3. Implement strict exit procedures for departing employees, including revoking access to systems and multi-signature wallets. #### Behavioral and Cultural Measures 1. Foster a \[culture of security awareness] {/* TODO: link not found: ../../awareness/security-culture/overview.md */} where team members understand the importance of protecting sensitive information and reporting suspicious activities. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Human-Centered Security Security is not just about technology—it's about people. The human element is often the most vulnerable part of any security system, making human-centered security approaches essential for a robust operational security posture. ### Introduction Human-centered security focuses on understanding, supporting, and enhancing the security behaviors of individuals within an organization. It recognizes that security is a shared responsibility and that technical controls alone cannot provide comprehensive protection without considering the human factors involved. ### Key Components This section covers the following aspects of human-centered security: 1. [Insider Threat Detection and Mitigation](/opsec/old/human-centered-security/detecting-and-mitigating-insider-threats) * Strategies for identifying and mitigating risks posed by insiders 2. [Social Engineering Defense](/opsec/old/human-centered-security/social-engineering-defense) - Techniques to protect against manipulation and deception 3. [Travel Security](/opsec/old/human-centered-security/travel-security) - Security considerations for team members when traveling 4. [Personal OpSec for Team Members](/opsec/old/human-centered-security/personal-opsec) - Guidelines for individuals to maintain security in their personal activities ### Intersection with Awareness While this section focuses on operational measures to address human-centered security, it works in close conjunction with the [Security Awareness Framework](/awareness/overview). The awareness framework provides the educational foundation, while human-centered security implements the operational controls and procedures needed to protect against human-related security risks. ### Risk-Based Approach Not all human-centered security risks are equal. Organizations should adopt a risk-based approach by: 1. Identifying roles with access to critical assets or sensitive information 2. Assessing the potential impact of human errors or malicious actions 3. Implementing controls proportionate to the identified risks 4. Creating an environment where security is valued and prioritized Focusing on human factors in security, organizations can create a more resilient security posture that combines technical controls with human awareness and behavior. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Personal OpSec for Team Members Personal operational security (OpSec) extends beyond the workplace, encompassing practices that team members should implement in their personal lives to protect both themselves and organizational assets. This is particularly important in Web3 where the boundaries between personal and professional digital presence are often blurred. ### Digital Footprint Management #### Social Media Practices 1. Regularly audit and adjust privacy settings on all social media platforms 2. Be cautious about revealing employment details, especially for high-profile or security-sensitive roles 3. Avoid sharing location data in real-time, particularly during travel 4. Consider using separate accounts for professional and personal interactions 5. Be mindful of information revealed in photos, including backgrounds that might expose sensitive information #### Public Information Minimization 1. Periodically search for your own name and digital identifiers to understand your public exposure 2. Request removal of sensitive personal information from data broker sites 3. Use domain privacy services if you own personal domains 4. Consider using pseudonyms for non-professional online activities where appropriate and legal ### Personal Device Security #### Home Network Security 1. Secure home Wi-Fi networks with strong passwords and WPA3 encryption when available 2. Segment networks to separate IoT devices from computers used for work 3. Keep router firmware updated and change default administrative credentials 4. Consider using a dedicated VLAN for work activities conducted from home #### Personal Device Hardening 1. Apply the same security standards to personal devices used for work as corporate devices 2. Implement automatic updates for operating systems and applications 3. Use password managers to maintain strong, unique passwords across services 4. Enable full-disk encryption on all personal devices 5. Install and maintain reputable security software ### Secure Communication Practices 1. Use end-to-end encrypted messaging platforms for sensitive communications 2. Be aware of metadata exposure even when content is encrypted 3. Verify security of communication channels before discussing sensitive topics 4. Consider using separate phone numbers or identifiers for high-security communications 5. Apply appropriate security measures to personal email accounts, including MFA ### Physical Security Awareness 1. Be conscious of physical surroundings when accessing sensitive information 2. Secure physical documents and devices at home, especially when traveling 3. Consider appropriate home security measures based on role sensitivity 4. Practice good physical security habits like using privacy screens in public places ### Web3-Specific Personal OpSec #### Cryptocurrency Security 1. Separate personal and work-related wallets and accounts 2. Apply strong security practices to personal crypto holdings 3. Be cautious about revealing personal cryptocurrency holdings or involvement in projects 4. Consider the implications of blockchain transparency and on-chain activity linkability 5. Use hardware wallets for long-term storage of significant personal assets #### Identity Separation 1. Consider separating on-chain identities used for work from personal activities 2. Be aware of how personal ENS names or identifiers may link to work-related activities 3. Understand the risks of doxing in the Web3 space and take appropriate precautions ### Personal Threat Modeling 1. Assess personal risk based on role, project visibility, and asset access 2. Identify potential adversaries and their capabilities 3. Implement security measures proportionate to identified risks 4. Periodically reassess as role or external factors change ### Balance and Sustainability 1. Focus on high-impact security practices that are sustainable long-term 2. Recognize that perfect security is impossible and aim for reasonable protections 3. Develop habits that incorporate security into daily routines 4. Understand the trade-offs between convenience and security in personal life ### Reporting and Support 1. Know how to report suspicious activities that might target you personally due to your role 2. Understand what organizational support is available for personal security incidents 3. Maintain awareness of current threats targeting individuals in your industry or role By implementing personal OpSec practices, team members can significantly reduce security risks that originate outside the workplace while maintaining a reasonable balance between security and quality of life. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Social Engineering Defense Social engineering attacks target the human element of security by manipulating individuals into breaking security protocols, revealing sensitive information, or granting unauthorized access. Defending against these attacks requires a combination of awareness, training, and operational controls. ### Understanding Social Engineering Social engineering encompasses various manipulation techniques that exploit human psychology rather than technical vulnerabilities. For a comprehensive overview of common attack vectors, refer to our \[Security Awareness Attack Vectors] {/*TODO: link not found: /awareness/attack-vectors/README */} documentation. ### General Defense Strategies Regardless of the specific social engineering technique, several core defensive measures are effective: 1. **Implement Verification Protocols**: Establish multi-step verification procedures for sensitive requests, especially those involving financial transactions, credential changes, or access modifications 2. **Develop a Questioning Culture**: Encourage team members to verify unexpected requests through alternative communication channels, even when they appear to come from trusted sources 3. **Technical Controls**: Deploy appropriate filtering, monitoring, and access control systems to detect and prevent social engineering attempts 4. **Regular Training**: Conduct ongoing security awareness training with realistic scenarios based on current threats 5. **Clear Reporting Mechanisms**: Create simple, accessible ways for team members to report suspected social engineering attempts ### Specific Defensive Considerations While general principles apply broadly, some attack vectors require specific defensive approaches: #### Phishing Defense Email and messaging-based deception requires specialized filtering solutions and training team members to recognize suspicious indicators like sender addresses, grammatical errors, and urgent requests. #### Voice and In-Person Manipulation Defense For pretexting, vishing, and impersonation attacks, implement strict identity verification procedures and establish clear escalation paths for unusual requests. #### Physical Security Considerations To counter baiting, tailgating, and physical social engineering, develop protocols for handling unknown devices, visitor management, and physical access controls. ### Cross-Function Collaboration Effective social engineering defense requires collaboration across multiple organizational functions: 1. **Security Teams**: Implement technical controls and monitoring systems 2. **Human Resources**: Incorporate security awareness into onboarding and ongoing training 3. **Communications**: Develop clear guidelines for verifying the authenticity of communications 4. **Leadership**: Demonstrate a commitment to security through policies and practices ### Integration with Threat Intelligence 1. Stay informed about emerging social engineering tactics through threat intelligence sources 2. Update training materials and defenses based on current threat landscape 3. Share information about attempted attacks with the broader security community when appropriate ### Incident Response for Social Engineering Attacks 1. Document all suspected social engineering attempts 2. Establish clear reporting mechanisms for team members who believe they've been targeted 3. Create specific response procedures for different types of social engineering attacks 4. Conduct post-incident reviews to identify lessons learned and improve defenses ### Building Resilience The goal of social engineering defense is not just to prevent specific attacks but to build organizational resilience: 1. Foster a security culture where questioning unusual requests is encouraged, not penalized 2. Develop and practice "security skepticism" as a valued trait 3. Design systems and processes with human behavior in mind, acknowledging that perfect compliance is unrealistic Combining technical controls with human awareness and organizational procedures, teams can significantly reduce their vulnerability to social engineering attacks. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Travel Security Team members traveling for business purposes face unique security risks that require specialized preparation and awareness. Effective travel security measures help protect both the individual and organizational assets during travel. ### Pre-Travel Preparation #### Risk Assessment 1. Assess destination-specific risks including political stability, crime rates, health concerns, and local laws 2. Consider the sensitivity of work to be conducted during travel and adjust security measures accordingly 3. Consult reliable sources such as government travel advisories and internal threat intelligence #### Device Preparation 1. Use dedicated travel devices whenever possible, with minimal data and applications 2. Update all software and security patches before departure 3. Enable full-disk encryption on all devices 4. Install and test VPN software prior to departure 5. Consider using temporary travel accounts with limited access to organizational resources 6. Backup all data before departure and store the backup securely #### Documentation and Emergency Planning 1. Create copies of important documents (passport, visas, insurance) 2. Establish emergency communication protocols and points of contact 3. Share itinerary details with appropriate team members 4. Register with embassy or consular services when traveling to high-risk locations ### In-Transit Security 1. Maintain physical control of devices and sensitive items at all times 2. Be aware of shoulder surfing when working on sensitive information 3. Avoid connecting to public or hotel Wi-Fi networks without VPN protection 4. Disable Bluetooth, Wi-Fi, and other wireless connectivity when not in use 5. Consider using privacy screens to prevent visual data leakage ### On-Location Security #### Physical Security 1. Store sensitive devices in hotel safes when not in use, or maintain physical possession 2. Be aware of surroundings and potential surveillance or targeting 3. Avoid discussing sensitive business matters in public spaces 4. Use privacy screens when working in public areas #### Digital Security 1. Connect to corporate networks only through secure VPN channels 2. Be cautious of USB charging stations which may present data theft risks 3. Report any suspicious activity or security incidents immediately 4. Exercise extra caution when connecting to Wi-Fi networks 5. Use mobile hotspots from trusted providers when possible ### Post-Travel Procedures 1. Inspect devices for signs of tampering 2. Change passwords used during travel 3. Run security scans on all devices before reconnecting to corporate networks 4. Report any suspicious incidents or security concerns 5. Debrief with security team about any potential security issues encountered ### Special Considerations for High-Risk Locations 1. Consider using "burner" devices for travel to high-risk locations 2. Establish more frequent check-in protocols 3. Be aware of local surveillance capabilities and legal requirements for device inspection 4. Prepare for potential device confiscation at borders by minimizing sensitive data 5. Consider using end-to-end encrypted communication methods ### Web3-Specific Travel Security 1. Use hardware wallets for storing crypto assets and keep them physically secure 2. Be cautious about revealing cryptocurrency holdings or involvement in high-value projects 3. Consider using duress passwords or accounts if traveling to high-risk regions 4. Be aware of targeted attacks at crypto conferences and events 5. Establish specific protocols for transaction approvals while traveling ### Integration with Other Security Frameworks Travel security integrates with several other security frameworks: 1. [Device and Endpoint Security](/opsec/old/device-endpoint-security/overview) for device hardening practices 2. [Digital Identity and Access Management](/opsec/old/digital-identity-access/overview) for authentication during travel 3. [Physical Security](/opsec/old/physical-security/overview) for protecting physical assets By implementing comprehensive travel security measures, organizations can significantly reduce risks associated with business travel while enabling team members to work effectively and safely when away from their primary work location. *** ## Security policies & roles ## Third-party/vendor governance ## Digital Identity and Access Management import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Password/Secrets Management Effective management of passwords and cryptographic keys help maintain the security and integrity of digital assets and sensitive information. ### Best Practices 1. Do not reuse passwords across services as it increases the risk of multiple accounts being compromised when one service is breached. Instead, use a password vault that can generate complex, random, and unique passwords for each service. * While browsers provide password vaults with passwords, it is recommended to use an external password vault with improved security features. 2. Check if your email has been in any breach on [Have I Been Pwned](https://haveibeenpwned.com/) and set up notifications for future breaches. Change passwords on the services where you may have been breached. 3. If you suspect a breach of your password, change it as soon as possible. 4. Use MFA whenever possible. It is a key measure in preventing account breaches. It is highly recommended to use a hardware token such as Yubikey to protect your accounts. If you use a mobile authenticator such as Authy to store your MFA tokens, ensure that you also set an encryption password to mitigate the risk of SIM swapping. Avoid using SMS for MFA unless there is no other option, as there are multiple cases where people have been SIM swapped and their accounts taken over. If SMS is the only option, it is still better than having no MFA enabled at all. It is recommended to not use the password manager/vault used for your passwords to store your MFA codes. 5. **Reminder:** Do not derive wallets from self generated passwords, even if they look random. It is very easy to make mistakes in the derivation process and end up with a wallet that is easy to compromise. It is always better to use an appropriate wallet software to generate your seed phrases. ### Password and Key Security #### Passphrases Utilizing long, memorable phrases as passwords. They are easier to remember than complex passwords and can be equally secure. For example, "CorrectHorseBatteryStaple" is more secure and memorable than a shorter, complex password. ![XKCD Password Strength](https://imgs.xkcd.com/comics/password_strength.png) #### Password Cards (e.g., Qwertycards) Aids in generating and recalling complex passwords using a physical card as a mnemonic device. These can be particularly useful for creating strong, unique passwords without relying on digital tools. #### Non-default BIP-44 Derivation Path Using custom paths for key generation in crypto wallets to enhance security. For example, MyEtherWallet allows users to set custom derivation paths. #### Password Managers Digital solutions for securely storing and managing various passwords. They reduce the risk of password reuse and simplify password management by generating and storing complex, unique passwords for each service. ### Key Storage and Recovery #### Memory and Notebook Relying on human memory or physical writing to store keys. It's highly secure against digital theft but vulnerable to forgetting or physical loss. Always have a secure backup plan. #### Paper Wallets Involves printing or writing down keys on paper. Offers protection from online hacks but can be lost, damaged, or deteriorate over time. Store paper wallets in secure, dry, and fireproof locations. #### Encrypted Drives Storing keys on encrypted drives balances digital convenience with security. However, it is vulnerable to physical theft and damage. Always have multiple backups in different locations. #### Back-ups / Rotation / Recovery Regular backup and update of key information to ensure recovery. This is critical for maintaining access in case of primary key loss. Use secure, redundant backup solutions and periodically test recovery procedures. #### Shamir Backup Shamir's Secret Sharing is a method to split a secret, such as a private key, into multiple parts, where a subset of these parts is required to reconstruct the secret. This enhances security and ensures recoverability. ### Authentication and Access Control #### 2FA / MFA (Multi-Factor Authentication) Employs multiple verification methods, significantly increasing security by adding layers beyond just passwords. Use hardware tokens like Yubikeys for the highest level of security. #### SSO (Single Sign-On) Allows using one set of credentials to access multiple services. Convenient but necessitates strong security for the primary credentials. Ensure SSO solutions are configured with strong security measures and regularly audited. #### Trusted Key Management System (KMS) Systems designed to manage and protect digital keys, critical for securing cryptographic operations and sensitive data. Use a reputable KMS to handle key generation, storage, and rotation securely. #### Hardware Security Keys Physical devices used for authentication, offering a high level of security against remote attacks. They are particularly effective when combined with MFA. ### Biometric Security #### Fingerprint Scanners Uses fingerprints, unique to every individual, as a means of secure and convenient authentication. They are widely used in mobile devices and some laptops. #### Facial Recognition Employs facial characteristics for verification, increasingly popular in mobile and personal devices. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## SIM Swapping SIM swapping occurs when a threat actor trick a mobile phone provider into transferring a victim's phone number to a SIM card that the criminals control. This allows the criminals to intercept the victim's text messages and phone calls, including any two-factor authentication codes. With access to the victim's phone number, the criminals can then gain unauthorized access to the victim's accounts. ### Stop Using SMS-Based 2FA This is by far the most important thing you can do to protect yourself against SIM swaps. Think about your most important online accounts and how valuable they are to an attacker: * They can read all the information available on that account. This includes emails, photos, private messages, or embarrassing details from years ago that you forgot you sent. * They can steal everything of value in that account, like money, crypto, important documents, or other personal information. * They can use it to impersonate you while scamming people you know, putting them at risk and putting you in a really tough spot. If this thought scares you, you should go and **make sure SMS 2FA is disabled** for any account that you care about. Instead, consider using either an app like Google Authenticator (make sure to disable cloud sync!) or a security key (e.g., Yubico). Avoid using Authy, as it is tied to your phone number too. Not sure where to start? Here’s a brief list of services to inspire you: * **Email**: Gmail, Yahoo * **Social Media**: Facebook, Twitter * **Instant Messaging**: Telegram, Discord * **Crypto Exchanges**: Coinbase, Gemini, Binance * **Domain Registrars**: GoDaddy, Squarespace * **Banking**: PayPal, Revolut ### Switch to a High-Security Carrier The next best thing you can do is to simply switch to a new carrier entirely. Generally speaking, there are two ways that an attacker can compromise your phone number: * Social engineer a support agent (easier) * Compromise an insider (harder) By switching to a high-security carrier, you reduce or eliminate the risk from social engineering, but you’re still at risk of an insider attack. Unfortunately, there’s almost nothing you can do to defend against that. #### USA If you live in the USA, you get the option of one of the big three Mobile Network Operators: AT\&T, Verizon, and T-Mobile. None is perfect, but AT\&T and Verizon are slightly ahead in terms of security reputation, while T-Mobile has been compromised a handful of times. ##### Google Fi [Google Fi](https://fi.google.com/) is an MVNO using T-Mobile’s network and only offers online support via your Google account. Given the seriousness that Google approaches security with, Google Fi is one of the most secure self-service carriers you can choose in the USA. This is even more so if you enable Advanced Protection on your Google account. For an added bonus, you might consider creating a new Google account under a fake name and purchasing Google Fi from there. This will ensure that an insider at T-Mobile won’t be able to find your phone number by name. ##### Efani [Efani](https://www.efani.com/) is an MVNO using AT\&T’s and Verizon’s networks and is designed for high-risk individuals. Efani has negotiated agreements in which they are responsible for manually approving requests to modify subscriber accounts instead of allowing agents at AT\&T or Verizon to make those changes. Efani also masks your information before submitting it to the MNOs, making it harder for an insider to locate your account. ### Place a Note on Your Carrier Account If you can’t switch carriers or no secure carriers are available in your area, your next option is to mitigate the likelihood of a support agent being social engineered. Some carriers will offer this explicitly (for example, some sort of account lock that you can opt into). If there is no option, you may need to either call or go in-store and ask for a note to be placed on your account. Keep in mind that some support agents may not know about SIM swapping, and that’s not their fault. If this happens, you might need to politely ask to speak to a manager or just come back another day. Also, keep in mind that while you may be able to add an internal note to your account, there’s no guarantee that whatever support agent who is communicating with a scammer will actually read the note. The scammer may also be able to convince the agent that they’re desperately in need to regain access quickly, and to ignore the note entirely. As such, placing a note on your account is a nice additional measure but not nearly as effective as simply disabling SMS 2FA on your accounts. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Device and Endpoint Security Securing the devices used by your organization is a critical component of operational security. Endpoints such as laptops, desktops, mobile devices, and servers are common entry points for attackers and require robust protection. ### Introduction Device and endpoint security encompasses the policies, tools, and practices that protect individual computing devices from threats. As the boundary between work and personal devices blurs, and as remote work becomes more common, securing endpoints has become increasingly challenging and important. ### Key Components This section covers the following aspects of device and endpoint security: 1. [Standard Operating Environment](/opsec/old/device-endpoint-security/standard-operating-environment) - Establishing and maintaining secure baseline configurations 2. \[Endpoint Protection] {/*TODO: link not found : ./endpoint-protection.md */} - Tools and technologies to protect endpoints from malware and other threats 3. \[Mobile Device Security] {/*TODO: link not found : ./mobile-device-security.md */} - Securing smartphones, tablets, and other mobile devices 4. \[Secure Configuration] {/*TODO: link not found : ./secure-configuration.md */} - Hardening devices through secure configuration practices 5. \[Patch Management] {/*TODO: link not found : ./patch-management.md */} - Keeping systems updated to address known vulnerabilities ### Risk-Based Approach Device and endpoint security should be implemented based on the sensitivity of the data being handled and the criticality of the device to operations: 1. Inventory all devices that access organizational resources 2. Classify devices based on the data they handle and criticality to operations 3. Implement appropriate security controls based on risk levels 4. Regularly audit device compliance with security policies ### Web3 Considerations In Web3 environments, device and endpoint security includes additional considerations: * Securing devices used for cryptocurrency transactions and wallet security * Protecting hardware wallets and other specialized Web3 hardware * Addressing the risks of browser-based Web3 interactions * Securing devices that participate in blockchain networks (e.g., validator nodes) The guidance in this section addresses both traditional and Web3-specific device and endpoint security considerations. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Standard Operating Environment A Standard Operating Environment (SOE) refers to a standardized and controlled computing environment used across a project. It ensures that all devices and systems adhere to the same security policies, configurations, and software versions, thereby reducing vulnerabilities and simplifying management. ### Key Components of an SOE #### Device Configuration 1. Ensure all workstations and mobile devices use [full-disk encryption](/encryption/full-disk-encryption) to protect data at rest. 2. Configure devices to automatically apply critical security patches and updates. 3. Ensure all installed applications are regularly updated to their latest versions to mitigate vulnerabilities. 4. Never leave workstations unlocked and unattended. 5. Operating Systems commonly affected by malicious software should have anti-malware software installed and running. 6. Ensure the plugins you use for your browser are secure. 7. Avoid using an Administrator account for day-to-day activities. 8. Disable macros on Office products. 9. If a device has been left unlocked with a third party having access without you seeing what they did (e.g., at an airport security check), treat it as having been compromised. #### User Access Controls 1. Grant users the minimum level of access required to perform their job functions. Avoid using administrative accounts for day-to-day activities. 2. Implement RBAC to manage permissions and access based on user roles within the organization. 3. Require MFA for accessing sensitive systems and data. Use hardware tokens (e.g., Yubikeys) for the highest level of security. #### Security Software 1. Install and maintain anti-malware software on all devices where relevant. Ensure it is configured to automatically update and scan regularly. 2. Enable and configure local firewalls on all devices where applicable to control inbound and outbound network traffic. #### Data Management 1. Encrypt sensitive data both in transit and at rest. Use strong encryption standards and manage encryption keys securely. 2. Implement regular backup procedures for all critical data. Ensure backups are encrypted and stored securely offsite or in the cloud. Regularly test recovery processes to ensure data integrity. 3. Classify data based on sensitivity and implement appropriate handling and storage procedures for each classification level. #### Network Security 1. Segment networks to limit access to sensitive systems where applicable. Use virtual LANs (VLANs) and firewalls to enforce segmentation. 2. Require the use of VPNs for remote access to the organization's network. Ensure VPNs use strong encryption protocols. 3. Secure wireless networks using WPA3 or WPA2 with AES encryption. Regularly update Wi-Fi passwords and manage access to authorized devices only. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Data Protection Data is one of an organization's most valuable assets, and protecting it throughout its lifecycle is a critical component of operational security. ### Introduction Data protection encompasses the strategies, policies, tools, and techniques used to secure data at rest, in transit, and in use. It involves not only technical controls but also procedural and administrative measures designed to safeguard sensitive information from unauthorized access, use, disclosure, disruption, modification, or destruction. ### Key Components This section covers the following aspects of data protection: 1. \[Data Classification] {/*TODO: link not found : ./data-classification.md */} - Categorizing data based on sensitivity and value 2. \[Encryption] {/*TODO: link not found : ./encryption.md */} - Protecting data through cryptographic methods 3. \[Data Loss Prevention] {/*TODO: link not found : ./data-loss-prevention.md */} - Controls to prevent unauthorized data exfiltration 4. \[Secure Data Sharing] {/*TODO: link not found : ./secure-data-sharing.md */} - Methods for securely sharing data with authorized parties 5. \[Data Backup and Recovery] {/*TODO: link not found : ./data-backup-recovery.md */} - Ensuring data availability and resilience 6. \[Data Minimization and Retention] {/*TODO: link not found : ./data-minimization-retention.md */} - Principles for data lifecycle management ### Risk-Based Approach Data protection should be implemented based on the sensitivity and value of the data being protected: 1. Identify and classify data based on sensitivity and regulatory requirements 2. Assess the potential impact of data breaches or loss 3. Implement appropriate security controls based on risk levels 4. Regularly audit data protection measures and adapt to evolving threats ### Web3 Considerations In Web3 environments, data protection includes additional considerations: * The balance between on-chain transparency and privacy * Protecting cryptographic secrets that control assets * The implications of immutable data stored on blockchains * Privacy-preserving techniques for blockchain interactions The guidance in this section addresses both traditional and Web3-specific data protection considerations, helping organizations implement appropriate safeguards regardless of their technological environment. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Google Workspace Security Google Workspace (formerly G Suite) is a powerful suite of productivity and collaboration tools widely used by projects. A lot of things may depend on Google Workspace, in which case it is important to consider the security of it. ### Account Security #### Multi-Factor Authentication (MFA) 1. Require all users to enable multi-factor authentication for their Google Workspace accounts. This adds an extra layer of security by requiring a second form of verification in addition to the password. 2. Encourage the use of hardware tokens (e.g., Yubikeys) for MFA instead of SMS, which is more vulnerable to SIM swapping attacks. #### Strong Password Policies 1. Implement policies requiring strong, complex passwords that are regularly updated. 2. Encourage the use of password managers to generate and store unique passwords for each account. ### Access Management #### Role-Based Access Control (RBAC) 1. Implement RBAC to ensure users have access only to the information and applications necessary for their job roles. 2. Conduct regular reviews of user permissions to ensure access levels are appropriate and revoke access for users who no longer need it. #### Least Privilege Principle 1. Ensure users have the minimum level of access necessary to perform their duties. 2. Use Just-In-Time (JIT) access controls to grant temporary access when needed and automatically revoke it after a specified period. ### Data Protection #### Data Loss Prevention (DLP) 1. Set up DLP policies to monitor and protect sensitive information from being shared outside the organization or to unauthorized users. 2. Use DLP to scan emails and documents for sensitive content and enforce policies to prevent data leakage. #### Encryption 1. Use Google Workspace's built-in encryption features to protect emails in transit. 2. Ensure that files stored in Google Drive are encrypted both in transit and at rest. ### Monitoring and Alerts #### Activity Monitoring 1. Enable and regularly review audit logs to track user activities, such as login attempts, file access, and administrative changes. 2. Use the Google Workspace Security Center to monitor security metrics, detect potential threats, and receive alerts for suspicious activities. #### Incident Response 1. Set up alerts for unusual activities, such as multiple failed login attempts, suspicious file sharing, and changes to security settings. 2. Develop and maintain an [incident response plan](/incident-management/overview) specific to Google Workspace, detailing the steps to be taken in the event of a security breach. ### Device Management #### Mobile Device Management (MDM) 1. Use Google Workspace's MDM features to enforce security policies on mobile devices, such as requiring screen locks, enabling encryption, and remotely wiping data if a device is lost or stolen. 2. Maintain an inventory of all devices accessing Google Workspace and regularly audit to ensure compliance with security policies. ### Communication and Collaboration #### Secure Sharing 1. Set policies to control sharing of files and documents within and outside the project. Use link sharing settings that restrict access to only specific people. 2. Use shared drives for team collaboration with appropriate access controls and permissions. #### Email Security 1. Enable advanced spam and phishing protection features to filter out malicious emails. 2. Encourage the use of secure communication channels for sensitive discussions, such as Google Chat with end-to-end encryption. ### Compliance and Governance #### Compliance Settings 1. Configure Google Workspace to comply with relevant regulatory requirements (e.g., GDPR) by using compliance tools and settings. 2. Use Google Workspace Admin Console to enforce security policies and ensure compliance with project and regulatory standards. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Cloud and Third-Party Security In today's interconnected digital ecosystem, organizations rely heavily on cloud services and third-party vendors to operate efficiently. However, these dependencies introduce security risks that must be carefully managed. ### Introduction Cloud and third-party security focuses on protecting data and operations that depend on external providers. It encompasses the assessment, monitoring, and management of security risks associated with cloud services, software-as-a-service (SaaS) applications, and third-party vendors that have access to your systems or data. ### Key Components This section covers the following aspects of cloud and third-party security: 1. [G-Suite Security](/opsec/old/cloud-third-party/g-suite-security) - Securing Google Workspace (formerly G-Suite) environments 2. \[Cloud Security Fundamentals] {/*TODO: link not found : ./cloud-security-fundamentals.md */} - Essential security considerations for cloud environments 3. \[SaaS Security] {/*TODO: link not found : ./saas-security.md */} - Securing software-as-a-service applications 4. \[Vendor Security Assessment] {/*TODO: link not found : ./vendor-security-assessment.md */} - Evaluating and monitoring the security of third-party vendors 5. \[API Security] {/*TODO: link not found : ./api-security.md */} - Securing application programming interfaces ### Risk-Based Approach Cloud and third-party security should be implemented based on the sensitivity of the data being handled and the criticality of the services provided: 1. Inventory all cloud services and third-party relationships 2. Classify providers based on the data they handle and criticality to operations 3. Implement appropriate security controls and monitoring based on risk levels 4. Regularly review and audit third-party security practices ### Web3 Considerations In Web3 environments, cloud and third-party security includes additional considerations: * The security of blockchain infrastructure providers * The risks associated with decentralized services and protocols * The assessment of smart contract dependencies * The security of Web3 development and deployment tools The guidance in this section addresses both traditional and Web3-specific cloud and third-party security considerations. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Mfa > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Multi-Factor Authentication](/opsec/mfa/overview) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Multi-Factor Authentication MFA is necessary but not sufficient as an OpSec strategy. If you have not yet implemented MFA, we suggest making it your first priority as soon as you finish reading this page. Not all MFAs are created equally. A few recommendations: 1. **Stay away from text and email as MFA methods.** There are innumerable reasons why neither of these methods is a good idea. Suffice it to say, best practices have long since outlawed these MFA methods. 2. **TOTP (e.g., Google Authenticator) is good but not great.** Why? It is easy enough to trick users into entering TOTP codes into a phishing site. The methods cited below are more difficult to exploit. Also, any manual typing is susceptible to keyloggers. 3. **Push-based MFA is better.** Why? Because initiating a push notification on iOS/Android requires that the device itself be enrolled with the identity provider. Phishing sites cannot initiate a push notification to the Gmail app, for example, without a major compromise of Google's infrastructure. 4. **Passkeys are the best.** Biometrics are hard to fake, and in a world where attackers are looking for low hanging fruit, passkeys protected by biometric factors are typically too hard for them to reach. However, passkey storage is critical to ensuring that this choice is secure - please read the note below. 5. **Key admins (e.g., your G Suite admin) should be using Yubikeys.** They are inexpensive and easy. There is no excuse here for not protecting the keys to the castle with the industry gold standard for MFA. Once you have MFA in place, you are ready to move on to the next step in your Opsec framework. However, before you declare your MFA journey a success, make sure you haven't forgotten any of your communication tools along the way. In this industry, we often use a combination of X, Signal, and Telegram, and each of them can and should be protected with an additional authentication factor. Also, note that the more you allow one-off sign-ins for each tool you use, the more you have to be concerned about the MFA features of each tool. Implementing single sign-on wherever possible is the best way to enforce MFA across all the tools you use. Take into consideration that, while using passkeys seems the most appropriate course of action, using them irresponsibly could lower your security posture. Passkeys only improve security when they remain tied to a strong device and recovery model; used carelessly, they can weaken it by shifting trust from a hard-to-phish login flow to softer cloud sync and account recovery paths. A common failure case is storing high-value passkeys in consumer sync ecosystems protected by weak recovery, reused credentials, SMS reset, or unmanaged devices, so an attacker who compromises the sync account can restore those passkeys on their own device and log in cleanly with what appears to be strong authentication. In that setup, the passkey itself is not broken, but the overall security posture is worse because the real attack surface becomes account recovery, device enrollment, and endpoint compromise rather than direct credential theft. A typical mistake would be to store a passkey in the Google password manager for your personal Google account, which may not be adequately protected with a strong password, MFA, and a secure account recovery method. To address the passkey storage issue, this section should be read in conjunction with the section (coming soon) about password handling and password management. Passkeys are the strongest form of MFA when stored in a secure password manager with biometric authentication (e.g., Bitwarden, 1Password). Passkeys stored in a personal account that uses phone or SMS as a recovery mechanism make overall security worse, not better. Before finalizing any decision to migrate to passkeys, please read the password management section and ensure that you are ready to store your passkeys securely. ## DevSecOps Integration ## Governance Alignment {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Integration > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [OpSec Integration](/opsec/integration/overview) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Integration & Mapping to Other Frameworks Operational security does not exist in isolation but interacts with and complements other security frameworks and practices. This section outlines how to integrate OpSec with other security domains and frameworks. ### Section Outline * [DevSecOps Alignment](/opsec/integration/devsecops) — embed OpSec practices into engineering and delivery pipelines. * [Governance Integration](/opsec/integration/governance) — connect OpSec posture with organizational oversight and compliance. * [Privacy Alignment](/opsec/integration/privacy) — unify security and privacy requirements for data-driven operations. ### DevSecOps Alignment Integrating operational security with development, security, and operations practices. #### Key Integration Points 1. **Secure Development Lifecycle**: Incorporating OpSec principles into the development process 2. **Infrastructure as Code Security**: Applying OpSec to infrastructure automation 3. **CI/CD Pipeline Security**: Securing continuous integration and deployment pipelines 4. **Security Automation**: Automating security controls and tests 5. **Feedback Loops**: Creating effective security feedback mechanisms #### Implementation Steps 1. Integrate security requirements into user stories and development tasks 2. Implement security gates in the CI/CD pipeline 3. Automate security testing and compliance verification 4. Establish shared security responsibilities across development and operations 5. Create security champions within development teams 6. Develop security playbooks for common development scenarios #### Web3-Specific Considerations 1. **Smart Contract Development**: Integrating security into contract development lifecycle 2. **Protocol Upgrades**: Secure processes for protocol upgrades and migrations 3. **Test Networks**: Security practices for testnet deployments 4. **Validator Operations**: Secure DevOps for validator infrastructure 5. **Node Deployment**: Security automation for node deployment and management ### Privacy Framework Alignment Ensuring operational security supports and enhances privacy protections. #### Key Integration Points 1. **Data Minimization**: Collecting and retaining only necessary information 2. **Privacy by Design**: Incorporating privacy considerations in security controls 3. **Data Protection**: Securing personal and sensitive information 4. **Access Controls**: Limiting access to private information 5. **Transparency**: Clear communication about security and privacy practices #### Implementation Steps 1. Conduct privacy impact assessments for security controls 2. Implement privacy-enhancing technologies alongside security measures 3. Establish data classification that addresses both security and privacy 4. Develop policies that balance security needs with privacy rights 5. Create incident response procedures that respect privacy considerations 6. Implement security controls that protect privacy by default #### Web3-Specific Considerations 1. **On-Chain Privacy**: Balancing blockchain transparency with privacy needs 2. **Zero-Knowledge Proofs**: Implementing security for privacy-preserving technologies 3. **Pseudonymity Protection**: Securing pseudonymous identities 4. **Metadata Protection**: Addressing privacy risks from transaction metadata 5. **Private Transaction Security**: Security for confidential transaction mechanisms ### Governance Framework Alignment Integrating operational security with organizational governance structures. #### Key Integration Points 1. **Risk Management**: Aligning security activities with enterprise risk management 2. **Compliance**: Ensuring security controls meet regulatory requirements 3. **Security Policies**: Developing and enforcing policies that support governance 4. **Oversight**: Establishing appropriate security oversight mechanisms 5. **Reporting**: Creating effective security reporting to governance bodies #### Implementation Steps 1. Map security controls to governance requirements and objectives 2. Integrate security risk assessments with enterprise risk management 3. Develop security metrics that support governance reporting needs 4. Establish clear security roles and responsibilities within governance structures 5. Create escalation paths for security issues requiring governance attention 6. Implement security compliance verification processes #### Web3-Specific Considerations 1. **DAO Governance**: Security integration with decentralized autonomous organizations 2. **Token-Based Governance**: Security considerations for token voting systems 3. **Multi-Signature Governance**: Security practices for multi-signature arrangements 4. **On-Chain Governance**: Security for on-chain governance mechanisms 5. **Regulatory Navigation**: Addressing evolving regulatory requirements ### Mapping to Security Standards Aligning operational security practices with established security standards and frameworks. #### Common Security Standards 1. **ISO 27001**: Information security management systems 2. **NIST Cybersecurity Framework**: Protect, detect, respond, recover 3. **CIS Controls**: Prioritized security controls 4. **OWASP**: Web application security best practices 5. **SOC 2**: Trust services criteria for security, availability, and confidentiality #### Implementation Steps 1. Identify relevant standards based on organizational needs 2. Map existing security controls to standard requirements 3. Identify gaps requiring additional controls or processes 4. Implement controls to address identified gaps 5. Maintain documentation of standard alignment 6. Consider formal certification where beneficial #### Web3-Specific Standards 1. **MITRE AADAPT** — [Adversarial Tactics, Techniques, and Procedures for Digital Asset Systems](https://aadapt.mitre.org/). Modeled after MITRE ATT\&CK, AADAPT catalogs real-world adversary behavior targeting blockchain and digital-asset infrastructure. It provides a structured taxonomy of tactics, techniques, and sub-techniques that helps security teams understand attacker workflows, map detections, and prioritize defenses. Use AADAPT to align OpSec threat modeling with the latest Web3 TTPs. 2. **OWASP Smart Contract Weakness Enumeration (SCWE)** — [OWASP SCWE](https://scs.owasp.org/SCWE/). A smart-contract-specific weakness enumeration inspired by CWE. SCWE supersedes the now-outdated SWC Registry, covering all 36 SWC entries plus additional weakness classes identified since. Reference SCWE when classifying vulnerabilities found during audits, penetration tests, or formal verification to maintain a consistent, community-maintained taxonomy. 3. **OWASP Smart Contract Top 10** — [Smart Contract Top 10](https://owasp.org/www-project-smart-contract-top-10/). An awareness standard under the OWASP Top 10 initiative that highlights the ten most critical smart contract vulnerability categories, ranked and updated yearly. Use it as a risk-prioritization checklist during design reviews and audit scoping to ensure the most impactful weaknesses receive attention first. 4. **EEA EthTrust Security Levels v3** — [EthTrust SL v3](https://entethalliance.org/specs/ethtrust-sl/). Defines certification requirements and three assurance levels (S, M, Q) for audited smart contracts. Level S requires formal verification and comprehensive testing; Level M requires thorough manual review; Level Q covers quick-scan assessments. Map OpSec audit procedures to the appropriate EthTrust level to communicate assurance rigor to stakeholders and regulators. #### Early-Stage & Emerging Standards The following standards are actively maintained but have narrower adoption or are still evolving. They are worth tracking if you operate in their scope. 1. **Cryptocurrency Security Standard (CCSS)** — [CCSS v3.2](https://cryptoconsortium.org/ccss/). A maturity standard for crypto-infrastructure security covering key management, wallet operations, and key-person controls. CCSS defines three assurance levels: Level 1 covers self-assessment; Level 2 adds third-party audit; Level 3 requires penetration testing and full documentation review. Use CCSS when designing or evaluating the security posture of custodial wallets, exchanges, or treasury operations that handle private keys at scale. ### Creating a Unified Security Approach Developing a cohesive security strategy that integrates all relevant frameworks. #### Key Components 1. **Security Strategy Alignment**: Ensuring consistent security objectives across frameworks 2. **Unified Control Framework**: Developing a comprehensive set of security controls 3. **Integrated Assessment**: Conducting holistic security assessments 4. **Coordinated Improvement**: Aligning security improvement initiatives 5. **Shared Metrics**: Developing common security metrics across frameworks #### Implementation Steps 1. Create a security integration team with representatives from different domains 2. Develop a comprehensive security control framework that addresses all requirements 3. Implement integrated security assessment processes 4. Establish coordinated security improvement planning 5. Develop unified security dashboards and reporting 6. Create cross-domain security governance structures #### Web3-Specific Considerations 1. **Traditional-Web3 Security Integration**: Bridging conventional and blockchain security 2. **Multi-Chain Security**: Unified approaches across multiple blockchains 3. **Full-Stack Web3 Security**: Integrating security from smart contracts to front-end 4. **Hybrid Governance Models**: Security in mixed centralized/decentralized governance 5. **Ecosystem Security Collaboration**: Coordinating security across the ecosystem Effective integration of operational security with other frameworks creates a comprehensive security approach that addresses all aspects of an organization's security needs. By mapping controls, aligning processes, and coordinating improvements across frameworks, organizations can develop a cohesive security posture that is greater than the sum of its parts. *** ## Privacy Framework Alignment ## Post-Mortem & Lessons Learned ## Security KPIs & Reporting {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Google > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Google Workspace Security](/opsec/google/overview) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Google Security ### Summary > 🔑 **Key Takeaway:** Enhance your Google account security by implementing robust 2FA, eliminating redundant recovery > options, and diligently overseeing third-party access. **Google** provides a wide range of services—from email to file storage. Safeguarding your Google account is among the most critical steps you can take to protect your personal and professional data. Below are simple yet effective measures to improve your Google account security. *** ### For Individuals These settings apply to your personal Google account. All team members and admins should configure these on their own accounts. > This section does not include Google Suite or more advanced security configurations. For that, refer to the Operational > Security Framework, under [Google Suite Security](/opsec/old/cloud-third-party/g-suite-security). #### Account Security Checklist * [Google Security Settings](https://myaccount.google.com/security): * [ ] Settings > Security > Skip passwords when possible > **Enabled** * *Skipping password entry allows you to renew logins in public places without having to type out your password or store it in your clipboard* * [ ] Settings > Security > Recovery email > **Enabled** * [ ] Settings > Security > [Recovery phone](https://myaccount.google.com/signinoptions/rescuephone) > **Disabled** * By default, Google allows account recovery using phone numbers and emails. Attackers can exploit these if they compromise your phone or email. * **Optional**: If you're confident you won't need standard recovery processes, also remove [Recovery Email](https://myaccount.google.com/recovery/email) * [ ] Settings > Security > Third-party apps with account access > Remove all unnecessary * Some apps request extensive permissions (e.g., full inbox or file access). Regularly review these to minimize risks. * [ ] Settings > Security > [Your devices](https://myaccount.google.com/device-activity) > Log out from all unnecessary devices * Keeping track of active sessions helps you detect unauthorized access. * [ ] Security > Enhanced Safe Browsing > **Enabled** * [2-Step Verification](https://myaccount.google.com/signinoptions/two-step-verification): * Properly setting up two-factor authentication (2FA) is one of the most crucial steps you can take. Disable SMS 2FA to avoid SIM swaps, and instead use an authenticator app or a hardware security key (preferred). * [ ] Enable any available method, but passkeys or an authenticator app are recommended. You can also continue using **Google prompts**. * [ ] Disable "Voice or text message" if enabled * [ ] Remove any App passwords * [ ] Store Backup Codes offline in a secure place * [Google Connections](https://myaccount.google.com/connections): * [ ] Review each connected app's permissions; remove if unnecessary or excessive * [Google Profile](https://myaccount.google.com/profile): * Publicly visible personal info can aid attackers in impersonating you. * [ ] Check Visibility: If any info is set to "Anyone," switch it to private if unnecessary * [ ] **Birthday:** Consider making it private *** #### Extended Security Settings For a comprehensive security review, follow these steps from [Google Security](https://myaccount.google.com/security): * [ ] "Your connection to third-party apps & Services" > Revoke all applications that should not be connected * [ ] "Log out of all unknown devices" * [ ] "Turn off" skip password when possible (below previous step) * [ ] "How you sign in with Google" > Set up your 2FA or Security Key * [ ] Ensure you do not have a recovery phone setup. No SMS 2FA or phone number on your account at all. * [ ] Change your password after completing these steps * [ ] Note down your backup codes > If using Google Authenticator as a 2FA app on your phone, disconnect it from the cloud, as backup codes are then stored > in the google cloud associated to email. Use it without an account and ensure backup codes are written down offline. *** #### Advanced Protection Program For those who are public figures or need heightened security, Google's **Advanced Protection Program** is worth considering. It requires the use of security keys, limits access to unverified apps, and makes the process of account recovery more challenging. * [ ] [Enroll in Advanced Protection Program](https://myaccount.google.com/advanced-protection/landing) *** #### Best Practices & Ongoing Maintenance * [ ] **Review Security Alerts:** Pay attention to any email or phone notifications from Google regarding unusual sign-ins or account changes. * [ ] **Perform a Security Checkup:** Regularly visit [Google's Security Checkup](https://myaccount.google.com/security-checkup) to identify potential issues and resolve them. * [ ] **Consider** using identity **monitoring** apps like [Push Security](https://pushsecurity.com). *** ### For Team Members These guidelines apply to team members who use Google Workspace but don't have administrative access. Team members should: * Ensure their individual account settings are configured according to the checklist above * Pay attention to any email or phone notifications from Google regarding unusual sign-ins or account changes * Regularly visit [Google's Security Checkup](https://myaccount.google.com/security-checkup) to identify potential issues and resolve them *** ### For Admins These settings and practices apply to Google Workspace administrators with elevated privileges. #### Admin Settings (Workspace Configuration) ##### Rules and Notifications * [Rules](https://admin.google.com/ac/ax) > Enable notifications for security events * [ ] "User's password changed" * [ ] "Suspicious login" * [ ] "User granted Admin privilege" * [ ] "User's Admin privilege revoked" * [ ] "Primary admin changed" * [ ] "Leaked password" * [ ] "Device compromised" [\[1\]](#1-security-alerts) ##### Security Settings * [ ] Security > Overview > Less Secure Apps > **Disable access to less secure apps** * [ ] Security > Authentication > 2-Step Verification > **Allow users to turn on 2-Step Verification** * [ ] Enforcement > **On** * [ ] Methods > **Any except verification codes via text, phone call** or **Only security key** [\[2\]](#2-2fa-enrollment) * Security > Authentication > Account Recovery > * [ ] Super admin account recovery > **On** (if fewer than 3 super admins on account) * [ ] User account recovery > **On** * [ ] Security > Authentication > Password Management > **Enforce strong password** * [ ] Length > Minimum length > At least **12** * [ ] Security > Access and data control > Google Cloud session control > Reauthentication policy > **Require reauthentication** * [ ] Exempt Trusted apps > **Off** * [ ] Reauthentication frequency > **16** ##### Apps and Data Control * [ ] Apps > Google Workspace > Drive and Docs > Sharing options > * [ ] Sharing outside of organization > **OFF** or **ALLOWLISTED DOMAINS** * [ ] Allow users in organization to receive files from users or shared drives outside of organization/allowlisted domains > **Off** * [ ] When sharing outside of organization is allowed, users in organization can make files and published web content visible to anyone with the link > **Off** * [ ] Distributing content outside of organization > **No one** * [ ] Apps > Google Workspace > Settings for Google Chat > Service Settings > **OFF for everyone** ##### Gmail Security * Apps > Google Workspace > Settings for Gmail > * [ ] Authenticate email > Set up **DKIM** with your DNS provider * **Safety >** * [ ] Attachments > **Enable** all protections and set to quarantine * [ ] IMAP [view time protections](https://support.google.com/a/answer/10036904?sjid=9191352966703497335-NC) > **Enabled** * [ ] Links and external images > **Enable** all * [ ] Spoofing and authentication > **Enable** all and set to quarantine * [ ] **Protect against any unauthenticated emails** can be set to **Keep email in inbox and show warning** in order to prevent blocking external emails ##### Email Authentication * **SPF & DMARC** * Follow these guides to confirm and/or set up SPF and DMARC: * [Set up SPF](https://support.google.com/a/answer/33786?hl=en\&sjid=5876544508252018851-NC#spf-already-setup) * [Set up DMARC](https://support.google.com/a/answer/2466580?hl=en#dmarc-step2) ##### Optional Enhancement * Enroll in the [Advanced Protection Program](https://landing.google.com/advancedprotection/) for high-risk users or your entire organization *** #### Notes ##### \[1] Security Alerts Other alerts should be enabled by default, but it is recommended to go through the list and enable any others that would indicate concerns. ##### \[2] 2FA Enrollment You can confirm user enrollment status at Directory > Users, under the **2-step verification enrollment** and **Advanced Protection Program enrollment** columns. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Endpoint > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Endpoint Security](/opsec/endpoint/overview) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Endpoint Security > **Key Takeaway:** Match device security investment to role risk. Managed hardware for privileged operators, > VDI for global contractors, enterprise browsers as minimum viable security for everyone else. Unmanaged personal devices are a primary vector for credential theft and lateral movement in Web3 organizations. Infostealers, malicious browser extensions, and compromised development environments all start at the endpoint. Organizations need a device provisioning strategy that scales security with role sensitivity. ### Device Security Tiers #### Tier 1: Managed Devices (Gold Standard) Issue organization-managed hardware to your highest-risk roles. This provides full security stack visibility and control. * **EDR** (CrowdStrike Falcon, SentinelOne) for real-time behavioral monitoring and threat hunting * **MDM** (Intune, JAMF) to enforce configuration policy and enable remote wipe * **Full disk encryption** (BitLocker, FileVault) so stolen devices reveal nothing * **Biometric authentication** (TouchID, Windows Hello) for phishing-resistant local auth * **Centralized logging** for threat hunting and incident reconstruction **Target roles:** Developers with production access, leadership, treasury custodians, key signers, security leads. #### Tier 2: Virtual Desktop Infrastructure (Privacy-First Scale) For global contractors where issuing hardware is impractical, VDI provides a secure cloud-hosted environment accessible from any device. The employee's personal machine becomes a thin client — all sensitive work happens inside the managed virtual desktop. * Complete visibility and control inside the virtual environment * Corporate web proxying and traffic inspection * Protects employee device privacy (organization sees inside VDI, not the host) * **Limitation:** Susceptible to host-level keyloggers and screen capture * **Limitation:** Performance and latency overhead * **Limitation:** Hardware authentication dongle (YubiKey) compatibility issues in virtualized environments **Target roles:** Global operations, customer support, regional teams, contractors with defined scopes. Providers: AWS WorkSpaces, Azure Virtual Desktop, Google Cloud Workstations. #### Tier 3: Enterprise Browser (Minimum Viable Security) For general staff and short-term contractors, an enterprise browser provides a managed browsing environment on any machine. * **Extension allowlisting** — eliminates malicious extension vectors (e.g., Discord session cookie theft) * **IdP integration** — enforces identity and access policies at the browser layer * **Isolated history and cookies** — work browsing sandboxed from personal browsing * **Limitation:** Zero protection if the host OS is compromised * **Limitation:** Cannot block host-level screen capture or USB access **Target roles:** General staff, community managers, short-term contractors. > If you use Google Workspace, you already have **Chrome Enterprise Core** at no additional cost. Enabling > extension allowlisting alone eliminates one of the most common attack vectors against Discord and web-based platforms. ### Choosing the Right Tier | Factor | Managed Device | VDI | Enterprise Browser | | ------------------------------ | ----------------------- | ------------------------- | --------------------------- | | **Visibility** | Full (OS + apps) | Inside VDI only | Browser only | | **Host compromise protection** | Yes — EDR on host | Partial — Host keyloggers | No — None | | **Hardware cost** | High (org buys devices) | Low (any device) | None | | **Privacy** | Low (org owns device) | Medium (host is private) | High (only browser managed) | | **Best for** | Core team, signers | Global contractors | General staff | Most Web3 organizations will use all three tiers simultaneously — the goal is to match investment to actual risk, not to force a single approach across all roles. ### Further Reading * [Hardening your organization](/dprk-it-workers/mitigating-dprk-it-workers#hardening-your-organization) — Access control policies for remote workers * [Browser Security](/opsec/browser/overview) — Browser-specific hardening import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Operational Implementation Process > 🔑 **Key Takeaway**: Operational security is implemented through a practical five-phase process: critical asset > identification, practical threat analysis, actionable vulnerability assessment, contextual risk evaluation, and > targeted control deployment. ### Relationship to Security Fundamentals This document outlines a practical implementation process for operational security that organizations can follow in sequence. This process complements the [Security Fundamentals](/opsec/core-concepts/security-fundamentals) document, which defines the guiding principles: * This process provides a **sequential workflow** for security teams to follow * The fundamentals establish **enduring principles** that shape security architecture While this process offers a concrete methodology for implementation, the fundamentals establish the ongoing security approaches that must be maintained throughout your systems. Both elements must work together: the fundamentals guide your overall approach, while this process provides the tactical roadmap. For organizations just beginning their security journey, start here with these concrete implementation steps. ### 1. Critical Asset Identification Map and document the assets that would cause significant harm to your organization if compromised. > **🔗 Related Framework:** This phase integrates with [Asset Inventory](/infrastructure/asset-inventory) practices and > drives [Data Protection](/opsec/old/data-protection/overview) strategies. #### Implementation Actions 1. Conduct asset discovery across your environment using both automated tools and manual inventorying * Digital assets: Use network scanning, CMDB tools, and cloud resource inventories * Physical assets: Document hardware, systems and access points 2. Apply a practical classification system with clear, actionable categories * High-value assets: Direct financial impact if compromised (e.g., private keys, treasury wallets) * Operational assets: Required for continued business operations * Sensitive data: Includes Customer information, intellectual property, strategic plans 3. Map information flows to understand how data moves between systems 4. Assign specific owners responsible for each asset category 5. Establish a sustainable review cadence based on your environment * High-volatility environments: Monthly reviews * Stable environments: Quarterly reviews * Document trigger events that require immediate reassessment (e.g., acquisitions, new product, etc.) ### 2. Practical Threat Analysis Identify specific, relevant threat actors and their tactics based on your organization's profile. > **🔗 Related Framework:** For hands-on approaches, see > [Understanding Threat Vectors](/awareness/understanding-threat-vectors) and [Threat Modeling](/threat-modeling/overview) > frameworks. #### Implementation Actions 1. Create a focused threat profile based on: * Your industry's recent attack history (consult threat intelligence reports) * Your organization's specific attack surface * The value of your assets to different adversaries 2. Document concrete adversary personas with specific capabilities: * External attackers: Targeted vs. opportunistic * Insider risks: Privileged users, contractors, disgruntled employees * Supply chain actors: Vendors with access to your systems 3. Map threat actors to their likely tactics using MITRE ATT\&CK or similar frameworks 4. Establish threat intelligence feeds relevant to your environment 5. Create a lightweight process for updating threat models when new intelligence emerges ### 3. Actionable Vulnerability Assessment Systematically identify and validate weaknesses in your environment through practical testing. > **🔗 Related Framework:** This aligns with the [Security Testing](/security-testing/overview) framework and includes > practices like [Static Application Security Testing](/security-testing/overview) and [Dynamic Application Security Testing](/security-testing/overview). #### Implementation Actions 1. Implement a layered vulnerability discovery program: * Automated scanning: Deploy tools appropriate for your environment (infrastructure, applications, cloud) * Manual testing: Conduct regular penetration tests focusing on critical systems * Red team exercises: Simulate real-world attacks against your defenses 2. Examine security processes for operational gaps: * Incident response procedures: Test through tabletop exercises * Access management: Audit privilege escalation paths * Change management: Review for security bypass opportunities 3. Evaluate security awareness through: * Targeted phishing simulations * Knowledge assessments * Procedural compliance checks 4. Document findings in a centralized vulnerability management system with clear ownership 5. Implement a consistent vulnerability scoring system to enable prioritization ### 4. Contextual Risk Evaluation Analyze identified risks in the context of your business to drive informed decision-making. > **🔗 Related Framework:** For practical approaches, see [Governance](/governance/overview) and > [Risk Management](/governance/risk-management) frameworks. #### Implementation Actions 1. Establish a practical risk calculation methodology that considers: * Business impact (financial, operational, reputational) * Exploitation likelihood based on real-world attack patterns * Existing control effectiveness 2. Create a prioritized risk register with clear owners and timelines 3. Define risk acceptance criteria based on your organization's risk tolerance 4. Develop risk narratives that translate technical findings into business impacts 5. Implement a streamlined risk review process that: * Enables timely decisions * Involves appropriate stakeholders * Documents rationale for future reference * Triggers reassessment when conditions change ### 5. Targeted Control Deployment Implement security controls that address prioritized risks while minimizing operational friction. > **🔗 Related Framework:** Implementation integrates with [Security Automation](/security-automation/overview) and > control frameworks like [Infrastructure](/infrastructure/overview) and > [Identity and Access Management](/iam/overview). #### Implementation Actions 1. Design a defense-in-depth strategy with layered controls: * Preventive: Stop attacks before they succeed * Detective: Identify attacks in progress * Responsive: Limit damage from successful attacks * Recovery: Restore normal operations 2. Select controls using a balanced approach: * Technical feasibility in your environment * Implementation and maintenance costs * Potential operational impact * Coverage of multiple risks where possible 3. Implement controls using a phased approach: * Quick wins: Deploy high-impact, low-effort controls first * Foundational controls: Build core security capabilities * Advanced measures: Address sophisticated threats 4. Validate control effectiveness through: * Technical testing * Process verification * Metrics collection 5. Document clear procedures for: * Control operation * Maintenance requirements * Monitoring and alerting * Incident response when controls fail *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Core Concepts > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Security Fundamentals](/opsec/core-concepts/security-fundamentals) * [OpSec Implementation Process](/opsec/core-concepts/implementation-process) * [Web3 Security Considerations](/opsec/core-concepts/web3-considerations) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Security Fundamentals > 🔑 **Key Takeaway**: Effective security operations are built on five practical fundamentals: layered protective > measures, minimized access scopes, controlled information flows, system isolation, and continuous visibility — working > together to secure critical assets in dynamic environments. ### Relationship to Implementation Process This document outlines the foundational security approaches that should be embedded throughout your organization's operations. They complement the practical [Operational Implementation Process](/opsec/core-concepts/implementation-process), which defines specific action steps: * These fundamentals establish **enduring approaches** that shape your security architecture * The implementation process provides a **sequential workflow** for security teams to follow While these fundamentals provide the security principles that should be consistently applied across your environment, the implementation process offers a structured methodology for putting security into practice. Both elements must work in concert - these fundamentals guide your overall approach, while the implementation process provides the tactical roadmap. For organizations just beginning their security journey, start with the [Operational Implementation Process](/opsec/core-concepts/implementation-process) for concrete steps. The ultimate goal is to prevent unauthorized access to systems and information that could cause operational, financial, or reputational harm if compromised. > **Practical Example: Web3 Organization** > > Consider a Web3 project managing a DeFi protocol with a treasury of $10M in assets. Practical security fundamentals in > action include: > > * **Layered protection**: Hardware security modules for key storage, multi-signature requirements (3-of-5) for > transactions, automated monitoring for unusual patterns, and regular third-party security audits > * **Minimal access scopes**: Deployment keys accessible only to specific DevOps team members, with different > permission levels strictly enforced between development, staging, and production environments > * **Information flow control**: Private keys for multi-signature wallets distributed among trusted team members based > on role, with sensitive incident response procedures restricted to the security team > * **System isolation**: Clear separation between development environments and production systems, with treasury > management isolated from day-to-day operations > * **Continuous visibility**: Real-time monitoring systems tracking transaction patterns, weekly security reviews, and > quarterly penetration tests with findings addressed in prioritized sprints ### 1. Layered Protection Implement multiple overlapping security controls so that if one mechanism fails, others will continue to protect your assets. > **🔗 Related Framework:** This approach is reinforced in frameworks like [Infrastructure](/infrastructure/overview) > with [Zero-Trust Principles](/infrastructure/zero-trust-principles) and > [Network Security](/infrastructure/network-security). #### Practical Application 1. Implement multiple defensive mechanisms that protect against the same risks using different methods * Example: Protect admin interfaces using network ACLs, MFA, time-limited access windows, and anomaly detection 2. Deploy protection at each layer of your technology stack * Network layer: Firewalls, network segmentation, DDoS protection * Host layer: Endpoint protection, host-based IDS, secure configuration * Application layer: Input validation, output encoding, API security * Data layer: Encryption, access controls, data loss prevention 3. Identify and eliminate single points of failure in your security architecture * Map defense coverage to ensure overlapping protections * Document security dependencies and create contingency plans 4. Test defensive layers regularly through realistic scenarios * Conduct tabletop exercises focused on specific defensive failures * Use red team exercises to validate defense-in-depth effectiveness 5. Maintain a continuous improvement cycle for each defensive layer * Review and update security controls after incidents or near-misses * Track industry developments to identify emerging defensive tactics ### 2. Minimal Access Scopes Grant users, systems, and processes only the specific permissions they need to perform their required functions and nothing more. > **🔗 Related Framework:** For detailed implementation, see [Identity and Access Management](/iam/overview) and > [Role-Based Access Control](/iam/role-based-access-control). #### Practical Application 1. Implement a structured permission model that starts with zero access * Default deny: Require explicit permission grants for all access * Document justification for each permission granted * Create standardized role templates for common job functions 2. Establish automated processes for access lifecycle management * Onboarding: Provision minimal initial access based on role * Role changes: Adjust permissions when responsibilities change * Offboarding: Remove all access immediately upon departure 3. Apply time-based restrictions to elevated privileges * Use just-in-time access for administrative functions * Implement automatic session termination after periods of inactivity * Require re-authentication for sensitive operations 4. Conduct regular access reviews with verification * Quarterly: Review all privileged accounts and service accounts * Semi-annually: Audit all standard user accounts and group memberships * Use automated tools to identify inactive or excessive permissions 5. Implement technical controls to enforce minimal access * Application permissions: API scopes, feature flags, entitlement checks * Infrastructure permissions: IAM policies, network ACLs, resource policies * Database permissions: Row-level security, column-level controls ### 3. Information Flow Control Ensure sensitive information is only accessible to those with a legitimate need to know, with restrictions on how that information can be shared and used. {/* > **🔗 Related Framework:** This approach is supported by practices in [Data Protection](/opsec/old/data-protection/overview) and aspects of [Privacy](/privacy/overview). */} #### Practical Application 1. Implement a practical data classification system with clear handling requirements * Public: Information approved for general distribution * Internal: Business information for employee use only * Confidential: Sensitive information requiring specific protections * Restricted: Critical information with strictly controlled access 2. Define and enforce data handling procedures for each classification level * Storage requirements: Where information can be stored * Transmission rules: How information can be sent/shared * Processing restrictions: How information can be used * Retention limits: How long information should be kept 3. Deploy technical controls to enforce information flow policies * Data loss prevention tools to monitor and block unauthorized sharing * Encryption for data at rest and in transit based on sensitivity * Information rights management for persistent protection 4. Establish secure channels for different types of communication * High-sensitivity: End-to-end encrypted messaging with disappearing messages * Medium-sensitivity: Encrypted collaboration platforms with access controls * Low-sensitivity: Standard business communication tools 5. Train users on practical information handling procedures * Provide clear guidelines with concrete examples * Use realistic scenarios in training materials * Conduct periodic verification checks ### 4. System Isolation Segment systems and networks into isolated zones to contain security breaches and limit lateral movement. #### Practical Application 1. Implement network segmentation based on security requirements * Create security zones with consistent trust levels * Implement strict traffic control between zones * Document and regularly review allowed communication paths 2. Establish environment separation with controlled boundaries * Maintain distinct development, testing, staging, and production environments * Implement one-way data flows from higher to lower environments * Control code promotion processes between environments 3. Isolate high-value systems with enhanced protection * Place critical infrastructure on dedicated hardware * Example: Run blockchain nodes on dedicated hardware isolated from general workstations * Implement jump servers or privileged access workstations for administrative access 4. Apply micro-segmentation where appropriate * Container isolation: Enforce pod security policies and network policies * Application segmentation: Implement service meshes with mutual TLS * Process isolation: Use containerization, virtualization, or sandboxing 5. Monitor and enforce boundary controls * Implement egress filtering to control outbound connections * Deploy internal firewalls between segments * Use network monitoring to detect unauthorized communication attempts ### 5. Continuous Visibility Maintain ongoing awareness of your security posture through active monitoring, testing, and continuous improvement. > **🔗 Related Framework:** For implementation details, see the [Monitoring](/monitoring/overview) framework, including > [Guidelines](/monitoring/guidelines) and [Thresholds](/monitoring/thresholds). Also relevant is > [Incident Management](/incident-management/overview) for response to detected issues. #### Practical Application 1. Implement a multi-layered monitoring strategy * System monitoring: Performance, availability, and system integrity * Security monitoring: Threat detection, anomaly identification, and correlation * Compliance monitoring: Policy enforcement and regulatory requirements * Establish clear ownership for each monitoring domain 2. Define actionable metrics tied to security objectives * Leading indicators: Metrics that help predict future issues * Example: Percentage of systems with current patches * Lagging indicators: Metrics that measure past performance * Example: Mean time to detect and respond to incidents 3. Establish a regular testing cadence to validate security controls * Vulnerability scanning: Weekly automated scans * Penetration testing: Quarterly focused tests on critical systems * Red team exercises: Annual comprehensive assessments 4. Implement a structured incident management process * Define clear incident response procedures with specific roles * Conduct regular tabletop exercises to practice response * Perform thorough post-incident reviews focused on improvement * Create feedback loops to security controls based on incidents 5. Maintain an active threat intelligence program * Collect intelligence relevant to your specific environment * Analyze and contextualize threats for your organization * Disseminate actionable intelligence to appropriate teams * Use threat intelligence to drive security improvements *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Web3-Specific OpSec Considerations > 🔑 **Key Takeaway**: Web3 environments require specialized security approaches that balance blockchain transparency > with privacy, address immutability risks, manage self-custody responsibilities, secure decentralized operations, > mitigate smart contract vulnerabilities, and navigate community-driven security challenges. In addition to traditional OpSec principles, Web3 environments require consideration of unique challenges. Many organizations claim to be backed only by decentralized technologies, but they later realize that part of their process is dependant on technologies that are not. {/* > **🔗 Related Framework:** Explore the dedicated [Web3-Specific OpSec](/operational-security/web3-specific-opsec/) framework for comprehensive guidance. */} ### Transparency vs. Privacy Balancing the transparent nature of blockchain with the need for operational privacy. #### Suggested steps 1. Understand what information is publicly visible on-chain * Transaction amounts, addresses, contract interactions, and timestamps * Use block explorers and analysis tools to understand your on-chain footprint 2. Develop strategies to maintain operational privacy while utilizing public blockchains * Use different addresses for different transaction types or business functions * Consider privacy-focused layer 2 solutions for sensitive operations 3. Use privacy-enhancing technologies where appropriate * ZK (Zero-Knowledge) protocols for privacy-preserving computations * Privacy pools or similar technologies (when legally permissible) * Privacy-focused blockchains for specific operations (e.g., Monero, Zcash) ### Immutability and Finality Recognizing that blockchain transactions are generally irreversible, requiring heightened security before execution. #### Suggested steps 1. Implement robust verification procedures before executing transactions * Mandatory multi-person review for transactions above defined thresholds * Automated checks for anomalous transaction patterns * Hash verification of destination addresses 2. Use multi-signature requirements for high-value transactions * 3-of-5 or 2-of-3 signature schemes for treasury operations * Hardware wallets for each signer with physical separation * Time-locks for large transfers (24-48 hour delay before execution) 3. Deploy transaction simulation tools to verify outcomes before execution * Use Tenderly or similar platforms to simulate transactions in a fork of the chain * Verify gas estimates and test with small amounts first when using new contracts\\ * Use auxiliary tools such as [Safe Multi-sig Transaction Hashes](https://github.com/pcaversaccio/safe-tx-hashes-util) 4. Establish secure deployment practices for smart contracts * Use formal verification tools before mainnet deployment * Implement deployment scripts with dry-run functionality * Require multiple approvals in your deployment pipeline * Consider gradual deployments with circuit breakers for critical contracts ### Self-Custody Responsibility Managing private keys and digital assets with appropriate security controls. > **🔗 Related Framework:** For detailed guidance on wallet security practices, see the > [Wallet Security](/wallet-security/overview) framework. #### Suggested steps 1. Develop clear procedures for wallet security * Air-gapped hardware wallet setups for cold storage * Specific seed phrase backup procedures (e.g., metal backups, split storage) * Clear rules for when hot vs. cold wallets should be used 2. Implement separation of duties for transaction approval * Different roles for transaction initiation, verification, and execution * Rotation of responsibilities to prevent single points of compromise * Hardware security modules (HSMs) for institutional-grade key management 3. Balance security with operational efficiency * Define thresholds for different security requirements (e.g., `<$10K`, `$10K-$100K`, `>$100K`) * Implement tiered wallet architecture (hot wallets for operations, cold storage for reserves) * Establish secure methods for replenishing hot wallets from cold storage 4. [Stay up-to-date](/awareness/staying-informed-and-continuous-learning) with best practices in wallet security and custody solutions * Subscribe to security advisory services for cryptocurrencies * Follow developments in MPC (Multi-Party Computation) wallet technologies * Regularly review and test recovery procedures ### Decentralized Operations Securing operations across distributed teams and systems. #### Suggested steps 1. Establish clear security protocols for remote team members * Device security requirements (disk encryption, endpoint protection, auto-updates) * Secure home network guidelines (dedicated VLANs, strong WPA3 passwords) * Clear policies for public WiFi usage (always-on VPN requirement) 2. Use secure communication channels for sensitive discussions * End-to-end encrypted messaging (Signal, Matrix/Element with verified devices) * Ephemeral messaging for highly sensitive topics (disappearing messages) * Encrypted video conferencing with waiting rooms and passwords (Jitsi, Signal) * PGP-encrypted emails for sensitive communications that need to be preserved 3. Implement strong authentication for all team members * Hardware security keys (Yubikeys, Passkeys) as primary 2FA method * TOTP apps as backup authentication method (not SMS) * Passwordless authentication where possible (WebAuthn/FIDO2) * Regular access review and prompt offboarding procedures 4. Create guidelines for secure collaboration in a distributed environment * Encrypted file storage and sharing (Cryptomator, end-to-end encrypted cloud storage) * Private repositories with signed commits for code collaboration * Secure DevOps practices for CI/CD pipelines * Role-based access to administrative systems with just-in-time privilege elevation ### Smart Contract Vulnerabilities Addressing the immutable nature of deployed code. #### Suggested steps 1. Conduct thorough code reviews and security audits before deployment * Multiple independent security audits for critical contracts * Comprehensive test coverage (>95%) for all contract functions * Symbolic execution and static analysis tools (Slither, Mythril) 2. Implement upgradability patterns where appropriate * Proxy patterns with clear governance mechanisms * Immutable core logic with upgradeable periphery * Emergency pause functionality with decentralized controls 3. Use formal verification where possible * Mathematical proofs of contract correctness for critical functions * Verification of business logic and security properties * Property-based testing frameworks (Echidna, Scribble) 4. Maintain comprehensive testing environments * Local development environments with mainnet forking * Testnet deployments with real-world simulation * Adversarial testing and red team exercises 5. Consider timelocks and circuit breakers for critical functions * Time-delayed administration actions (48-72 hours) * Value-limit circuit breakers for suspicious transaction volumes * Decentralized monitoring and alerting systems ### Community Dynamics Managing security in open, community-driven projects. #### Suggested steps 1. Develop clear security guidelines for community contributors * Documented security policies in repositories * Security templates for pull requests * Required security reviews for changes to sensitive components 2. Establish review processes for community-submitted code * Multi-level review requirements based on code criticality * Automated security scanning integrated into CI/CD pipelines * Bounty programs for vulnerability identification 3. Create security awareness programs for the community * Educational resources on common vulnerabilities * Regular security-focused community calls or workshops * Recognition for security-conscious contributions 4. Balance transparency with operational security needs * Clear guidelines on what information should remain private * Secure channels for reporting vulnerabilities * Responsible disclosure policies and timelines * Public security incident post-mortems (with appropriate redactions) *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Control Domains > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [OpSec Control Domains](/opsec/control-domains/overview) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Organizational Controls Organizational controls form the foundation of an operational security program. These controls establish the governance structures, policies, and processes necessary to implement and maintain security throughout the organization. ### Compliance & Regulatory Alignment Ensuring that security practices align with relevant regulations, standards, and industry best practices. #### Key Components 1. **Regulatory Identification**: Identifying applicable laws, regulations, and standards 2. **Compliance Mapping**: Aligning security controls with compliance requirements 3. **Gap Assessment**: Evaluating compliance status and identifying deficiencies 4. **Remediation Planning**: Developing plans to address compliance gaps 5. **Continuous Monitoring**: Regularly assessing compliance status #### Implementation Steps 1. Identify and document all applicable regulatory requirements 2. Map requirements to specific security controls and policies 3. Conduct regular compliance assessments 4. Develop and implement remediation plans for identified gaps 5. Maintain documentation of compliance activities and status 6. Stay informed about changes to regulatory requirements #### Web3-Specific Considerations 1. **Regulatory Uncertainty**: Navigate evolving regulations specific to blockchain and cryptocurrency 2. **Cross-Jurisdictional Compliance**: Address requirements across multiple jurisdictions 3. **Token Classification**: Understand securities laws and regulations that may apply to tokens 4. **AML/KYC Requirements**: Implement appropriate controls where required by law 5. **Data Protection**: Comply with privacy regulations while leveraging blockchain transparency ### Supply-Chain Security Managing security risks associated with vendors, suppliers, and other third parties in your supply chain. #### Key Components 1. **Vendor Risk Assessment**: Evaluating the security posture of potential vendors 2. **Security Requirements**: Establishing security expectations for vendors 3. **Contractual Controls**: Including security requirements in contracts 4. **Ongoing Monitoring**: Regularly assessing vendor security compliance 5. **Incident Response Coordination**: Coordinating with vendors during security incidents #### Implementation Steps 1. Develop a vendor security assessment methodology 2. Establish security requirements based on the sensitivity of data and systems accessed 3. Include security clauses in contracts and agreements 4. Implement a process for regular vendor security reviews 5. Develop procedures for addressing vendor security concerns 6. Create incident response plans that include vendor coordination #### Web3-Specific Considerations 1. **Code Dependencies**: Assess security of open-source libraries and components 2. **Smart Contract Auditors**: Evaluate and select qualified auditors for code review 3. **Node Operators**: Assess security of infrastructure providers and node operators 4. **Blockchain Integration**: Evaluate security of bridges, oracles, and other blockchain integrations 5. **Wallet Providers**: Assess security of wallet solutions and key management services ### Organizational Structure & Roles Establishing clear security responsibilities and accountability throughout the organization. #### Key Components 1. **Security Governance**: Defining how security decisions are made 2. **Roles and Responsibilities**: Clearly defining security responsibilities 3. **Separation of Duties**: Ensuring no single person has excessive control 4. **Escalation Paths**: Establishing clear processes for raising security concerns 5. **Security Team Structure**: Organizing security personnel effectively #### Implementation Steps 1. Define and document security roles and responsibilities 2. Implement separation of duties for critical functions 3. Establish security decision-making processes 4. Create clear escalation procedures for security issues 5. Ensure security representation in key decision-making bodies #### Web3-Specific Considerations 1. **Decentralized Teams**: Implement security governance in distributed organizations 2. **Multi-Signature Control**: Establish clear roles for multi-signature key holders 3. **Community Governance**: Balance security with community-driven decision making 4. **Pseudonymous Contributors**: Develop trust models for pseudonymous team members 5. **DAO Structures**: Integrate security governance into decentralized autonomous organizations Effective organizational controls provide the structure needed to implement and maintain operational security throughout your organization. By establishing clear governance, compliance processes, and supply chain controls, you create a foundation for all other security measures. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Control Domains Operational security controls are organized into domains that address different aspects of security. This section provides an overview of these domains and how they work together to create a comprehensive security posture. ### Introduction to Control Domains Security controls are safeguards or countermeasures designed to protect the confidentiality, integrity, and availability of information and systems. Organizing these controls into domains helps ensure comprehensive coverage across different aspects of security. The primary control domains in operational security are: 1. **Organizational Controls**: Policies, governance, and management structures 2. **People & Personnel Controls**: Security measures related to human behavior and awareness 3. **Physical & Environmental Controls**: Protection of physical assets and environments 4. **Technical & Digital Controls**: Security measures for systems, networks, and data ### Implementing a Balanced Control Framework Effective operational security requires a balanced approach across all control domains: 1. **Layered Defense**: Implement controls across multiple domains to create defense in depth 2. **Risk-Based Approach**: Allocate resources based on risk assessment rather than implementing all possible controls 3. **Continuous Evaluation**: Regularly assess the effectiveness of controls against evolving threats 4. **Adaptability**: Adjust controls based on changes in technology, threats, and organizational needs ### Section Outline * [Organizational Controls](/opsec/control-domains/organizational) — governance, compliance, and third-party assurance. * [Compliance & Regulatory Alignment](/opsec/control-domains/organizational/compliance-regulatory-alignment) * [Supply Chain Security](/opsec/control-domains/organizational/supply-chain-security) * [People Controls](/opsec/control-domains/people) — culture, training, and insider-risk mitigation. * [Insider Threat Mitigation](/opsec/control-domains/people/insider-threat-mitigation) * [Security Training & Culture](/opsec/control-domains/people/security-training-culture) * [Social Engineering Defense](/opsec/control-domains/people/social-engineering-defense) * [Physical & Environmental Controls](/opsec/control-domains/physical-environmental) — protecting locations, devices, and travel. * [Secure Workspace & Travel](/opsec/control-domains/physical-environmental/secure-workspace-travel) * [Tamper Evidence](/opsec/control-domains/physical-environmental/tamper-evidence) * [Technical Controls](/opsec/control-domains/technical) — hardening infrastructure, endpoints, and communication. * [Cryptocurrency Controls](/opsec/control-domains/technical/cryptocurrency-controls) * [Device Hardening](/opsec/control-domains/technical/device-hardening) * [Encrypted Storage & Backups](/opsec/control-domains/technical/encrypted-storage-backups) * [Network & Communication Security](/opsec/control-domains/technical/network-communication-security) * [Two-Factor & Hardware Auth](/opsec/control-domains/technical/two-factor-hardware-auth) ### Control Selection and Implementation When selecting and implementing controls: 1. **Identify Requirements**: Determine what needs to be protected and why 2. **Assess Current State**: Evaluate existing controls and identify gaps 3. **Select Appropriate Controls**: Choose controls based on risk assessment and organizational context 4. **Implement Systematically**: Deploy controls in a coordinated manner 5. **Monitor Effectiveness**: Regularly evaluate how well controls are working 6. **Improve Continuously**: Refine and enhance controls based on performance and changing needs ### Web3-Specific Considerations In Web3 environments, control implementation must address unique challenges: 1. **Decentralized Operations**: Implementing controls across distributed teams and systems 2. **Cryptocurrency Security**: Specialized controls for digital asset protection 3. **Smart Contract Security**: Controls specific to blockchain-based code 4. **Community Governance**: Balancing centralized security controls with decentralized governance The following sections detail the specific controls within each domain, providing guidance on implementation and best practices tailored to Web3 organizations. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## People & Personnel Controls People are both the greatest asset and potentially the greatest vulnerability in any security program. This section outlines controls to mitigate human-related security risks while fostering a security-aware culture. ### Social-Engineering Defense Protecting against attacks that manipulate people to divulge confidential information or perform actions that compromise security. #### Key Components 1. **Awareness Training**: Educating team members about social engineering tactics 2. **Attack Simulation**: Conducting controlled social engineering exercises 3. **Verification Procedures**: Establishing processes to verify requestor identity 4. **Reporting Mechanisms**: Creating clear channels for reporting suspicious activities 5. **Response Protocols**: Developing procedures for handling potential social engineering incidents #### Implementation Steps 1. Develop targeted training on common social engineering tactics 2. Implement regular phishing simulations and other controlled tests 3. Establish protocols for verifying requests for sensitive information or actions 4. Create and communicate clear procedures for reporting suspicious activities 5. Regularly update training and awareness materials based on current threats #### Web3-Specific Considerations 1. **Community Channels**: Address social engineering in Discord, Telegram, and other platforms 2. **Crypto-Specific Scams**: Educate about common scams like fake airdrops and giveaways 3. **Impersonation**: Train team members to verify identity through secure channels 4. **Public Information**: Consider the risks of publicly available information about team members 5. **Multiple Communication Channels**: Establish out-of-band verification for critical actions ### Insider-Threat Mitigation Addressing risks posed by team members who may intentionally or unintentionally compromise security. #### Key Components 1. **Access Controls**: Implementing least privilege and separation of duties 2. **Monitoring**: Establishing appropriate monitoring of user activities 3. **Onboarding/Offboarding**: Securing processes for adding and removing team members 4. **Behavior Analytics**: Identifying unusual activities that may indicate threats 5. **Response Procedures**: Developing protocols for addressing potential insider threats #### Implementation Steps 1. Implement robust access controls based on the principle of least privilege 2. Establish monitoring for critical systems and sensitive data access 3. Develop and enforce secure onboarding and offboarding procedures 4. Create guidelines for identifying and reporting concerning behaviors 5. Establish response procedures that balance security with privacy and legal considerations #### Web3-Specific Considerations 1. **Key Management**: Implement controls for those with access to private keys 2. **Multi-Signature Requirements**: Use multi-signature arrangements for critical operations 3. **Distributed Teams**: Address insider threat risks in remote and distributed teams 4. **Pseudonymous Contributors**: Develop trust models for pseudonymous team members 5. **Financial Incentives**: Consider unique incentives related to cryptocurrency holdings ### Security Training & Culture Building a culture where security is valued and integrated into daily operations. #### Key Components 1. **Security Awareness Program**: Comprehensive training on security principles 2. **Role-Based Training**: Specialized training based on job responsibilities 3. **Security Champions**: Designated representatives who promote security within teams 4. **Continuous Learning**: Ongoing education about emerging threats 5. **Positive Reinforcement**: Recognizing and rewarding security-conscious behavior #### Implementation Steps 1. Develop a comprehensive security awareness program 2. Implement role-specific security training for different functions 3. Establish a security champions program to promote security within teams 4. Create a continuous learning program with regular updates on new threats 5. Develop recognition programs for security-conscious behaviors and reporting 6. Integrate security into performance evaluations and team objectives #### Web3-Specific Considerations 1. **Crypto-Specific Training**: Educate on unique aspects of blockchain security 2. **Open-Source Mindset**: Balance security with transparency in an open-source culture 3. **Decentralized Teams**: Deliver effective training across distributed organizations 4. **Rapidly Evolving Threats**: Keep training current with fast-changing Web3 threats 5. **Community Education**: Extend security awareness to community members and users ### Personnel Security Measures Ensuring appropriate security controls throughout the employment lifecycle. #### Key Components 1. **Pre-Employment Screening**: Appropriate background checks and verification 2. **Security Agreements**: Confidentiality and acceptable use policies 3. **Clear Expectations**: Defined security responsibilities for all roles 4. **Performance Management**: Integration of security into performance evaluation 5. **Termination Procedures**: Secure processes for departing team members #### Implementation Steps 1. Implement appropriate pre-employment screening procedures 2. Develop and require security agreements for all team members 3. Clearly document security responsibilities in job descriptions 4. Include security considerations in performance evaluations 5. Establish and enforce secure termination procedures #### Web3-Specific Considerations 1. **Pseudonymous Contributors**: Develop alternative verification approaches 2. **Global Teams**: Navigate screening challenges across different jurisdictions 3. **Community Contributors**: Address security for non-employee contributors 4. **DAO Participants**: Establish security expectations in decentralized organizations 5. **Key Recovery**: Implement procedures for key recovery when team members depart Effective people and personnel controls recognize that security is fundamentally a human issue. By addressing social engineering, insider threats, and security awareness, organizations can transform their people from potential vulnerabilities into a critical line of defense. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Physical & Environmental Controls Physical security is a crucial component of operational security that is often overlooked in digital-focused organizations. This section covers controls to protect physical assets, secure workspaces, and address travel security concerns. ### Secure Workspace & Travel Security Implementing controls to secure physical work environments and protect team members while traveling. #### Secure Workspace Components 1. **Physical Access Controls**: Restricting access to facilities and sensitive areas 2. **Visitor Management**: Procedures for handling visitors and contractors 3. **Clean Desk Policy**: Guidelines for securing sensitive information when not in use 4. **Environmental Monitoring**: Detection of environmental threats (fire, water, etc.) 5. **Equipment Security**: Physical protection of hardware and devices #### Implementation Steps for Workspace Security 1. Implement appropriate physical access controls based on sensitivity 2. Establish visitor management procedures and logging 3. Develop and enforce clean desk and clear screen policies 4. Implement environmental monitoring and response procedures 5. Secure hardware with appropriate physical controls (locks, alarms, etc.) #### Travel Security Components 1. **Pre-Travel Assessment**: Evaluating security risks at destinations 2. **Secure Travel Practices**: Guidelines for secure behavior while traveling 3. **Device Security**: Protecting devices and data during travel 4. **Emergency Response**: Procedures for handling security incidents while traveling 5. **Post-Travel Measures**: Actions to take after returning from high-risk locations #### Implementation Steps for Travel Security 1. Develop pre-travel risk assessment procedures 2. Create travel security guidelines for different risk levels 3. Implement technical controls for devices used during travel 4. Establish emergency response procedures for travelers 5. Develop and enforce post-travel security measures where appropriate #### Web3-Specific Considerations 1. **Remote-First Organizations**: Addressing physical security in distributed teams 2. **Hardware Wallets**: Securing cryptocurrency hardware devices 3. **Conference Security**: Protecting team members at industry events 4. **Pseudonymous Team Members**: Balancing privacy with physical security needs 5. **Doxing Risks**: Protecting team members from having personal information exposed ### Tamper-Evidence & "Evil-Maid" Attacks Protecting against physical tampering with devices and equipment, especially when left unattended. #### Key Components 1. **Tamper-Evident Measures**: Physical indicators of device tampering 2. **Device Integrity Verification**: Methods to verify device has not been compromised 3. **Secure Storage**: Protected storage for sensitive devices when not in use 4. **Device Handling Procedures**: Guidelines for maintaining device chain of custody 5. **Response Procedures**: Actions to take when tampering is suspected #### Implementation Steps 1. Implement tamper-evident measures for sensitive devices (seals, markers, etc.) 2. Establish procedures for verifying device integrity after periods of absence 3. Provide secure storage options for devices when not in use 4. Develop clear device handling procedures 5. Create response plans for suspected tampering incidents 6. Train team members on tamper detection and response #### Web3-Specific Considerations 1. **Hardware Wallet Security**: Protecting cryptocurrency hardware devices 2. **Cold Storage**: Physical security for offline key storage 3. **Seed Phrase Protection**: Secure storage of recovery phrases 4. **Air-Gapped Systems**: Maintaining security of isolated systems 5. **Physical Backup Security**: Protecting backup storage media ### Physical Security of Critical Assets Protecting the physical security of servers, network equipment, and other critical infrastructure. #### Key Components 1. **Asset Inventory**: Cataloging and tracking physical assets 2. **Secure Facilities**: Protected locations for critical infrastructure 3. **Environmental Controls**: Protection against environmental threats 4. **Maintenance Procedures**: Secure processes for equipment maintenance 5. **Disposal Procedures**: Secure disposal of equipment and media #### Implementation Steps 1. Maintain a comprehensive inventory of physical assets 2. Implement appropriate physical security controls for facilities 3. Deploy environmental monitoring and protection systems 4. Establish secure maintenance procedures 5. Develop and enforce secure disposal procedures for equipment and media #### Web3-Specific Considerations 1. **Node Security**: Physical protection of blockchain nodes 2. **Validator Security**: Enhanced protection for validator infrastructure 3. **Redundancy Planning**: Physical distribution of backup systems 4. **Hardware Security Modules**: Physical protection of HSMs 5. **Key Ceremony Security**: Physical controls for key generation events Effective physical and environmental security controls address risks that are often overlooked in digital-focused organizations. By implementing appropriate physical protections, organizations can prevent attacks that bypass technical controls through physical access or tampering. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Technical & Digital Controls Technical controls form the backbone of operational security, protecting systems, networks, and data from digital threats. This section outlines key technical controls that should be implemented as part of a comprehensive security program. ### Device Hardening Securing devices by minimizing attack surfaces and implementing defensive configurations. #### Key Components 1. **Secure Configuration Baselines**: Standardized secure configurations for different device types 2. **Endpoint Protection**: Anti-malware, application control, and other protective tools 3. **OS Hardening**: Removing unnecessary services and securing operating systems 4. **Patch Management**: Keeping systems updated with security patches 5. **Local Firewall**: Controlling network connections at the device level #### Implementation Steps 1. Develop secure configuration baselines for each device type 2. Implement endpoint protection solutions on all devices 3. Remove or disable unnecessary services, applications, and features 4. Establish an effective patch management process 5. Configure local firewalls with appropriate rules 6. Regularly scan for compliance with security baselines #### Web3-Specific Considerations 1. **Development Environments**: Securing environments used for smart contract development 2. **Cold Storage Systems**: Hardening systems used for cryptocurrency key management 3. **Transaction Signing Devices**: Enhanced security for devices used to sign transactions 4. **Node Operation**: Specialized hardening for blockchain node infrastructure 5. **Testing Environments**: Securing environments used for contract testing and simulation ### Network & Communication Security Protecting data in transit and securing network infrastructure against attacks. #### Key Components 1. **Network Segmentation**: Dividing networks into security zones 2. **Encrypted Communications**: Protecting data transmitted over networks 3. **Secure Remote Access**: VPN and other secure access solutions 4. **Network Monitoring**: Detecting suspicious network activity 5. **Perimeter Security**: Firewalls, intrusion prevention, and other boundary protections #### Implementation Steps 1. Implement network segmentation based on security requirements 2. Deploy encryption for all sensitive communications 3. Establish secure remote access solutions with strong authentication 4. Implement network monitoring and traffic analysis 5. Deploy and properly configure perimeter security controls 6. Regularly test network security through vulnerability assessments and penetration testing #### Web3-Specific Considerations 1. **Node Communication**: Securing blockchain node communications 2. **API Security**: Protecting interfaces to blockchain services 3. **RPC Endpoint Protection**: Securing remote procedure call endpoints 4. **P2P Network Security**: Addressing risks in peer-to-peer networks 5. **MEV Protection**: Mitigating risks related to maximal extractable value ### Encrypted Storage & Backups Protecting data at rest through encryption and secure backup strategies. #### Key Components 1. **Full-Disk Encryption**: Encrypting entire storage devices 2. **File-Level Encryption**: Protecting individual sensitive files 3. **Key Management**: Securely managing encryption keys 4. **Secure Backups**: Protecting backup data through encryption and access controls 5. **Recovery Testing**: Verifying the ability to restore from backups #### Implementation Steps 1. Implement full-disk encryption on all devices storing sensitive data 2. Deploy file-level encryption for particularly sensitive information 3. Establish secure key management processes with appropriate access controls 4. Implement encrypted and access-controlled backup solutions 5. Regularly test backup recovery processes 6. Store backup media securely with appropriate physical protections #### Web3-Specific Considerations 1. **Seed Phrase Backups**: Secure storage of wallet recovery information 2. **Multi-Location Backups**: Distributing backup data to prevent single points of failure 3. **Cold Storage Backups**: Offline backup strategies for critical keys 4. **Smart Contract Backups**: Preserving contract source code and deployment parameters 5. **Social Recovery Options**: Implementing secure social recovery systems for critical keys ### Two-Factor & Hardware Authentication Strengthening authentication through multiple factors and hardware-based solutions. #### Key Components 1. **Multi-Factor Authentication**: Requiring multiple verification methods 2. **Hardware Security Keys**: Physical devices for authentication 3. **Biometric Authentication**: Using biological characteristics for verification 4. **Time-Based One-Time Passwords**: Temporary codes for authentication 5. **Single Sign-On Integration**: Centralizing and securing authentication #### Implementation Steps 1. Implement multi-factor authentication for all access to sensitive systems 2. Deploy hardware security keys for high-value accounts and systems 3. Establish backup authentication methods and recovery processes 4. Integrate MFA with single sign-on solutions where appropriate 5. Train users on proper use of authentication tools 6. Regularly audit authentication configurations and access #### Web3-Specific Considerations 1. **Hardware Wallets**: Using dedicated devices for cryptocurrency transactions 2. **Multi-Signature Setups**: Requiring multiple approvals for critical transactions 3. **Air-Gapped Signing**: Using offline devices for transaction signing 4. **Social Recovery**: Implementing secure key recovery through trusted contacts 5. **DApp Authentication**: Securing connections to decentralized applications ### Cryptocurrency-Specific Controls Technical controls specifically designed to address the unique security challenges of cryptocurrency operations. #### Key Components 1. **Wallet Security**: Technical measures to secure cryptocurrency wallets 2. **Transaction Verification**: Processes to verify transaction details before signing 3. **Key Management**: Secure generation, storage, and use of cryptographic keys 4. **Blockchain Monitoring**: Tracking on-chain activity for anomalies 5. **Smart Contract Security**: Technical controls for secure contract interaction #### Implementation Steps 1. Implement appropriate wallet solutions based on security requirements 2. Establish transaction verification procedures with multiple checks 3. Deploy secure key management practices and technologies 4. Implement monitoring for blockchain transactions and activities 5. Develop secure processes for smart contract interaction 6. Regularly review and update cryptocurrency security controls #### Web3-Specific Best Practices 1. **Cold Storage**: Using offline systems for storing significant assets 2. **Multi-Signature Wallets**: Requiring multiple approvals for transactions 3. **Transaction Simulation**: Testing transactions before execution 4. **Gas Limit Setting**: Controlling transaction costs and preventing attacks 5. **Contract Interaction Verification**: Verifying contract behavior before approval Effective technical and digital controls provide a strong foundation for operational security. By implementing comprehensive device, network, data, and authentication protections, organizations can significantly reduce their attack surface and better protect their digital assets. *** ## Cryptocurrency-specific controls ## Device hardening ## Encrypted storage & backups ## Network & communication security ## Two-factor & hardware authentication ## Secure workspace & travel security ## Tamper-evidence & "evil-maid" ## Insider-threat mitigation ## Security training & culture ## Social-engineering defense ## Compliance & regulatory alignment ## Supply-chain security {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Browser > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Browser Security](/opsec/browser/overview) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Browser Security Placeholder for Browser Security content import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Case Studies & Exercises This section provides real-world case studies and tabletop exercises that organizations can use to learn from past incidents and test their security readiness. These examples illustrate common security challenges and effective response strategies. ### Web3 Security Incidents #### Case Study 1: Private Key Compromise ##### Incident Overview A mid-sized DeFi protocol experienced a security breach when an attacker gained access to a private key used for deploying smart contracts. The attacker used the key to deploy a malicious contract update that drained approximately $3 million from the protocol. ##### Root Causes 1. The private key was stored in a development environment with inadequate access controls 2. The same key was used for both testing and production deployments 3. There was no multi-signature requirement for contract deployments 4. Monitoring systems failed to detect the unauthorized deployment ##### Response Actions 1. The team immediately alerted users via social media and official channels 2. All remaining funds were moved to secure wallets 3. A forensic investigation was initiated to determine the attack vector 4. Law enforcement and blockchain analytics firms were engaged 5. The team implemented a compensation plan for affected users ##### Lessons Learned 1. Implement multi-signature requirements for all critical operations 2. Establish separate keys for different environments with appropriate controls 3. Improve deployment security with additional verification steps 4. Enhance monitoring to detect unauthorized deployments 5. Develop and test incident response procedures specific to key compromise #### Case Study 2: Social Engineering Attack ##### Incident Overview A community manager for a popular NFT project had their Discord account compromised after clicking a link in a direct message that appeared to come from a team member. The attacker used the compromised account to post a fake minting link, resulting in approximately 50 community members connecting their wallets and losing assets. ##### Root Causes 1. Lack of verification procedures for team communications 2. Insufficient security awareness training for team members 3. Absence of multi-factor authentication on critical accounts 4. Inadequate controls for posting official announcements ##### Response Actions 1. The team removed the compromised account's permissions 2. An official announcement was made warning about the scam 3. The fake minting site was reported for takedown 4. Affected community members were identified for potential compensation 5. Communication procedures were revised to prevent similar incidents ##### Lessons Learned 1. Implement strong authentication for all team accounts 2. Establish verification protocols for team communications 3. Create a secure process for publishing official announcements 4. Conduct regular security awareness training for team members 5. Develop an incident response plan specific to community channel compromises ### Tabletop Exercises #### Exercise 1: Wallet Security Incident ##### Scenario Your organization's multi-signature wallet has shown unusual transaction activity. A transaction that was not authorized by the team has been initiated, requiring one more signature to execute. The transaction would send a significant amount of funds to an unknown address. ##### Exercise Questions 1. What immediate actions would you take? 2. How would you investigate the source of the unauthorized transaction? 3. What stakeholders need to be notified, and what information would you provide? 4. What steps would you take to secure your remaining assets? 5. How would you communicate with your community or users? ##### Key Discussion Points * Multi-signature wallet security procedures * Transaction verification processes * Incident response roles and responsibilities * Communication strategies during security incidents * Forensic investigation approaches #### Exercise 2: Smart Contract Vulnerability ##### Scenario A security researcher has privately disclosed a critical vulnerability in one of your deployed smart contracts. The vulnerability could potentially allow an attacker to drain funds, but it requires specific conditions that have not yet occurred. You have approximately 48 hours before these conditions align. ##### Exercise Questions 1. How would you validate the reported vulnerability? 2. What immediate mitigation steps could you take? 3. How would you prioritize and approach developing a fix? 4. What stakeholders need to be involved in the decision-making process? 5. How and when would you communicate with users and the broader community? ##### Key Discussion Points * Vulnerability verification processes * Short-term mitigation strategies * Smart contract upgrade procedures * Decision-making during time-sensitive incidents * Responsible disclosure and communication #### Exercise 3: Team Member Device Compromise ##### Scenario A developer on your team reports that their laptop has been stolen while traveling. The laptop was used for development work and had access to various internal systems. The developer had logged into several services recently and is unsure if all sessions were properly closed. ##### Exercise Questions 1. What immediate actions would you take to contain potential damage? 2. What systems and access credentials might be at risk? 3. How would you determine if any unauthorized access has occurred? 4. What steps would you take to restore secure operations? 5. How would you improve security to prevent similar incidents? ##### Key Discussion Points * Device security policies and procedures * Access revocation processes * Security monitoring and detection capabilities * Recovery procedures for compromised credentials * Travel security policies ### Security Exercises for Teams #### Red Team Exercise: Phishing Simulation ##### Exercise Overview This exercise simulates a phishing attack targeting team members to test awareness and response. ##### Setup Requirements 1. Prepare simulated phishing emails targeting different team roles 2. Create a safe landing page that records interactions 3. Establish monitoring to track responses 4. Prepare educational materials for post-exercise discussion ##### Exercise Process 1. Send simulated phishing emails to selected team members 2. Monitor interactions with the phishing content 3. Document actions taken by recipients 4. Track if and how the incident is reported 5. Conduct a debrief session to discuss results ##### Evaluation Criteria * Percentage of team members who detected the phishing attempt * Time taken to report suspicious emails * Effectiveness of reporting procedures * Quality of response from security team * Lessons learned and areas for improvement #### Security Control Assessment: Key Management ##### Exercise Overview This exercise evaluates the effectiveness of cryptocurrency key management procedures. ##### Setup Requirements 1. Create a test environment with non-production keys 2. Prepare scenarios that test different aspects of key management 3. Establish evaluation criteria for each scenario 4. Ensure safety measures to prevent actual asset risk ##### Exercise Process 1. Simulate routine key management operations 2. Introduce scenarios requiring emergency access to keys 3. Test key recovery procedures 4. Evaluate separation of duties enforcement 5. Assess documentation and procedure clarity ##### Evaluation Criteria * Adherence to established key management procedures * Effectiveness of security controls * Time required to safely complete key operations * Quality of documentation and procedures * Identification of gaps and improvement opportunities These case studies and exercises provide practical examples and scenarios that organizations can use to learn from past incidents and test their security readiness. By regularly conducting such exercises, teams can identify weaknesses in their security posture and improve their ability to respond effectively to incidents. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Glossary of Terms This glossary provides definitions for key terms used throughout the Operational Security framework. It includes both general security terminology and Web3-specific concepts to help ensure a common understanding of security concepts. ### General Security Terms #### A **Access Control**: Systems and policies that restrict access to resources based on user identity and authorization level. **Authentication**: The process of verifying the identity of a user, system, or entity. **Authorization**: The process of determining what actions an authenticated entity is permitted to perform. **Availability**: The property of being accessible and usable upon demand by an authorized entity. #### B **Backup**: A copy of data created and stored separately from the original, to enable recovery in case of data loss. **Breach**: An incident that results in the unauthorized access, disclosure, or acquisition of protected data. #### C **Confidentiality**: The property that information is not made available or disclosed to unauthorized individuals, entities, or processes. **Configuration Management**: The process of establishing and maintaining consistency of a system's performance and functional attributes with its requirements and design. **Containment**: Actions taken to limit the scope and impact of a security incident. **Countermeasure**: An action, device, procedure, or technique that mitigates a security threat or vulnerability. #### D **Defense in Depth**: A security strategy that employs multiple layers of controls to protect resources. **Disaster Recovery**: A set of policies, tools, and procedures to enable the recovery of vital technology infrastructure and systems following a disaster. #### E **Encryption**: The process of converting information into a code to prevent unauthorized access. **Endpoint Security**: The practice of securing entry points of end-user devices such as desktops, laptops, and mobile devices from being exploited by malicious actors. #### I **Incident Response**: The process of addressing and managing the aftermath of a security breach or attack. **Integrity**: The property that data has not been altered in an unauthorized manner since it was created, transmitted, or stored. **Intrusion Detection System (IDS)**: A system that monitors network traffic for suspicious activity and issues alerts when such activity is discovered. #### L **Least Privilege**: The principle of providing users with the minimum levels of access necessary to perform their job functions. **Logging**: The recording of events, activities, and changes within a system or network. #### M **Malware**: Software designed to disrupt, damage, or gain unauthorized access to a computer system. **Multi-Factor Authentication (MFA)**: An authentication method that requires a user to provide two or more verification factors to gain access. #### P **Penetration Testing**: An authorized simulated attack on a computer system to evaluate its security. **Phishing**: A technique for attempting to acquire sensitive data, such as passwords or credit card details, by masquerading as a trustworthy entity. **Principle of Least Privilege**: The concept of granting users only the minimum access rights necessary to perform their job functions. #### R **Risk Assessment**: The process of identifying, analyzing, and evaluating risk. **Risk Management**: The coordinated activities to direct and control an organization with regard to risk. #### S **Security Controls**: Safeguards or countermeasures to avoid, detect, counteract, or minimize security risks. **Security Incident**: An event that potentially compromises the confidentiality, integrity, or availability of information or systems. **Separation of Duties**: A principle that divides critical functions among different staff members to prevent fraud and errors. #### T **Threat**: A potential cause of an unwanted incident, which may result in harm to a system or organization. **Two-Factor Authentication (2FA)**: A method of confirming a user's claimed identity by utilizing a combination of two different factors. #### V **Vulnerability**: A weakness that can be exploited by a threat actor to perform unauthorized actions. **Vulnerability Assessment**: The process of identifying, quantifying, and prioritizing vulnerabilities in systems, applications, and network infrastructure. ### Web3-Specific Terms #### A **Air-Gapped**: A security measure where a computer or network is physically isolated from unsecured networks, such as the public internet or an insecure local area network. #### B **Blockchain**: A distributed ledger technology that maintains a continuously growing list of records, called blocks, which are linked and secured using cryptography. #### C **Cold Storage**: The practice of keeping a reserve of cryptocurrency offline, typically in hardware wallets or paper wallets. **Consensus Mechanism**: The process in a blockchain network that achieves agreement among distributed processes or systems on a single data value. **Custodial Wallet**: A cryptocurrency wallet where the private keys are held by a third-party service. #### D **Decentralized Application (DApp)**: An application that runs on a decentralized network, avoiding a single point of control or failure. **Decentralized Autonomous Organization (DAO)**: An organization represented by rules encoded as a computer program that is transparent, controlled by the organization members, and not influenced by a central government. #### E **Externally Owned Account (EOA)**: An Ethereum account controlled by a private key, typically belonging to a person. #### G **Gas**: A unit that measures the amount of computational effort required to execute operations on the Ethereum network. #### H **Hardware Wallet**: A special type of cryptocurrency wallet that stores the user's private keys in a secure hardware device. **Hot Wallet**: A cryptocurrency wallet that is connected to the internet, allowing for quick transactions but with increased security risks. #### M **Mempool**: A collection of all transaction data that have been verified by nodes but have not yet been recorded onto the blockchain. **Multisignature (Multisig)**: A digital signature scheme that allows a group of users to sign a single document, with multiple parties required to authorize a transaction. #### N **Node**: A computer that connects to a blockchain network and maintains a copy of the blockchain. **Non-Custodial Wallet**: A cryptocurrency wallet where users have full control over their private keys and cryptocurrency. #### P **Private Key**: A secret number that allows cryptocurrency to be spent. It is paired with a public key in asymmetric cryptography. **Public Key**: A cryptographic key that can be obtained and used by anyone to encrypt messages intended for a particular recipient, such that the encrypted messages can only be decrypted by the recipient's paired private key. #### S **Smart Contract**: Self-executing contracts with the terms of the agreement directly written into code, which automatically enforce and execute the terms when predetermined conditions are met. **Seed Phrase**: A series of words generated by cryptocurrency wallets that give users access to the cryptocurrency associated with that wallet. #### T **Token**: A digital asset that is created, issued, and managed on an existing blockchain. **Transaction**: The record of a change in ownership of a cryptocurrency or the execution of a smart contract. #### W **Wallet**: Software that stores private and public keys and interacts with various blockchain to enable users to send and receive digital currency and monitor their balance. **Web3**: The concept of a new iteration of the web which incorporates concepts such as decentralization, blockchain technologies, and token-based economics. This glossary provides a common language for discussing operational security concepts. Understanding these terms is essential for effective communication about security risks, controls, and practices in both traditional and Web3 environments. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Appendices > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [OpSec Resources & Appendices](/opsec/appendices/overview) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Appendices The appendices provide additional resources, templates, and reference materials to support the implementation of operational security practices. These materials complement the guidance provided in the main framework sections. ### Overview of Appendices The appendices are organized into the following sections: 1. **Policy & Template Library**: Ready-to-use security policy templates and documents 2. **Case Studies & Exercises**: Real-world examples and tabletop exercises 3. **Glossary of Terms**: Definitions of key operational security concepts These resources are designed to be practical tools that organizations can adapt to their specific needs and contexts. ### Section Outline * [Case Studies & Exercises](/opsec/appendices/case-studies) — scenario walk-throughs and retrospectives to train teams. * [Glossary](/opsec/appendices/glossary) — quick reference for OpSec and Web3 terminology. * [Policies & Templates](/opsec/appendices/policies) — reusable documents that accelerate program rollout. ### Using the Appendices The materials in the appendices should be: 1. **Customized**: Adapted to your organization's specific needs and context 2. **Regularly Updated**: Reviewed and updated as threats and best practices evolve 3. **Integrated**: Used in conjunction with the main framework guidance 4. **Shared**: Distributed to relevant stakeholders as appropriate Organizations should view these materials as starting points rather than finished products. They should be tailored to address your specific security requirements, organizational structure, and risk profile. ### Web3-Specific Resources The appendices include materials specifically designed for Web3 environments, including: 1. **Web3-Specific Policy Templates**: Policies addressing cryptocurrency operations, smart contract deployments, and other blockchain-specific concerns 2. **Web3 Case Studies**: Examples of security incidents and responses in blockchain projects 3. **Web3 Security Exercises**: Tabletop scenarios focused on blockchain-specific threats 4. **Web3 Security Terminology**: Definitions of blockchain security concepts These Web3-specific resources help bridge the gap between traditional security practices and the unique requirements of blockchain environments. ### Contributing to the Appendices The appendices are designed to be living resources that evolve over time. Organizations and individuals are encouraged to: 1. **Share Experiences**: Contribute case studies and lessons learned 2. **Suggest Improvements**: Provide feedback on existing materials 3. **Submit New Resources**: Develop and share new templates, exercises, or reference materials 4. **Collaborate**: Work together to enhance the quality and relevance of these resources By contributing to these resources, you help strengthen the operational security practices of the broader Web3 community. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Policy & Template Library This library provides templates and examples of security policies, procedures, and other documents that organizations can adapt to their specific needs. These templates serve as starting points for developing comprehensive security documentation. ### Core Security Policies #### Information Security Policy ```markdown # Information Security Policy ## Purpose This policy establishes the framework for protecting information assets and technology resources of [ORGANIZATION NAME]. ## Scope This policy applies to all employees, contractors, consultants, temporary staff, and other workers at [ORGANIZATION NAME], including personnel affiliated with third parties. ## Policy Statements 1. [ORGANIZATION NAME] shall maintain an information security program that: - Protects the confidentiality, integrity, and availability of information - Complies with applicable legal and regulatory requirements - Aligns with business objectives and risk tolerance - Follows industry best practices 2. All users must: - Protect sensitive information from unauthorized access or disclosure - Use information systems in accordance with acceptable use guidelines - Report security incidents and suspected vulnerabilities - Complete security awareness training 3. Management shall: - Ensure adequate resources for security controls - Regularly review security effectiveness - Enforce compliance with security policies - Support continuous improvement of security practices ## Roles and Responsibilities [Define specific security roles and responsibilities] ## Compliance Violations of this policy may result in disciplinary action, up to and including termination of employment or contract. ## Related Documents - Acceptable Use Policy - Access Control Policy - Incident Response Policy ``` #### Access Control Policy ```markdown # Access Control Policy ## Purpose This policy establishes requirements for controlling access to [ORGANIZATION NAME]'s information systems and data. ## Scope This policy applies to all systems, data, and users within [ORGANIZATION NAME]. ## Policy Statements 1. Access Control Principles - All access shall be granted based on the principle of least privilege - Access rights shall be reviewed regularly - Authentication mechanisms shall be appropriate to the sensitivity of the information 2. User Access Management - Formal user registration and de-registration procedures shall be implemented - Privileged access rights shall be restricted and controlled - Regular access rights reviews shall be conducted 3. User Responsibilities - Users shall follow good authentication practices - Users shall protect their authentication information - Users shall not share access credentials ## Implementation Guidelines [Specific implementation guidelines for access control] ## Exceptions Exceptions to this policy must be documented and approved by [ROLE]. ``` ### Web3-Specific Policies #### Cryptocurrency Key Management Policy ```markdown # Cryptocurrency Key Management Policy ## Purpose This policy establishes requirements for the secure management of cryptographic keys used for cryptocurrency transactions and operations. ## Scope This policy applies to all cryptographic keys used to secure cryptocurrency assets and operations at [ORGANIZATION NAME]. ## Policy Statements 1. Key Generation and Storage - Private keys shall be generated using secure methods - Critical keys shall be stored in hardware security modules or hardware wallets - Keys shall be backed up securely with appropriate redundancy 2. Transaction Signing - High-value transactions shall require multi-signature approval - Transaction details shall be verified before signing - Signing devices shall be kept secure and regularly audited 3. Key Recovery and Backup - Key recovery information shall be securely stored in multiple locations - Recovery procedures shall be documented and tested - No single individual shall have access to full recovery information ## Implementation Guidelines [Specific implementation guidelines for key management] ## Roles and Responsibilities [Define specific roles and responsibilities for key management] ``` #### Smart Contract Deployment Policy ```markdown # Smart Contract Deployment Policy ## Purpose This policy establishes requirements for the secure development and deployment of smart contracts. ## Scope This policy applies to all smart contracts developed, deployed, or maintained by [ORGANIZATION NAME]. ## Policy Statements 1. Development Requirements - Smart contracts shall follow secure coding guidelines - All contracts shall undergo peer review - Critical contracts shall be audited by qualified third parties 2. Testing Requirements - Contracts shall undergo comprehensive testing including security tests - Tests shall include edge cases and potential attack scenarios - Test coverage metrics shall be established and maintained 3. Deployment Requirements - Contracts shall be deployed through a secure, controlled process - Deployment transactions shall require multi-signature approval - Deployed contracts shall be verified on blockchain explorers 4. Monitoring and Maintenance - Deployed contracts shall be monitored for unusual activity - Security updates shall follow a defined process - Upgrade mechanisms shall be secured with appropriate controls ## Implementation Guidelines [Specific implementation guidelines for smart contract deployment] ## Roles and Responsibilities [Define specific roles and responsibilities for contract deployment] ``` ### Procedure Templates #### Incident Response Procedure ```markdown # Security Incident Response Procedure ## Purpose This procedure outlines the steps to be followed when responding to security incidents. ## Incident Detection and Reporting 1. Detection Sources - Automated alerts from monitoring systems - Reports from users or team members - External notifications 2. Reporting Process - Initial notification to [CONTACT/CHANNEL] - Required information for incident reports - Escalation criteria and process ## Incident Response Phases 1. Preparation - Necessary tools and resources - Team roles and responsibilities - Communication channels 2. Identification - Verifying and assessing the incident - Determining scope and impact - Assigning severity level 3. Containment - Short-term containment actions - Evidence preservation steps - System isolation procedures 4. Eradication - Removing the cause of the incident - Vulnerability remediation - Malware removal 5. Recovery - System restoration procedures - Verification of system integrity - Return to operation process 6. Lessons Learned - Post-incident review process - Documentation requirements - Improvement implementation ## Communication Guidelines [Guidelines for internal and external communication during incidents] ## Specific Incident Types [Specific procedures for different types of incidents] ``` #### Key Ceremony Procedure ```markdown # Cryptocurrency Key Ceremony Procedure ## Purpose This procedure outlines the steps for generating and securing cryptographic keys for cryptocurrency operations. ## Preparation 1. Required Materials - Hardware wallets or HSMs - Backup materials (metal plates, recovery phrase cards) - Tamper-evident bags and seals 2. Participant Roles - Ceremony Administrator - Key Holders - Witnesses - Security Officer 3. Location Requirements - Physical security controls - Network isolation measures - Environmental controls ## Key Generation Process 1. Device Preparation - Verification of device authenticity - Firmware verification - Device initialization 2. Key Generation - Entropy generation process - Key creation steps - Verification process 3. Backup Creation - Recovery phrase documentation - Backup verification - Secure storage preparation ## Security Controls 1. Physical Security - Access control to ceremony location - Video recording requirements - Device handling protocols 2. Participant Controls - Identity verification - Non-disclosure agreements - Role separation requirements 3. Documentation Requirements - Required ceremony records - Signature requirements - Storage of ceremony documentation ## Post-Ceremony Actions [Actions to be taken after the ceremony is complete] ``` ### Checklists and Forms #### Security Assessment Checklist ```markdown # Security Assessment Checklist ## System Information - System Name: ________________ - System Owner: ________________ - Assessment Date: ________________ - Assessor: ________________ ## Access Controls - [ ] User access is based on least privilege - [ ] Strong authentication is enforced - [ ] Privileged accounts are restricted - [ ] Access is reviewed regularly - [ ] Password policies are enforced ## Network Security - [ ] Firewalls are properly configured - [ ] Network traffic is monitored - [ ] Remote access is secured - [ ] Network segmentation is implemented - [ ] Encrypted protocols are used for sensitive data ## Data Protection - [ ] Sensitive data is identified and classified - [ ] Data encryption is implemented - [ ] Data backups are performed regularly - [ ] Data retention policies are enforced - [ ] Data destruction procedures are in place ## System Security - [ ] Systems are patched regularly - [ ] Antimalware protection is implemented - [ ] System hardening is performed - [ ] System logs are collected and reviewed - [ ] Change management processes are followed ## Physical Security - [ ] Physical access controls are in place - [ ] Environmental controls are implemented - [ ] Equipment is protected from theft or damage - [ ] Media is securely handled and disposed of - [ ] Physical security incidents are monitored ## Incident Response - [ ] Incident response procedures are documented - [ ] Staff is trained on incident response - [ ] Incidents are reported and tracked - [ ] Post-incident reviews are conducted - [ ] Lessons learned are implemented ## Additional Notes [Space for assessment notes and observations] ``` These templates provide starting points for developing comprehensive security policies and procedures. Organizations should customize these templates to address their specific security requirements, organizational structure, and risk profile. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, } from "../../../components"; ## Backup Signing & Infrastructure If the default interfaces for either Safe or Squads are down or suspected of being compromised, these alternatives enable continued critical signing operations. As a signer, you should familiarize yourself with these tools and practice signing transactions with your team. ### UI Alternatives #### EVM Networks **Eternal Safe - Decentralized fork of Safe\{Wallet}** * GitHub: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet) * Hosted (IPFS): [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires you to bring your own RPC) * Local: Can be downloaded and run locally Note: Local/alternative UIs may not be actively maintained. Treat them as emergency options and perform extra verification. Please DYOR. #### Solana \*\*Squads Public Client - Open source Squads V4 interface: \*\* * GitHub: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client) * Features: Verifiable build, self-hostable with Docker, IPFS distribution * Local: Can be built and run locally #### Mobile (Safe) \*\*Safe Mobile Apps: \*\* * GitHub: [https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile](https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile) * App Store: [https://apps.apple.com/us/app/safe-mobile/id6748754793](https://apps.apple.com/us/app/safe-mobile/id6748754793) * Play Store: [https://play.google.com/store/apps/details?id=global.safe.mobileapp](https://play.google.com/store/apps/details?id=global.safe.mobileapp) ### RPC Backup Options #### Basic guidance: * Multiple providers: Set up accounts with 2-3 different RPC services * eg. Alchemy, Infura, Chainstack, Quicknode, Tenderly * Avoid correlation: Choose providers that don't share infrastructure, if that information is available * Private RPCs preferred: Public RPC URLs are typically not sufficient for reliable operation #### Administrator responsibilities Ensure signer preparedness: * Provide access to offline UI tools listed above * Verify signers have practiced using backup interfaces * Test backup RPCs during non-emergency periods * Document procedures for switching to backup infrastructure ### Block Explorer Backup Options #### EVM Networks Etherscan provides the default block explorer for nearly all EVM chains. In the event that Etherscan is compromised or goes down, it is important to have backup options that can be used for monitoring and investigating transactions. \*\*Blockscout - Open source Etherscan alternative: \*\* * [https://www.blockscout.com/](https://www.blockscout.com/) * Available for all EVM networks * Can also be [self-hosted](https://github.com/blockscout/blockscout), although it requires significant time to run full node and index More explorers: A broader list of network explorers is maintained here: [https://explorer.swiss-knife.xyz/](https://explorer.swiss-knife.xyz/) #### Solana Networks Both explorer.solana.com and Solscan are reliable options for Solana transaction exploration and decoding. **explorer.solana.com** - [https://explorer.solana.com/](https://explorer.solana.com/) * Can be [self-hosted](https://github.com/solana-foundation/explorer) using open source code **Solscan** - [https://solscan.io/](https://solscan.io/) ### Preparation **It is recommended to download dependencies ahead of time and store them in a secure location** so they are easily accessible during emergencies. ### EVM Networks #### Eternal Safe - Decentralized fork of Safe\{Wallet} ##### Access Options * **GitHub**: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet) * **Hosted (IPFS)**: [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires you to bring your own RPC) * **Local**: Can be downloaded and run locally ##### Setup 1. Select network and enter an RPC URL
Eternal Safe network selection

Eternal Safe network selection screen: choose your network and enter an RPC URL

2. Enter Safe address and load ![Eternal Safe address entry](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-address-entry.png) 3. Eternal Safe will automatically detect Ether balances but not ERC20 tokens. They can be added manually ![Eternal Safe token configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-token-configuration.png) ##### Transaction Verification **Critical**: It is still essential to verify hashes and calldata from Eternal Safe. Follow the verification steps in [Safe Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification). ##### Smart Link System Once a transaction has been signed by one signer, a **Smart Link** is created which can be forwarded to the next signer to add their signature. The transactions do not go to any centralized backend. **Example Smart Link:** ``` Please sign this Eternal Safe transaction for the Safe: base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC. Current confirmations: 1 of 2. https://eternalsafe.eth.limo/transactions/tx/?safe=base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC&tx=eyJzaWduYXR1cmVzIjp7ImRhdGFUeXBlIjoiTWFwIiwidmFsdWUiOltbIjB4NDBiYjMyZjA4NjJkMjI3ODEzYzg2ZmQ4M2E3YjNjOWRiOTA3NGUyYSIseyJzaWduZXIiOiIweDQwYkIzMkYwODYyRDIyNzgxM2M4NkZEODNBN0IzYzlkYjkwNzRFMkEiLCJkYXRhIjoiMHgwZDMxZTZjODIxZjBhMGZlM2M5NmNlZWY4ZDNhM2JhZmU3YmZmZTliODQ0ZWNkYzBkYWNmNzc0MzFkODQ0NjU4MTgwZjUwNmZlMjZiZjMzOTQwY2VhOTJiMzlhNDNjODRkMDRhNThiMGY1ODQ2NzhlNzE0YTllMWJkMzE0NTg5ZjFiIn1dXX0sImRhdGEiOnsiZGF0YSI6IjB4IiwiYmFzZUdhcyI6IjAiLCJnYXNQcmljZSI6IjAiLCJzYWZlVHhHYXMiOiIwIiwiZ2FzVG9rZW4iOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJub25jZSI6NCwicmVmdW5kUmVjZWl2ZXIiOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJ2YWx1ZSI6IjEwMDAwMDAwMDAwMDAwMDAiLCJ0byI6IjB4RTBiY2ZlNWUzMEFCYTBCNDZmMTNCMEMyNENiQzQ3MERDQTNlYjg2NSIsIm9wZXJhdGlvbiI6MH19 ``` ##### Execution Once all signatures are collected, execute the transaction. **Note**: Prior to execution you can manually simulate using Tenderly by entering the transaction data, but an automatic simulation link will not be available. ### Solana #### Squads Public Client - Open source Squads V4 interface ##### Access Options * **GitHub**: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client) * **Hosted**: [https://backup.app.squads.so/](https://backup.app.squads.so/) * **Features**: Verifiable build, self-hostable with Docker, IPFS distribution * **Local**: Can be built and run locally ##### Setup 1. If running locally, follow setup instructions in [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client) and access via `http://localhost:8080` 2. Enter RPC URL in settings ![Squads RPC configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-rpc-configuration.png) 3. Enter multisig address in the **lower** text box (Search for Multisig Config) and select the detected Multisig Config ![Squads multisig selection](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-multisig-selection.png) ##### Transaction Operations 1. Create, approve, or execute transactions. *Smart Links* are not needed for Solana as all transactions are on chain and accessible via the RPC without an API ![Squads transaction interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-transaction-interface.png) ### Security Considerations #### Enhanced Verification When using backup systems: * **Extra caution required**: Be more thorough with verification procedures * **Multiple verification methods**: Use additional tools to cross-check transaction details * **Team confirmation**: Verify with other signers before proceeding with critical transactions * **Documentation**: Record use of backup systems and any issues encountered #### Risk Assessment * **Delay non-critical operations**: Consider postponing non-urgent transactions until primary systems recover * **Emergency operations only**: For critical emergency responses, proceed with enhanced verification * **Communication**: Keep team informed about system status and verification procedures ### Testing and Preparation #### Regular Practice * **Monthly testing**: Practice using backup interfaces during normal operations * **Team coordination**: Ensure all signers can operate backup systems * **Process documentation**: Update procedures based on practice sessions #### Emergency Drills * **Simulated outages**: Practice coordinating with backup systems during drills * **Communication testing**: Verify backup communication channels work with backup UIs * **Time measurement**: Track how long backup system activation takes ### Troubleshooting #### Common Issues * **RPC connectivity**: Switch to alternative RPC providers if connection fails * **Transaction loading**: Refresh or try different network endpoints * **Signature verification**: Use multiple verification tools when in doubt #### Support Resources * **GitHub documentation**: Refer to project documentation for technical issues * **Team assistance**: Coordinate with other signers for problem-solving * **Alternative tools**: Have multiple backup options available ### Related Documents * [Safe Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Verification procedures * [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - General emergency response * [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication during outages import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Communication Setup ### Primary channel Set up a dedicated communication channel for multisig operations: * **Platform**: Signal recommended (end-to-end encryption) * **Membership**: Multisig signers + authorized management only * **Configuration**: Notifications enabled, disappearing messages for sensitive discussions * **Naming**: Clear channel naming convention (e.g., "X-Treasury-Multisig") ### Backup channels Configure backup communication on a different platform: * **Platform**: Different from primary (if Signal primary, use Telegram/Discord/Slack) * **Same membership restrictions** as primary * **Document access procedures** for all signers ### Paging system (Critical/Emergency Multisigs) For multisigs requiring rapid response: * Configure alerts that can reach signers 24/7 * Include essential info in page: multisig name, urgency level, primary action needed * Link to emergency runbooks in notification message * Test quarterly to ensure reliability import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Emergency Procedures When security incidents occur, quick and decisive action is critical. This page covers procedures for key compromise, lost access, and communication breaches. ### Key Compromise #### Immediate Actions (Within 30 Minutes) 1. **Stop operations** - Halt all non-emergency transactions 2. **Notify team** - Alert via all communication channels using emergency notification template 3. **Assess scope** - Determine which keys may be compromised 4. **Escalate** - Contact Security team immediately 5. **Document** - Record timeline and details #### Recovery Process 1. **Isolate** - Quarantine potentially compromised devices 2. **New hardware setup** - Set up fresh wallet with new seed following [Hardware Wallet Setup](/wallet-security/intermediates-and-medium-funds) 3. **Coordinate replacement** - Plan signer replacement transaction with team 4. **Execute replacement** - Replace compromised signer on multisig, following the [Signer Rotation Runbook](/multisig-for-protocols/runbooks/signer-rotation) 5. **Verify security** - Confirm new setup before resuming operations ### Lost Key Access #### Immediate Steps 1. **Try backup device first** if available 2. **Contact team immediately** via backup communication channels 3. **Do not panic** - Lost access doesn't mean compromised keys 4. **Document the situation** - Record what happened and when #### Identity Verification Process Since you can't sign with your key, verify identity through alternative methods: * **Video call** with other signers * **Authentication** via verified social media account * **Other pre-arranged verification methods** #### Replacement Coordination 1. **Generate new hardware wallet** following standard setup procedures in [Hardware Wallet Setup](/wallet-security/intermediates-and-medium-funds) 2. **Verify new address** through identity verification process above 3. **Coordinate timing** with other signers for replacement transaction 4. **Execute replacement** once team confirms identity 5. **Update documentation** with new signer information ### Communication Account Compromise #### If Telegram/Signal/Discord Gets Taken Over ##### Immediate Actions 1. **Assume all recent messages are suspect** - Don't trust recent communication 2. **Use backup channels** to alert team about compromise 3. **Change passwords** and enable additional security on compromised account ##### Team Verification Process **For the compromised person:** * Use alternative contact methods (email, phone, other platforms) * Verify identity through video call or pre-arranged methods * Provide proof of the compromise (screenshots, platform confirmation) **For other team members:** * Verify all recent requests from compromised account * Cancel any pending transactions initiated via compromised communication * Require additional verification for any future requests until resolved ##### Recovery Steps 1. **Regain account control** through platform recovery processes 2. **Enable maximum security** (2FA, security keys, session management) 3. **Review recent message history** for unauthorized communications 4. **Alert team** when account is secured and verified clean 5. **Resume normal operations** only after team confirms account security ### Emergency Notification Template Use this template for security incidents or key compromises: ``` Subject: [URGENT] Multisig Security Incident - [Multisig Name] Immediate details: - Multisig address: [ADDRESS] - Classification: [Impact Level / Operational Type] - Incident type: [Key Compromise / Communication Failure / System Issue] - Time of discovery: [TIMESTAMP] - Reporting signer: [NAME/HANDLE] Situation summary: [Brief description of what happened and current status] Immediate actions taken: □ Stopped non-emergency operations □ Isolated affected systems □ Notified team members □ [Other actions] Next steps required: □ Security team assessment □ Key rotation process □ Emergency transaction execution □ [Other actions] Current multisig status: - Available signers: [X/Y] - Communication status: [Operational/Compromised] - Operational capability: [Full/Limited/Suspended] ``` ### Emergency Communication Protocols #### Multi-Channel Notification * **Primary channel**: Alert via main communication channel * **Backup channels**: Simultaneously notify via backup platforms * **Emergency contacts**: Use emergency contact procedures if established #### Identity Verification * **Code words**: Use pre-established verification phrases * **Multiple confirmations**: Verify through multiple channels * **Video verification**: Use video calls for critical confirmations #### Information Sharing * **Need-to-know basis**: Share only essential information * **Secure channels only**: Use most secure available communication * **Documentation**: Record all emergency communications ### Operational Emergency Procedures #### For Emergency Response Multisigs ##### Rapid Response Protocol 1. **Immediate assessment** - Determine scope and urgency 2. **Signer activation** - Contact threshold number of signers 3. **Streamlined verification** - Use minimal verification appropriate for risk level 4. **Execute response** - Implement emergency measures 5. **Post-action review** - Document and assess response effectiveness ##### 24/7 Availability * **Geographic distribution** - Ensure coverage across time zones * **Backup signers** - Have additional signers available for activation * **Communication redundancy** - Multiple ways to reach each signer ### Emergency Pause Runbook Use the full [Emergency Pause Runbook](/multisig-for-protocols/runbooks/emergency-pause) as the canonical execution playbook for emergency pause transactions. Keep this page focused on incident coordination, communication, and recovery, and use the runbook page for the transaction-specific signing and execution steps. #### Emergency Drill Procedures ##### Regular Testing Schedule * **Quarterly**: Communication system tests * **Bi-annually**: Emergency paging system tests * **Annually**: Full emergency simulation with all signers ##### Drill Components 1. **Notification test** - Verify all signers receive alerts 2. **Response time measurement** - Track time to threshold signatures 3. **Process verification** - Ensure procedures work under pressure 4. **Documentation review** - Update procedures based on drill results ### Recovery and Post-Incident #### Immediate Recovery 1. **Restore operations** - Resume normal operations once threat is mitigated 2. **Monitor for issues** - Watch for any residual security concerns 3. **Update security measures** - Implement additional controls if needed #### Post-Incident Analysis 1. **Root cause analysis** - Determine how incident occurred 2. **Process improvement** - Update procedures to prevent recurrence 3. **Team debriefing** - Gather lessons learned from all participants 4. **Documentation updates** - Revise emergency procedures based on experience #### Communication 1. **Team notification** - Inform team when incident is resolved 2. **Stakeholder updates** - Notify relevant parties as appropriate 3. **Documentation** - Complete incident report for future reference ### Emergency Contact Information #### Security Team Contact * **Email**: \[Security team email] * **Emergency escalation**: \[24/7 emergency contact if available] * **Communication**: Use subject line format from emergency notification template #### Internal Escalation * **Protocol leadership**: \[Contact information] * **Technical team**: \[Emergency technical contact] * **Legal/compliance**: \[If regulatory notification required] ### Related Documents * [Incident Reporting](/multisig-for-protocols/incident-reporting) - Formal incident reporting procedures * [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication channels * [Hardware Wallet Setup](/wallet-security/intermediates-and-medium-funds) - Device replacement procedures * [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key recovery procedures * [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account security measures * [Operational Runbooks](/multisig-for-protocols/runbooks/overview) - Example runbooks for common operations import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Implementation Checklist This checklist ensures all multisig participants have the knowledge and skills necessary for secure operations. Complete all applicable sections before beginning multisig operations. ### For Multisig Administrators #### Planning & Setup * [ ] I have classified my multisig using the impact and operational framework from [Planning & Classification](/multisig-for-protocols/planning-and-classification) * [ ] I have selected appropriate thresholds based on the classification guidance * [ ] I have identified and verified all signers for the multisig * [ ] I have deployed the multisig with correct configuration * [ ] I have set up required modules (eg. allowance module to rescue assets) #### Documentation & Communication * [ ] I have classified and documented the new multisig using templates from [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) * [ ] I have set up primary and backup communication channels per [Communication Setup](/multisig-for-protocols/communication-setup) * [ ] I have tested emergency notification procedures * [ ] I have documented emergency contact information #### Ongoing Management * [ ] I have established procedures for regular reviews and updates per [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) * [ ] I have set up backup infrastructure and tested alternative UIs per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) * [ ] I have verified all signers have completed training requirements * [ ] I understand signer rotation procedures for my multisig type ### For Signers #### Hardware & Security Setup * [ ] I have purchased recommended hardware wallet from authorized source per [Hardware Wallet Setup](/wallet-security/intermediates-and-medium-funds) * [ ] I have set up my hardware wallet with proper firmware and PIN * [ ] I have created and tested backup hardware wallet with same seed * [ ] I have stored my seed phrase securely using approved methods from [Seed Phrase Management](/wallet-security/seed-phrase-management) * [ ] I have created dedicated accounts for each multisig I'm signing for #### Operational Readiness * [ ] I have joined multisig communication channels (primary and backup) per [Communication Setup](/multisig-for-protocols/communication-setup) * [ ] I have verified my signer address using the required signature process from [Joining a Multisig](/multisig-for-protocols/joining-a-multisig) * [ ] I understand my multisig's classification and response time requirements * [ ] I have completed a test transaction with the multisig team #### Transaction Verification * [ ] I can use approved verification tools (Safe CLI Utils, OpenZeppelin SafeUtils for EVM) from [Tools & Resources → Transaction Verification](/wallet-security/tools-and-resources#transaction-verification) * [ ] I understand how to verify transaction hashes before signing * [ ] I can decode and verify transaction details (amounts, recipients, contract calls) * [ ] I have practiced verifying both simple transfers and complex transactions #### Emergency Preparedness * [ ] I have downloaded backup UIs (Eternal Safe for EVM, Squads public client for Solana) per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) * [ ] I know how to sign transactions when primary UI is down per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) * [ ] I understand emergency procedures for key compromise and communication failures per [Emergency Procedures](/multisig-for-protocols/emergency-procedures) * [ ] I have tested backup communication methods with my team * [ ] I know who to contact for security incidents and emergencies per [Incident Reporting](/multisig-for-protocols/incident-reporting) #### Personal Security * [ ] I have enabled 2FA on all accounts with approved methods (YubiKey preferred) per [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) * [ ] I use dedicated devices or accounts for multisig operations when required * [ ] I have implemented travel security procedures appropriate for my risk level * [ ] I understand incident reporting procedures for security concerns #### Compliance * [ ] I have read and understand all sections of this security framework * [ ] I understand my specific role requirements based on multisig classification * [ ] I know how to properly offboard when leaving a multisig role per [Offboarding](/multisig-for-protocols/offboarding) * [ ] I commit to following these security procedures and reporting any deviations ### Specialized Training by Use Case #### Emergency Response Multisigs Additional requirements from [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements): * [ ] I understand 24/7 availability requirements * [ ] I have participated in emergency simulation drills * [ ] I know how to respond to emergency paging * [ ] I understand streamlined verification procedures for emergencies #### Treasury Multisigs * [ ] I understand allowance module configuration and purpose * [ ] I know governance rescue procedures * [ ] I understand financial reporting requirements #### Smart Contract Control Multisigs * [ ] I understand timelock configuration per [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration) * [ ] I know how to verify staged transactions * [ ] I understand higher threshold requirements for upgrades ### Practical Skills Assessment #### Transaction Verification (EVM) * [ ] I can successfully verify a Safe transaction hash using CLI tools * [ ] I can decode transaction calldata and identify recipients and amounts * [ ] I can identify risky transaction types and warnings * [ ] I can verify nested Safe transactions if applicable #### Transaction Verification (Solana) * [ ] I can analyze Solana transaction instruction data * [ ] I can convert hex values to decimal for amount verification * [ ] I can identify different transaction types (SOL transfer, token transfer, config changes) #### Emergency Procedures * [ ] I can access backup UIs and complete a transaction * [ ] I can contact team via backup communication channels * [ ] I know how to report key compromise immediately * [ ] I can execute identity verification procedures if needed #### Tool Proficiency * [ ] I am comfortable using my hardware wallet for signing * [ ] I can navigate backup block explorers * [ ] I can use alternative RPC endpoints * [ ] I understand how to manually simulate transactions ### Documentation Review #### Required Reading Completed * [ ] [Secure Multisig Best Practices](/wallet-security/secure-multisig-best-practices) - Core requirements for all multisigs * [ ] [Hardware Wallet Setup](/wallet-security/intermediates-and-medium-funds) - Device security requirements * [ ] [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key protection procedures * [ ] [Safe Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Signing procedures * [ ] [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - Crisis response protocols * [ ] [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account and device security #### Role-Specific Documentation **For Administrators:** * [ ] [Planning & Classification](/multisig-for-protocols/planning-and-classification) * [ ] [Setup & Configuration](/multisig-for-protocols/setup-and-configuration) * [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) * [ ] [Communication Setup](/multisig-for-protocols/communication-setup) * [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) **For Specialized Use Cases:** * [ ] [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements) * [ ] [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) * [ ] [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration) (if applicable) ### Certification and Acknowledgment #### Training Completion * [ ] I have completed all applicable training requirements * [ ] I have successfully demonstrated practical skills * [ ] I understand the security implications of my role * [ ] I acknowledge my responsibilities as a multisig participant #### Ongoing Commitment * [ ] I commit to following all security procedures outlined in this framework * [ ] I will report any security incidents or concerns promptly * [ ] I will participate in regular training updates and refreshers * [ ] I will maintain the required level of security for my role #### Trainer Verification (if applicable) **For organizations requiring formal training:** Trainer: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Trainee has demonstrated competency in: * [ ] Transaction verification procedures * [ ] Emergency response protocols * [ ] Security best practices * [ ] Role-specific requirements **Signature:** \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ ### Refresher Training Schedule #### Regular Updates * **Monthly**: Review emergency procedures and contact information * **Quarterly**: Practice backup system usage and emergency drills * **Annually**: Complete full framework review and updates * **As needed**: Training on new tools, procedures, or threats #### Trigger Events Additional training required after: * Framework updates or changes * Security incidents affecting the team * New tool adoption * Role changes or additional responsibilities ### Related Documents All documents in this framework serve as training materials. Refer to individual documents for detailed procedures and requirements specific to your role. import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Incident Reporting ### What to Report #### Security incidents (report immediately) * Key compromise or suspected compromise * Account takeovers (email, communication platforms, etc.) * Device theft or loss * Suspicious activity on multisig accounts * Phishing attempts targeting multisig operations * Communication channel infiltration #### Operational issues (Report Within 24 Hours) * Lost access to signing keys or devices * Failed hardware wallets or backup devices * Communication channel failures * Verification tool malfunctions * Difficulty following security procedures #### Near misses (report when convenient) * Social engineering attempts * Suspicious emails or messages * Security procedure confusion or errors * Training gaps or unclear documentation ### How to report #### Immediate security incidents 1. Secure the situation first (disconnect devices, change passwords, etc.) 2. Notify your multisig team via secure channels 3. Email Protocol Security 4. Use subject line: "URGENT: Security Incident - \[Your Handle/Multisig Name]" #### Standard reporting * Email Protocol Security * Use clear subject line: "Incident Report - \[Brief Description]" * Include required documentation (see below) * Follow up if you don't receive acknowledgment within 48 hours #### Emergency contact For critical security incidents requiring immediate response: Email: security team ### Emergency notification template Use this template for security incidents or key compromises: ``` Subject: [URGENT] Multisig Security Incident - [Multisig Name] Immediate details: - Multisig address: [ADDRESS] - Classification: [Impact Level / Operational Type] - Incident type: [Key Compromise / Communication Failure / System Issue] - Time of discovery: [TIMESTAMP] - Reporting signer: [NAME/HANDLE] Situation summary: [Brief description of what happened and current status] Immediate actions taken: □ Stopped non-emergency operations □ Isolated affected systems □ Notified team members □ [Other actions] Next steps required: □ Security team assessment □ Key rotation process □ Emergency transaction execution □ [Other actions] Current multisig status: - Available signers: [X/Y] - Communication status: [Operational/Compromised] - Operational capability: [Full/Limited/Suspended] ``` ### Documentation Simple incident report template: ``` Incident report Date/Time: [When incident occurred] Reported by: [Your handle] Multisig(s) affected: [Names/addresses] What happened: [Brief description of the incident] When discovered: [How and when you became aware] Actions taken: - [Step 1] - [Step 2] - [Step 3] Current status: [Resolved/Ongoing/Assistance needed] Impact: [None/Limited/Significant - brief explanation] Additional notes: [Any other relevant information] ``` {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Multisig For Protocols > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Multisig Security Framework](/multisig-for-protocols/overview) * [Multisig Planning & Classification](/multisig-for-protocols/planning-and-classification) * [Multisig Setup & Configuration](/multisig-for-protocols/setup-and-configuration) * [Multisig Registration & Documentation](/multisig-for-protocols/registration-and-documentation) * [Multisig Communication Setup](/multisig-for-protocols/communication-setup) * [Multisig Use Case Requirements](/multisig-for-protocols/use-case-specific-requirements) * [Joining a Multisig](/multisig-for-protocols/joining-a-multisig) * [Multisig Emergency Procedures](/multisig-for-protocols/emergency-procedures) * [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) * [Multisig Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) * [Multisig Incident Reporting](/multisig-for-protocols/incident-reporting) * [Multisig Offboarding](/multisig-for-protocols/offboarding) * [Multisig Implementation Checklist](/multisig-for-protocols/implementation-checklist) * [Runbooks](/multisig-for-protocols/runbooks) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Joining a Multisig It is recommended to always create a fresh address on a hardware wallet for each new multisig. ### Verifying address ownership Creating a proof of address ownership provides important documentation and security assurances to the protocol for all multisig signers. Entity affiliations are acceptable - the goal is accountability, not doxing. #### Preparing and sharing address & Signature Sign the message like \[@social\_handle | name | entity] is looking to join \[Multisig Name] X DAO multisig with address 0x... with the private key you intend to use as a signer. One option is to use the MyCrypto web UI: 1. Connect your wallet to [https://app.mycrypto.com/sign-message](https://app.mycrypto.com/sign-message) 2. Enter the message, click "sign" and sign the message on the wallet. 3. The sig field in the result JSON is the signature hash. Share the message: * **Option 1** - Publish the message along with the signature hash on twitter or other easily accessible social media. * **Option 2** - Share the message privately with multisig admin so it can be stored with multisig documentation ### Ethereum signature verification #### Etherscan UI 1. Go to [https://etherscan.io/verifiedSignatures](https://etherscan.io/verifiedSignatures). 2. Click the Verify Signature button. 3. Input address, message & signature hash data & click Continue. 4. See whether the signature provided is valid. 5. To publish: choose "Verify & publish" and click "Continue". 6. After the signature is verified, you'll get the link for sharing. Note: Enter plain text message (not the hex version MyEtherWallet will give!) and ensure the signature includes the 0x prefix. #### MyCrypto 1. Go to [https://app.mycrypto.com/verify-message](https://app.mycrypto.com/verify-message) 2. Enter json & click Verify: ```json { "address": "0x...", "msg": "0x...", "sig": "signature_hash" } ``` Note that "msg" is hex text starting with 0x (add 0x before the hex encoded string if necessary). 4. See whether the signature provided is valid. import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Offboarding When leaving a multisig, follow these steps: ### Signer removal 1. **Coordinate with team** - Notify other signers and schedule the removal transaction 2. **Execute removal** - Follow the [Signer Rotation Runbook](/multisig-for-protocols/runbooks/signer-rotation) 3. **Verify removal** - Confirm your address has been removed from the multisig 4. **Update documentation** - Ensure documentation reflects the change ### Timing requirements Teams should define offboarding timelines in advance based on the multisig's role, risk, and governance process. For higher-risk or emergency-sensitive multisigs, signer removal may need to happen on a much shorter timeline. For lower-risk setups, the appropriate timeline may be longer. Document the expected response window in your internal policy and make sure it is understood by all signers. For example: * **Emergency-class multisigs**: Complete signer removal within 48-72 hours * **Critical-class multisigs**: Complete signer removal within 7 days * **Other multisigs**: Complete signer removal within 14 days ### Clean up access * Leave all multisig communication channels (Signal, Telegram, etc.) * Remove access to any sensitive shared documents or resources * Delete any locally stored sensitive multisig information ### Handover * Share any relevant context or pending items with remaining signers * Provide contact information if needed for transition questions import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Multisig Security Framework ### How to use this guide **Quick start**: New to multisigs? Start with the Foundation for the essentials, then jump to your role: * Setting up a new multisig? → Multisig Administration: [Setup & Configuration](/multisig-for-protocols/setup-and-configuration) and [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) * Joining as a signer? → [Joining a Multisig](/multisig-for-protocols/joining-a-multisig) and [Hardware Wallet Setup](/wallet-security/intermediates-and-medium-funds) * Need to sign a transaction? → Signing & Verification: [Safe Multisig](/wallet-security/signing-and-verification/secure-multisig-safe-verification) and [Squads](/wallet-security/signing-and-verification/secure-multisig-squads-verification), plus [Operational Runbooks](/multisig-for-protocols/runbooks/overview) * Emergency situation? → [Emergency Procedures](/multisig-for-protocols/emergency-procedures) ### Core principles * **Security first**: Every multisig must meet [minimum security standards](/wallet-security/secure-multisig-best-practices) * **Operational readiness**: Procedures that work under pressure * **Clear accountability**: Everyone knows their role and responsibilities * **Emergency preparedness**: Plans for when things go wrong ### Framework Structure #### 1. Foundation * [Secure Multisig Best Practices](/wallet-security/secure-multisig-best-practices) - Core requirements for all multisigs #### 2. Multisig Administration * [Planning & Classification](/multisig-for-protocols/planning-and-classification) - Assess requirements and classify risk * [Setup & Configuration](/multisig-for-protocols/setup-and-configuration) - Deploy and configure multisigs * [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - Document and verify setup * [Communication Setup](/multisig-for-protocols/communication-setup) - Establish secure communication channels * [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements) - Special requirements by type * [Operational Runbooks](/multisig-for-protocols/runbooks/overview) - Example procedures for common operations #### 3. For Signers * [Hardware Wallet Setup](/wallet-security/intermediates-and-medium-funds) - Secure device configuration * [Seed Phrase Management](/wallet-security/seed-phrase-management) - Protect your recovery keys * [Joining a Multisig](/multisig-for-protocols/joining-a-multisig) - Verification and onboarding process * [Safe Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Safely verify and sign transactions * [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - Handle key compromise and emergencies * [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) - Use backup interfaces * [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Protect your accounts and devices * [Incident Reporting](/multisig-for-protocols/incident-reporting) - Report security issues and incidents * [Offboarding](/multisig-for-protocols/offboarding) - Safely leave a multisig role #### 4. Reference * [Implementation Checklist](/multisig-for-protocols/implementation-checklist) - Verify readiness for multisig operations import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Personal Security (OpSec) ### Account Security #### Basic requirements * 2FA enabled on all accounts (authenticator apps or hardware keys) * Password manager with unique, strong passwords for every account * Remove phone numbers from account recovery options where possible * Regular security checkups and removal of unused app permissions * Backup email for account recovery (separate from primary email) #### For extra security **YubiKeys**: Use hardware security keys instead of authenticator apps * Provides stronger protection against phishing and SIM swapping * Recommended: 3 keys (primary, backup, secure storage) * Models: YubiKey 5C NFC, YubiKey 5C Nano **Cold backup accounts**: Separate email/phone for sensitive account recovery * Backup / cold accounts are tied to sensitive accounts (AppleID, Telegram, Signal, WhatsApp, Password Manager etc). Such email addresses must never be shared with anyone and kept private to remain secure and not targeted. Example: random44\@gmail is tied to your AppleID, and you are only logged in (the email) on a separate secure device. If your main device (laptop) gets compromised, you will be able to recover your account or revoke sessions, moreover your cold account won't be affected / compromised. It prevents people from targeting your accounts by not knowing your email linked to it. * Use different providers from primary accounts (Gmail, Proton) * Only access from secure devices * Never used for regular communications ### Device Security #### Basic requirements * Full disk encryption enabled (FileVault/BitLocker) * Automatic updates enabled on all devices * Screen lock after 5 minutes of inactivity on computers, 30 seconds on mobile * Strong passcodes (6+ digits or alphanumeric on mobile) * Endpoint protection software on computers * No admin rights for daily use accounts (create separate admin account) #### For extra security **Dedicated signing device**: Clean laptop/tablet used only for multisig operations * Minimal software installation * Regular security updates * Clean restart before each use * Offline storage when not in use * Justification: Reduces attack surface for high-value operations ### Network Security #### Dedicated Signing Machines * Multi-sig operations must be performed on devices dedicated only to these transactions and verification tools * All network access should be default blocked, with only the minimum necessary IPs to execute these transaction signatures allowed * Signing devices must be operated on private, authenticated networks or over trusted VPNs #### Air-Gapped Machine Options * For highest security, physically remove or disable the network interface * Use USB drives (with strict auto-run restrictions) or QR codes to transfer transaction data #### Advanced OS-Level Controls * Consider employing SELinux or similar tools for advanced security configurations * Restrict file system access and inter-process communications #### Network Monitoring Tools Organizations must implement active network monitoring on signing devices: * [Little Snitch](https://www.obdev.at/products/littlesnitch/index.html) for active firewall and network monitoring * [Lulu](https://objective-see.org/products/lulu.html) as a free, open source alternative to Little Snitch * [Glasswire](https://www.glasswire.com/) can be used for Windows machines #### DNS Security Use [DeFi DNS Whitelist](https://github.com/0xKoda/defi-dns-whitelist/tree/main) as a firewall for dedicated signing machines. ### Communication Security #### Basic requirements **Signal with verified safety numbers** for multisig communications: You MUST check the codes with the person you are interacting with to verify them. How? Click on any chat > Contact name > View Safety Number > Call on another communication channel to verify them > Click at the bottom "Mark as Verified". If the account connects on a new device these codes will change & you will receive a security notification. * Screen lock enabled on mobile devices * 2FA enabled on backup platforms (Telegram/Discord/Slack) * Privacy settings maximized on all platforms * Session management - remove old/unknown devices regularly #### Signal configuration * Registration lock enabled * Signal PIN configured * Hide phone number (use username only) * Safety number verification for all contacts * Disappearing messages for sensitive chats #### URL Navigation Safety Links to URLs containing transaction requests or confirmation data (even those provided by trusted parties) must never be clicked - they must be navigated to by using bookmarks or typing them out manually. #### For extra security **Enhanced verification**: Advanced safety procedures for critical communications * Code words for identity verification * Multiple verification channels for important requests * Regular communication channel security audits ### Travel considerations #### What to bring * Primary hardware wallet only (leave backups secure at home) * Essential devices only (laptop + phone) * Emergency contact information (offline copy) * Own chargers and cables #### What NOT to bring * Seed phrases (never travel with these) * Backup hardware wallets * USB drives with sensitive data * Non-essential devices #### Basic travel security * Use device locks at all times * Avoid public WiFi (use mobile hotspot or VPN) * Don't leave devices unattended in hotel rooms * Use hotel safes for device storage when out * Have offline backup of emergency contacts #### For extra security **Enhanced travel procedures**: Additional precautions for high-risk situations * Disable biometric unlock at airports/borders (use PIN only) - prevents forced unlocking * Decline hotel housekeeping services - reduces access to devices * Advance notification to multisig team (72 hours for critical operations) * Use separate carrier SIM card for travel communications * Professional security assessment of travel destinations ### Implementation priority #### Start with basics Focus on fundamental security practices first * Password manager + 2FA on all accounts * Device encryption and screen locks * Signal setup with safety number verification * Basic travel security practices #### Add extra security Implement additional measures based on your risk level and operational needs * YubiKeys for critical accounts * Dedicated signing devices for high-value operations * Enhanced travel procedures for international travel * Professional security assessments for critical roles Remember: Perfect security doesn't exist - focus on practical improvements that significantly reduce your risk while remaining operationally feasible. For the full OpSec article, see [Operational Security](/opsec/overview). import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, } from "../../../components"; ## Planning & Classification Before setting up a new multisig, take time to properly assess its role and requirements. This planning phase will guide all subsequent configuration decisions and help ensure appropriate security measures. ### Before You Start #### Define Purpose and Scope Document the multisig's intended use: * **Primary function** - What will this multisig do? * **Asset types and amounts** - What will it control? * **Operational frequency** - How often will it be used? * **Decision timeline** - How quickly must it respond? * **Integration points** - What systems will it interact with? #### Assess Constraints and Recovery Consider limiting factors that affect risk: * **Smart contract constraints** - What technical limits reduce risk? * **Governance recovery** - Can governance override or recover funds? * **Operational limits** - Are there built-in spending or parameter limits? * **Backup mechanisms** - What happens if this multisig fails? #### Identify Stakeholders Determine who should be involved: * **Required expertise** - What knowledge is needed for decisions? * **Geographic distribution** - Do you need global coverage? * **External signers** - Should independent parties be involved? * **Backup signers** - Who can step in if primary signers are unavailable? ### Classification Process Use this dual classification system to determine appropriate security measures. These classifications are guidance to help you think through risk levels - they inform threshold selection, signer requirements, and operational procedures in later sections. #### Step 1: Impact Assessment What happens if this multisig is compromised or fails? ##### Financial Exposure: * Direct funds controlled by the multisig * Indirect exposure through protocol impacts * Maximum potential loss in worst-case scenario ##### Protocol Impact: * Can the protocol function without this multisig? * How difficult would recovery be? * Are there alternative execution paths? ##### Reputational Risk: * How visible is this multisig to the community? * What would compromise mean for the protocol's reputation? * Are there regulatory or compliance considerations? ##### Impact Classification | Level | Financial Exposure | Protocol Impact | Reputational Risk | | ------------ | ----------------------- | ----------------------------------------------------- | ----------------------------- | | **Low** | \<$100k direct exposure | Minimal disruption, alternative paths exist | Limited scope impact | | **Medium** | $100k - $1M exposure | Significant operational delays, workarounds available | Moderate reputational concern | | **High** | $1M - $10M exposure | Major protocol disruption, difficult recovery | Serious reputational damage | | **Critical** | >$10M exposure | Protocol-wide failure, catastrophic impact | Severe reputational damage | #### Step 2: Operational Assessment How quickly and under what conditions must this multisig respond? ##### Response Time Requirements: * How quickly must decisions be made? * What are the consequences of delays? * Are there market or competitive timing factors? ##### Decision Context: * Are operations routine and predictable? * Do market conditions affect timing? * Is this primarily for emergency response? ##### Coordination Complexity: * How many parties must coordinate? * Are signers distributed globally? * What communication is required? ##### Operational Classification | Type | Response Time | Decision Context | Verification Level | | ------------------ | ------------- | -------------------------------------------- | -------------------------------- | | **Routine** | 24-48 hours | Standard procedures, predictable operations | Full verification protocols | | **Time-Sensitive** | 2-12 hours | Market conditions, protocol needs | Streamlined but thorough | | **Emergency** | \<2 hours | Crisis response, preventing immediate damage | Minimal delays, risk-appropriate | #### Step 3: Classification Matrix Combine your impact and operational assessments. Below are some example configurations. | Use Case | Impact | Operational | Standard Threshold | | ------------------- | -------- | -------------- | ---------------------------------------- | | Emergency Freeze | Critical | Emergency | 2/4 | | Protocol Parameters | High | Routine | 4/7 (higher for upgrades, consider 7/9+) | | Capital Allocation | High | Time-Sensitive | 3/5 | | Treasury - Large | High | Routine | 4/7 | | Treasury - Small | Medium | Routine | 3/5 | | Constrained DeFi | Medium | Time-Sensitive | 2/3 | #### Step 4: Document Your Decision Record your classification decision in the [Registration template](/multisig-for-protocols/registration-and-documentation#registration-template). ### Important Notes ⚠️ **When between classifications**: Always err toward higher security requirements. Classifications can be relaxed with proper justification, but security incidents cannot be undone. This classification will guide your threshold selection ([Thresholds & Configuration](/wallet-security/secure-multisig-best-practices#thresholds--configuration)), signer requirements, and operational procedures throughout the rest of the documentation. ### Next Steps After completing classification, proceed to: 1. [Setup & Configuration](/multisig-for-protocols/setup-and-configuration) - Deploy your multisig 2. [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - Document your setup import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Registration & Documentation Proper documentation is essential for multisig security and accountability. This page covers the registration process and required documentation. ### Protocol Documentation Fill out the registration template and send as a PDF to the protocol security team. They will create a dedicated section in protocol docs for your multisig with the registration information. ### Registration Template ``` Multisig Name: [Name] Address: [Checksummed address] Network: [Ethereum/Solana/etc] Threshold: [X of Y signers] Classification: [Impact Level] / [Operational Type] Purpose: [Brief description] Signers: - [Handle/Entity]: [Address] - [Verification signature] - [Handle/Entity]: [Address] - [Verification signature] Controlled contracts: [List contract addresses and purposes] On-chain roles: [Describe roles like ownable, Access Control roles (PAUSER_ROLE)] Impact assessment: - Financial exposure: $[amount] ([reasoning]) - Protocol impact: [description] - Classification: [Low/Medium/High/Critical] Operational classification: [Routine/Time-Sensitive/Emergency] Constraining factors: - [Smart contract limits, governance controls, etc.] Attestation: This multisig [meets/deviates from] security standards. [If deviation: Justification and compensating controls] Last updated: [Date] Updated by: [Name/Handle] ``` ### Signer Verification Process Each signer must provide a verification signature linking their identity to their address: 1. **Sign message**: "\[handle/entity] intends to join \[multisig address] with signer \[address]" 2. **Share signature** with multisig team 3. **Update registration** with verified information Detailed steps for collecting this information are provided in [Joining a Multisig](/multisig-for-protocols/joining-a-multisig). **Note**: Entity affiliations are acceptable - the goal is accountability, not doxing. ### Roles & Accountability #### Accountability Structure | Role | Responsibilities | | ---------------------------- | --------------------------------------------------------------------------------------------- | | **Multisig Operations Lead** | Policy maintenance, signer coordination, documentation, periodic reviews, incident escalation | | **Security Contact** | Security incident response, signer verification, emergency coordination | #### Multisig-Specific Roles For each multisig, assign: | Role | Responsibility | | ------------------------ | ---------------------------------------------------------------- | | **Admin** | Setup, configuration, signer management, documentation | | **Transaction Proposer** | Prepares and proposes transactions (may be delegated non-signer) | | **Signers** | Review, verify, and sign transactions | #### Signer Responsibilities Every signer must: * Use a hardware wallet for multisig operations * Maintain a documented recovery and continuity plan * Store seed material and recovery credentials securely * Verify every transaction before signing * Understand multisig response time expectations * Report incidents promptly * Complete required onboarding, training, and drills Recovery procedures vary by team. Some teams use backup devices or replicated seed material, while others avoid that model because it changes the threat surface. Document the tradeoffs and controls for whichever recovery approach you use. ##### Response Time SLAs Define expected response windows based on the multisig's classification, the assets or permissions it controls, and the team's operational model. See [Planning & Classification](/multisig-for-protocols/planning-and-classification#operational-classification). For example, teams often set much shorter expectations for emergency actions than for routine operational transactions. Record those expectations in your internal policy and make sure all signers understand them. Example: * **Emergency**: \<2 hours * **Time-Sensitive**: 2-12 hours * **Routine**: 24-48 hours #### Admin Responsibilities Multisig admins typically: * Ensure the multisig is properly documented * Maintain an up-to-date signer list with verified addresses * Set up primary and backup communication channels * Coordinate signer onboarding and offboarding * Schedule and conduct periodic reviews at a cadence appropriate to the multisig's risk and activity level (e.g. quarterly minimum) * Ensure backup infrastructure is configured and tested #### Operational Lead Responsibilities * Maintain the playbook and keep documentation current * Coordinate across all multisigs * Periodically review multisig configurations and supporting documentation * Escalate security concerns to the security contact * Report on operational status #### Review Schedule The right review cadence depends on the multisig's scope, activity level, and risk profile. Example review areas to assign and track: | Review Type | Frequency | Owner | | ------------------------------ | -------------------------------- | ------------------- | | Signer access review | Quarterly | Multisig Admin | | Classification review | Quarterly or after major changes | Ops Lead | | Emergency contact verification | Every 6 months | Ops Lead | | Full policy review | Annually | Ops Lead + Security | ### Update Template Use this template when making changes to signer composition: ``` Multisig Signer Update Multisig Name: [Name] Address: [Checksummed address] Network: [Ethereum/Solana/etc] Updated by: [Name/Handle] Update Date: [Date] Threshold Changes: Previous: [X of Y signers] New: [X of Y signers] Signer Changes: Additions: - [Handle/Entity]: [Address] - [Verification signature] Removals: - [Handle/Entity]: [Address] Current Signer Set: - [Handle/Entity]: [Address] - [Handle/Entity]: [Address] - [Handle/Entity]: [Address] Transaction: [Link to executed transaction] ``` ### Documentation Requirements #### Initial Registration * Complete registration template with all required fields * Verification signatures from all signers * Classification assessment from [Planning & Classification](/multisig-for-protocols/planning-and-classification) * Submit to protocol security team #### Ongoing Maintenance * Update documentation when signers change * Record rationale for any threshold changes * Update classification if operational patterns change * Maintain current contact information #### Transaction Review Records Maintain transaction records appropriate to your team's operational, legal, and compliance needs. At a minimum, teams often record: * What the transaction was for * Who proposed it * Who reviewed or approved it * Whether it was executed successfully * Any issues or anomalies encountered Retention periods and evidence requirements should be defined by your organization's own policy. **Retention**: 3 years minimum Transaction records should capture: ##### Header * Transaction: \[Brief Description] * Date: \[YYYY-MM-DD] * Multisig: \[Name] * Status: Proposed / Signing / Executed / Rejected ##### Transaction Details * Network * Safe or Squad address * Nonce * Transaction type ##### What This Transaction Does * Plain language description of what the transaction accomplishes ##### Initiation * Proposed by * Proposed date * Reason or justification * Runbook followed ##### Verification & Signing * Signer * Verified * Signed * Date * Notes ##### Verification Checklist * Correct multisig address * Correct network * Expected nonce * Target address verified * Calldata or amount verified * Simulation performed * Hash matched hardware wallet ##### Simulation Results * Tool used * Result * Expected behavior confirmed * Link ##### Execution * Executed by * Execution date * Transaction hash * Block explorer link * Gas used ##### Post-Execution Verification * Transaction confirmed on-chain * Expected state change verified * Registration updated if applicable * Team notified ##### Issues Encountered * Document any issues, delays, or anomalies ##### Attachments * Screenshot of simulation * Screenshot of hardware wallet confirmation * Communication thread link #### Alternative simple transaction record A simple transaction record might capture: ##### Core Record * Transaction: \[Brief Description] * Date: \[YYYY-MM-DD] * Multisig: \[Name] * Status: Proposed / Signing / Executed / Rejected * Proposed by * Reason or justification * Network * Multisig address * Transaction type * Transaction hash or proposal link * Who reviewed or signed * Outcome * Notes on any issues encountered ##### Optional Additional Evidence Higher-maturity teams may also choose to retain: * Expected nonce * Simulation results * Verification notes * Links to communication threads * Post-execution verification notes * Screenshots or supporting artifacts where appropriate ##### Sign-Off * Proposer * Final executor ### Ongoing Management #### Regular reviews Set periodic reminders to keep documentation current: * **Quarterly**: Review and update protocol documentation if needed * **After major changes**: Update when operational patterns or financial exposure changes significantly * **Protocol updates**: Reassess if significant protocol changes affect the multisig's role #### Signer changes Follow these procedures for adding, removing, or replacing signers: ##### Adding/Removing signers * Maintain or increase total signer count and threshold * Document rationale for any changes that reduce signers or threshold * Update all documentation immediately after change ##### Replacing signers Follow steps in the [Signer Rotation Runbook](/multisig-for-protocols/runbooks/signer-rotation) #### Documentation updates After any signer change: * Record change rationale and date * Communicate changes to protocol security team * Update communication channel memberships ##### Update Template Use the template in [Registration & Documentation → Update Template](/multisig-for-protocols/registration-and-documentation#update-template). ### Related Documents * [Planning & Classification](/multisig-for-protocols/planning-and-classification) - How to classify your multisig * [Joining a Multisig](/multisig-for-protocols/joining-a-multisig) - Signer verification process * [Operational Runbooks](/multisig-for-protocols/runbooks/overview) - Example procedures for common operations import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Setup & Configuration This page covers the technical deployment and configuration of multisigs on supported networks. ### Basic Setup #### EVM Networks (Ethereum, Base, etc.) 1. Go to [https://app.safe.global](https://app.safe.global) 2. Connect wallet of the deploying signer 3. Create new Safe with your determined threshold and signer addresses 4. **Multi-network deployment**: If deploying on multiple networks, Safe UI will offer to replicate the configuration #### Solana 1. Go to [https://squads.xyz/squads-multisig](https://squads.xyz/squads-multisig) 2. Connect wallet of the deploying signer 3. Create new multisig with your determined threshold and signer addresses ### Self-Hosted Multisig UI Multi-sig coordination UIs should be self-hosted to eliminate supply chain risk. Hosted UI should be IP restricted to allow access only from signer machines. Deploy from [Safe Wallet Monorepo](https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/web). While it should not be your final line of defense, securing the UI does protect your verification process from being compromised by supply-chain attacks. For emergency situations when the primary UI is unavailable, see [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure). ### Delegated Proposer It is recommended, but not required to authorize a separate transaction proposer for a Safe. This address can prepare transactions for signers to sign but is not an authorized signer on the Safe. Therefore **there is no risk of malicious signatures which can affect the Safe assets**. This wallet can hold no funds and simply act as a proposer. The primary reason to have a delegated proposer is that the hash verification utilities depend on the Safe API (unless details are entered manually). Until a transaction is **proposed** it does not show up in the API so the hash verification tools cannot detect it. ![Delegated proposer configuration interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/delegated-proposer-configuration-interface.png) ### Modules & Guards #### Allowance Module (Required for Treasury Multisigs) If your multisig will hold any assets on behalf of the DAO, set up governance rescue capability: **Mainnet configuration:** * **Module**: Allowance Module * **Grant allowance to**: DAO Agent * **Amount**: Max value for each token held #### Zodiac Delay Modifier (Time-Locks) Consider using [Zodiac Modifier Delay](https://github.com/gnosisguild/zodiac-modifier-delay/tree/main) or equivalent for implementing on-chain time-lock transaction delays to Safe wallets. See [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration) for detailed timelock configuration guidance. #### Other Modules Do not install any other modules or guards without explicit governance approval and security review. ### Contract-Level Controls **Advanced Configuration Warning:** The following contract-level controls are advanced security features that can provide additional protection but require careful implementation. Before implementing any guards or modules: * **Conduct thorough research** on available guard implementations and their compatibility with your multisig setup * **Ensure all guards are well-audited** by reputable security firms before deployment * **Test extensively** on testnets to verify functionality and edge cases * **Understand the risks**: Incorrect configuration or incompatible guards can render your multisig unusable, potentially locking access to funds permanently #### Address Whitelisting Approved smart contract and wallet addresses must be added to a whitelist that is enforced at the contract-level. Interactions with all other addresses should be denied and revert the transaction. Updating the whitelist should require an extra signer in addition to the standard transaction approval quorum. #### Invariant Enforcement Design contracts to enforce invariants and expected state changes such as token balance changes, ownership and administration, and proxy implementation addresses. Ensure contracts automatically revert transactions if any invariant is violated. ### Initial Testing #### Verify Basic Functionality 1. **Small test transaction**: Send a low-value token transfer (e.g., 1 USDS or equivalent) 2. **All signers test**: Ensure each signer can successfully sign the test transaction 3. **Confirm execution**: Verify the transaction executes as expected 4. **Test communication**: Use your established channels to coordinate the test ### Pre-Launch Checklist * [ ] Safe deployed with correct threshold * [ ] All signer addresses added and [verified](/multisig-for-protocols/registration-and-documentation#signer-verification-process) * [ ] Allowance module configured (if required) * [ ] Test transaction completed successfully * [ ] All signers confirmed they can sign * [ ] [Communication channels](/multisig-for-protocols/communication-setup) tested during transaction * [ ] Safe addresses documented for all networks #### Practice on Testnet Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and owner management on a test network. Once setup is complete, proceed to [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) for registration and documentation requirements. ### Nested Safes A nested Safe is one in which a Safe is set as a signer on another Safe rather than an EOA. This can be useful on a case-by-case basis. For example, if a signer is an entity that might want to have multiple individual signers, the nested Safe could have a 1/X threshold allowing anyone authorized on the team to sign. However, this configuration allows the signers on the nested Safe to update the signer addresses without needing authorization from the main Safe. It is generally recommended **not** to use nested safe on protocol multisigs unless there is a specific use case that it enables. ### Next Steps After completing setup: 1. [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - Document your multisig 2. [Communication Setup](/multisig-for-protocols/communication-setup) - Establish secure communication 3. [Hardware Wallet Setup](/wallet-security/intermediates-and-medium-funds) - Ensure all signers are properly configured ### Active Monitoring Implement monitoring and alerting systems to be immediately notified of any on-chain activity related to the multisig, including proposed transactions, new signatures, and owner changes (e.g., using tools like [Safe Watcher](https://github.com/Gearbox-protocol/safe-watcher)). #### Immutable Monitoring Channels Monitoring channels (e.g. email, Slack or Telegram chats) must be immutable (or trigger alerts when their configuration changes or logs are deleted/tampered with) and redundant such that an admin could not disable or tamper with one monitoring channel without generating an alert on the other channel. import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Use Case Specific Requirements ### Treasury Multisigs #### Key requirements: * **Allowance module** required for all multisigs (see [Modules & Guards](/multisig-for-protocols/setup-and-configuration#modules--guards)) #### Hot/Cold Wallet Separation * Hot wallet must be used as an intermediary for treasury wallets * Cold wallet must store the majority of assets * Only basic transfers to the hot wallet address allowed * Hot wallet must have a minimum 2-of-3 signer quorum #### Wallet Segregation * Very high value assets must be distributed amongst separate wallets to prevent potential loss of all assets * At least 3 equally funded cold wallets are recommended * Segregated wallets should be managed by different multi-sigs * Seldom used wallets should have increased time-lock periods * Any activity on seldom used wallets should trigger alerts to the entire team #### External Signer Requirements * Multi-sigs managing high value wallets and contracts should have at least 1 additional required signer that is external to the organization (such as a security partner or trusted advisor) #### External Transaction Monitoring * A third party outside of the organization should be set up to monitor time locked transactions for anomalies and unintended transaction effects * The external monitor must perform transaction simulation of all pending transactions * Monitor reports must be delivered at least 48 business hours before the time lock for a transaction lapses in order to provide adequate time to respond in the event of an anomaly ### Emergency response Multisigs #### Training & Drills: * Bi-annual paging system tests to verify alert functionality * Annual full emergency simulation with all signers #### Additional requirements: * Geographic distribution encouraged for 24/7 coverage * 24/7 availability for threshold number of signers ### Capital allocation Multisigs #### Operational constraints: * Encourage on-chain constraints wherever possible (smart contract limits, parameter bounds) * Protocol expertise required for all signers ### Smart contract control Multisigs #### On-chain constraints: * [**Timelock contracts**](#timelock-configuration) for major changes (upgrades, significant parameter changes) * Parameter limits enforced by smart contracts where feasible #### Threshold considerations: * Higher thresholds for contract upgrades (consider 7/9+) * Lower thresholds acceptable for highly constrained operations (rate setting with bounds and a backup recovery mechanism to replace the multisig) ### Timelock Configuration For sensitive protocol operations like configuration changes or upgrades it is recommended to use a timelock contract (eg. [OpenZeppelin Timelock Controller](https://docs.openzeppelin.com/contracts/5.x/api/governance#TimelockController)) to stage transactions on-chain for final verification before execution. It is not necessary to have a long delay. Some timelock contracts are even configured with 0 delay. The key is to have the full transaction payload fully on chain after signature with a final opportunity to review it and cancel it. #### Configuration When using a timelock contract the timelock address will be set as the owner or role-holder for the protocol contract. The Safe will be the sole contract that has the Proposer role on the timelock contract. The Safe, or an address of a multisig signer, or other desired EOA can be set as the canceller or executor on the timelock contract. By default the timelock contract is set to be its own admin. This means that any changes to timelock contract roles also go through the timelock stage. #### Veto Quorum * Establish a smaller veto group separate from the confirmation quorum to review and confirm transaction legitimacy * Organizations can establish veto quorums to bypass time-locks in case of emergency * The standard quorum plus two additional signers should be required to bypass #### Recommended Time-Lock Delays Time-locks should delay transactions a minimum of 3 days. #### Simulation Consideration When using a timelock the simulation for the multisig transaction will not show the execution of the transaction but instead the addition of the pending transaction to the timelock. The pending transaction can be simulated manually as shown in [Simulation testing](/wallet-security/signing-and-verification/secure-multisig-safe-verification). ![Timelock configuration diagram](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/timelock-configuration-diagram.png) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Emergency Pause Runbook This is an example runbook. Review and customize it for your protocol before use. Add your specific contract addresses, pause functions, emergency contacts, and communication channels. ### Quick Reference | Field | Value | | ---------------------- | -------------------------------------------------------------- | | **Severity** | EMERGENCY | | **Response Time** | Defined by your incident-response policy (e.g. \<2 hs) | | **Required Threshold** | Use the threshold and signer path predefined for this multisig | | **Owner** | Security Team | | **Last Updated** | *Date* | ### When to Use * Active exploit detected * Suspicious activity on protocol contracts * Key compromise affecting protocol * Vulnerability disclosure requiring immediate action ### Immediate Actions (First 30 Minutes) #### 1. Alert Team * [ ] Send alert to emergency Signal group * [ ] Page signers via configured paging system * [ ] Notify the security contact **Alert template**: ```text URGENT: [Brief description] Multisig: [Name] Action needed: [Pause/Freeze/etc.] Respond ASAP - <2hr SLA ``` #### 2. Assess Situation * [ ] Confirm threat is real (not false alarm) * [ ] Identify affected contracts or assets * [ ] Determine which pause function(s) to call * [ ] Estimate urgency #### 3. Prepare Transaction **Proposer** (can be any signer or delegated proposer): 1. Go to Safe or Squads UI 2. Use Transaction Builder for contract interaction 3. Select target contract 4. Select `pause()` or appropriate emergency function 5. Create transaction ### Signing Process (Streamlined) Emergency signing follows abbreviated verification. #### Minimum Verification ```text [ ] Correct multisig address [ ] Correct network [ ] Target contract is correct (verify address) [ ] Function is pause() or expected emergency function [ ] No unexpected additional calls [ ] Hash matches hardware wallet ``` #### Sign and Communicate * [ ] Sign immediately after verification * [ ] Message: "Signed - \[X/Y] - \[your name]" * [ ] Stay available until executed #### Execute * [ ] Execute as soon as threshold is reached * [ ] Verify pause took effect (check contract state) * [ ] Communicate: "EXECUTED - pause confirmed" ### Contract Reference | Contract | Address | Pause Function | Expected Behavior | | ----------------------- | ------- | ----------------- | -------------------- | | Example contract 1 | `0x...` | `pause()` | Stops all operations | | Example contract 2 | `0x...` | `emergencyStop()` | Stops withdrawals | | Add your contracts here | | | | ### After Pause #### Immediate (Within 1 hour) * [ ] Confirm pause is effective * [ ] Document incident using [Incident Reporting](/multisig-for-protocols/incident-reporting) * [ ] Notify stakeholders #### Short-term (Within 24 hours) * [ ] Root cause analysis * [ ] Plan for resolution * [ ] Draft public communication if needed #### Resolution * [ ] Fix underlying issue * [ ] Test fix thoroughly * [ ] Plan unpause procedure * [ ] Execute unpause with full verification (not emergency process) ### If Primary UI is Down Use backup infrastructure: **EVM**: 1. [Eternal Safe](https://eternalsafe.eth.limo) 2. Configure with backup RPC 3. Load Safe address 4. Create custom transaction with pause calldata **Solana**: 1. [Squads Backup](https://backup.app.squads.so) 2. Configure RPC 3. Load multisig See [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) for detailed instructions. ### Escalation If threshold cannot be reached within SLA: 1. Contact backup signers 2. Escalate to decision makers 3. Consider alternative mitigations 4. Document why threshold was not met **Emergency contacts**: See your configured emergency contact list. ### Related Documents * [Emergency Procedures](/multisig-for-protocols/emergency-procedures) * [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) * [Incident Reporting](/multisig-for-protocols/incident-reporting) * [Operational Runbooks](/multisig-for-protocols/runbooks/overview) {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Runbooks > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Multisig Operational Runbooks](/multisig-for-protocols/runbooks/overview) * [Token Transfer Runbook](/multisig-for-protocols/runbooks/token-transfer) * [Signer Rotation Runbook](/multisig-for-protocols/runbooks/signer-rotation) * [Threshold Change Runbook](/multisig-for-protocols/runbooks/threshold-change) * [Emergency Pause Runbook](/multisig-for-protocols/runbooks/emergency-pause) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Operational Runbooks These are example runbooks for common multisig operations. Review and customize them for your protocol before use. ### Available Runbooks * [Token Transfer Runbook](/multisig-for-protocols/runbooks/token-transfer) - Send tokens from a multisig to another address using standard verification and execution steps. * [Signer Rotation Runbook](/multisig-for-protocols/runbooks/signer-rotation) - Add, remove, or replace signers while preserving signer-count and threshold requirements. * [Threshold Change Runbook](/multisig-for-protocols/runbooks/threshold-change) - Update a multisig threshold while checking policy requirements and post-change verification. * [Emergency Pause Runbook](/multisig-for-protocols/runbooks/emergency-pause) - Execute urgent pause transactions with streamlined verification and backup infrastructure. ### Related Documents * [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - Record changes and maintain audit trails * [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - Coordinate incidents and recovery actions * [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) - Use backup interfaces when primary systems are unavailable import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Signer Rotation Runbook This is an example runbook. Review and customize it for your protocol before use. Add your specific multisig addresses, signer requirements, and communication channels. ### Quick Reference | Field | Value | | ---------------------- | -------------- | | **Typical Severity** | Routine | | **Required Threshold** | Standard | | **Owner** | Multisig Admin | | **Last Updated** | *Date* | ### When to Use * Adding a new signer * Removing a departing signer * Replacing a signer (key rotation, lost access) ### Prerequisites * [ ] Reason for change documented * [ ] New signer has completed [Joining a Multisig](/multisig-for-protocols/joining-a-multisig) (if new) * [ ] New signer's address verified via signed message * [ ] Change maintains minimum signer count and threshold requirements * [ ] If reducing signers or threshold: justification documented and approved ### Adding a Signer #### EVM (Safe) **Proposer**: 1. Go to [Safe](https://app.safe.global) 2. Settings > Setup > Owners 3. Click "Add new owner" 4. Enter new signer's address (checksummed) 5. Set threshold (typically maintain same ratio) 6. Create transaction **Verification checklist**: ```text [ ] New signer address is correct (verified via signed message) [ ] Threshold is appropriate after addition [ ] Not accidentally removing anyone [ ] Message hash matches hardware wallet ``` #### Solana (Squads) **Proposer**: 1. Go to [Squads Multisig](https://squads.xyz/squads-multisig) 2. Configuration > Add Member 3. Enter new signer's address 4. Set permissions 5. Create proposal ### Removing a Signer #### EVM (Safe) **Proposer**: 1. Settings > Setup > Owners 2. Click remove (trash icon) next to signer 3. Adjust threshold if needed (cannot exceed new signer count) 4. Create transaction **Verification checklist**: ```text [ ] Correct signer being removed [ ] Threshold still appropriate (>=50%) [ ] Maintains minimum signer count (3+) [ ] Message hash matches hardware wallet ``` #### Solana (Squads) **Proposer**: 1. Configuration > Remove Member 2. Select member to remove 3. Adjust threshold if needed 4. Create proposal ### Replacing a Signer (Swap) When a signer needs to change their address. #### If Original Key is Accessible 1. New signer proves ownership by signing message with **existing** address: ```text [Handle] is rotating to new address [0xNEW...] for [Multisig Name] ``` 2. New signer completes [Joining a Multisig](/multisig-for-protocols/joining-a-multisig) with the new address 3. Create transaction to add new address 4. After execution, create transaction to remove old address #### If Original Key is Lost 1. Signer verifies identity through alternative methods: * Video call with other signers * Authentication via verified social media * Other pre-established verification 2. Document verification in transaction notes 3. New signer completes onboarding 4. Create transaction to add new and remove old (can be batch) ### Batch Add + Remove Can combine add and remove in a single transaction: **EVM (Safe)**: 1. Use Transaction Builder or batch transaction 2. Add `addOwnerWithThreshold` call 3. Add `removeOwner` call 4. Execute as a single transaction **Benefits**: Atomic operation, no intermediate state with wrong threshold. ### Post-Transaction After execution: * [ ] Update registration or internal documentation with the new signer list * [ ] Update communication channel membership * [ ] Removed signer leaves communication channels * [ ] Test that the new signer can successfully sign a test transaction ### Offboarding Checklist When removing a signer: * [ ] Signer removed from multisig on-chain * [ ] Signer removed from communication channels * [ ] Documentation updated * [ ] Signer deleted local sensitive information * [ ] Any shared credentials rotated (if applicable) **Timeline requirements**: * Emergency-class multisigs: 48-72 hours * Critical-class: 7 days * Others: 14 days ### Related Documents * [Joining a Multisig](/multisig-for-protocols/joining-a-multisig) * [Threshold Change Runbook](/multisig-for-protocols/runbooks/threshold-change) * [Offboarding](/multisig-for-protocols/offboarding) * [Operational Runbooks](/multisig-for-protocols/runbooks/overview) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Threshold Change Runbook This is an example runbook. Review and customize it for your protocol before use. Adjust threshold requirements to match your organization's policies. ### Quick Reference | Field | Value | | ---------------------- | ----------------- | | **Typical Severity** | Routine | | **Required Threshold** | Current threshold | | **Owner** | Multisig Admin | | **Last Updated** | *Date* | ### When to Use * Increasing threshold for higher security * Decreasing threshold for operational efficiency * Adjusting after signer count changes ### Prerequisites * [ ] Justification documented * [ ] New threshold meets policy requirements: * Minimum 50% of signers * Avoid `N of N` configurations * [ ] If decreasing: approval from security contact * [ ] All signers notified of change ### Policy Requirements | Multisig Type | Minimum Threshold | | ----------------------- | -------------------------- | | Standard | 50%+ | | Treasury ($1M+) | 50%+ with 7+ signers | | Emergency | Can be lower (2/4 typical) | | Smart Contract Upgrades | Consider 7/9+ | ### EVM (Safe) Procedure #### 1. Create Transaction **Proposer**: 1. Go to [Safe](https://app.safe.global) 2. Settings > Setup > Owners 3. Click "Change threshold" 4. Select new threshold from dropdown 5. Create transaction #### 2. Verify Transaction **Each signer must**: ```text [ ] Transaction is ONLY changing threshold (no other changes) [ ] New threshold value is correct [ ] New threshold meets policy requirements [ ] No signers being added or removed in same transaction [ ] Message hash matches hardware wallet ``` **Simulation check**: * Should show `changeThreshold` call to Safe * New threshold value matches intended #### 3. Sign and Execute * [ ] Verify hash on hardware wallet * [ ] Sign immediately after verification * [ ] Message: "Signed - \[X/Y] - \[your name]" * [ ] Stay available until executed * [ ] Last signer executes once threshold is reached #### 4. Verify * [ ] Check Safe settings show new threshold * [ ] Test that the next transaction requires new threshold ### Solana (Squads) Procedure #### 1. Create Proposal 1. Go to [Squads Multisig](https://squads.xyz/squads-multisig) 2. Configuration > Change Threshold 3. Select new threshold 4. Create proposal #### 2. Verify Proposal ```text [ ] Proposal is ONLY changing threshold (no other changes) [ ] New threshold value is correct [ ] New threshold meets policy requirements [ ] No members being added or removed in the same proposal [ ] Hardware wallet display matches expected threshold change ``` #### 3. Sign and Execute * [ ] Verify proposal details on hardware wallet * [ ] Sign immediately after verification * [ ] Message: "Signed - \[X/Y] - \[your name]" * [ ] Stay available until executed * [ ] Last signer executes once threshold is reached #### 4. Verify * [ ] Check Squads settings show new threshold * [ ] Test that the next transaction requires new threshold ### Post-Change * [ ] Update registration or internal documentation with new threshold * [ ] Notify all signers of new threshold * [ ] Update any documentation referencing old threshold ### Common Scenarios #### Adding Signer + Adjusting Threshold When adding a signer, it is often appropriate to increase threshold. **Option 1**: Two transactions 1. Add signer (threshold stays same) 2. Increase threshold **Option 2**: Single batch transaction (EVM) 1. Use Transaction Builder 2. Batch `addOwnerWithThreshold` (sets new threshold automatically) #### Removing Signer + Adjusting Threshold When removing a signer, plan final signer count and threshold together: 1. If needed, reduce threshold first or in the same change window 2. Ensure the final configuration still meets policy requirements and avoids `N of N` ### Related Documents * [Planning & Classification](/multisig-for-protocols/planning-and-classification) * [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) * [Operational Runbooks](/multisig-for-protocols/runbooks/overview) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Token Transfer Runbook This is an example runbook. Review and customize it for your protocol before use. Add your specific multisig addresses, token details, and verification procedures. ### Quick Reference | Field | Value | | ---------------------- | ------------------------ | | **Typical Severity** | Routine / Time-Sensitive | | **Required Threshold** | Standard | | **Owner** | Treasury Admin | | **Last Updated** | *Date* | ### When to Use Sending tokens (ETH, ERC20, SOL, SPL tokens) from a multisig to another address. ### Prerequisites * [ ] Recipient address verified via independent source (not just chat message) * [ ] Amount confirmed * [ ] Reason for transfer documented or approved ### EVM (Safe) Procedure #### 1. Create Transaction **Proposer**: 1. Go to [Safe](https://app.safe.global) 2. Select correct Safe and network 3. Click "New Transaction" > "Send tokens" 4. Enter recipient address (use checksummed format) 5. Select token and enter amount 6. Review and create transaction #### 2. Verify Transaction **Each signer must**: ```text [ ] Correct Safe address [ ] Correct network (Ethereum/Base/etc.) [ ] Expected nonce [ ] Recipient address matches independent source [ ] Token is correct [ ] Amount is correct [ ] Simulation shows expected transfer [ ] Message hash matches hardware wallet ``` **Hash verification**: ```bash ./safe_hashes.sh --network mainnet --address [SAFE_ADDRESS] --nonce [NONCE] ``` Or use [OpenZeppelin Safe Utils](https://safe-utils.openzeppelin.com). **Simulation check**: * Click "Simulate" in Safe UI * Verify token transfer event shows correct recipient and amount * No unexpected transfers or approvals #### 3. Sign * [ ] Review transaction on hardware wallet * [ ] Verify message hash matches tool output * [ ] Sign * [ ] Communicate: "Verified and signed, X more needed" #### 4. Execute * [ ] Last signer clicks "Execute" (or designated executor) * [ ] Confirm transaction on-chain via block explorer * [ ] Communicate: "Executed - \[tx hash]" ### Solana (Squads) Procedure #### 1. Create Transaction **Proposer**: 1. Go to [Squads Multisig](https://squads.xyz/squads-multisig) 2. Select correct Squad 3. Click "Send" > Select token 4. Enter recipient address and amount 5. Create proposal #### 2. Verify Transaction **Each signer must**: ```text [ ] Correct Squad address [ ] Recipient address matches independent source [ ] Token is correct [ ] Amount is correct [ ] Simulation shows expected transfer ``` **Simulation check**: * Click "Simulate" after first signature * For SOL: Find "System Program Instruction", verify destination and amount * For tokens: Find "Token Program Instruction", verify destination, mint, and amount #### 3. Sign * [ ] Click "Approve" * [ ] Verify hash in Squads UI matches Ledger display * [ ] Sign on Ledger * [ ] Communicate: "Verified and signed, X more needed" #### 4. Execute * [ ] Last signer executes * [ ] Verify on Solana Explorer * [ ] Communicate: "Executed - \[tx signature]" ### Verification Details #### Recipient Address Always verify recipient via independent source: * Direct communication with recipient (video call or verified channel) * Published address in official documentation * On-chain verification (existing relationship) Never trust an address shared only via chat message. #### Amount Verification For ERC20 or SPL tokens, verify decimals: * USDC or USDS: 6 decimals (1,000,000 = 1 token) * Most ERC20: 18 decimals ### Common Issues | Issue | Solution | | ----------------------- | ------------------------------------------------ | | Simulation fails | Check token balance, gas estimation | | Wrong network | Reject and recreate on correct network | | Nonce mismatch | Clear pending transactions first | | Recipient can't receive | Verify address is correct type (EOA vs contract) | ### Related Documents * [Safe Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) * [Squads Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-squads-verification) * [Operational Runbooks](/multisig-for-protocols/runbooks/overview) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Guidelines for On-Chain Monitoring Effective on-chain monitoring is complex and involves setting up systems and processes to continuously observe blockchain activities and detect any anomalies. ### Key Principles * **Transparency:** Prefer open-source or auditable tools so your monitoring infrastructure can itself be reviewed. * **Real-time detection:** Minimize the time between an on-chain event and the alert reaching a responder. * **Automation:** Automate repetitive detection tasks to reduce human error and ensure consistent coverage. * **Scalability:** Design your monitoring setup to scale as protocol activity and the number of monitored contracts grows. ### Best Practices #### Define Monitoring Objectives 1. Determine the critical metrics to monitor. Common categories include: * Large fund transfers from protocol or treasury wallets * Token minting and burning events * Changes in contract ownership or admin roles * Contract upgrades and proxy implementation changes * Access control modifications (role grants, revocations) * Unusual gas usage patterns that may indicate griefing or exploitation attempts #### Implement Monitoring Tools 1. Use automated monitoring tools that can continuously track blockchain activities and generate alerts for anomalies. See the [Tools](/monitoring/tools) page for a catalog of available options. 2. Supplement automated tools with periodic manual reviews. #### Establish Alerting Mechanisms 1. Set up real-time alerts to notify relevant project members of any suspicious activities or threshold breaches. 2. Use multiple channels for alerts (Discord webhooks, Telegram bots, PagerDuty, Slack) to ensure timely delivery. 3. Every alert must have a designated owner and a documented response. An alert with no one responsible is indistinguishable from no alert at all. #### Monitoring Strategies Structure monitoring coverage across these tracks: ##### Transaction monitoring * Large fund transfers above defined thresholds * Unusual transaction frequency from key addresses * Flash loan interactions with protocol contracts ##### Contract event monitoring * Token minting and burning * Approval and transfer events outside normal patterns * Contract upgrades and ownership transfers * Admin role grants and revocations ##### Bridge monitoring * Unusual inflow or outflow volumes through bridge contracts * Bridge contract state changes or ownership modifications ##### Oracle and governance monitoring * Price feed deviations beyond expected bounds * Unexpected governance proposals or accelerated vote execution ##### Node and network monitoring * Block propagation times and node health * Network latency affecting transaction confirmation * RPC endpoint availability #### Regular Reviews and Updates 1. Conduct regular reviews of your monitoring systems to ensure they are functioning correctly and covering all necessary metrics. 2. Regularly update thresholds and alert configurations to reflect your current needs. 3. **Test your alerts periodically**: verify that alert delivery actually works end-to-end, not just that the detection rule is configured. A misconfigured webhook or expired token can silently break your alerting. 4. **Alert on alert tampering**: configure alerts for the disabling or modification of existing alerts. This protects against both accidental misconfiguration and adversarial tampering that could silently disable your detection coverage. #### Incident Response 1. Develop and maintain an [incident response plan](/incident-management/overview) to handle alerts and anomalies as soon as possible. 2. Document who gets paged for each alert category and what the first response steps are. This should be decided before an incident, not during one. #### Forensic readiness Monitoring detects anomalies. Forensic readiness ensures you can reconstruct and prove what happened with defensible evidence. These are complementary capabilities: monitoring without forensic readiness means you can notice an incident but may struggle to investigate, substantiate, or disclose it reliably. See [Forensic Readiness](/incident-management/forensic-readiness) for how to design evidence collection into your architecture. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Monitoring > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Monitoring](/monitoring/overview) * [On-Chain Monitoring Guidelines](/monitoring/guidelines) * [On-Chain Monitoring Tools](/monitoring/tools) * [Monitoring Alert Thresholds](/monitoring/thresholds) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Monitoring Monitoring is a crucial aspect of maintaining the security and integrity of a blockchain project. Effective monitoring allows you to detect anomalies and potential security breaches in real-time, enabling prompt response and mitigation. This section focuses on monitoring the on-chain security of a project, including guidelines for setting up monitoring systems, defining thresholds for alerts, and utilizing existing on-chain monitoring tools. ### First Principles Before deploying any monitoring tool, establish the fundamentals that make monitoring effective. #### Know what you're monitoring and why Define which on-chain events are meaningful to your project and what response each alert should trigger. A monitoring setup without defined responses is noise: it consumes attention without producing safety. For every alert you configure, answer: *who receives this, and what do they do when it fires?* #### Act on your alerts Organizations fail to monitor in two ways: not logging at all or logging without acting. Both leave you blind. Every alert must map to a concrete, documented response. For smart contract protocols, this typically means having a pause mechanism or circuit breaker and, in higher-maturity setups, possibly a carefully designed automated system that can trigger when a critical alert fires, but only where the trigger conditions and failure modes have been explicitly reviewed. Without this, monitoring only tells you what happened, not what you could have prevented. #### Monitor with redundancy *(higher maturity)* No monitoring provider has perfect uptime or perfect detection. For critical systems, run two independent providers monitoring the same invariants in parallel (one self-hosted, one managed). If one has downtime or misses an event, the other still provides coverage. See the [Tools](/monitoring/tools) page for guidance on combining self-hosted and managed options. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Defining Thresholds for On-Chain Monitoring Setting appropriate thresholds for on-chain monitoring is hard when taking into account you want to detect unusual activities, without generating excessive false positives. Here are some guidelines for defining and configuring thresholds. For guidance on what to monitor and how to set up alerting, see the [Guidelines](/monitoring/guidelines) page. ### Generic Guidelines #### Understand Normal Activity Patterns 1. Establish baseline metrics for normal activities, such as average transaction volumes and typical token minting rates (if any). 2. Use historical data to understand activity patterns and identify deviations from the norm. #### Set Thresholds for Alerts 1. Define thresholds for large fund transfers from project wallets, considering both absolute amounts and relative percentages. 2. Set thresholds for token minting events, including the number of tokens minted and the frequency of minting. 3. Establish thresholds for changes in contract ownership or significant modifications to contract code. #### Adjust Thresholds Over Time 1. Implement adaptive thresholds that can adjust based on changing activity patterns and emerging threats. 2. Periodically review and update thresholds to ensure they remain relevant and effective. #### Multi-Layered Thresholds 1. Use primary thresholds for critical alerts and secondary thresholds for less urgent notifications. 2. Define thresholds based on a combination of metrics to reduce false positives and improve accuracy. #### Anomaly Detection It is hard, if not impossible, to predict every type of alert one should set up for their project. As such, implementing an anomaly detection system can be of great value as it will monitor the project and its transactions in real time, and compare it to its previous behavior. If for example it is common that 4% of tokens change owner each day and there's a day with 20% of tokens changing owner in the past 10 minutes, then that could be detected as an anomaly and a cause for investigation. Several of the tools in the [Tools](/monitoring/tools) catalog offer built-in anomaly detection. Hypernative uses ML-based behavioral modeling, and Tenderly supports custom alert rules that can approximate anomaly thresholds. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## On-Chain Monitoring Tools > The tools below are primarily focused on EVM-compatible chains. For non-EVM chains (Solana, Cosmos, etc.), verify > chain support before selecting a tool. For critical systems, consider running monitors from two independent providers > simultaneously. See the [Reliability Considerations](#reliability-considerations) section below. ### Open Source / Self-Hosted #### BlockScout Open-source blockchain explorer with monitoring capabilities. Track transactions, contract events, and token transfers with custom alerts for your contracts and addresses. Can be self-hosted for free (MIT license) or deployed via BlockScout's managed options: Autoscout (self-service managed hosting, $250-950/month depending on transaction volume) or Explorer as a Service (EaaS, enterprise pricing). A PRO API is also available with a free tier (100K credits/day, 5 req/s) and paid plans from $49/month. * **Chains:** Multiple EVM networks * **GitHub:** [blockscout/blockscout](https://github.com/blockscout/blockscout) * **Website:** [blockscout.com](https://www.blockscout.com) #### Prometheus + Grafana Infrastructure-level metrics collection (Prometheus) and visualization/alerting (Grafana). Useful for monitoring blockchain node health, block propagation times, RPC endpoint availability, and custom on-chain metrics exported via a scraper. * **Chains:** Chain-agnostic (infrastructure layer) * **GitHub:** [prometheus/prometheus](https://github.com/prometheus/prometheus) | [grafana/grafana](https://github.com/grafana/grafana) ### Commercial / Hosted #### Etherscan Address monitoring via Watch List, free for registered users. Monitor up to 50 Ethereum addresses and receive email notifications on inbound and outbound transactions. Configurable per address via the account dashboard. The API supports polling-based monitoring (3 req/s, 100K calls/day on the free tier) but has no push or streaming endpoints; custom polling layers are required for automated alerting. * **Free plan:** Watch List available with a free account; API free tier for personal use * **Chains:** Ethereum (and Etherscan-family explorers for other EVM chains) * **Website:** [etherscan.io](https://etherscan.io) * **Documentation:** [docs.etherscan.io](https://docs.etherscan.io) #### Guardrail Real-time DeFi security monitoring and automated threat response. Deploys customizable Guards (rule sets that inspect every on-chain transaction per block, per function, or per event) and can trigger automated protective responses such as contract pauses, wallet flagging, and on-call escalation. Covers DeFi protocols, DApps, oracle networks, DAO governance, and multisig operations. * **Chains:** 30+ (Ethereum, Arbitrum, Optimism, Base, Polygon, zkSync, Scroll, and others) * **Website:** [guardrail.ai](https://www.guardrail.ai) #### Hexagate Chainalysis's real-time on-chain threat detection and automated prevention platform. Uses ML-driven anomaly detection and GateSigner (pre-signing transaction simulation) to catch exploits before they land on-chain. Supports custom detection rules via Gatelang. Free access available for protocols building on partner chains (Base, Avalanche, Polygon, Cronos, Immutable, and others) through chain-specific application programs. * **Free plan:** Available for protocols on partner chains; check with your chain's foundation * **Chains:** 75+ blockchains * **Website:** [chainalysis.com/product/hexagate](https://www.chainalysis.com/product/hexagate/) #### Hypernative Machine learning-based anomaly detection and pre-crime threat detection for DeFi protocols. Detects novel attack patterns by modeling protocol behavior rather than relying solely on known signatures. * **Chains:** 70+ blockchains * **Website:** [hypernative.io](https://hypernative.io) #### Tenderly Real-time smart contract monitoring platform with a free tier. Supports 12 alert trigger types (function calls, event emissions, balance changes, state variable changes, and transaction value thresholds) with delivery to 8 destinations: Slack, Discord, Telegram, email, webhooks, PagerDuty, Sentry, and Web3 Actions (TypeScript serverless functions that run on Tenderly's infrastructure). The CLI and SDKs are open-source (GPL-3.0). * **Free plan:** Available; exact monitoring quotas visible on the pricing page * **Chains:** 100+ networks * **Website:** [tenderly.co](https://tenderly.co) * **GitHub:** [Tenderly](https://github.com/Tenderly) (CLI, SDKs, framework plugins) #### TxScope Pre-signing transaction threat scanner for Solana multisigs. Monitors Squads Protocol vaults for pending proposals, simulates each transaction against mainnet via Helius RPC, and generates plain-language threat reports before any signer approves. Detection modules cover durable nonces, authority and admin transfers, withdrawal guard manipulation, known attack pattern matching, instruction-level trace and decode, proposer history and anomaly detection, and risk scoring (0–100). Free for on-demand scans; paid tiers for continuous monitoring with Telegram and Slack alerts. * **Chains:** Solana * **Website:** [txscope.com](https://txscope.com) ### Reliability Considerations Your monitoring system is only effective if it is itself reliable. Before committing to a tooling setup, evaluate these factors: #### Self-hosted vs. managed | | Self-Hosted | Managed Platform | | ---------------------- | ----------------------------------------- | ----------------------------------------- | | **Control** | Full control over configuration and data | Vendor controls infrastructure | | **Operational burden** | You own uptime, upgrades, and maintenance | Vendor handles ops | | **Vendor risk** | None | Platform downtime or shutdown affects you | | **Cost** | Infrastructure cost + engineering time | Subscription fee | #### Key reliability metrics to evaluate * **Uptime SLA:** What guaranteed availability does the provider offer? Is there a status page? * **Time-to-alert:** How quickly after an on-chain event does a notification reach you? Minutes matter during an exploit. * **Alert delivery guarantees:** Does the platform guarantee at-least-once delivery, or is it best-effort? #### Redundancy recommendation For any protocol holding significant value, do not rely on a single monitoring provider. Run at least two independent monitoring setups (ideally one self-hosted and one managed) covering the same critical invariants. If the managed platform has downtime or misses an anomaly, the self-hosted layer still provides coverage, and vice versa. #### Alert channel reliability Your monitoring is only as good as the delivery mechanism for its alerts. * **Prefer:** PagerDuty or OpsGenie (escalation policies, on-call rotations, delivery receipts) * **Use with care:** Slack, Discord, Telegram (useful for visibility, but easy to miss; no delivery guarantees) * **Don’t rely on email as the sole channel for critical alerts**: Email may be appropriate as a secondary or audit channel, not primary paging (high latency, often filtered to spam) For high-severity alerts, use a dedicated paging tool with escalation so that if the primary on-call misses the alert, it automatically escalates to a secondary. *** import { AttackSurfaceDashboard } from '../../../components' import { TagList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Attack Surface Overview See where your protocol is most exposed. Click the checkbox on each vector to track your security posture. Your progress is saved locally in your browser. *** import { ContributeFooter, TagFilter, TagProvider } from '../../../components' ## How to Navigate the Website Navigating the Security Frameworks by SEAL will be designed, in time, to be intuitive and user-friendly. We currently allow users to filter content by role, but we're not quite there yet. For a visual entry point, try the [Attack Surface Overview](/intro/attack-surface)—it surfaces common threats as a clickable map, with links into the relevant frameworks for each one. Any feedback on how to improve the usage of frameworks in the future is appreciated. ### Categories The content is organized into different categories, each focusing on a specific aspect of security. Currently, we are in the Introduction section, but you can explore the broader category of "Frameworks" below. Each framework is categorized to help you find relevant information quickly. ### Filtering by Profile This is being implemented, and we're looking for volunteers and collaborators for this specific task. The main objective is to allow users to filter the content by profile to focus on information relevant to their role within the organization. This feature allows them to bypass unnecessary reading and concentrate on what matters most. Example roles: * Developer * Executive * Security * Finance * Crypto * Management * Community * Non-Technical This targeted approach will ensure you get the most relevant information efficiently. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Intro > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Introduction to SEAL Frameworks](/intro/introduction) * [How to Navigate the Website](/intro/how-to-navigate-the-website) * [Overview Of Each Framework](/intro/overview-of-each-framework) * [Attack Surface Overview](/intro/attack-surface) * [What It Is](/intro/what-is-it) * [What It Isn't](/intro/what-it-isnt) * [LLMs | Security Alliance Frameworks](/intro/llms) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, BenchmarkList } from '../../../components' ## Introduction to Frameworks Welcome to the Security Frameworks by Security Alliance (SEAL), a curated resource for those seeking knowledge in the realm of blockchain security. Our organization, a collective of dedicated security specialists, is on a mission to spread awareness and educate the community about best practices and potential pitfalls in Web3 security. ### Why We Created This Resource We have noticed a growing need to address the various challenges and issues facing our field, some of which include security threats not specifically aimed at Web3 infrastructure. Recognizing that information is abundant but not always easily accessible, we've compiled and organized existing resources from around the internet and generated new content specifically with this purpose in mind. ### Who Can Benefit Regardless of your background—whether in Web2, Web3, or beyond—these guidelines are open to all who seek to learn and contribute. We aim to establish a comprehensive, high-level security framework for Web3 projects, providing best practices to development teams throughout the lifecycle of their projects. Consider this a one-stop shop for everything related to Web3 security. ### How to Contribute Read our [Contribution Guide](/contribute/contributing) to learn how you can contribute to this project. ### License Security Frameworks © 2023 by Security Alliance, licensed under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/). ### Who We Are SEAL is a not-for-profit organization committed to enhancing security awareness, education, and specialized work as a public good for the Web3 ecosystem, its supporting technologies, and communities. Our efforts are driven by a shared desire to foster a safer, more informed digital landscape. We do this by designing innovative projects, engaging elite technologists, and coordinating on the social layer to ensure meaningful adoption. :::info[AI-friendly documentation] All framework content is available in LLM-friendly format following the [llms.txt](https://llmstxt.org/) standard - one file per framework, plus a routing index. See the [LLMs page](/intro/llms) for the full list. ::: *** ## LLMs The Security Alliance Frameworks documentation is available in LLM-friendly format following the [llms.txt](https://llmstxt.org/) standard. These files are generated at build time and designed to be fetched by AI assistants and coding tools to provide accurate, up-to-date framework content as context. ### How to use AI assistants should start with [`/llms.txt`](https://frameworks.securityalliance.org/llms.txt), the routing index. It lists every framework with a description and topic summary, so the AI can identify the best match and fetch the framework index file. From there, per-page files can be fetched for detailed content on a specific topic. ### File structure Three file types are available: ``` /llms.txt routing index —> lists all framework index files /llms/{framework-name}.txt framework index —> overview + links to per-page files /llms/{framework-name}/{page}.txt per-page file —> full content of a single page ``` The `{framework-name}` maps to the framework's folder name in the repository and `{page}` to the page's slug. For example, the Wallet Security seed phrase page lives at `docs/pages/wallet-security/seed-phrase-management.mdx` and its per-page file is at `/llms/wallet-security/seed-phrase-management.txt`. ### What each file contains **`/llms.txt`** - routing index: * One entry per framework with its index file URL, description, and topic list **`/llms/{framework-name}.txt`** - framework index: * Header, description, and AI instructions * Full content of the overview page for immediate context * Links to all per-page files with one-line descriptions **`/llms/{framework-name}/{page}.txt`** - per-page file: * Full markdown content of that page * Source URL and framework attribution New frameworks and pages are picked up automatically on the next build. ### For agents using a retrieval policy Agents that load skill or policy files can find a retrieval policy at [SKILL.md](https://github.com/security-alliance/frameworks/blob/develop/SKILL.md) in the repository root. It defines branch policy (`main` vs `develop`), behavior with retrieved content, and what to do when retrieval returns nothing relevant. It complements the inline instructions inside `/llms.txt`. import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, DevOnly } from '../../../components' ## Overview of Each Framework > **Important Disclaimer**: The frameworks presented in this documentation are living documents that evolve with the > Web3 security landscape. They may undergo restructuring, updates, or modifications in the future to reflect emerging > threats, new best practices, and community feedback. We recommend regularly checking for updates to ensure you're > working with the most current security guidelines. This document provides an overview of the various frameworks covered in the Security Frameworks by SEAL. Each framework addresses a specific aspect of Web3 security, providing best practices and guidelines to help secure your projects. ### AI Security This framework covers emerging AI-native security risks and controls, including prompt injection defenses, runtime execution-path enforcement, and sandboxing strategies for agentic systems. [Explore the AI Security framework →](/ai-security/overview) ### Awareness This section covers strategies for fostering security awareness among team members and users of Web3 projects, including understanding threat vectors, cultivating a security-aware mindset, and staying informed about security developments. [Read more about the Awareness framework →](/awareness/overview) ### Community Management This framework explores best practices for securing and managing online communities associated with Web3 projects, covering platforms like Discord, Twitter, Telegram, and Google. It focuses on establishing secure communication channels and community guidelines. [Go to the Community Management framework →](/community-management/overview) ### DevSecOps This framework focuses on integrating security practices into the development and operations processes, covering code signing, CI/CD, IDE security, repository hardening, and security testing. [Explore the DevSecOps framework →](/devsecops/overview) ### Insider Threats (DPRK IT Workers) This framework addresses the organizational and personal risks related to insider threats, most commonly associated with North Korean hacker-freelancers. It covers identifying, recognizing, and mitigating risks from insider threat actors, including hardening hiring processes and organizational defenses. [Go to the DPRK IT Workers framework →](/dprk-it-workers/overview) ### Encryption This comprehensive section covers various encryption methods and their applications in protecting data, including cloud data encryption, communication encryption, database encryption, and various types of storage encryption. [Explore the Encryption framework →](/encryption/overview) ### ENS This section covers Ethereum Name Service security considerations, including data integrity, cross-chain compatibility, smart contract integration, interface compliance, and name handling. [Go to the ENS framework →](/ens/overview) ### External Security Reviews This framework provides guidance on conducting and preparing for external security audits and reviews, including setting expectations, preparation, security policies, and vendor selection. [Explore the External Security Reviews framework →](/external-security-reviews/overview) ### Front-End/Web Application This section addresses security considerations specific to the user-facing components of Web3 projects, including both web and mobile application security, common vulnerabilities, and security tools. [Go to the Front-End/Web Application framework →](/front-end-web-app/overview) ### Governance This section covers best practices for implementing governance in Web3 projects, including setting clear policies, establishing accountability, compliance with regulatory requirements, risk management, and security metrics and KPIs. [Read more about the Governance framework →](/governance/overview) ### Identity and Access Management (IAM) This framework covers best practices for managing user identities and access control in Web3 projects, including role-based access control and secure authentication. [Go to the IAM framework →](/iam/overview) ### Incident Management This section outlines protocols for handling security incidents, including communication strategies, detection and response procedures, lessons learned, and playbooks, including specific guidelines for SEAL 911 War Room. [Read more about the Incident Management framework →](/incident-management/overview) ### Infrastructure This section covers the fundamental aspects of securing the underlying infrastructure of Web3 projects, including asset inventory, cloud infrastructure, DDoS protection, DNS security, IAM, network security, and zero-trust principles. [Read more about the Infrastructure framework →](/infrastructure/overview) ### Monitoring This framework discusses the importance of continuous monitoring in Web3 projects, focusing on setting up effective monitoring systems and defining appropriate thresholds for alerts. [Explore the Monitoring framework →](/monitoring/overview) ### Multisig for Protocols This comprehensive framework provides security guidelines for managing multisig wallets in protocols, covering planning and classification, setup and configuration, signer onboarding, hardware wallet setup, transaction verification, emergency procedures, and incident reporting. [Read more about the Multisig for Protocols framework →](/multisig-for-protocols/overview) ### Operational Security (OpSec) This comprehensive framework addresses day-to-day security practices for Web3 teams, covering fundamentals, governance, risk management, control domains, lifecycle management, monitoring, incident response, and continuous improvement. [Explore the OpSec framework →](/opsec/overview) ### Privacy This section explores tools and practices for maintaining privacy in the Web3 ecosystem, including secure browsing, data removal, digital footprint management, encrypted communication, and privacy-focused operating systems. [Go to the Privacy framework →](/privacy/overview) ### Safe Harbor This framework provides guidance on establishing safe harbor protocols for security researchers, including key terms, protocols, technical outlines, and whitehat guidelines. [Read more about the Safe Harbor framework →](/safe-harbor/overview) ### Secure Software Development This section focuses on integrating security practices throughout the software development lifecycle, including secure coding standards, code reviews, and secure design principles. [Read more about the Secure Software Development framework →](/secure-software-development/overview) ### Security Automation This framework focuses on using technology to perform security tasks with minimal human intervention, covering compliance checks, infrastructure as code, and threat detection and response to improve efficiency and reduce human error. [Explore the Security Automation framework →](/security-automation/overview) ### Security Testing This framework explores various methods of testing Web3 projects for security vulnerabilities, including dynamic and static application security testing, fuzz testing, and security regression testing. [Explore the Security Testing framework →](/security-testing/overview) ### Supply Chain This framework addresses the security implications of dependencies and third-party components in Web3 projects, including dependency awareness and supply chain levels for software artifacts. [Read more about the Supply Chain framework →](/supply-chain/overview) ### Threat Modeling This framework provides guidance on creating and maintaining threat models, as well as identifying and mitigating potential threats to Web3 projects. [Explore the Threat Modeling framework →](/threat-modeling/overview) ### Treasury Operations This section provides institutional-grade security frameworks for managing custodial treasury accounts and large cryptocurrency transfers, including account classification, registration documentation, enhanced controls, and transaction verification protocols. [Go to the Treasury Operations framework →](/treasury-operations/overview) ### Vulnerability Disclosure This section discusses best practices for handling and disclosing vulnerabilities in Web3 projects, including establishing security contacts and managing bug bounty programs. [Go to the Vulnerability Disclosure framework →](/vulnerability-disclosure/overview) ### Wallet Security This section delves into the crucial aspect of managing cryptographic keys in Web3 projects, discussing various wallet types (cold vs hot, custodial vs non-custodial), hardware wallets, signing schemes, and software wallets. [Go to the Wallet Security framework →](/wallet-security/overview) ### SEAL Certifications This framework provides a certification system developed by SEAL with standardized guidelines and evaluation criteria for assessing the security of DeFi protocols. It includes modular certifications for specific areas such as DevOps & Infrastructure, DNS Security, Identity & Accounts, Incident Response, Multisig Ops, and Treasury Ops. [Read more about SEAL Certifications →](/certs/overview) *** import { ContributeFooter, TagFilter, TagProvider } from '../../../components' ## What Is It This resource is a collection of best practices written in an abstract or general fashion to be applicable regardless of the specific technology. It serves as a comprehensive guide to help you secure various aspects of your Web3 projects and build resilience against potential threats. This guide aims to centralize existing information, so you might not see novel features but rather a well-organized compilation of security-related topics, from simpler ones to more complex ones. The goal is to provide a comprehensive resource that brings together diverse security insights and practices into one accessible place. Our hope is that these resources will help expand your security skill set. *** import { ContributeFooter, TagFilter, TagProvider } from '../../../components' ## What It Isn't This resource isn't just a compilation of existing information. While it may initially seem like a collection of curated content, its primary focus is on providing in-depth, practical guidance. Unlike other curations, compilations, or blog posts that often focus on the latest technologies, this guide delves into underlying concepts and technical aspects essential for securing Web3 projects. It’s not meant to be read like a "story" but rather used as a reference to enhance your understanding and application of security practices. The content may not always follow the latest state-of-the-art technologies, as its focus is on fundamental security principles that are broadly applicable. Our aim is to provide valuable insights and practical advice to help you secure your projects effectively. This guide is not intended to be offensive, though it might include strong examples to illustrate particular points. Our goal is to ensure clarity and effectiveness in conveying security best practices. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Asset Inventory An asset inventory means having information about everything related to your project, meaning for example contracts, hardware, software, cloud providers, dependencies and network components. This is important, as if you don't have awareness of your assets then how are you going to be able to protect them? You should at the very least document as much as you can with regards to your assets, and update this on a regular basis. It is highly recommended to also assign ownership of each asset, so that someone ensures the safety of this asset. Classifying them based on their criticality and sensitivity also helps you prioritize them with regards to security measures. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Cloud Infrastructure Securing your cloud infrastructure could be considered as important as securing your decentralized application, as a lot of users will be interacting with your dapp through the cloud provider. Some best practices to consider are: 1. Implement strict access controls and identity management to ensure that only authorized individuals can interact with cloud resources. Use role-based access control (RBAC) and multi-factor authentication (MFA). 2. Encrypt data both in transit and at rest. Use managed encryption keys or bring your own keys (BYOK) for enhanced security. 3. Configure virtual private clouds (VPCs), implement firewalls, and monitor network traffic to protect against unauthorized access and threats. 4. Set up comprehensive logging, monitoring, and threat detection systems to identify and respond to security incidents in real-time. Use services like AWS CloudTrail, Azure Monitor, and Google Cloud Logging. 5. Implement high availability, data backup, and disaster recovery plans to protect against service disruptions. Use automated fail-over and replication strategies. 6. Ensure compliance with regulatory requirements (e.g., GDPR, MiCA). ### Cloud Provider Hardening Guides All cloud providers have hardening guides that provide step-by-step instructions and best practices for securing cloud infrastructure: * **AWS**: [Security, Identity, and Compliance](https://aws.amazon.com/architecture/security-identity-compliance/) * **Azure**: [Best Practices and Patterns](https://learn.microsoft.com/en-us/azure/security/fundamentals/best-practices-and-patterns) * **GCP**: [Security Best Practices](https://cloud.google.com/security/best-practices) ### Open Source Tools To aid with vulnerability detection and compliance, you could consider using the following open-source tools: * **CloudSploit**: [CloudSploit](https://github.com/aquasecurity/cloudsploit) * **Prowler**: [Prowler](https://github.com/prowler-cloud/prowler) * **S3Scanner (AWS)**: [S3Scanner](https://github.com/sa7mon/S3Scanner) * **Zeus (AWS)**: [Zeus](https://github.com/DenizParlak/Zeus) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## DDoS Protection Distributed Denial of Service (DDoS) attacks are a pervasive threat that can disrupt your services by overwhelming them with excessive traffic. ### Best Practices * **Use Cloud Provider Solutions**: Utilize DDoS protection services offered by your cloud provider: #### AWS * **AWS Shield Standard and Advanced**: * *Shield Standard*: Basic DDoS protection at no extra cost. * *Shield Advanced*: Enhanced protection with real-time visibility and access to AWS DDoS Response Team (DRT). * **Amazon CloudFront and AWS WAF**: * *CloudFront*: Distributes traffic globally to mitigate DDoS attacks. * *AWS WAF*: Protects against application layer attacks. #### Azure * **Azure DDoS Protection Basic and Standard**: * *DDoS Protection Basic*: Automatic protection against common attacks. * *DDoS Protection Standard*: Advanced protection with real-time monitoring. * **Azure Front Door and Azure Application Gateway with WAF**: * *Front Door*: Global application delivery with DDoS mitigation. * *Application Gateway with WAF*: Protects against various attacks. #### GCP * **Google Cloud Armor**: Provides DDoS protection and WAF capabilities. * **Load Balancing**: Distributes traffic to mitigate DDoS attacks. * **VPC Flow Logs and Stackdriver Logging**: Monitors and logs traffic patterns for effective response. ### External DDoS Protection Providers In addition to cloud provider solutions, consider external DDoS protection services: * **Cloudflare**: Offers comprehensive DDoS protection and mitigation services. * **Akamai**: Provides scalable DDoS protection solutions. * **Imperva**: Specializes in DDoS protection and mitigation. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Identity and Access Management Right now, this subsection has an entire category of its own. Please refer to [Incident and Access Management (IAM)](/iam/access-management) *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Infrastructure > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Infrastructure](/infrastructure/overview) * [Asset Inventory](/infrastructure/asset-inventory) * [Cloud Infrastructure](/infrastructure/cloud) * [DDoS Protection](/infrastructure/ddos-protection) * [Identity And Access Management](/infrastructure/identity-and-access-management) * [Network Security](/infrastructure/network-security) * [Operating System Security](/infrastructure/operating-system-security) * [Zero Trust Principles](/infrastructure/zero-trust-principles) * [Domain And Dns Security](/infrastructure/domain-and-dns-security) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Network Security > 🔑 **Key Takeaway**: Default-deny ingress, segment everything, encrypt in transit, > log and audit continuously. Network security is not a single tool but a layered posture — > each layer assumes the one below it may fail. Network security spans every boundary where your infrastructure touches the internet or other untrusted networks. In Web3, the stakes are higher than typical SaaS: a compromised frontend or RPC endpoint can drain user wallets in minutes, and blockchain transactions cannot be reversed. Your network is the first perimeter after your code. The steps you take depend on whether you manage your own network, use a cloud provider, or rely on a managed service. The guidance below applies to all three, with cloud-specific notes where relevant. ### Practical guidance #### 1. Default-deny ingress Block all incoming traffic by default. Open only the ports and source IPs you need, and document why each rule exists. * SSH, RDP, and database ports must never be open to `0.0.0.0/0`. Use bastion hosts or VPN-only access. * Cloud environments: use security groups (AWS), NSGs (Azure), or VPC firewall rules (GCP) with explicit allow-lists. Remove default "allow all" rules. * Review firewall rules quarterly. Stale rules accumulate and widen your attack surface silently. #### 2. Segment your network Divide your network into zones so a compromise in one zone does not grant access to everything. * At minimum, separate: public-facing (frontends, APIs), internal services (RPC nodes, indexers), and management (SSH, CI/CD, monitoring). * Use VLANs or VPC subnets with strict routing between them. Traffic crossing zone boundaries must go through a firewall or proxy. * Cloud: place each tier in its own subnet. Use VPC peering or PrivateLink for cross-subnet communication — never route through the public internet. * See also: [Zero-Trust Principles](/infrastructure/zero-trust-principles) for micro-segmentation within zones. #### 3. Firewalls and IDS/IPS * **Firewalls**: enforce the default-deny and segmentation rules above. Use both network-layer (packet filtering) and application-layer (WAF) firewalls. * **IDS/IPS**: deploy intrusion detection and prevention systems to identify and block suspicious traffic patterns. Cloud providers offer managed IDS (AWS GuardDuty, Azure Sentinel, GCP Security Command Center). * For Web3 frontends, a WAF is essential — it filters malicious requests before they reach your application. See [DDoS Protection](/infrastructure/ddos-protection) for WAF-as-DDoS-mitigation patterns. #### 4. VPNs for remote access Use VPNs to provide secure remote access to internal services. This is an infrastructure concern (who can reach the management plane), distinct from the privacy use of VPNs by individuals. * **Infrastructure VPN**: WireGuard, OpenVPN, or cloud-native VPN gateways for team access to internal dashboards, SSH, and databases. * **Privacy VPN**: for individual privacy (hiding metadata from local networks, public Wi-Fi protection), see [VPN Services](/privacy/vpns/overview). * Enforce VPN-only access for management interfaces. Disable direct internet access to admin panels and SSH. #### 5. Encrypt data in transit * Enforce TLS 1.2+ on all external endpoints. Use HSTS headers to prevent downgrade attacks. * Internal services: use mTLS (mutual TLS) between microservices, or IPsec/WireGuard for network-level encryption between data centers. * DNS queries leak browsing metadata. Configure DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) for outbound resolution. See [DNS and Domain Registration](/infrastructure/domain-and-dns-security/overview) for DNS security guidance. #### 6. Access control lists (ACLs) * Define which systems and users can reach which network resources. Apply the principle of least privilege at the network layer. * Cloud: use IAM policies tied to security groups, not just broad network rules. * Document ACLs and review them alongside firewall rules. Undocumented ACLs are a common source of silent outages and security gaps. #### 7. Audits and monitoring * Conduct network security audits at least quarterly. Automated tools (Prowler, CloudSploit) can run continuously — see [Cloud Infrastructure](/infrastructure/cloud) for tool references. * Centralize flow logs (VPC Flow Logs, NetFlow) and alert on anomalies: unusual outbound traffic volumes, connections to unexpected regions, or port scans. * Keep network devices and software patched. Subscribe to vendor security advisories for firmware updates. ### Why is it important Network-level failures have caused real Web3 incidents: * **Curve Finance (2022, 2025)**: DNS hijacking redirected users to a malicious frontend, draining wallets. Proper DNS monitoring and registrar locks could have prevented this. See [Domain & DNS Security](/infrastructure/domain-and-dns-security/overview). * **Galxe (2023)**: DNS hijack drained over 1,100 wallets for $270k. The attack exploited a lack of DNS change monitoring. * **eth.limo (2026)**: EasyDNS suffered a [DNS hijack](https://crypto.news/easydns-admits-to-security-failure-following-eth-limo-domain-hijack/). A failure within its own systems allowed a social engineering attacker to briefly seize control of eth.limo, a primary gateway for the Ethereum Name Service. * **General DDoS**: Web3 frontends are high-value targets for extortion DDoS. Without protection, a single volumetric attack can take your dApp offline for hours. See [DDoS Protection](/infrastructure/ddos-protection). The common thread: these incidents exploited network-layer weaknesses (DNS, DDoS, open management ports), not smart contract bugs. ### Implementation details | Sub-Topic | Related Page | | --------------------------------------------- | ------------------------------------------------------------------------- | | DDoS Protection | [DDoS Protection](/infrastructure/ddos-protection) | | DNS and Domain Security | [Domain & DNS Security](/infrastructure/domain-and-dns-security/overview) | | Cloud Network Hardening | [Cloud Infrastructure](/infrastructure/cloud) | | Zero-Trust and Micro-Segmentation | [Zero-Trust Principles](/infrastructure/zero-trust-principles) | | VPNs for Individual Privacy | [VPN Services](/privacy/vpns/overview) | | Asset Inventory (know what's on your network) | [Asset Inventory](/infrastructure/asset-inventory) | ### Common pitfalls & examples 1. **Over-trusting cloud defaults** — AWS security groups default to "no inbound rules," but many teams add `0.0.0.0/0` on port 22 or 443 out of convenience and never tighten them. Audit with `aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values='0.0.0.0/0'`. 2. **Flat networks** — Putting frontend, API, database, and SSH in the same subnet means a single vulnerability gives lateral access to everything. Segment first, connect second. 3. **Ignoring DNS** — DNS hijacking is the most common Web3 frontend attack vector, yet many teams treat DNS as an afterthought. Enable DNSSEC, registry locks, and change monitoring. See [Domain & DNS Security](/infrastructure/domain-and-dns-security/overview). 4. **No VPN for management** — Exposing admin panels or SSH to the internet, even on non-standard ports, is discovered by scanners within minutes. Require VPN or bastion host access. 5. **Stale firewall rules** — A rule opened "temporarily" six months ago is still there, and nobody remembers why. Tag rules with tickets and expiration dates. Review quarterly. ### Quick-reference / Cheat sheet | Action | Minimum | Recommended | | -------------------- | ------------------------------ | ------------------------------------------------------ | | Inbound default | Deny all | Deny all + explicit allow-list with tickets | | SSH/RDP access | Non-standard port | VPN or bastion only, key-based auth | | Network segmentation | Public / internal | Public / internal / management + mTLS between services | | IDS/IPS | Cloud-native (GuardDuty, etc.) | Cloud-native + custom rules for Web3 patterns | | DNS | DNSSEC + registrar lock | DNSSEC + registry lock + change monitoring + DoH/DoT | | TLS | 1.2 on external endpoints | 1.3 + HSTS + mTLS internally | | Flow logging | Enabled | Centralized + alerts on anomalies | | Audit cadence | Quarterly | Continuous automated + quarterly manual review | ### Further Reading & Tools * [NIST SP 800-41 Rev. 1](https://csrc.nist.gov/publications/detail/sp/800-41/rev-1/final) — Guidelines for Firewalls and Firewall Policy * [CIS Controls v8](https://www.cisecurity.org/controls) — Control 12 (Network Infrastructure Management) * [Prowler](https://github.com/prowler-cloud/prowler) — AWS/Azure/GCP security posture tool * [CloudSploit](https://github.com/aquasecurity/cloudsploit) — Cloud security configuration scanner * [WireGuard](https://www.wireguard.com/) — Modern, minimal VPN for infrastructure access * [The Red Guild: Are VPNs Really Necessary?](https://blog.theredguild.org/are-vpns-really-necessary-is-https-enough/) — Privacy-focused VPN guidance *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Operating System Security This document outlines some general best practices one should follow with regards to operating system security, however if you're interested in a much more comprehensive guide you could look at [NIST 800-123](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf). ### Best Practices 1. Keep your operating systems updated with the latest security patches and updates. 2. Block the remote shell port from all but required IPs. 3. Block all ports except absolutely required ones from public. 4. Use tools such as fail2ban to protect against attacks. 5. Enforce personal account and SSH key login 6. Enable multi factor authentication. 7. Implement strict access controls to limit administrative privileges and use role-based access control (RBAC). 8. Use antivirus and anti-malware software to detect and prevent malicious activities on systems where relevant 9. Configure host-based firewalls to control incoming and outgoing network traffic. 10. Implement host-based intrusion detection and prevention systems (HIDS/HIPS). 11. Follow secure configuration guides, such as the NIST 800-123 guidelines, to harden your operating systems. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Infrastructure Infrastructure can often be overlooked in web3, but it's often a very important area given that most front-end web applications are running on centralized infrastructure. This section focuses on Infrastructure Security, encompassing critical aspects such as cloud infrastructure, DNS providers, domain registrars, and DDoS (Distributed Denial of Service) protection. When designing your architecture, it may be worth considering how many different providers you rely on. Are you going to use different providers for infrastructure, DDoS protection, domain registration, and DNS, or will you choose a provider that provides all of these? On one hand, putting all your eggs in one basket means a failure of that service would cause downtime. On the other hand, using a single service and ensuring it follows all best practices with regard to security measures means a lower risk surface. ### Contents 1. [Asset Inventory](/infrastructure/asset-inventory) 2. [Cloud Infrastructure](/infrastructure/cloud) 3. [DDoS Protection](/infrastructure/ddos-protection) 4. [DNS and Domain Registration](/infrastructure/domain-and-dns-security/overview) 5. [Network Security](/infrastructure/network-security) 6. [Operating System Security](/infrastructure/operating-system-security) 7. [Zero-Trust Principles](/infrastructure/zero-trust-principles) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Zero-Trust Principles The Zero-Trust security model assumes that threats can exist both inside and outside the network. It requires strict verification for every user and device attempting to access resources, regardless of their location. ### Key Principles 1. Always authenticate and authorize based on all available data points, including user identity, location, device health, and service or workload. 2. Limit user access with just-in-time and just-enough-access (JIT/JEA), risk-based adaptive policies, and data protection. 3. Segment networks and use encryption to limit the potential impact of a breach. ### Implementation Strategies 1. Implement strong IAM practices, including multi-factor authentication (MFA) and conditional access policies. 2. Use micro-segmentation to create secure zones in data centers and cloud environments. 3. Ensure all endpoints (e.g., devices, servers) comply with security policies before granting access. 4. Implement continuous monitoring and analytics to detect and respond to anomalies in real-time. 5. Use automation to enforce security policies consistently across the network. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, MermaidRenderer } from '../../../../components' export const dnsFlowDiagram = `flowchart TD Start([User types:
example.com]) --> Cache{Check
Cache?} Cache -->|Found| Fast[Return IP instantly
93.184.216.34] Cache -->|Not Found| Recursive[Your ISP DNS
Recursive Resolver] Recursive -->|1. Where is .com?| Root[Root Server
.] Root -->|2. Ask TLD| Recursive Recursive -->|3. Where is example.com?| TLD[TLD Server
.com] TLD -->|4. Ask Authoritative| Recursive Recursive -->|5. What's the IP?| Auth[Authoritative Server
example.com] Auth -->|6. IP: 93.184.216.34
TTL: 24h| Recursive Recursive -->|7. Validated & Cached| Result[Return IP
93.184.216.34] Fast --> Connect([Connect to Website]) Result --> Connect style Start fill:#e1f5ff style Connect fill:#d4edda style Root fill:#fff3cd style TLD fill:#fff3cd style Auth fill:#d1ecf1 style Recursive fill:#e7e7ff style Fast fill:#a8e6cf style Cache fill:#ffeaa7`; ## DNS Basics & Common Attacks ### How DNS Resolution Works When users type your domain, their request may traverse multiple trust points (flows vary by resolver caching, stub resolver config, and provider): 1. Local device cache 2. ISP/recursive DNS resolver 3. Root nameservers 4. TLD registry servers 5. Your authoritative nameservers Each step represents a potential attack surface where responses can be intercepted, modified, or poisoned. This multi-step process creates numerous opportunities for attackers to redirect users to malicious sites while their browser still shows the correct domain name. ### Common Attack Vectors * Social Engineering at Registrars: Attackers convince/bribe support staff they're legitimate owners using publicly available information * Expired Domain Sniping: Domains that expire enter a grace period before becoming publicly available to anyone (note: grace/redemption periods differ per TLD) * DNS Hijacking: Unauthorized changes to DNS records redirecting traffic to malicious servers * Email Interception (MX tampering): Password reset attacks and communication interception * DNS Tunneling: Encoding data within DNS queries for covert communication channels, often used for data exfiltration * DNS Cache Poisoning: Injecting forged responses into a resolver's cache to redirect subsequent queries *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## DNSSEC, CAA, SMTP DANE and Email Security ### DNSSEC Implementation DNSSEC (DNS Security Extensions) provides cryptographic authentication of DNS responses, preventing attackers from redirecting your users to malicious sites by tampering with DNS queries. Think of it as a digital signature that proves the DNS response came from the legitimate source. **How it protects you**: Without DNSSEC, attackers can intercept DNS queries and return fake IP addresses, redirecting users to malicious sites that look identical to yours. DNSSEC prevents this by cryptographically signing all DNS responses. While most client devices and many recursive resolvers do not perform DNSSEC validation on general DNS queries, DNSSEC is sometimes required and often preferred as a foundational component for security-sensitive internet protocols and features such as SMTP DANE, SSHFP, and CAA. **Preconditions**: * Domain is using the provider's nameservers * Registrar supports DS records * If the registrar supports CDS/CDNSKEY auto-publish, enable that if offered **Practical setup**: 1. **Enable signing at DNS provider** * Turn on DNSSEC in the zone settings * Provider generates KSK (Key Signing Key) and ZSK (Zone Signing Key), signs the zone, and shows DS parameters: * **Key Tag**: Unique identifier for the key * **Algorithm**: Common options: * `13` (ECDSAP256SHA256) - Recommended * `8` (RSASHA256) * `15` (ECDSAP384SHA384) * **Digest Type**: * `2` (SHA-256) - Recommended for widest compatibility * `4` (SHA-384) * **Digest**: Hex string of the hash 2. **Publish DS at registrar** * Create a DS record with the exact four fields above * Prefer Algorithm `13` (ECDSAP256SHA256) with Digest Type `2` (SHA-256) where supported * If both digest types 2 and 4 are offered, pick 2 for the widest compatibility Example registrar DS template: ``` Owner: yourdomain.tld Key Tag: 2371 Algorithm: 13 Digest Type: 2 Digest: 5C9F3E7B3F...A1C7 ``` 3. **Verify validation** * Wait for registrar DS propagation (can take minutes to hours) * Verify from a validating resolver using command-line tools: * `dig +dnssec example.com A` (check for AD flag in response) * `kdig +dnssec example.com A` (Knot DNS tool) * `drill -D example.com A` (LDNS tool) * For detailed analysis, use web tools: * [Verisign DNSSEC Analyzer](https://dnssec-analyzer.verisignlabs.com/yourdomain.org) * [DNSViz](https://dnsviz.net/d/yourdomain.org/analyze/) 4. **Monitor validation and changes** * Set up alerts for DS record changes at the registrar * Monitor DNSSEC validation status regularly * Watch for DNSKEY rollovers and ensure they complete successfully **Security notes**: * DNSSEC authenticates data; it does **not** encrypt queries. Use DoT (DNS over TLS) or DoH (DNS over HTTPS) for transport privacy if needed. * Harden registrar accounts, protect transfer locks, and monitor for DS changes; DS removal downgrades protection. * A hijacked registrar account can remove DS records, eliminating DNSSEC protection * Add alerts on registrar activity to detect unauthorized changes ### CAA Records Certificate Authority Authorization (CAA) records specify which Certificate Authorities (CAs) are allowed to issue SSL certificates for your domain. This prevents unauthorized certificate issuance, which attackers could use to create fake SSL certificates for your domain. **How it protects you**: Without CAA records, any Certificate Authority can issue SSL certificates for your domain. Attackers could potentially obtain fake certificates and use them in sophisticated phishing attacks that appear to have valid SSL encryption. A well-behaved CA not explicitly permitted via CAA records will deny certificate requests for that domain. \ While CA compromises are rare, history shows they do happen — and in such cases, attackers could potentially bypass or ignore CAA entirely. \ Notable incidents include: * [DigiNotar (2011)](https://en.wikipedia.org/wiki/DigiNotar) * [Comodo (2011)](https://www.theregister.com/2011/03/28/comodo_gate_hacker_breaks_cover/) \ Honorable mention, where it’s unclear whether CAA would have prevented the issue: * [Symantec Mis‑Issuance (2015–2017)](https://groups.google.com/a/chromium.org/g/blink-dev/c/eUAKwjihhBs/m/rpxMXjZHCQAJ) Before setting CAA records, identify which CA issued your current certificate: * **Command line**: `openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -issuer` * **Web tools**: [SSL Labs Server Test](https://www.ssllabs.com/ssltest/) provides comprehensive certificate analysis including issuer information * **Browser**: Click the padlock icon → Certificate details → Issuer information **Setup process**: Add CAA records to your DNS zone. Most DNS providers allow you to add these through their web interface: With the issuer's full name in hand, we now need to map it to the "Issuer Domain Name". There is no centralized repository mapping public CA's to their issuer domain names, but they are generally easily found with a simple search for f.x. "Let's Encrypt CAA". \ The Common CA Database also provides a [comprehensive collection to reference](https://ccadb.org/resources). ``` # Allow only specific CAs to issue certificates example.com. CAA 0 issue "letsencrypt.org" example.com. CAA 0 issue "digicert.com" # Send violation reports when unauthorized CAs attempt issuance example.com. CAA 0 iodef "mailto:security@example.com" # Control wildcard certificate issuance separately example.com. CAA 0 issuewild "letsencrypt.org" # Completely disable all certificate issuance (useful for non-web domains) example.com. CAA 0 issue ";" ``` ### SMTP DANE DNS-based Authentication of Named Entities (DANE) is an email security protocol that relies on TLSA DNS records secured via DNSSEC. The TLSA record contains information on the MX and the certificate in use, allowing a secure connection to be made using that certificate. This prevents both MiTM and downgrade attacks. \ DANE requires DNSSEC to be enabled on your domain - without it, TLSA records can be spoofed and offer no security benefit. If no record is found, SMTP DANE supporting clients will fall back to their usual connection flow. *While traditional PKI relies on trusted CAs, DANE allows domain owners to specify their own certificates, relying instead on DNSSEC to authenticate the certificate.* **Current industry support**: Of the major providers, Microsoft is the only one that currently supports SMTP DANE since its [RFC](https://datatracker.ietf.org/doc/html/rfc7672) was published in 2015. Notable smaller implementers include Comcast, Protonmail, Cisco, Fastmail, Posteo and Mailbox.org. **Implementation**: For those interested, a simple step-by-step tutorial can be found here for [Exchange Online](https://learn.microsoft.com/en-us/purview/how-smtp-dane-works#inbound-smtp-dane-with-dnssec). And for the brave, the Dutch Internet Standards Platform has published [detailed documentation](https://github.com/internetstandards/toolbox-wiki/blob/main/DANE-for-SMTP-how-to.md#reliable-certificate-rollover) on various aspects of supporting SMTP DANE on a self-hosted MX like postfix. **Example TLSA Record**: smtpdane.mx.microsoft. TLSA 900 "3 1 1 c495d9e40f7e625be22f83cc64305182ab0fe74232de30db8b218d09650cb0ea" * \_25.\_tcp.smtpdane.mx.microsoft. → Host + port (SMTP uses 25/TCP) * TLSA → Record type for DANE * 900 → TTL in seconds * 3 1 1 → * Usage 3 = Bind to end-entity cert * Selector 1 = Public key info * Match 1 = SHA-256 hash * Hex string → Hash of the MX certificate's public key **Further reading**: * [Microsoft SMTP DANE](https://learn.microsoft.com/en-us/purview/how-smtp-dane-works) * [RFC 7672](https://datatracker.ietf.org/doc/html/rfc7672) * [Google Cloud DNSSEC](https://docs.cloud.google.com/dns/docs/dnssec-advanced#tlsa) (only general docs, no Google Mail support as of writing) ### Email Security Configuration Email security records protect against email spoofing and phishing attacks. When your domain is compromised, attackers often change email settings to intercept password reset emails and other sensitive communications. #### SPF (Sender Policy Framework) SPF records specify which mail servers are authorized to send emails on behalf of your domain. This prevents attackers from spoofing your domain in phishing emails. **How it protects you**: Without SPF, anyone can send emails claiming to be from your domain. Attackers use this for sophisticated phishing campaigns that appear to come from your legitimate email address. This is particularly dangerous as attackers can impersonate executives or team members to target your own organization and users - imagine receiving a "urgent wire transfer" request from your CFO's email address, or your users getting a "mandatory wallet update" from your official support email. **Setup**: Add an SPF record to your DNS zone: ``` example.com. TXT "v=spf1 include:_spf.google.com ~all" ``` #### DKIM (DomainKeys Identified Mail) DKIM adds a digital signature to your emails, allowing receiving servers to verify that emails actually came from your domain and haven't been tampered with. **How it protects you**: DKIM signatures prove email authenticity and integrity, making it much harder for attackers to successfully spoof your domain in phishing campaigns. **Setup**: Configure with your email provider and publish public keys in DNS (your email provider will provide the specific records). #### DMARC (Domain-based Message Authentication) DMARC builds on SPF and DKIM to provide policy enforcement for email authentication. It tells receiving mail servers what to do with emails that fail authentication checks. **How it protects you**: DMARC prevents email spoofing by instructing receiving servers to reject or quarantine emails that fail authentication, protecting your users from phishing attacks. Without it, emails breaking SPF/DKIM may still be delivered by some providers (like Gmail, Outlook), often to the inbox or spam folder, sometimes with a warning banner (e.g., "This message may not be from…") DMARC also enables aggregate (rua) and forensic (ruf) reporting, giving domain owners visibility into who is sending email on their behalf - legitimate or otherwise. **Setup**: Add a DMARC record to your DNS zone: **Baseline example (aggregate reports only)**: ``` _dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com" ``` **Report types**: * **`rua=`** (Aggregate reports): Daily summaries of authentication results. This is the baseline and widely supported. * **`ruf=`** (Failure reports): Real-time forensic reports for individual failures. Not recommended as they are: * Not widely supported by mail providers * Raise privacy concerns (contain message content/headers) * May not deliver reliably * Often unnecessary for monitoring purposes **Recommendation**: Start with aggregate reports only (`rua=`). They provide sufficient visibility into authentication issues without the privacy and reliability concerns of failure reports. #### MTA-STS (Mail Transfer Agent Strict Transport Security) MTA-STS enforces encrypted connections between mail servers, preventing man-in-the-middle attacks on email transmission. **How it protects you**: Without MTA-STS, emails can be intercepted in transit. This is especially critical for passwords reset emails and other sensitive communications. **Deployment steps**: 1. **Create the MTA-STS policy file** Host a plain text file at: `https://mta-sts./.well-known/mta-sts.txt` Policy file structure: ``` version: STSv1 mode: testing mx: smtp.example.com mx: alt1.smtp.example.com max_age: 86400 ``` **Mode options**: * `testing` - Monitor TLS failures but don't block mail (recommended to start) * `enforce` - Require TLS for mail delivery * `none` - Disable policy **Important**: List all your MX servers. Ensure they have valid TLS certificates matching their hostnames. 2. **Host the policy file over HTTPS** The file must be: * Publicly accessible at the exact path * Served over HTTPS with a valid certificate * Available 24/7 (use reliable hosting) 3. **Publish DNS TXT record** Create a TXT record at `_mta-sts.`: ``` _mta-sts.example.com. TXT "v=STSv1; id=20250101000000" ``` The `id` value (often a timestamp or version) signals mail servers to fetch the latest policy. Update it whenever you change the policy file. 4. **Testing and enforcement** * Start with `mode: testing` to monitor without blocking * Collect and review TLS failure reports using TLS-RPT (See dedicated section below) * Verify policy is accessible using recent protocols: ``` curl --silent --show-error --fail --location \ --proto '=https' --tlsv1.2 --tls-max 1.3 \ --connect-timeout 10 --max-time 30 \ https://mta-sts.example.com/.well-known/mta-sts.txt -o /dev/null ``` * Once confident, change to `mode: enforce` * Update the `id` in DNS TXT record after policy changes **Provider-specific tips**: * **Google Workspace**: Manage MX in Admin console; host policy yourself; add TXT via DNS * **Cloudflare**: Host policy on Workers/Pages; manage TXT in DNS; HTTPS auto via Cloudflare SSL * **Amazon SES**: Host on S3 or CloudFront; manage TXT in Route 53; ensure domains are verified **Security notes**: * `max_age` determines how long mail servers cache the policy (86400 = 1 day) * All MX servers must support TLS with valid certificates * Monitor policy file availability - if unreachable, mail delivery may fail in enforce mode #### TLS-RPT (TLS Reporting) TLS-RPT collects delivery reports for messages transmitted using MTA-STS and SMTP DANE. Most major providers (Google, Microsoft, etc.) send one aggregated report per day per domain summarizing all failures for that day and some also indicate how many transmissions were successful. This is crucial for already established projects to ensure current email communication is not broken when enabling the security features above. **Setup**: Create a new DNS TXT record with the following structure and update example.com as well as the "mailto" email address. ``` _smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:reports@example.com" ``` **Example scenario - MTA-STS test phase**: * MTA-STS is deployed with a low max\_age value to allow for more rapid iteration * TLS-RPT DNS record is created * An email provider attempts to deliver mail to our domain * The email provider fetches the domain's MTA-STS policy and attempts delivery using TLS according to the policy * If an issue arises, a failure is logged and reported using TLS-RPT * The sender may still deliver without enforcing the MTA-STS policy **Example scenario - MTA-STS in production**: * MTA-STS policy file mode set to 'enforce' mode, and max\_age eventually raised as confidence in the deployment is gained * MTA-STS TXT DNS record ID value updated * An email provider attempts to deliver mail to our domain * If not already cached, the SMTP server fetches the domain's MTA-STS policy and attempts delivery using TLS according to the policy * If an issue arises, a failure is logged and reported using TLS-RPT * Mail delivery hard fails at this point **Consuming TLS reports**: * [https://github.com/domainaware/parsedmarc](https://github.com/domainaware/parsedmarc): best open-source option (Python). Handles both DMARC aggregate reports and TLS-RPT. * Many DMARC report analyzers like easyDMARC / dmarcian / Valimail also offer TLS-RPT parsing. Simply route the reports to your provider's report receiver address for visual summaries. ##### Report receiver in the same email domain? It is perfectly reasonable for a domain's TLS-RPT report receiver to reside in that same domain. \ This remains true even after MTA-STS and/or SMTP DANE have been fully enabled. See the following snippet from [RFC8460](https://www.rfc-editor.org/rfc/rfc8460) which defines TLS-RPT: *In the case of "mailto", reports should be submitted to the specified email address. When sending failure reports via SMTP, sending MTAs MUST deliver reports despite any TLS- related failures and SHOULD NOT include this SMTP session in the next report. This may mean that the reports are delivered unencrypted.* *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Domain And Dns Security > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Domain & DNS Security](/infrastructure/domain-and-dns-security/overview) * [DNS Basics & Common Attacks](/infrastructure/domain-and-dns-security/dns-basics-and-attacks) * [DNSSEC, CAA, SMTP DANE and Email Security](/infrastructure/domain-and-dns-security/dnssec-and-email) * [Registrar Security & Registry Locks](/infrastructure/domain-and-dns-security/registrar-and-locks) * [DNS Monitoring & Incident Response](/infrastructure/domain-and-dns-security/monitoring-and-alerting) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Monitoring, Alerts, and Incident Response ### DNS Record Monitoring DNS record monitoring involves continuously checking your domain's DNS records for unauthorized changes. Attackers often modify DNS records to redirect traffic to malicious servers while keeping your site partially functional. **What to watch for**: * **Nameserver (NS) record changes**: Attackers change your nameservers to point to their own DNS servers, giving them complete control over all DNS records * **Sudden TTL drops**: Very low TTLs *can* indicate preparation for rapid DNS changes during an attack * **Note**: Low TTL is common and legitimate with CDNs and auto-scaling contexts; Cloudflare "Auto" is often 300s * **Context**: Cloudflare allows TTL 30-60s for [unproxied records](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/); this is not inherently malicious * **Monitor for**: *Unexpected* drops from higher values or drops combined with other suspicious activity * **CAA record removal or overrides**: Allows any Certificate Authority to issue certificates for your domain * **Note**: Child zones override parent CAA records * **Advanced monitoring**: Watch for parameters like `accounturi` and `validationmethods` which provide finer control over certificate issuance * **DNSSEC disabled unexpectedly**: Removes cryptographic protection from DNS responses **If nameservers remain unchanged, also monitor**: * **A/AAAA record modifications**: IP address changes could redirect users to malicious sites * **MX record modifications**: Email server changes could intercept password reset emails * **TXT record changes**: Could affect email security (SPF/DMARC) or domain validation **Monitoring tools** (continuous change tracking): * [MXToolbox](https://mxtoolbox.com/) - Comprehensive DNS record monitoring and alerts * [HetrixTools](https://hetrixtools.com/) - Free DNS monitoring with email alerts * [SecurityTrails](https://securitytrails.com/) - Historical DNS data and change tracking **Analysis and debugging tools**: * [DNSViz](https://dnsviz.net/) - DNSSEC chain validation and debugging * [DNS Dumpster](https://dnsdumpster.com/) - DNS reconnaissance and record discovery **GitOps and zone control**: * [OctoDNS](https://github.com/octodns/octodns) - Infrastructure-as-code for DNS; manage zones via code with auditable, reviewed changes through CI/CD * [DNSControl](https://github.com/StackExchange/dnscontrol) - Synchronize DNS across multiple providers; declarative configuration with version control **Note**: If attackers change your NS records, they control everything. But attackers with DNS panel access might make subtle changes without touching NS records to avoid detection, which is why monitoring individual record types remains important. ### Certificate Transparency Monitoring Certificate Transparency (CT) logs are public records of all SSL certificates issued by Certificate Authorities. Monitoring these logs helps detect unauthorized certificate issuance. **Why it matters**: Attackers sometimes obtain fake SSL certificates for legitimate domains to make phishing sites appear more credible. CT monitoring helps you detect these certificates before they're used in attacks. **Setup and tools**: * [crt.sh](https://crt.sh/) - Search and monitor CT logs for your domain * [Cert Spotter](https://sslmate.com/certspotter/) - Free CT monitoring with API access * Watch for wildcard certificates if you don't use them (could indicate broader compromise) ### Passive DNS Monitoring Passive DNS monitoring tracks historical DNS resolution data across the internet, helping you detect brief changes that might be missed by periodic checks. **What it detects**: * **Brief record changes**: Attackers often make quick changes to avoid detection * **Geographic anomalies**: DNS records resolving to unexpected countries or regions * **Suspicious hosting provider changes**: Sudden switches to hosting providers known for malicious activity **Tools for passive DNS**: * [PassiveTotal (RiskIQ)](https://community.riskiq.com/) - Comprehensive passive DNS database * [Mnemonic Passive DNS](https://passivedns.mnemonic.no/) - Free passive DNS lookup * [SecurityTrails](https://securitytrails.com/) - Historical DNS and WHOIS data ### Setting Up Alerts #### Critical Alerts (Immediate Response Required) 1. **Registrar Changed** * **What it monitors**: Changes to your domain's registrar * **Why it's critical**: Indicates potential domain hijacking or unauthorized transfer * **Response**: Immediate verification and potential incident response activation 2. **Nameserver Changed** * **What it monitors**: Changes to nameserver records * **Why it's critical**: Attackers often change nameservers to redirect traffic to malicious servers * **Response**: Verify legitimacy, check if you initiated the change 3. **DNSSEC Broken** * **What it monitors**: DNSSEC validation failures or disabled DNSSEC * **Why it's critical**: DNS responses can be tampered with, leading to man-in-the-middle attacks * **Response**: Investigate signing issues, check for configuration changes 4. **CAA Records Removed or Overridden** * **What it monitors**: Removal of Certificate Authority Authorization records or child zone overrides * **Why it's critical**: Allows any CA to issue certificates for your domain, enabling SSL certificate attacks * **Response**: Restore CAA records immediately, investigate who removed them * **Note**: Child zones override parent CAA; parameters like `accounturi` and `validationmethods` can provide finer control 5. **Unexpected TTL Drops** * **What it monitors**: Sudden TTL drops from higher values * **Why it's important**: Can indicate preparation for rapid DNS changes (attack preparation) * **Context**: Low TTL (30-300s) is normal for CDNs and auto-scaling; Cloudflare allows 30-60s for [unproxied records](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/) * **Response**: Investigate *unexpected* drops or drops combined with other suspicious activity; verify if legitimate infrastructure changes #### High Priority Alerts (When NS Unchanged) 1. **A Record Changed** * **What it monitors**: IP redirects without NS changes * **Why it's important**: Could redirect users to malicious servers * **Response**: Verify the new IP address is legitimate and expected 2. **MX Record Changed** * **What it monitors**: Changes to mail server configurations * **Why it's important**: Could intercept emails, including password reset messages * **Response**: Verify mail server changes are authorized 3. **DMARC Policy Weakened** * **What it monitors**: Changes from "reject" to "quarantine" or "none" * **Why it's important**: Weaker policies allow more spoofed emails to reach users * **Response**: Investigate why policy was weakened, restore if unauthorized 4. **Unexpected Certificate Issued** * **What it monitors**: New SSL certificates issued for your domain * **Why it's important**: Could indicate certificate-based attacks or unauthorized issuance * **Response**: Verify the certificate was requested by your team, revoke if unauthorized ### Incident Response Plan #### Immediate Response 1. **Verify the compromise** - Check DNS records via multiple resolvers 2. **Access registrar account** - Attempt login, check for lockout 3. **Contact registrar security team** - Use pre-documented emergency contacts 4. **Document everything** - Screenshot all current settings #### Containment 1. **Invoke registry lock** if available 2. **Update NS records** if you maintain access 3. **Warn users** via social media/status page 4. **Contact law enforcement** if significant theft occurred #### Recovery 1. **Regain control** through registrar security procedures 2. **Audit all DNS records** against known-good baseline 3. **Reset all credentials** for registrar and DNS hosting 4. **Review access logs** to understand attack vector #### Post-Incident 1. **Conduct thorough investigation** 2. **Update security measures** based on lessons learned 3. **Consider legal action** if appropriate 4. **Publish transparency report** to rebuild trust *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Domain & DNS Security — Overview DNS (Domain Name System) is the backbone of the internet, translating domain names into IP addresses. In Web3, domain security is particularly critical as compromised domains can lead to irreversible financial losses through wallet drainers and phishing attacks. Unlike traditional web applications where stolen funds can sometimes be recovered, blockchain transactions are permanent. Moreover, DNS controls your email infrastructure through MX records - once compromised, attackers gain the keys to your entire organization through password resets and intercepted communications, making domain security a matter of both financial and operational survival. ### Web3-Specific Considerations #### Why Domain Security is Critical in Web3 Domain security is exponentially more critical in Web3 compared to traditional web applications due to the unique characteristics of blockchain technology: * **Irreversible transactions**: Unlike traditional banking where stolen funds can sometimes be recovered, blockchain transactions are permanent. Once funds are stolen through a domain hijack, they're gone forever. * **Direct wallet interactions**: Users connect their wallets directly to your domain, giving attackers immediate access to user funds without needing to compromise individual accounts. * **Reputation damage**: One domain hijack incident can permanently destroy protocol trust, as users lose confidence in the project's security practices. ### Historical Context #### Notable Domain Security Incidents Domain hijacking has impacted numerous Web3 projects: * **[Curve Finance (2025)](https://news.curve.finance/curve-domain-incident/)**: Domain hijacking at the registrar level, unrelated to any breach of Curve's infrastructure. * **[Puffer Finance (2024)](https://www.kucoin.com/news/articles/the-trojan-horse-of-web3-puffer-finance-attack-exposes-centralized-vulnerabilities)**: DNS hijack exploited centralized infrastructure vulnerabilities * **[Compound Finance (2024)](https://www.bitget.com/news/detail/12560604092919)**: Domain takeover attempt prevented by registry lock * **[Galxe (2023)](https://help.galxe.com/en/articles/8452958-october-6th-dns-security-incident-statement-guide)**: DNS hijack resulted in over 1,100 wallets drained for $270k * **[Curve Finance (2022)](https://rekt.news/curve-finance-rekt)**: DNS hijacking led to $575k in stolen funds through frontend compromise These incidents highlight the critical importance of proper domain security measures and the recurring nature of these attacks. ### References and Resources #### Incident Response Contacts * [SEAL Alliance TG Bot](https://t.me/seal_911_bot) - Web3 emergency response team * Your registrar's security team (document contact info) * Local FBI/law enforcement cybercrime division #### Standards and Best Practices * [NIST Special Publication 800-81-2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf) - Secure Domain Name System Deployment Guide * [ICANN DNSSEC Resources](https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en) * [RFC 8461](https://datatracker.ietf.org/doc/html/rfc8461) - MTA-STS specification * [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489) - DMARC specification * [DNS Security in Web3: Attacks & Monitoring Setup Explained](https://web3secnews.substack.com/p/the-hidden-dns-threats-that-could) - Comprehensive Web3 DNS security guide *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Registrar Security & Registry Locks ### Choosing a Secure Registrar Your domain registrar is the company that manages your domain registration with the central registry. This is often the weakest link in domain security, as many registrars have poor security practices and are vulnerable to social engineering attacks. #### Enterprise-Grade Registrars (Recommended) These registrars are designed for high-value domains and have security measures that consumer registrars lack: * **MarkMonitor**: Used by Fortune 500 companies, requires legal documentation for changes, dedicated security team * **AWS Route53**: IAM policy integration, CloudTrail logging, uses Amazon Registrar for major TLDs (but check TLD support) * **Cloudflare Registrar**: No markup pricing, automatic DNSSEC, built-in DDoS protection, requires Cloudflare services #### Consumer Registrars to Avoid for Critical Domains These registrars are designed for personal use and lack the security measures needed for Web3 projects: * **GoDaddy**: History of social engineering vulnerabilities, call center support vulnerable to manipulation * [2020 incident: Employees tricked into compromising cryptocurrency domains](https://threatpost.com/godaddy-employees-tricked-compromise-cryptocurrency/161520/) * [Multiple low-tech, high-impact breaches](https://krebsonsecurity.com/2023/02/when-low-tech-hacks-cause-high-impact-breaches/) * **Namecheap**: While better than GoDaddy, still vulnerable to social engineering and lacks enterprise-grade security controls * **Consumer-focused services** (Google Domains/Squarespace): Designed for personal use, not enterprise security * **Resellers**: Add another layer of complexity and potential attack surface **Due diligence**: Check [ICANN Compliance Notices](https://www.icann.org/compliance/notices) for registrar terminations, breaches, and compliance issues. ICANN has terminated several registrars due to security issues and breaches. Review your registrar's compliance history before trusting them with critical domains. ### Registry Lock (EPP Lock) Registry lock prevents unauthorized transfers at the registry level, not just the registrar. This is the strongest protection available for domain security. **Important distinction**: EPP status codes apply to **registry objects** (transfers, deletes, nameserver sets, contact updates), NOT DNS zone edits at your provider's DNS panel. You can still edit A records, MX records, TXT records, etc. in your DNS hosting provider's interface even with EPP locks enabled. **EPP Status Codes** that protect your domain: * `clientTransferProhibited`: Prevents domain transfers to another registrar * `clientUpdateProhibited`: Prevents registry object updates (nameservers, contact information) * `clientDeleteProhibited`: Prevents domain deletion * `serverTransferProhibited`: Registry-level transfer protection (stronger than client-level) * `serverUpdateProhibited`: Registry-level update protection (nameservers, contacts) * `serverDeleteProhibited`: Registry-level deletion protection **How it protects you**: Standard transfer locks only prevent transfers between registrars, but registry locks with full EPP protections prevent unauthorized changes to critical registry objects including transfers, deletions, nameserver changes, and contact modifications. Server-level locks require manual verification with the registry operator (like Verisign for .com domains), making social engineering attacks at the registrar level completely ineffective. **What EPP locks do NOT block**: DNS record edits (A, AAAA, MX, TXT, etc.) in your DNS provider's panel remain fully functional. EPP locks protect registry-level changes, not zone-level DNS record edits. **Setup**: Contact enterprise registrars for registry-operator level locks. This typically requires additional fees and documentation but provides the highest level of security. ### Multi-Factor Authentication Multi-factor authentication (MFA) adds an extra layer of security beyond just passwords, which are easily compromised through phishing or data breaches. **Strong recommendation**: Use **Hardware Security Keys (FIDO2/WebAuthn)** for registrar accounts. Given the critical nature of domain security and the irreversibility of domain hijacks, hardware keys are the ONLY authentication method we strongly recommend for Web3 projects. **Authentication options**: 1. **Hardware Security Keys (YubiKey, Titan, etc.) - STRONGLY RECOMMENDED** * **Immune to phishing**: Cannot be tricked by fake login pages * **No shared secrets**: Private key never leaves the device * **No SIM swap vulnerability**: Physical device required * **FIDO2/WebAuthn standard**: Industry-standard cryptographic authentication * **Why critical for domains**: Domain control = organization control; hardware keys provide the highest assurance 2. **TOTP Applications (Google Authenticator, Authy) - DISCOURAGED** * Vulnerable to phishing through man-in-the-middle attacks * Shared secrets can be compromised during setup * QR codes can be intercepted or screenshotted * Only use as a last resort if registrar doesn't support hardware keys * If forced to use TOTP, ensure registrar has additional protections 3. **SMS 2FA - DO NOT USE** * **Extremely vulnerable to SIM swapping attacks** * SMS can be intercepted via SS7 vulnerabilities * Social engineering attacks target mobile carriers * No cryptographic security * Numerous high-profile compromises via SMS 2FA * **Never use SMS 2FA for domain registrar accounts** **Action item**: If your registrar only supports SMS or TOTP, consider **migrating to an enterprise registrar** (MarkMonitor, AWS Route53 Registrar, Cloudflare Registrar) that supports hardware security keys. ### Dedicated Security Contact Email Use a dedicated email address for domain security that's completely separate from your main domain and personal accounts. **Why this matters**: If your main domain is compromised, you need a way to receive security notifications and regain control. Using the same domain creates a circular dependency. ``` ❌ admin@yourdomain.com (circular dependency - if domain is hijacked, you lose email access) ❌ personal@gmail.com (too many attack vectors, likely used across multiple services) ⚠️ domain-security@protonmail.com (better than gmail, but still a shared service) ✅ security@yourcompany-domains.com (best - separate domain dedicated to domain management) ``` As a best practice register a separate domain specifically for domain management (e.g., `yourproject-domains.com` or `yourproject-security.com`) with a different registrar than your main domain. This ensures you maintain communication channels even if your primary domain is completely compromised. ### Access Control Best Practices Limit and monitor who has access to your domain registrar account, as each person with access represents a potential attack vector. **Key practices**: * Document all personnel with registrar access * Use role-based access where available * Implement approval workflows for critical changes * Regular access audits (quarterly minimum) ### WHOIS Privacy Protection WHOIS records contain personal information about domain owners that is publicly accessible by default, including names, addresses, phone numbers, and email addresses. **Why it matters**: Without WHOIS privacy, your personal information is exposed to: * Attackers gathering information for social engineering attacks * Spammers harvesting contact details * Competitors researching your infrastructure * Anyone running a simple WHOIS lookup **Setup**: * Enable WHOIS privacy/proxy service through your registrar (often free or low-cost) * Use company information instead of personal details where privacy isn't available * Consider using a separate business entity for domain registration * Be aware that some TLDs (.us, .ca) don't allow WHOIS privacy **Important**: WHOIS privacy doesn't affect your legal ownership - you remain the legitimate owner, the privacy service just shields your personal information from public view. ### WHOIS vs RDAP **RDAP (Registration Data Access Protocol)** is the modern replacement for WHOIS. While WHOIS is still widely used, RDAP should be preferred for domain information lookups. **Why RDAP is better**: * **Structured data**: JSON-based responses are machine-readable and easier to parse * **Standardized**: Consistent format across registries and registrars * **Better display**: Modern CLIs and tools display RDAP data in organized, readable formats * **More reliable**: Built on RESTful APIs with better authentication and access control * **Links to authoritative sources**: Provides direct links to registrar and registry RDAP endpoints **Using RDAP**: * **Command-line tools**: Use RDAP CLIs like `rdap` (Rust-based) or `nicinfo` (Ruby-based) * **Web tools**: Many registries provide RDAP web interfaces * **Example lookup**: `rdap yourdomain.com` displays domain status, EPP codes, nameservers, registrar info, and expiration dates **Example RDAP output**: ``` ❯ rdap google.com 2025-10-06T20:36:58.203437Z INFO rdap: ICANN RDAP 0.0.23 Command Line Interface 2025-10-06T20:36:58.203497Z INFO rdap: query type is Domain Lookup for value 'google.com' ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― • host : rdap.verisign.com • Request URI : https://rdap.verisign.com/com/v1/domain/google.com ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― Domain GOOGLE.COM ┌────────────────────────────┬─────────────────────────────────────────────────────┐ │ Summary│Domain GOOGLE.COM │ │ │• 292 (Registrar) │ │ │ • Abuse │ │ │• Nameserver NS1.GOOGLE.COM │ │ │• Nameserver NS2.GOOGLE.COM │ │ │• Nameserver NS3.GOOGLE.COM │ │ │• Nameserver NS4.GOOGLE.COM │ ├────────────────────────────┼─────────────────────────────────────────────────────┤ │ Identifiers │ │ ├────────────────────────────┼─────────────────────────────────────────────────────┤ │ LDH Name│GOOGLE.COM │ │ Unicode Name│ │ │ Handle│2138514_DOMAIN_COM-VRSN │ ├────────────────────────────┼─────────────────────────────────────────────────────┤ │ Information │ │ ├────────────────────────────┼─────────────────────────────────────────────────────┤ │ Status│• Client Delete Prohibited │ │ │• Client Transfer Prohibited │ │ │• Client Update Prohibited │ │ │• Server Delete Prohibited │ │ │• Server Transfer Prohibited │ │ │• Server Update Prohibited │ ├────────────────────────────┼─────────────────────────────────────────────────────┤ │ Events │ │ ├────────────────────────────┼─────────────────────────────────────────────────────┤ │ Registration│• Mon, 15-Sep-1997 04:00:00 +00:00 │ │ Expiration│• Thu, 14-Sep-2028 04:00:00 +00:00 │ │ Last Changed│• Mon, 9-Sep-2019 15:39:04 +00:00 │ │Last Update Of RDAP Database│• Mon, 6-Oct-2025 20:36:39 +00:00 │ ├────────────────────────────┼─────────────────────────────────────────────────────┤ │ Links │ │ ├────────────────────────────┼─────────────────────────────────────────────────────┤ │ Self│• https://rdap.verisign.com/com/v1/domain/GOOGLE.COM │ │ Related│• https://rdap.markmonitor.com/rdap/domain/GOOGLE.COM│ └────────────────────────────┴─────────────────────────────────────────────────────┘ 292 (Registrar) ┌─────────────────┬────────────────────────────────────┐ │ Summary│292 (Registrar) │ │ │• Abuse │ ├─────────────────┼────────────────────────────────────┤ │ Identifiers │ │ ├─────────────────┼────────────────────────────────────┤ │ Handle│292 │ │ Roles│• registrar │ │IANA Registrar ID│292 │ ├─────────────────┼────────────────────────────────────┤ │ Contact │ │ ├─────────────────┼────────────────────────────────────┤ │ Full Name│MarkMonitor Inc. │ ├─────────────────┼────────────────────────────────────┤ │ Links │ │ ├─────────────────┼────────────────────────────────────┤ │ About│• http://www.markmonitor.com │ │ │• https://rdap.markmonitor.com/rdap/│ └─────────────────┴────────────────────────────────────┘ ``` **What RDAP shows**: * Domain status and EPP lock codes (clientTransferProhibited, serverUpdateProhibited, etc.) * Nameserver information * Registrar details and abuse contacts * Registration, expiration, and last update dates * Links to registry and registrar RDAP endpoints **For security audits**: Use RDAP to verify your domain's EPP status codes, confirm registry locks are active, check nameserver configurations, and validate expiration dates. The structured output makes it ideal for automated monitoring and compliance checks. ### Domain Expiration Protection Domain expiration is a critical yet often overlooked security risk. When domains expire, they enter a grace period before becoming publicly available, creating an opportunity for attackers to snipe your domain. **Expiration timeline (typical for gTLDs following ICANN rules)**: * Day 0: Domain expires (site goes down) * Day 1-45: Auto-renew grace period (can renew at normal price) * Day 46-75: Redemption period (costs 10x+ to recover) * Day 76-80: Pending delete * Day 81: Public availability (bot armies compete to register) **Important**: Grace and redemption periods **differ per TLD**. Generic TLDs (gTLDs like .com, .org, .net) follow ICANN rules with the timeline above. Country code TLDs (ccTLDs like .uk, .de, .ca) often have different policies set by their respective registries. Always verify your specific TLD's expiration policy with your registrar or registry. **Protection measures**: * **Enable auto-renewal** on all critical domains * **Set multiple renewal reminders** at 90, 60, 30, and 7 days before expiration * **Register domains for maximum period** (up to 10 years for most TLDs) * **Use a domain monitoring service** that alerts on upcoming expirations * **Document renewal dates** in your security calendar * **Ensure payment methods stay current** - expired credit cards are a common cause of accidental expiration * **Designate a backup person** responsible for domain renewals **Pro tip**: Set calendar reminders to check auto-renewal status quarterly - don't assume it's working until you verify. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Communication Strategies Communication during an incident can be very hard, as people are often scrambling to fix the issue at hand. Nonetheless, from a team member’s, outsider’s, or observer’s point of view, communication is very important to be able to understand what's happening, and it also provides some time to reflect and think about what is going on. With that said, providing information before confirming that it's accurate, can often be very negative and cause uncertainty. It is recommended to have a person designated for communication during an incident, and that updates are sent out on a fixed schedule, and it can often be that the update is that there is currently no new information available. ### Best Practices 1. Define and establish secure communication channels for incident response teams. Use [encrypted messaging apps](/encryption/communication-encryption) 2. Appoint primary and backup spokespersons to handle internal and external communications during an incident. 3. Develop pre-approved templates for incident notifications, updates, and press releases to ensure consistency and speed. 4. Provide regular updates to all stakeholders, including employees, customers, partners, and regulatory authorities, to keep them informed of the situation and response efforts. 5. Maintain clear communication within the incident response team to ensure that everyone is aware of their roles and responsibilities. 6. Be transparent with external stakeholders about the incident, the impact, and the steps being taken to address it. Avoid speculation and provide factual information. For message templates and example public updates, see [Incident Response Template: Communications](/incident-management/incident-response-template/communications). *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Forensic Readiness > 🔑 **Key Takeaway**: Forensic readiness means designing your systems and processes so that trustworthy > evidence survives an incident -- attributable, time-coherent, tamper-resistant, and preservable. It is > not the same as incident response or monitoring; it is the capability layer that lets you reconstruct, > prove, and defend what happened. Many organizations can detect that something suspicious happened, yet still struggle to reconstruct the event in a way that is operationally reliable, legally defensible, and regulator-ready. Forensic readiness closes that gap. It is an organization's ability to preserve, collect, correlate, and present trustworthy evidence when an incident occurs. In practice, it sits between security operations, governance, legal exposure, and resilience. The question is no longer only whether you can identify malicious activity. The question is whether you can rapidly produce a defensible account of what happened, what was affected, what evidence supports that conclusion, and how much confidence decision-makers should have in that account. ### Why forensic readiness is becoming strategic Three converging pressures are pushing forensic readiness from a niche DFIR specialty to a strategic concern. #### 1. Institutional framing has changed NIST CSF 2.0 broadened the conversation beyond narrow control checklists and emphasized governance and organizational preparedness. The updated NIST incident response guidance puts preparation back at the center, rather than treating incident handling as something that begins only after detection. NIST's cloud forensics work makes clear that evidence handling in modern distributed environments requires deliberate design, not improvised collection after the fact. #### 2. Infrastructure changed faster than evidence practices Traditional forensic assumptions came from environments where systems were relatively stable, hosts were long-lived, and data locations were predictable. That model does not map cleanly to cloud-native and distributed systems, including blockchain infrastructure. Containers are ephemeral. Workloads shift quickly. Application logic is fragmented across services. Critical context may exist briefly in memory, transient queues, reverse proxies, or short-retention telemetry layers. In these environments, evidence must be intentionally captured, preserved, normalized, and linked before it disappears. #### 3. The cost of ambiguity increased Regulatory and disclosure regimes are compressing response timelines. Organizations increasingly have to make externally visible statements under time pressure, sometimes before internal certainty is complete. If an organization has weak evidence hygiene -- fragmented logs, inconsistent timestamps, poor chain-of-custody discipline, or no reliable way to reconstruct incident scope -- the risk is not only technical. It becomes legal, financial, and reputational. CIRCIA, SEC disclosure expectations, and related regulatory pressure increase the premium on being able to substantiate what happened, quickly and credibly. ### Forensic readiness vs. monitoring vs. incident response These are related but distinct capabilities. | Property | Monitoring | Incident Response | Forensic Readiness | | ----------------- | ----------------------------- | -------------------------------------- | ----------------------------------------------------------------- | | Primary goal | Detect anomalies in real time | Contain and recover from incidents | Preserve and present defensible evidence | | Timing | During the event | After detection | Designed before, used after | | Evidence standard | Sufficient for alerting | Sufficient for operational decisions | Attributable, time-coherent, tamper-resistant, legally defensible | | Chain of custody | Not required | Helpful | Required | | Typical output | Alerts and dashboards | Incident timeline, containment actions | Forensic report, evidence package, scope analysis | Having SIEM, EDR, cloud logs, and retention policies is useful. None of it automatically creates forensic readiness. Forensic readiness requires properties that ordinary monitoring programs do not consistently provide: evidence must be attributable, time-coherent, preservable, and resistant to accidental or intentional tampering. Cross-source relationships have to survive collection boundaries. Critical context has to remain understandable after the incident, not only during real-time alert review. In some cases, the organization also needs proof that an artifact was collected in a controlled way, preserved without silent mutation, and associated with a defensible chain of custody. That is a different standard than "the log existed in the platform at some point." ### Practical guidance #### Step-by-step actions 1. **Inventory your evidence sources** -- Identify all systems, services, and infrastructure components that could generate relevant evidence during an incident (on-chain events, off-chain logs, API request/response traces, access logs, deployment pipelines, communication channels). 2. **Assess evidence volatility** -- Classify each source by how long data persists before it is overwritten or lost. Ephemeral containers, in-memory caches, and short-retention telemetry are high-volatility. Persistent databases and on-chain data are low-volatility. 3. **Define retention and preservation requirements** -- For each evidence source, determine how long data must be retained and in what format. Regulatory requirements, contractual obligations, and realistic investigation timelines all factor in. 4. **Implement evidence collection pipelines** -- Build automated collection that captures high-volatility evidence before it disappears. This may include sidecar log shippers, memory dump triggers, or event stream archivers. 5. **Establish chain-of-custody procedures** -- Document who collected each artifact, when, how, and from where. Use hash verification to prove integrity. Store artifacts in write-once or append-only storage where feasible. 6. **Normalize and correlate evidence** -- Ensure timestamps are synchronized (NTP/PTP) across all sources. Use consistent formats and identifiers so that evidence from different systems can be correlated reliably. 7. **Test forensic readiness regularly** -- Run tabletop exercises and simulated incidents to verify that evidence collection works end-to-end, artifacts are retrievable, and chain-of-custody documentation holds up. 8. **Integrate with incident response** -- Ensure the [incident response plan](/incident-management/incident-detection-and-response) references forensic readiness procedures. First responders must know what to preserve and how, not just how to contain. #### Best-practice checklist * [ ] All critical evidence sources are inventoried and classified by volatility * [ ] Retention periods are defined for each evidence source and meet or exceed regulatory requirements * [ ] High-volatility evidence (ephemeral containers, in-memory data) has automated capture before loss * [ ] Time synchronization (NTP) is configured on all systems generating evidence * [ ] Evidence artifacts are stored in tamper-evident or append-only storage * [ ] Hash verification (SHA-256 or stronger) is performed on collected artifacts * [ ] Chain-of-custody documentation is defined and tested * [ ] Forensic readiness procedures are referenced in the incident response plan * [ ] Tabletop exercises include forensic readiness validation at least annually * [ ] Access to forensic artifacts is logged and restricted to authorized personnel #### Role-based tips * **Operations/SRE**: Focus on evidence volatility -- ensure ephemeral workloads, container logs, and short-retention telemetry are captured before they disappear. Automate preservation workflows. * **Security specialists**: Focus on evidence integrity and chain of custody. Ensure artifacts are hash-verified, stored securely, and accessible only to authorized investigators. * **Legal/compliance**: Focus on retention requirements, disclosure timelines, and whether your evidence practices meet the standard for regulatory submissions. Work with security to understand what can be substantiated under pressure. * **Engineers/developers**: Focus on application-layer evidence. Ensure your services emit structured, traceable runtime context (request IDs, transaction hashes, decision logs) that survives collection boundaries. ### Application-layer forensic readiness Much of the security industry reasons from the network, endpoint, or identity perimeter inward. But many high-value incidents involve application behavior, API misuse, privilege boundary confusion, or complex multi-step sequences only partially visible to conventional telemetry. The missing evidence is often not another generic alert -- it is structured, trustworthy runtime context tied to what the application actually received, processed, rejected, transformed, or emitted. For Web3 projects, this is especially relevant. On-chain transactions are immutable and publicly verifiable, which is an advantage for forensic readiness. However, the off-chain infrastructure surrounding those transactions -- RPC endpoints, indexers, relayers, frontends, API gateways, key management systems -- generates ephemeral evidence that must be deliberately preserved. #### Application-layer evidence to capture * API request and response traces with correlation IDs * Authentication and authorization decision logs * Transaction submission and signing events * Smart contract interaction sequences (including reverted transactions) * Admin and privileged operation audit trails * Configuration change histories * Deployment pipeline artifacts and approvals ### Common pitfalls * **Assuming existing monitoring is sufficient**: Monitoring alerts tell you something happened. Forensic readiness ensures you can prove what happened, to whom, and with what evidence. These are different standards. * **Ignoring high-volatility evidence**: Ephemeral containers, in-memory queues, and short-retention logs are often the most valuable evidence sources and the first to disappear. If you do not capture them before an incident, they are gone. * **No chain-of-custody discipline**: Without documentation of who collected what, when, and how, even authentic evidence becomes hard to defend. Courts, regulators, and insurers may question whether evidence was tampered with. * **Inconsistent timestamps**: If systems are not time-synchronized, correlating evidence across sources becomes unreliable. A few seconds of clock drift can make timelines inconsistent. * **Forensic readiness as an afterthought**: By the time an organization decides it "now needs forensic evidence," the highest-value evidence may already be degraded, overwritten, scattered, or contextless. Readiness must be designed into the system before the incident. ### Quick-reference | Category | Action | Priority | | ------------------ | ------------------------------------------------------------------------ | ---------- | | Evidence inventory | Catalog all evidence sources and classify by volatility | High | | Preservation | Automate capture of high-volatility sources | High | | Retention | Define and enforce minimum retention per source | High | | Time sync | Deploy NTP across all evidence-generating systems | High | | Integrity | Hash-verify artifacts on collection (SHA-256+) | Medium | | Chain of custody | Document collection, transfer, and access for every artifact | Medium | | Correlation | Normalize formats and identifiers across sources | Medium | | Testing | Run annual tabletop exercises that validate forensic procedures | Medium | | Access control | Restrict and log access to forensic artifacts | Medium | | Application layer | Emit structured trace context from services (request IDs, decision logs) | Low-Medium | ### Further reading * [NIST CSF 2.0](https://www.nist.gov/cyberframework) -- Governance and organizational preparedness framework * [NIST SP 800-86](https://csrc.nist.gov/publications/detail/sp/800-86/rev-1/final) -- Guide to integrating forensic techniques into incident response * [NIST Cloud Forensics Reference Architecture](https://csrc.nist.gov/projects/cloud-forensics) -- Evidence handling in distributed cloud environments * [Tracehound: Forensic Readiness Is Becoming a Strategic Security Discipline](https://tracehoundlabs.com/blog/forensic-readiness-is-becoming-a-strategic-security-discipline) \-- Analysis of why forensic readiness is shifting from niche practice to strategic discipline * [Incident Detection and Response](/incident-management/incident-detection-and-response) -- Detection and response procedures * [Monitoring Guidelines](/monitoring/guidelines) -- On-chain monitoring best practices * [Lessons Learned](/incident-management/lessons-learned) -- Post-incident review and improvement *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Incident Detection and Response You don't want to be the project that has funds stolen and then doesn't notice it for multiple days. Early detection and effective response to security incidents will help minimize damage. ### Key Components of Incident Detection * **Monitoring and Logging**: Implement continuous monitoring and logging of on-chain activity for your project to understand when something is behaving out of the ordinary. Also implement monitoring of system events, and user behavior to detect anomalies and potential security incidents in non-on-chain systems such as web applications or cloud environments. ### Key Components of Incident Response * **Incident Response Team (IRT)**: Establish a dedicated IRT with clearly defined roles and responsibilities. * **Incident Response Plan (IRP)**: Develop and maintain an IRP that outlines the procedures for detecting, responding to, and recovering from security incidents. * **Containment**: Implement strategies to contain the incident. * **Recovery and Remediation**: Ensure that everything is restored to normal operation and take steps to prevent future incidents. * **Post-Incident Review**: Conduct a thorough review of the incident to identify lessons learned and improve future response efforts. * **Forensic Readiness**: Ensure your systems can preserve and present defensible evidence before an incident occurs. See [Forensic Readiness](/incident-management/forensic-readiness). For a complete incident response policy template covering roles, severity, documentation, and response flow, see [Incident Response Template: Incident Response Policy](/incident-management/incident-response-template/incident-response-policy) and [Incident Response Template: Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing). *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Incident Management > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Incident Management](/incident-management/overview) * [Incident Communication Strategies](/incident-management/communication-strategies) * [Incident Detection And Response](/incident-management/incident-detection-and-response) * [Forensic Readiness](/incident-management/forensic-readiness) * [Incident Lessons Learned](/incident-management/lessons-learned) * [Incident Response Template](/incident-management/incident-response-template) * [Playbooks](/incident-management/playbooks) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Lessons Learned Conducting a post-incident review and identifying lessons learned will improve your project's incident response capabilities. By analyzing what went well and what could be improved, you can enhance your readiness for future incidents. ### Best Practices 1. Review the incident together with everybody involved in handling it shortly after the incident is resolved. 2. Record details about the incident, including the timeline, root cause, impact, and response efforts. 3. Assess the effectiveness of the incident response, highlighting areas where the team performed well and areas needing improvement. 4. Create action plans to address identified weaknesses and enhance strengths. Assign responsibilities and deadlines for implementing improvements. 5. Share the lessons learned with the ecosystem to promote awareness and improve overall security practices. 6. Revise incident response policies and procedures based on the lessons learned to ensure continuous improvement. ### Questions worth asking * Was the incident detected as quickly as it should have been? * Did the severity level reflect actual impact? * Were the right people involved early enough? * Did the team have an appropriate runbook or was too much invented during the response? * Was the external communication cadence appropriate? * Did logs, dashboards, and evidence collection support investigation effectively? * What should change in monitoring, alerting, staffing, or access controls? ### Outputs beyond the write-up A good retrospective often drives updates to: * playbooks and runbooks * alert thresholds and monitoring coverage * access control or break-glass procedures * communication templates * training and tabletop exercises The review should end with tangible changes, not just a document. For a concrete post-mortem structure and example write-up, see [Incident Response Template: Post-Mortem Template](/incident-management/incident-response-template/templates/post-mortem-template) and [Incident Response Template: Example Post-Mortem](/incident-management/incident-response-template/templates/example-post-mortem). *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Incident Management Incident management involves preparing for, detecting, responding to, and recovering from security incidents. By thinking about incident management prior to actually experiencing an incident, you can help increase the likelihood of a timely recovery. ### Contents 1. [Communication Strategies](/incident-management/communication-strategies) 2. [Incident Detection and Response](/incident-management/incident-detection-and-response) 3. [Forensic Readiness](/incident-management/forensic-readiness) 4. [Lessons Learned](/incident-management/lessons-learned) 5. [Playbooks](/incident-management/playbooks/overview) 6. [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines) 7. [Incident Response Template](/incident-management/incident-response-template/overview) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Decentralized Incident Response Framework (DeIRF) A lightweight, end-to-end scaffold for security teams that work without a single authority. Use it as a menu, not a mandate. ### 1. Guiding Principles | Principle | What it means in practice | | -------------------------- | ----------------------------------------------------------------------- | | **Zero-trust by default** | Assume every identity, device, and network path is potentially hostile. | | **Shared responsibility** | Any responder can start an action if quorum rules are met. | | **Minimum viable process** | Fewer steps, fewer blockers, faster containment. | | **Open tooling** | Prefer transparent, auditable, community-maintained tools. | | **Identity plurality** | Accept multiple forms of strong identity proof. | | **Evidence first** | Collect before you change anything. | | **Continuous learning** | Retrospective after every incident and drill. | *** ### 2. Roles and Identities | Role | Key duties | Identity options (at least two) | | -------------------- | ------------------------------------------------ | ------------------------------------------ | | **First Reporter** | Sounds the alarm and starts evidence capture. | GPG key, DID, or multisig wallet signature | | **Triage Lead** | Confirms severity, forms a swarm, assigns tasks. | FIDO2 passkey, GPG, signed Matrix handle | | **Comms Lead** | Handles community and regulator updates. | Company issued OIDC, Lens profile | | **Containment Lead** | Executes on chain actions or host isolation. | Multisig signer, SSH CA cert | | **Recorder** | Maintains the timeline in an immutable log. | GPG key, signed git commit | > **Tip**: Publish a public mapping of handles to real names and keep it in a tamper evident repo. *** ### 3. Preparation Checklist | Item | Why it matters | Suggested tools | | ----------------------------------- | ---------------------------------------- | --------------------------------------------------------- | | Asset inventory (code, infra, keys) | You cannot protect what you do not know. | ConfigDB + IaC scans, Sheet/CSV | | Log pipeline with reliable clock | Forensic accuracy and ordering. | Vector + Loki or OpenSearch, Elasticsearch, RunReveal | | Secure comms channels | Quick swarm with strong auth. | Matrix + E2EE, Signal groups, Wire | | Evidence bucket (write-once) | Keeps raw data safe. | S3 object-lock, Storj, or IPFS | | Automated alert rules | Detect known bad patterns. | On chain monitors, Falco, OpenZeppelin Defender, Slackbot | | Drill schedule | Muscle memory beats panic. | Calendar invites, gamedays, CTF | *** ### 4. Detection and Triage Flow 1. **Alert fires or user reports an issue.** 2. **First Reporter** opens a ticket in the transparent issue tracker (GitHub security advisory or private GitLab issue). 3. **Triage Lead** checks severity matrix. 4. If **P1**, spin up a temporary incident channel with a predefined template. 5. Assign Leads and set T-minus deadlines. | Pros | Cons | | ------------------------ | --------------------------------------------------- | | Fast and clear ownership | Relies on people in multiple time zones being awake | | Public log builds trust | Attackers also watch public data if over-shared | *** ### 5. Containment Options | Method | When to use | Pros | Cons | | ------------------------------------------ | ----------------------- | ------------------------------ | ------------------------------------------------ | | **Smart contract pause / circuit breaker** | Critical on-chain bug | Stops further damage instantly | Requires a pre-coded pause function and multisig | | **Multisig treasury freeze** | Key compromise or theft | No central keyholder | Coordination overhead | | **Host or pod quarantine** | Off-chain infra breach | Isolates without full shutdown | Needs orchestration rights | | **DNS or CDN reroute** | Phishing or DDoS | Quick traffic shift | May break some services | Keep a one-liner command ready for each action and store it in the runbook. *** ### 6. Eradication and Recovery 1. Patch or replace vulnerable code. 2. Peer review with at least two signers. 3. Deploy to staging with replay of attack scenario. 4. Roll forward to production by multisig or automated pipeline. 5. Verify by monitoring metrics and logs for stability. | Automation hint | Keep it simple | | ----------------------------------------------------------- | ----------------------------------------------------------------- | | GitHub Actions, ArgoCD, and Defender Autotasks are popular. | Always include a manual approval gate in case of false positives. | *** ### 7. Post-Incident Actions | Step | Purpose | Tool Example | | --------------------------------------- | --------------------------------- | ----------------------------------- | | **Retrospective within 72 h** | Capture lessons before they fade. | Miro board, Markdown doc in repo | | **Update runbooks and detection rules** | Prevent repeat events. | Docs-as-code PR | | **Reward community reporters** | Encourage transparency. | Bug bounty payouts, incentive model | | **Public disclosure** | Build long-term trust. | Blog post plus on-chain message | *** ### 8. Quick-Start Templates | Need | Template location | | ------------------------ | ------------------------------ | | Incident channel message | /templates/incident-kickoff.md | | Retrospective form | /templates/retro-form.md | *** ### 9. Pros and Cons of Decentralized IR | Aspect | Pros | Cons | | ------------------------------ | --------------------------------------- | -------------------------------------------- | | **No single point of failure** | Resilience if one keyholder is offline. | Slower consensus for urgent actions. | | **Community trust** | Transparent logs and multisig votes. | Public scrutiny can amplify panic. | | **Open tools** | Low cost, auditable, extensible. | Less vendor support, more DIY. | | **Identity plurality** | Flexibility for global teams. | Complex to manage revocation and role drift. | *** ### 10. Keep It Alive * Run quarterly red team drills. * Rotate secrets on a fixed cadence. * Review identity proofs every six months. * Measure mean time to detect and contain. * Iterate on this framework during each retrospective. > **Remember**: Simplicity plus strong fundamentals beat heavy processes every time. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## North Korea (DPRK) Attack If you’ve been sent this document, then we have very good reason to believe that you have been hacked by North Korea (DPRK). This document will give you some information about North Korea, why they’ve hacked you, and how they might’ve done it. > BEFORE YOU CONTINUE FOLLOW THIS GUIDE TO PROTECT YOUR ASSETS: > [**Malware Infection**](/incident-management/playbooks/malware) North Korea is an extremely isolated country that has increasingly relied on cybercrime in order to generate revenue for itself. In **2024**, North Korea stole an estimated **1.34 billion USD** from the cryptocurrency industry alone, and in **February of 2025**, North Korea stole **1.5 billion USD** from Bybit exchange. North Korea operates a few different hacking squads, one of which we believe is responsible for compromising your computer. Each squad has their own preferred methodology, but their end goal is the same: **to steal your private keys and your login information**. If you have been infected by North Korean malware, you should assume your private keys, files, and online accounts have all been stolen. North Korean hackers may then use your accounts to impersonate you and hack your contacts. Here are some of the more recent ways we’ve seen North Korea hack people. ### The Fake Video Conference Software In this method, the hackers will impersonate a person that you know or are likely to trust, like an investor. They will send you a link to a video call, but it will not be Google Meet, Zoom, Microsoft Teams, or some other common software. Instead, the domain will be something entirely different.
Example 1

A message sent by a North Korean hacker impersonating an investor


When you visit this link and try to join the call, you will encounter an “error” and be prompted to fix it yourself.
Example 2

A fake error shown by the North Korean website


The instructions that you are provided will install malware on your computer. ### The Fake PDF In this method, you are sent a link to download a report, slide deck, or other plausible document.
Example 3

An example of a North Korean hacker attempting to share a link to malware


Example 4

An older example of a North Korean phishing email

If you download and run this file, you will have executed the malware. The first thing the malware does is open the PDF file you were expecting, so that you do not suspect you were infected. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Wallet Drainer Attack If you’ve been sent this document, then we believe that your funds have been stolen by a wallet drainer. This document will give you some information about drainers, how they work, and how you can protect yourself going forward. In general, when we refer to a drainer, we’re referring to one of a small number of popular drainer software available. A drainer customer (or “affiliate”) will purchase access to the drainer software from the drainer developer. From there, the affiliate will upload it to phishing websites and promote it via social media, such as Twitter. You can think of drainers like how a franchised restaurant owner will buy the rights to use the logo from the corporation and then pay royalties for every sale.
Example 5

Drainers use a variety of different tactics to gain control over your wallet and tokens. For example, drainers have been known to: * Request approval to spend your tokens directly * Request signatures to buy your tokens via a DEX that you’ve already approved * Request permission to upgrade your wallet to a 7702 wallet, which gives them full control * Request your private key or seed phrase directly, which gives them full control Depending on which type of drainer affected you, you might need to take different actions to recover control of your wallet. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## ELUSIVE COMET Attack If you’ve been sent this, then we believe that you’ve been hacked by a threat actor we’ve identified as ELUSIVE COMET. This document will give you some information about drainers, how they work, and how you can protect yourself going forward. ELUSIVE COMET is a threat actor which specializes in impersonation and social engineering. Their primary mode of operation is to impersonate a well-known individual (such as a journalist, a podcast host, an investor, etc) in order to convince the victim into getting onto a Zoom call.
Example 6

ELUSIVE COMET account reaching out to a potential victim


Once on the Zoom call, ELUSIVE COMET applies pressure and time urgency to convince victims to share their entire screen. If victims join from a browser or a phone, they may claim that they can’t hear or see the victim. If victims only share a specific window, they may claim that they can’t see the window, and that the entire screen needs to be shared.
Example 7

ELUSIVE COMET hackers on the Zoom call. Note the presence of a user named “Zoom”


ELUSIVE COMET requires that victims share their entire screen because Zoom contains a feature which allows users to request remote control access, but only if the target is sharing their entire screen. When the victim shares their screen, ELUSIVE COMET requests control from the “Zoom” user, which results in this prompt.
Example 8

Prompt shown by Zoom when ELUSIVE COMET requests remote control


Once the victim approves this request, ELUSIVE COMET uses the remote control to install malware to the victim’s computer. At this point, they are able to steal private keys, sensitive files, login sessions, and other valuable information. They use this to steal crypto, but also to perpetuate their scam by hijacking the victim’s social media accounts and sending out phishing messages to more people.
Example 9

A message sent from an account belonging to a victim of ELUSIVE COMET

*** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Playbooks > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Incident Response Playbooks](/incident-management/playbooks/overview) * [Malware Infection Response](/incident-management/playbooks/malware) * [North Korea (DPRK) Attack Response](/incident-management/playbooks/hacked-dprk) * [Wallet Drainer Attack Response](/incident-management/playbooks/hacked-drainer) * [ELUSIVE COMET Attack Response](/incident-management/playbooks/hacked-elusive-comet) * [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines) * [Decentralized Incident Response](/incident-management/playbooks/decentralized-ir) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Malware Infection This is a short guide prepared by SEAL that will help you navigate a malware infection. You have a limited amount of time to reduce the amount of damage that can be done to you. If you need help at any point, contact [**SEAL 911**](https://t.me/seal_911_bot) > IF YOU SUSPECT YOUR COMPUTER HAS BEEN HACKED **DO THE FOLLOWING IMMEDIATELY**: > > * Disconnect your computer from the internet > * Turn off your computer > * Open this document on another device > * Do not turn on your computer until further notice ### Secure your crypto assets The hackers have automatically stolen your crypto wallets, private keys, seed phrases, and credentials from: * Browser extension wallets (MetaMask, Phantom, Rabby, Coinbase Wallet, etc) * Hardware wallet applications (Ledger Live, SafePal, etc) * Local node wallets (Ethereum node keystore, Bitcoin node wallets, etc) * Password managers (1Password, Bitwarden, LastPass, etc) * Cloud storage (iCloud, Google Drive, etc) * Centralized exchanges (Coinbase, Binance, etc) * And more **You need to:** 1. Prioritize the wallets with the highest value. 2. Create a new wallet from a clean device (phone, tablet, other computer) and write the seed phrase down on paper. 3. Move all assets out from your old wallets, starting with tokens/NFTs/admin roles and ending with the native token (such as ETH). If you need information from your compromised device, **do not** reconnect it to the internet, or the hackers will continue stealing your data. The hackers may have installed “sweeper bots” on your addresses. These bots automatically “sweep” tokens to their wallets, but might not be able to handle non-tokenized deposits or protocols that require complex withdrawals. If your address has been swept, do not withdraw any additional assets without consulting [**SEAL 911**](https://t.me/seal_911_bot) or [**Flashbots Whitehats**.](https://whitehat.flashbots.net/) ### Notify your colleagues/friends The hackers may try to use the files and data they stole from your computer to impersonate you and scam/hack people in your network. If you work at a crypto protocol, the hackers may try to leverage your access to steal internal files and private keys and hack your protocol. **You need to:** * Notify your company’s security team, IT team, or simply your coworkers * Notify a few other people in your network Here is a message that you can copy/paste: > Hey, I think my computer was infected by malware and my wallets/accounts might be hacked. I’m currently working with > SEAL 911 on next steps. Please don’t trust any suspicious messages from me until you can fully confirm that I’ve > recovered my accounts, and help me spread the word. ### Secure your accounts The hackers have automatically stolen your active login session, and potentially your passwords, from: * Browsers (Chrome, Brave, Firefox, etc) * Desktop Applications (Telegram Desktop, WhatsApp, etc) * Password managers (1Password, Bitwarden, LastPass, etc) This means that your online accounts are at risk, such as: * Telegram * Twitter * Discord * Email (Google, Apple, Proton, etc) * Password manager (yes, your password manager account may be at risk) * Company accounts (Okta, Slack, etc) * Social media * Online banking * Cloud storage/backups **You need to:** * Log in to your accounts from a clean device (phone, tablet, other computer) * Go to the security settings and log out all other active sessions * Change your password * Activate or reset 2FA ### Notify the authorities If the hackers have managed to steal any crypto, take over any accounts, or cause other impact, you need to begin the slow process of involving the legal system. Collect the following information: * Any addresses (including the chain) or exchange accounts that have been stolen from * Any transactions through which the theft occurred (including the chain) * Any accounts that the hackers messaged you from * Any URLs that you visited or downloaded files from * Any other suspicious activity you observed * A timeline of events (see below for example) You will need this information to file reports at the following places: * [IC3.gov](http://IC3.gov) (even if you are not a US citizen/resident, US law enforcement may be able to match you with other victims) * [Chainabuse.com](http://Chainabuse.com) * [SEAL 911](https://t.me/seal_911_bot) * Your local police department **Example timeline:** > **October 22, 2024** > > * \[USERNAME] reached out to me on Telegram > * They appeared to be an investor with \[VC FIRM] and asked to schedule a call > * On the date of the call, they sent me this link: \[URL] > * I joined the call but got an error that said my call timed out > * I told \[USERNAME] and they told me to follow the instructions on the site to fix it > * I followed the instructions, but it didn’t work, so we rescheduled the call > * These were the instructions I followed: \[COMPUTER CODE] > > **October 23, 2024** > > * Approximately 200k USD was stolen from these wallets > * \[ADDRESS 1] > * \[ADDRESS 2] > * I was logged out of my Telegram account (\[USERNAME]) and could not log back in > * I was logged out of my Twitter account (\[USERNAME]) and could not log back in > * I received an email from Bitgo that someone logged into my account from \[IP] ### Get a new computer Your compromised computer is no longer safe to use. You can either: * **Get a new computer**: If you work for a large company, you may want to send your compromised computer to a forensics company for further analysis or for regulatory compliance. If so, you will need to buy a new computer. * **Wipe your existing computer**: If you feel comfortable with performing a full factory reset of your computer, you can do so yourself. If not, you may consider bringing it to a local technician (such as an Apple store, Geek Squad, or similar). Some people find it easier to simply buy a new computer. You must start fresh from this computer. **Do not** restore your device from backup (such as Time Machine, Windows Backup, or any third-party backup programs), or you may restore the malware as well. If you need to copy files from the compromised computer, **do not** connect it to the internet (or the malware may continue stealing your data), and **do not** copy your entire user folder (or you may copy the malware). ### Stay vigilant The hackers may have stolen additional logins that you were not aware of, or you may have not fully removed the infection. If you notice additional signs of compromise, such as login alerts, randomly being logged out of services, or crypto being stolen, you will need to follow this guide again. If you don’t already, consider following these best practices to keep yourself safe online: * Use a password manager (but not LastPass) * Turn on 2FA where available (disable cloud backups in your 2FA app) * Use a hardware wallet Here are some guides specifically for securing your: * [Securing Twitter](/community-management/twitter) * [Securing Telegram](/community-management/telegram) * [Securing Google](/opsec/google/overview) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Playbooks Generally speaking, incident response playbooks aim to provide detailed, step-by-step procedures for handling specific types of security incidents. Obviously, it's not possible to have thought about every possible scenario ahead of time, but one could create documentation for the most likely or devastating scenarios. ### Best Practices 1. Define the type of incident the playbook addresses (e.g., stolen funds, data breach, DDoS attack). 2. Outline the steps for detecting and analyzing the incident, including key indicators of compromise (IOCs) and tools to use. 3. Describe immediate actions to contain the incident and prevent further damage. 4. Provide detailed steps for eradicating the root cause of the incident. 5. Outline procedures for restoring everything affected to normal operation. 6. Detail the steps for conducting a lessons learned review. For example incident runbooks and templates, see [Incident Response Template: Templates](/incident-management/incident-response-template/templates/overview). *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## SEAL 911 SEAL 911 is a project designed to give users, developers, and even other security researchers an accessible method to contact a small group of highly trusted security researchers. The group can be reached via the [Telegram bot](https://t.me/seal_911_bot). Members of SEAL 911 follow a strict [CODE OF CONDUCT](https://github.com/security-alliance/seal-911/blob/main/CODE_OF_CONDUCT.md). When interacting with SEAL 911, ensure that you give as much information as possible in order to avoid double work by the security researchers. ### Crisis Handbook - Smart Contract Hack | [Google Doc](https://docs.google.com/document/d/1DaAiuGFkMEMMiIuvqhePL5aDFGHJ9Ya6D04rdaldqC0/edit#heading=h.c4h2beeflqpo) #### Actions Checklist #### Perform Immediately * [ ] Notify SEAL 911 Bot of the incident. Use this message template to get started. * [ ] Create a War Room with audio and share the invite link with trusted individuals. * [ ] Duplicate this document to allow collaboration and share the link in the War Room. * [ ] Review the Advice to Keep in Mind section. #### Perform in Parallel by Role 1. **Assign Key Roles to War Room Members**: * [ ] Assign members to specific roles. 2. **Analysis**: * [ ] Scope the impact of the attack. * [ ] Gather Transactions Involved. * [ ] Gather Affected Addresses. * [ ] Record Funds Movement. * [ ] Gather Attacker Information. * [ ] Investigate the issue and update the Issue Description. * [ ] Propose workable solutions. 3. **Protocol actions**: * [ ] Take immediate corrective/preventative actions to prevent further loss of funds. * [ ] Pause contracts if possible. * [ ] Execute pre-made defensive scripts. * [ ] Prioritize proposed solutions. * [ ] Validate and execute the solution. * [ ] Prepare monitoring alerts for situations that require future actions. 4. **Web actions**: * [ ] Disable deposits and/or withdrawals as needed in the web UI. * [ ] Enable front-end IP or Address blacklisting. * [ ] Create front-end for any user actions necessary (approval revoking, fund migrating, etc.). 5. **Communications**: * [ ] Identify social platforms that communications on the incident must be sent to. * [ ] Prepare messages for incident communication internally and externally. * [ ] Gather security contacts for any potentially affected downstream protocols (bridges, lending protocols). * [ ] Notify block explorers (like Etherscan) for attacker address labeling. * [ ] Continuously monitor social media for users providing additional information that aids whitehat efforts. * [ ] Monitor War Room efforts and maintain the Event Timeline. #### After all of the above is complete, consider Post Incident Actions ### Information Gathering Information will primarily be shared and acted upon in the War Room. As time allows, consolidate intel in the below section to achieve the following: * Accurately scope the incident impact. * Inform new War Room members and third parties efficiently. * Aid external communication. This is the chief duty of the Scribe. #### Issue Description The issue involves an unauthorized transfer of funds from the protocol's treasury contract due to a vulnerability in the contract's access control mechanism. The attacker exploited this vulnerability to initiate multiple transfers, siphoning funds to an external wallet. #### Events Timeline Record events to construct an overall timeline of the incident. Events worth recording: * First notice of the incident * War room creation * External communications * Attack transactions * Transactions performed by the team Record times in UTC. Use a UTC Time Converter. | Date-Time (UTC) | Event Description | Notes | | ---------------- | ----------------------------------------- | ------------------------------------ | | 2024-08-23 12:45 | First notice of the unauthorized transfer | Alert received via monitoring system | | 2024-08-23 12:50 | War room created | Initial members invited | | 2024-08-23 13:05 | Notified SEAL 911 Bot | Incident report submitted | | 2024-08-23 13:15 | Attack transaction identified | Transaction hash: 0x123456789abc | | 2024-08-23 13:20 | Contracts paused | Prevented further fund transfers | | 2024-08-23 13:30 | External communication initiated | First update sent via Twitter | #### Transactions Involved Record all transactions related to the incident. | Transaction Link | Notes | | ----------------------------------------------------------------- | ------------------------------ | | [0x123456789abcdef...](https://etherscan.io/tx/0x123456789abcdef) | Initial exploit transaction | | [0xabcdef123456789...](https://etherscan.io/tx/0xabcdef123456789) | Attacker moving funds to mixer | | [0xfedcba987654321...](https://etherscan.io/tx/0xfedcba987654321) | Defensive move by the team | #### Affected Addresses Record affected addresses related to the incident (protocol contracts, bridges, users, etc.). | Address Link | Status | Notes | | ---------------------------------------------------------------- | ------------ | ------------------------------------ | | [0x1111222233334444...](https://etherscan.io/address/0x11112222) | At Risk | User wallet, interacted with exploit | | [0x5555666677778888...](https://etherscan.io/address/0x55556666) | Impacted | Protocol treasury address | | [0x99990000aaaabbbb...](https://etherscan.io/address/0x99990000) | Paused | Lending protocol contract | | [0xaaaabbbbccccdddd...](https://etherscan.io/address/0xaaaabbbb) | Saved | Bridge contract, funds secured | | [0xddddeeeeffff0000...](https://etherscan.io/address/0xddddeeee) | Needs Review | User wallet, unusual activity noted | | [0x2222333344445555...](https://etherscan.io/address/0x22223333) | Uncertain | User wallet, pending analysis | #### Funds Movement Record funds movement to gather the impact of the incident and organize recovery efforts. * Original address that held the funds * Transaction that moved the funds * Assets and amounts the funds are comprised of * Destination the funds moved to (Contract, CEX, Bridge, Mixer) * Recovery Status of the funds Use Phalcon Tx Explorer to aid in recording funds movement. | Origin | Transaction Link | Amount / Asset | Destination | Recovery Status | Notes | | ------------------------------------------------------------ | --------------------------------------------------------- | -------------- | ----------------------------------------------------- | --------------- | ----------------------------------------- | | [0x5555666677778888...](https://etherscan.io/address/0x5555) | [0xabcdef123456789...](https://etherscan.io/tx/0xabcdef) | 1000 ETH | [Mixer address](https://etherscan.io/address/0x12) | Needs Review | Funds moved to Tornado Cash | | [0x99990000aaaabbbb...](https://etherscan.io/address/0x9999) | [0x9876543210fedcba...](https://etherscan.io/tx/0x987654) | 500,000 DAI | [CEX address](https://etherscan.io/address/0x34) | In Progress | Funds transferred to centralized exchange | | [0xaaaabbbbccccdddd...](https://etherscan.io/address/0xaaaa) | [0x123456789abcdef...](https://etherscan.io/tx/0x123456) | 200 BTC | [Contract address](https://etherscan.io/address/0x56) | Recovered | Funds recovered via multisig | | [0xddddeeeeffff0000...](https://etherscan.io/address/0xdddd) | [0xfedcba987654321...](https://etherscan.io/tx/0xfedcba) | 50,000 USDC | [Bridge address](https://etherscan.io/address/0x78) | Uncertain | Funds possibly moved cross-chain | #### Attacker Information Gather attacker information to aid legal efforts and fund recovery. | Address Link | Funded By | Notes | | ---------------------------------------------------------------- | ------------ | ----------------------------------------- | | [0xabcdefabcdefabcd...](https://etherscan.io/address/0xabcdefab) | Tornado Cash | Initial funding from Tornado Cash mixer | | [0x123456789abcdef...](https://etherscan.io/address/0x12345678) | CEX | Received funds from centralized exchange | | [0xfedcba987654321...](https://etherscan.io/address/0xfedcba98) | Unknown | No prior activity, potentially new wallet | ### Post Incident Actions 1. Confirm the incident has been resolved. 2. Create monitoring alerts for situations requiring future actions. 3. Prepare scripts to perform any actions related to monitoring events in the future. 4. Consider creating additional defensive scripts (pause/upgrade) to use for future situations. 5. Schedule a Post Mortem write-up. 6. Post the write-up to relevant social media. ### White Hat Frontrunning When a wallet's private key is compromised, white hat frontrunning can outpace attackers by submitting rescue transactions via Flashbots before the attacker drains the wallet. #### The Tool The open-source [white hat frontrunning script](https://github.com/pcaversaccio/white-hat-frontrunning) by [pcaversaccio](https://github.com/pcaversaccio) is a Bash script requiring only Linux native tools and Foundry's [`cast`](https://github.com/foundry-rs/foundry/tree/master/crates/cast). It supports two rescue flows: **Standard flow (`go.sh`):** A gas wallet sends ETH to the victim wallet, then the victim wallet sends tokens to a safe wallet — both bundled atomically via Flashbots so the attacker never sees them in the public mempool. **EIP-7702 flow (`go_eip7702.sh`):** No ETH needed on the victim wallet. A paymaster deploys a Vyper delegator contract ([`recoverooor.vy`](https://github.com/pcaversaccio/white-hat-frontrunning/blob/main/recoverooor.vy)) and executes the rescue via EIP-7702 delegation. The script also resets the authorization afterwards. #### When to Use It * [ ] A wallet's private key is confirmed compromised and funds remain. * [ ] The rescue team has a safe destination wallet and the victim's private key. * [ ] Someone on the team can run Bash scripts with Foundry's `cast` installed. #### Important Caveats * **Customize the main loop** for each rescue — it is not a one-click tool. * **Flashbots bundles are Ethereum mainnet only.** Other chains need different private mempool solutions. * **Debug mode (`DEBUG=true`) still sends real transactions** — it only adds verbose output, it is NOT a dry run. * **Coordinate with the War Room** before executing any rescue transactions. #### Real-World Rescues The repository documents successful rescues on [Base (Degen)](https://basescan.org/tx/0x344237ab211385caa2db08a9bb20a012bf0c0c0c4c6919005dd28fb18d08625a) and [Arbitrum (Zyfai)](https://arbiscan.io/tx/0x966ccc006e135e481b3aa4bb9645f0e05cc19dfa33baf3643d4fcb3b7c2f20b9). The [`community-examples/`](https://github.com/pcaversaccio/white-hat-frontrunning/tree/main/community-examples) directory contains customized scripts for various rescue scenarios. ### Appendix #### Advice to Keep in Mind * Limit the War Room occupancy. Be careful not to invite too many people during the early stages. Sensitive information is being shared; be wary. * Make it clear to War Room members not to publicize information without the protocol’s consent. * Do not speak to the press/news/publications. #### Key Roles * **Operations**: Initiates War Room, assigns roles, distributes tasks, herds multisig participants. * *Person Responsible* * **Scribe**: Consolidates gathered information for efficiency in knowledge-sharing. * *Person Responsible* * **Strategy Lead**: Prioritizes actions, considers trade-offs of decisions. * *Person Responsible* * **Protocol Lead**: Responsible for smart-contract actions (pausing, upgrading, etc.). * *Person Responsible* * **Web/Infrastructure Lead**: Responsible for updating the front-end, managing servers. * *Person Responsible* * **External Communicator**: Social media and user communications. * *Person Responsible* #### Suggested Tools and Platforms | Name | Type | Notes | | ------------------------ | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Discord | Platform | A familiar platform for web3 collaboration. Spin up a server quickly using our [recommended template](https://discord.new/CkADqy5aWsAH). Tips: New users must be granted the `approved` role before they can view chats. Upon creation, grant yourself the `approved` role and share an invite link with trusted members. | | Telegram | Platform | A familiar platform for web3 collaboration. Tips: Upon New Group creation, enable chat history as visible to new members. To do this: Info -> Edit -> Chat History For New Members -> Visible | | Google Hangouts | Platform | | | Phalcon Tx Explorer | Tx Analysis | | | Openchain Trace Explorer | Tx Analysis | | | Tenderly Tx Explorer | Tx Analysis, Debugging | Some features require login. | | Tenderly Alerts | Monitoring | Monitor addresses, on-chain actions, etc. Requires login. | | MetaSleuth | Monitoring | Monitor fund movement. 50 address limit. Requires login (premium feature). | | GitHub / Gist | Code Sharing | Create a private repo or secret gists and share the link with War Room participants only. | | CodeShare | Code Sharing | Sessions expire after 24 hours. | | HackMD | Code Sharing | Private notes become published after \~48 hours. Be very careful with sensitive information! | #### SEAL Message Template Fill out with relevant information and send to SEAL 911 Bot. ```plaintext Protocol: [Protocol Name] Attack Tx(s): [Transaction Hash(es)] Funds at Risk: [Estimated Amount in USD or Token] [Brief Description of the incident] ``` *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Communication Templates Templates and building blocks for incident communications. Adapt these to your situation and tone. ### Before You Post #### Checklist * [ ] Get approval from Incident Leader or Decision Maker * [ ] Verify facts are accurate * [ ] Avoid speculation about root cause (until confirmed) * [ ] Include what users should do (or not do) * [ ] State when you'll provide the next update #### What to Include | Element | When to Include | | ----------------------------- | ----------------------------------------- | | What happened (high level) | Always | | User funds are safe | If true | | What users should do | If action needed | | What users should NOT do | If relevant (e.g., don't interact with X) | | What still works | If partial outage | | When you'll update next | Always | | Link to status page or thread | If available | ### Building Blocks Use these as modular pieces. Combine as needed for your situation. #### Acknowledgment > We're aware of an issue affecting \[service/feature] and are actively investigating. #### Funds Safe > User funds are safe and have not been affected. #### Funds at Risk (be careful) > We are investigating a potential security issue. Out of caution, we recommend users \[specific action]. #### Action Required > If you \[specific condition], please \[specific action]. #### Do Not Interact > Do not interact with \[specific thing] until further notice. #### Service Paused > We have temporarily paused \[service/feature] while we investigate. #### Partial Outage > \[Feature X] is currently unavailable. \[Feature Y] and \[Feature Z] continue to work normally. #### Timeline Unknown > We don't have an ETA for resolution yet. We'll provide updates as we learn more. #### Next Update > We'll provide an update within \[timeframe] or sooner if the situation changes. #### Resolution > The issue has been resolved. \[Brief description of what happened and fix]. #### Post-Mortem Coming > We'll publish a detailed post-mortem within \[timeframe]. ### Example Templates #### Protocol Paused ##### For: Twitter/X, Discord announcement > We have temporarily paused \[protocol/feature] while we investigate a potential issue. > > User funds are safe. \[OR: We are still assessing the situation.] > > Do not interact with \[specific contracts/UI] until we confirm the issue is resolved. > > We'll provide an update within \[1 hour / as soon as we know more]. #### Website/Frontend Down ##### For: Twitter/X, Discord announcement > Our website is currently unavailable. We've taken it offline while we investigate \[a potential security issue / > technical problems]. > > Your funds in the protocol are not affected. Do not approve any transactions from sites claiming to be \[protocol > name] until we confirm service is restored. > > Follow this thread for updates. #### Social Account Compromised ##### For: Alternate channel (Discord if Twitter compromised, etc.) > The \[Twitter/Discord/Telegram] account of \[person/official account] has been compromised. > > Do NOT click any links or interact with messages from that account. > > We are working to recover the account. Any legitimate announcements will come from \[list alternate verified channels]. > > If you interacted with any links, revoke token approvals immediately at \[revoke.cash or similar]. #### Active Exploit (P1) ##### For: Initial announcement, keep brief > We are aware of a security incident affecting \[protocol/feature]. > > We are actively responding and will share more information as soon as possible. > > \[If applicable: We have paused affected contracts.] > > Do not interact with \[specific thing] until further notice. ##### For: Follow-up once stabilized > Update on the security incident: > > \[What happened - high level] > \[Current status] > \[What users should do] > \[Funds status - be precise about what was/wasn't affected] > > We'll publish a full post-mortem within \[timeframe]. #### Third-Party Outage ##### For: When the issue is not your fault > \[Feature] is currently unavailable due to an outage at \[provider/third-party]. > > Your funds are safe. This is affecting \[what's broken] but \[what still works] continues to function normally. > > We're monitoring the situation and will restore service when \[provider] resolves the issue. #### Issue Resolved ##### For: Closing out an incident > The issue affecting \[service/feature] has been resolved. > > \[One sentence on what happened] > \[One sentence on the fix] > > Thank you for your patience. We'll share a post-mortem with more details within \[timeframe]. ### Channel-Specific Notes #### Twitter/X * Keep initial post short * Use thread for updates * Pin important updates #### Discord * Use @everyone or @here sparingly (P1 only) * Create dedicated thread for ongoing updates * Lock thread after resolution to preserve record #### Telegram * Pin critical messages * Consider disabling chat during active incident to reduce noise ### Tone Guidelines * Be direct and factual * Avoid jargon users won't understand * Don't speculate on root cause until confirmed * Don't blame (individuals, third parties, users) * Acknowledge impact on users * Avoid excessive apologies (one is enough) *See [Incident Response Policy](./incident-response-policy) for the overall response process.* import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Critical Contacts Keep this updated. Stale contacts during an incident waste critical time. **Last verified:** \[DATE] ### Emergency Contacts #### SEAL 911 Industry-wide emergency response coordination for Web3 security incidents. | Field | Value | | ------------------- | ------------------------------------------------------------------------------ | | **Website** | [https://securityalliance.org/seal-911](https://securityalliance.org/seal-911) | | **When to contact** | Active exploits, cross-protocol incidents, need for industry coordination | | **How to contact** | \[Add contact method from their site] | > SEAL 911 can help coordinate response across the industry and connect you with security researchers and other > affected protocols during major incidents. ### Internal Team > **Tip:** Use team/group emails (e.g., `team-security@company.com`) instead of personal contacts where possible. > Group emails are more resilient to team changes and reduce maintenance burden. #### Decision Makers | Role | Name | Phone | Telegram/Signal | Email | | ---- | ---- | ----- | --------------- | ----- | | | | | | | | | | | | | | | | | | | #### Subject Matter Experts | Domain | Primary | Backup | Contact | | --------------- | ------- | ------ | ------- | | Smart Contracts | | | | | Infrastructure | | | | | Frontend | | | | | Security | | | | #### On-Call | Schedule | Current On-Call | Rotation Link | | -------- | --------------- | ------------- | | | | | ### Security Partners #### Auditors | Firm | Primary Contact | Email | When to Contact | | ---- | --------------- | ----- | ------------------------------------- | | | | | Code review, vulnerability assessment | | | | | | #### Incident Response Retainer | Firm | Primary Contact | Phone | Email | | ---- | --------------- | ----- | ----- | | | | | | #### Bug Bounty Platform | Platform | Program Link | Contact | | -------- | ------------ | ------- | | | | | ### Infrastructure Vendors | Service | Provider | Support Contact | Escalation | | ------------ | -------- | --------------- | ---------- | | Hosting | | | | | CDN | | | | | DNS | | | | | RPC Provider | | | | | Monitoring | | | | ### Legal & Communications | Role | Name/Firm | Contact | | ----------------- | --------- | ------- | | Legal Counsel | | | | PR/Communications | | | ### Key Partners Protocols, exchanges, or other partners to notify during major incidents. | Partner | Relationship | Contact | When to Notify | | ------- | ------------ | ------- | -------------- | | | | | | | | | | | ### Communication Channels | Purpose | Platform | Channel/Link | | --------------------- | -------- | ------------ | | Incident coordination | | | | Public updates | | | | Team alerts | | | ### Quick Reference - P1 Escalation For P1 (critical) incidents, contact in this order: 1. [ ] SEAL 911 (if active exploit) 2. [ ] Decision Makers (internal) 3. [ ] Security Partners (if needed) 4. [ ] Legal (if fund loss or regulatory implications) ### Maintenance * [ ] Review and update quarterly * [ ] Verify contact info after team changes * [ ] Test escalation paths periodically **Owner:** \[Assign someone to maintain this document] *See [Incident Response Policy](./incident-response-policy) and [Roles and Staffing](./roles-and-staffing) for how these contacts fit into the response process.* import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Incident Response Policy ### Overview This policy defines how we respond to security and operational incidents. It covers roles, severity classification, and the steps from detection through post-incident review. For role structures and on-call options, see [Roles and Staffing](./roles-and-staffing). ### Roles > One person can hold multiple roles. Roles can be reassigned during an incident as needed. #### Detector The person who identifies the incident. Their job is to notify responders and hand off. They don't need to fix it. #### Incident Leader Coordinates the response. Assigns tasks, makes decisions, ensures the process is followed. Escalates to Decision Makers when needed. #### Scribe Documents everything in the [Incident Log](./templates/incident-log-template). Maintains timestamps (UTC), captures decisions and rationale. This is a focused role. Don't also assign the Scribe to fix things. #### Communication Manager Handles internal and external communications. Drafts updates, coordinates with PR if needed, manages community channels. #### Subject Matter Experts (SMEs) Technical specialists called in based on incident type (smart contracts, infrastructure, security, etc.). #### Decision Makers Senior leadership for high-stakes decisions. Define who these are for your protocol (founders, security lead, legal, etc.). ### Severity Levels > **When in doubt, choose the higher severity.** A false P1 creates noise. A missed P1 costs funds. #### P1 - Critical | Aspect | Details | | ------------ | ---------------------------------------------------------------------------------------------- | | **Impact** | Loss of funds, critical systems down, active exploit | | **Response** | Immediate. Core team. Scale as needed. Decision Makers involved. | | **Examples** | Active exploit, private key compromise, critical smart contract vulnerability, production down | #### P2 - High | Aspect | Details | | ------------ | --------------------------------------------------------------------------------------- | | **Impact** | High impact to production, potential fund loss under specific conditions | | **Response** | Immediate | | **Examples** | Major vulnerability (not actively exploited), significant outage, DDoS on core services | #### P3 - Moderate | Aspect | Details | | ------------ | -------------------------------------------------------------------- | | **Impact** | Medium impact, no fund loss likely | | **Response** | Within hours | | **Examples** | Minor vulnerability, degraded performance, non-critical service down | #### P4 - Low | Aspect | Details | | ------------ | -------------------------------------------- | | **Impact** | Low impact, no fund loss | | **Response** | Can be scheduled | | **Examples** | Minor bugs, display issues, non-urgent fixes | #### P5 - Info | Aspect | Details | | ------------ | ----------------------------------------------------------- | | **Impact** | Informational, often from automated systems | | **Response** | No immediate action | | **Examples** | Expiring certificates, resource spikes, maintenance notices | ### Response Process #### Step 1: Detection Incidents can be detected via: * **Monitoring alerts** (Grafana, DataDog, on-chain monitors, etc.) * **Community reports** (Discord, Twitter, Telegram) * **Team members** noticing something wrong * **Bug bounty reports** * **Security audits** * **Partner notifications** The Detector's job: get the right people involved, fast. > **Don't know who to call?** Contact your incident response on-call team (e.g., DevOps or SecOps) via on-call system > or team-wide email (e.g., `team-security@company.com`). These serve as fallbacks when the detector is unfamiliar > with escalation paths. #### Step 2: Coordination **Detector responsibilities:** 1. Start a call (Zoom/Meet/Huddle) 2. Create a private channel (`#incident-[brief-description]`) 3. Alert responders via your alerting system or direct contact 4. Provide all known information 5. Hand off to an Incident Leader (get explicit acknowledgment) **For P1 incidents:** Keep the group minimal initially. Alert Decision Makers immediately. **Incident Leader responsibilities:** 1. Pull in relevant SMEs 2. Assign a Scribe → they create an [Incident Log](./templates/incident-log-template) 3. Assign Communication Manager(s) #### Step 3: Investigation **Goal:** Understand what's happening and assess impact. * Collect logs, error messages, reproduction steps * Identify affected services and scope of impact * Confirm or adjust severity level * Determine mitigation options **The Incident Leader assigns specific tasks to individuals.** One task per person at a time keeps things focused. #### Step 4: Resolution **Goal:** Stop the bleeding first, permanent fix later. If a temporary fix (rollback, pause, disable feature) is faster than a full fix and reduces damage, do that first. **Checklist:** * [ ] Apply temporary mitigation * [ ] Verify it's working * [ ] Notify stakeholders * [ ] Plan permanent fix with owner and timeline See [Runbooks](./runbooks/overview) for step-by-step guides for specific incident types. #### Step 5: Monitoring **Goal:** Confirm the fix actually worked. * Verify immediately after deployment * Monitor for at least a week * Consider adding new alerts or test cases * Document what monitoring is now in place #### Step 6: Post-Incident Review **Goal:** Learn and prevent recurrence. 1. Incident Leader schedules post-mortem (within a week of resolution) 2. Scribe prepares [Post-Mortem](./templates/post-mortem-template) draft 3. Team reviews timeline, identifies root causes, captures lessons 4. Define action items with owners and deadlines 5. Share with team (and community if appropriate) > All action items must have owners and deadlines. Track them to completion. ### Communication Guidelines * **Internal:** Regular updates in the incident channel. Frequency depends on severity. * **External:** Communication Manager drafts, gets approval before posting. See [Communications](./communications) for examples. * **Transparency:** Default to sharing post-mortems publicly (redacting sensitive details). ### Related Documents * [Roles and Staffing](./roles-and-staffing) - Team structure options * [Communications](./communications) - Public announcement guidance * [Incident Log Template](./templates/incident-log-template) - Fill out during incidents * [Post-Mortem Template](./templates/post-mortem-template) - Complete after incidents * [Contacts](./contacts) - Critical contacts * [Runbooks](./runbooks/overview) - Step-by-step incident guides ### Document Control | Version | Date | Author | Changes | | ------- | ------- | --------- | --------------- | | 1.0 | \[DATE] | \[AUTHOR] | Initial release | *Customize this policy for your protocol's tools, team structure, and communication channels.* {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Incident Response Template > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Incident Response Template for Web3 Protocols](/incident-management/incident-response-template/overview) * [Incident Response Policy](/incident-management/incident-response-template/incident-response-policy) * [Roles and Staffing](/incident-management/incident-response-template/roles-and-staffing) * [Communication Templates](/incident-management/incident-response-template/communications) * [Critical Contacts](/incident-management/incident-response-template/contacts) * [Runbooks](/incident-management/incident-response-template/runbooks) * [Templates](/incident-management/incident-response-template/templates) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Incident Response Template for Web3 Protocols A practical template for building incident response capabilities at cryptocurrency protocols and DAOs. > **This is a template, not a turnkey solution.** Every document, runbook, and checklist must be reviewed and customized > for your specific protocol, team, and infrastructure. The example runbooks contain generic guidance. Do not rely on > them without filling in your actual commands, contacts, and procedures. Test your IR capability through tabletop > exercises before you need it for real. ### Why Incident Response Matters Web3 protocols face unique challenges: * **Immutability**: On-chain actions often can't be reversed * **24/7 Operations**: Blockchain networks never sleep * **High Stakes**: Incidents can mean immediate, irrecoverable fund loss * **Adversarial Environment**: Active attackers constantly probing Without a plan, you'll waste critical time figuring out *who does what* while an exploit drains funds. You can't prevent all incidents. Focus on detecting quickly, responding effectively, and learning continuously. ### How to Build Your IR Capability #### Start Simple Don't over-engineer. A basic IR capability needs: 1. **Severity levels** - How bad is this? (P1-P5 scale) 2. **Roles** - Who does what during an incident? 3. **Communication channels** - Where do we coordinate? 4. **Documentation** - How do we capture what happened? That's it to start. Add complexity only as you need it. #### Scale With Your Team **Small teams (2-5 people):** * Everyone wears multiple hats * Define who leads incidents vs. who executes fixes * Establish a single communication channel * Keep one person documenting **Medium teams (5-15 people):** * Designate subject matter experts by domain * Consider a simple on-call rotation * Separate the "fix it" people from "communicate about it" people **Larger teams (15+ people):** * Formal First Responder program with training * Parallel on-call schedules (infra vs. smart contracts) * Dedicated communication/PR coordination * Regular tabletop exercises #### Practice Before You Need It * Read through your policy when there's no emergency * Run a tabletop exercise quarterly (even 30 minutes helps) * Review past incidents (yours or others via [Rekt News](https://rekt.news/)) * Update docs when you find gaps ### Using This Template Review and adapt these pages for your own internal incident response documentation. #### What's Included | Document | Purpose | | -------------------------------------------------------- | --------------------------------------------------------------- | | [Incident Response Policy](./incident-response-policy) | Core policy defining roles, severity levels, and response steps | | [Roles and Staffing](./roles-and-staffing) | Options for structuring your response team | | [Communications](./communications) | Guidance and examples for public announcements | | [Contacts](./contacts) | Critical partner and vendor contact sheet | | [Templates](./templates/overview) | Incident log and post-mortem templates | | [Example Incident Log](./templates/example-incident-log) | Sample filled-out incident log | | [Example Post-Mortem](./templates/example-post-mortem) | Sample filled-out post-mortem | | [Runbooks](./runbooks/overview) | Step-by-step guides for specific incident types | #### Customization Checklist Before using this template, customize these sections: * [ ] **Incident Response Policy** * [ ] Update severity level examples for your protocol * [ ] Add your communication tools (Slack/Discord/Telegram) * [ ] Add your alerting tools (PagerDuty/etc.) * [ ] Define your Decision Makers * [ ] **Contacts** * [ ] Fill in your team contacts * [ ] Add security partners (auditors, IR firms) * [ ] Add infrastructure vendors * [ ] Add legal/PR contacts * [ ] **Roles and Staffing** * [ ] Choose the model that fits your team size * [ ] Assign initial role holders * [ ] **Runbooks** * [ ] Customize for your specific infrastructure * [ ] Add protocol-specific scenarios * [ ] Fill in actual commands and dashboards #### Quick Start 1. Review the pages in this section 2. Work through the customization checklist above 3. Copy the structure into your internal docs or repo 4. Share with your team and walk through together 5. Run a tabletop exercise to test it ### Related Documentation These documents support effective incident response but typically live elsewhere in your protocol's documentation: | Document | Why It Helps | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Access Control Inventory** | List of privileged roles, multisigs, admin keys, and what each controls. Critical for understanding blast radius during key compromise. | | **Protocol Architecture** | Diagrams and descriptions of how components interact. Helps responders understand impact and dependencies. | | **Threat Model** | Documented risks, attack vectors, and mitigations. Speeds up investigation when you can reference known threats. | | **Audit Reports** | Findings from security audits. Known issues and accepted risks inform incident triage. | | **Tabletop Exercise Reports** | Learnings from practice incidents. Reveals gaps before real incidents expose them. | | **Dependency Inventory** | Third-party services, oracles, bridges your protocol relies on. Useful for third-party outage response. | | **Deployment Procedures** | How to deploy, pause, or upgrade contracts. Essential for resolution steps in runbooks. | | **Monitoring Documentation** | What's being monitored, alerting thresholds, and infrastructure used. Alerts in your paging system should link directly to relevant runbooks. | You don't need all of these to start. Build them over time as your protocol matures. ### Key Principles **When in doubt, escalate.** Treating a P2 as P1 creates some noise. Treating a P1 as P2 can cost millions. **Document as you go.** You won't remember details later. The Scribe role exists for a reason. **Blameless post-mortems.** Focus on systems, not individuals. "Why did the system allow this?" not "Who screwed up?" **Keep it current.** Stale contacts and outdated procedures create false confidence. ### Resources * [PagerDuty Incident Response Guide](https://response.pagerduty.com/) * [Google Cloud Incident Response](https://cloud.google.com/docs/security/incident-response) * [Rekt News](https://rekt.news/) - Learn from others' incidents * [SEAL 911](https://securityalliance.org/seal-911) - Emergency response coordination *This template is open source. Adapt it to your needs.* import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Roles and Staffing How you staff incident response depends on your team size and structure. This document covers options from small teams to larger organizations. See [Incident Response Policy](./incident-response-policy#roles) for role definitions. ### Core Roles (All Team Sizes) Every incident needs these roles filled, even if one person wears multiple hats: | Role | Responsibility | | ------------------- | ------------------------------------------------------------------------- | | **Incident Leader** | Coordinates response, assigns tasks, makes decisions | | **Scribe** | Documents everything in [Incident Log](./templates/incident-log-template) | | **Responders** | Execute fixes, investigate, implement mitigations | For larger incidents, add: * **Communication Manager** - Handles internal/external comms * **Subject Matter Experts** - Specialists for specific domains ### Small Teams (2-5 people) #### Approach Everyone knows everything. Just make sure someone is always reachable. > Whether you need formal on-call depends more on your commitments (SLAs, assets held, user expectations) than team > size alone. Small teams with high-value assets may still need structured coverage. #### Structure * Designate 1-2 people as default Incident Leaders (only one leads any given incident) * Everyone else responds as needed * Leader also serves as Scribe for minor incidents * Separate Scribe for P1/P2 incidents #### Expectations * Keep a shared contact list (see [Contacts](./contacts)) * Establish one communication channel for incidents * Someone should always be reachable (informal coverage) #### What You Might Not Need * Formal on-call rotation (unless your commitments require it) * Separate First Responder program * Multiple communication managers ### Medium Teams (5-15 people) #### Approach Define subject matter experts. Consider a simple on-call rotation. #### Structure ##### Subject Matter Experts (SMEs) | Domain | Primary | Backup | | --------------- | ------- | ------ | | Smart Contracts | | | | Infrastructure | | | | Frontend | | | | Security | | | ##### On-Call Options ##### Option A: Informal * No formal schedule, but SMEs are expected to be reachable during their working hours * Clear escalation for after-hours: who to call first ##### Option B: Simple Rotation * Weekly rotation among willing team members * One person on-call, responsible for initial triage * They pull in SMEs as needed #### Expectations * SMEs respond quickly when paged for their domain * On-call person handles initial assessment and escalation * Separate Scribe and Incident Leader for P1/P2 incidents ### Larger Teams (15+ people) #### Approach Formal First Responder program with trained personnel and scheduled on-call. #### First Responder Program **What First Responders Do:** * Initial triage when an incident is detected * Assess severity * Kick off the incident response process * Pull in the right people * Hand off to Incident Leader **What First Responders Don't Do:** * Fix the issue themselves (unless they're also the SME) * Make major decisions without escalation **Why This Model:** * Distributes knowledge across the organization * Reduces burden on any single team * Ensures someone is always ready to start the process * Doesn't require deep expertise in all domains #### On-Call Structure Consider parallel schedules for different domains: | Schedule | Coverage | Rotation | | --------------- | -------- | ----------------------- | | Infrastructure | 24/7 | Weekly among 6-8 people | | Smart Contracts | 24/7 | Weekly among 6-8 people | ex. With 8 people per rotation, each person is on-call one week every two months. #### First Responder Training Before going on-call, complete: * [ ] Review [Incident Response Policy](./incident-response-policy) * [ ] Review [Incident Log](./templates/incident-log-template) and [Post-Mortem](./templates/post-mortem-template) templates * [ ] Read 2-3 past post-mortems * [ ] Understand basic architecture (infra and smart contracts) * [ ] Know how to reach SMEs and Decision Makers * [ ] Test alerting system access #### On-Call Expectations **During your shift:** * Keep alerting device accessible * Respond to pages within 15 minutes * Triage and escalate appropriately * You don't need to fix everything. Get the right people involved **Off-shift:** * Stay current on documentation * Review new post-mortems * Participate in tabletop exercises ### Decision Makers Regardless of team size, define who can make high-stakes decisions during P1 incidents: | Role | Name | Contact | | ---- | ---- | ------- | | | | | | | | | | | | | These people should be reachable 24/7 for critical incidents. Consider: * Founders / C-level * Security Lead * Engineering Lead * Legal (for incidents with legal implications) ### Tools Checklist Ensure your on-call personnel have access to: * [ ] Alerting system (PagerDuty, etc.) * [ ] Communication platform (Slack, Discord, etc.) * [ ] Video conferencing * [ ] Monitoring dashboards * [ ] On-call schedule * [ ] [Contacts](./contacts) list ### Choosing Your Model | Team Size | Recommended Approach | | --------- | ----------------------------------------------- | | 2-5 | Informal coverage, designated leaders | | 5-10 | SME structure, optional simple rotation | | 10-15 | Simple rotation with SMEs | | 15+ | First Responder program with parallel schedules | **Start simple and add structure as you grow.** A lightweight process that people follow beats a heavyweight process that gets ignored. *See [Incident Response Policy](./incident-response-policy) for how these roles work during an actual incident.* import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Incident: API Outage - Rate Limiter Misconfiguration > **This is an example incident log.** Delete this file or use it as reference when creating real incident logs. ### Summary | Field | Value | | --------------------- | ------------------------ | | **Status** | Resolved | | **Severity** | P2 | | **Start Time** | 2024-01-15 14:32 UTC | | **Resolution Time** | 2024-01-15 16:45 UTC | | **Affected Services** | API, Frontend (degraded) | ### Roles | Role | Person | | --------------------- | ---------------------------- | | Detector | Monitoring (DataDog alert) | | Incident Leader | Alice | | Scribe | Bob | | Communication Manager | Carol | | Responders | Alice, Bob, Dave (infra SME) | ### Communication Channels * **Call:** [https://meet.google.com/xxx-xxxx-xxx](https://meet.google.com/xxx-xxxx-xxx) * **Chat:** #incident-2024-01-15-api ### Timeline ``` 14:32 UTC - DataDog alert fired: API error rate >5% 14:35 UTC - Bob acknowledged alert, started investigating 14:38 UTC - Bob escalated to #incident channel, started call 14:42 UTC - Alice joined, assigned as Incident Leader 14:45 UTC - Bob assigned as Scribe 14:48 UTC - Dave (infra SME) joined 14:52 UTC - Identified: rate limiter rejecting legitimate requests 14:55 UTC - Carol joined as Communication Manager 15:05 UTC - Root cause identified: bad config deployed at 14:15 UTC 15:12 UTC - Decision: rollback config 15:18 UTC - Rollback initiated 15:25 UTC - Rollback complete, monitoring 15:40 UTC - Error rates back to normal 15:45 UTC - Carol posted update to Discord 16:00 UTC - Continued monitoring, no issues 16:45 UTC - Incident declared resolved ``` ### Investigation #### What We Know * API started returning 429 errors at 14:32 UTC * Rate limiter was updated at 14:15 UTC as part of routine config change * New config had threshold set to 10 req/min instead of 1000 req/min (typo) * Affected all API endpoints #### Affected Services | Service | Impact | Status | | --------------- | ---------------------------- | -------- | | API | 429 errors for most requests | Resolved | | Frontend | Degraded (API calls failing) | Resolved | | Smart Contracts | No impact | N/A | #### Root Cause (initial assessment) Typo in rate limiter configuration: `10` instead of `1000` for requests per minute threshold. ### Actions #### Immediate * [x] Identify source of errors @Dave * [x] Find recent changes @Dave * [x] Prepare rollback @Dave #### Resolution * [x] Rollback config change @Dave * [x] Verify API functioning @Bob * [x] Post community update @Carol ### Resolution Summary #### Mitigation Applied Rolled back rate limiter configuration to previous known-good version. #### Verification * [x] API error rate back to baseline (\<0.1%) * [x] Sample API calls succeeding * [x] No user reports of issues post-fix ### Communications Sent | Time | Channel | Summary | | --------- | ---------------------- | -------------------------- | | 15:00 UTC | Discord #announcements | "Investigating API issues" | | 15:45 UTC | Discord #announcements | "API issues resolved" | | 16:00 UTC | Twitter | Brief update (optional) | ### Post-Incident * [x] Post-mortem scheduled for: 2024-01-17 15:00 UTC * [x] [Post-mortem document](./example-post-mortem) created * [ ] Action items assigned (pending post-mortem) ### Links & Evidence * DataDog dashboard: \[link] * Config PR that caused issue: \[link] * Rollback PR: \[link] *See [Incident Response Policy](../incident-response-policy) for severity definitions and process.* import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Post-Mortem: API Outage - Rate Limiter Misconfiguration > **This is an example post-mortem.** Delete this file or use it as reference when creating real post-mortems. ### Metadata | Field | Value | | ----------------- | ------------------------------------------------------- | | **Incident Date** | 2024-01-15 | | **Severity** | P2 | | **Authors** | Alice, Bob | | **Status** | Final | | **Incident Log** | [2024-01-15 Example API Outage](./example-incident-log) | ### Summary On January 15, 2024, at 14:32 UTC, our API began rejecting most requests with 429 (rate limited) errors. The incident lasted approximately 2 hours and 13 minutes. The root cause was a typo in a rate limiter configuration change deployed at 14:15 UTC. The threshold was set to 10 requests per minute instead of the intended 1000. This caused legitimate user requests to be rejected. The incident was detected via automated monitoring and resolved by rolling back the configuration change. No funds were at risk, but approximately 3,000 users experienced failed transactions during the outage window. ### Impact #### Users * Users affected: \~3,000 * Duration: 2h 13m * Services unavailable: API (full), Frontend (degraded) #### Financial * Funds at risk: None * Actual losses: None * Estimated costs: \~2 engineering hours for response #### Reputation * Public visibility: Low (brief Discord posts) * Media coverage: None * Community response: Minor frustration, resolved quickly ### Timeline | Time (UTC) | Event | | ---------- | ------------------------------- | | 14:15 | Config change deployed | | 14:32 | Incident began (errors started) | | 14:32 | Detected via DataDog alert | | 14:38 | Response started | | 14:42 | Incident Leader assigned | | 15:05 | Root cause identified | | 15:25 | Rollback complete | | 16:45 | Incident resolved | See [Incident Log](./example-incident-log) for detailed timeline. ### Root Cause #### Primary Cause Human error during configuration change. The rate limit threshold was typed as `10` instead of `1000`. #### Contributing Factors 1. No validation in config deployment process for obviously wrong values 2. Config change was not tested in staging environment 3. No gradual rollout for config changes 4. Alert threshold (5% error rate) took 17 minutes to trigger #### 5 Whys | Question | Answer | | --------------------------------- | ------------------------------------------------ | | Why did the API reject requests? | Rate limiter threshold was too low | | Why was the threshold wrong? | Typo in configuration file | | Why wasn't the typo caught? | No review process for config changes | | Why is there no review process? | Config changes considered "low risk" | | Why are they considered low risk? | Never had an incident before (survivorship bias) | ### What Went Well 1. Monitoring detected the issue within 17 minutes 2. Team mobilized quickly once alert fired 3. Root cause identified within 30 minutes 4. Rollback was straightforward 5. Communication to users was timely ### What Went Wrong 1. Config change deployed without testing 2. No peer review for config changes 3. Alert took 17 minutes to fire (threshold too high) 4. No validation for obviously wrong values (10 vs 1000) ### Where We Got Lucky 1. This happened during business hours when the team was available 2. The fix (rollback) was simple. If the old config was also broken, recovery would have been harder 3. No financial impact because this was the API layer, not smart contracts ### Action Items | Action | Owner | Deadline | Status | | -------------------------------------------------- | ----- | ---------- | ----------- | | Add peer review requirement for config changes | Dave | 2024-01-22 | Done | | Add config validation for rate limit thresholds | Dave | 2024-01-29 | Done | | Lower alert threshold to 1% error rate | Bob | 2024-01-19 | Done | | Add staging environment testing for config changes | Dave | 2024-02-15 | In Progress | | Document config change process | Alice | 2024-01-31 | Not Started | ### Lessons for Runbooks * [x] Existing runbook sufficient: [Third-Party Outage](../runbooks/third-party-outage) (config rollback section applicable) * [ ] No new runbook needed ### Detection | Aspect | Details | | ----------------------- | --------------------------------- | | How detected | Monitoring alert (DataDog) | | Time to detection | 17 minutes | | Could we detect faster? | Yes - lower alert threshold to 1% | ### Links * Incident Log: [2024-01-15 Example API Outage](./example-incident-log) * Config PR (bad): \[link] * Rollback PR: \[link] * Monitoring dashboard: \[link] ### Meeting Notes **Attendees:** Alice, Bob, Carol, Dave **Discussion points:** * Agreed config changes need same rigor as code changes * Discussed whether to require staging for all changes (decided yes) * Dave to implement validation this week *See [Incident Response Policy](../incident-response-policy#step-6-post-incident-review) for post-mortem process.* import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Incident Log Template Use this template during active incidents. The [Scribe](../incident-response-policy#scribe) owns this document. ### How to Use 1. Copy this template to your incident logs folder 2. Name it: `YYYY-MM-DD-brief-description` (e.g., `2024-03-15-api-outage`) 3. Update in real-time as things happen 4. Use UTC timestamps, 24-hour format 5. More detail is better. You can summarize later ## Incident: \[TITLE] ### Summary | Field | Value | | --------------------- | ----------------------------- | | **Status** | Active / Mitigated / Resolved | | **Severity** | P1 / P2 / P3 / P4 / P5 | | **Start Time** | YYYY-MM-DD HH:MM UTC | | **Resolution Time** | | | **Affected Services** | | ### Roles | Role | Person | | --------------------- | ------ | | Detector | | | Incident Leader | | | Scribe | | | Communication Manager | | | Responders | | ### Communication Channels * **Call:** \[link] * **Chat:** \[channel] ### Timeline ``` HH:MM UTC - Incident detected by [who/what] HH:MM UTC - [Person] assigned as Incident Leader HH:MM UTC - [Person] assigned as Scribe HH:MM UTC - Initial assessment: [description] HH:MM UTC - ... ``` ### Investigation #### What We Know * * * #### Affected Services | Service | Impact | Status | | ------- | ------ | ------ | | | | | #### Root Cause (initial assessment) ### Actions #### Immediate * [ ] \[Action] @\[Owner] * [ ] \[Action] @\[Owner] #### Resolution * [ ] \[Action] @\[Owner] * [ ] \[Action] @\[Owner] ### Resolution Summary #### Mitigation Applied #### Verification * [ ] \[Check 1] * [ ] \[Check 2] ### Communications Sent | Time | Channel | Summary | | ---- | ------- | ------- | | | | | ### Post-Incident * [ ] Post-mortem scheduled for: \[date] * [ ] [Post-mortem document](./post-mortem-template) created (save to your post-mortems folder) * [ ] Action items assigned ### Links & Evidence * \[Relevant dashboard] * \[Relevant PR/commit] * \[Screenshots] ### Severity Reference | Level | Description | | ----- | ---------------------------------------- | | P1 | Critical - funds at risk, active exploit | | P2 | High - major impact, immediate response | | P3 | Moderate - medium impact | | P4 | Low - minor issues | | P5 | Info - no action needed | See [Incident Response Policy](../incident-response-policy#severity-levels) for full definitions. {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Templates > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Templates](/incident-management/incident-response-template/templates/overview) * [Incident Log Template](/incident-management/incident-response-template/templates/incident-log-template) * [Post-Mortem Template](/incident-management/incident-response-template/templates/post-mortem-template) * [Runbook Template](/incident-management/incident-response-template/templates/runbook-template) * [Incident: API Outage - Rate Limiter Misconfiguration](/incident-management/incident-response-template/templates/example-incident-log) * [Post-Mortem: API Outage - Rate Limiter Misconfiguration](/incident-management/incident-response-template/templates/example-post-mortem) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Templates Templates for incident response documentation. Copy these when needed. > **Review these templates before your first incident.** Familiarize yourself with the structure so you're not > learning the format during an emergency. Consider running a tabletop exercise to practice filling them out. ### Available Templates | Template | When to Use | | ------------------------------------------------ | --------------------------------------------------- | | [Incident Log Template](./incident-log-template) | Copy when declaring an incident | | [Post-Mortem Template](./post-mortem-template) | Copy after resolving a significant incident (P1-P3) | | [Runbook Template](./runbook-template) | Copy when creating a new scenario-specific runbook | ### Examples | Example | Purpose | | ---------------------------------------------- | --------------------------------------------- | | [Example Incident Log](./example-incident-log) | Shows a filled-out incident log for reference | | [Example Post-Mortem](./example-post-mortem) | Shows a filled-out post-mortem for reference | For communication guidance and examples, see [Communications](../communications). ### Runbook Template See [Runbooks](../runbooks/overview) for the runbook template and existing runbooks. *See [Incident Response Policy](../incident-response-policy) for the full response process.* import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Post-Mortem Template Complete this after significant incidents (P1-P3). Focus on learning, not blame. ### How to Use 1. Copy this template to your post-mortems folder 2. Scribe creates draft before the post-mortem meeting 3. Hold meeting within a week of resolution 4. All responders contribute 5. Every post-mortem produces action items with owners and deadlines 6. Share with team (and publicly if appropriate) ## Post-Mortem: \[INCIDENT TITLE] ### Metadata | Field | Value | | ----------------- | ----------------------- | | **Incident Date** | YYYY-MM-DD | | **Severity** | P1 / P2 / P3 | | **Authors** | | | **Status** | Draft / Final | | **Incident Log** | \[Link to incident log] | ### Summary \[2-4 paragraphs. What happened, when, how long, how it was resolved. Someone unfamiliar should understand the incident after reading this.] ### Impact #### Users * Users affected: * Duration: * Services unavailable: #### Financial * Funds at risk: * Actual losses: #### Reputation * Public visibility: * Media coverage: ### Timeline | Time (UTC) | Event | | ---------- | --------------------- | | | Incident began | | | Detected | | | Response started | | | Root cause identified | | | Mitigation applied | | | Resolved | See linked Incident Log for detailed timeline. ### Root Cause #### Primary Cause \[What was the fundamental reason this happened?] #### Contributing Factors 1. 2. 3. #### 5 Whys | Question | Answer | | --------------------------- | ------ | | Why did \[incident] happen? | | | Why? | | | Why? | | | Why? | | | Why? | | ### What Went Well 1. 2. 3. ### What Went Wrong 1. 2. 3. ### Where We Got Lucky \[What fortunate circumstances helped that we shouldn't rely on next time?] 1. 2. ### Action Items > Every action item needs an owner and deadline. | Action | Owner | Deadline | Status | | ------ | ----- | -------- | ------ | | | | | | | | | | | | | | | | ### Lessons for Runbooks Should we create or update a [runbook](../runbooks/overview) based on this incident? * [ ] New runbook needed: \[type] * [ ] Existing runbook to update: \[which one] * [ ] No runbook changes needed ### Detection | Aspect | Details | | ----------------------- | ---------------------------------------------- | | How detected | Monitoring / User report / Team member / Other | | Time to detection | | | Could we detect faster? | | ### Links * Incident Log: \[Link to incident log] * Relevant PRs: * Dashboards: * External references: ### Meeting Notes **Attendees:** **Discussion points:** *Template based on [Incident Response Policy](../incident-response-policy#step-6-post-incident-review)* import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Runbook Template Copy this template to create runbooks for specific incident types. ## Runbook: \[INCIDENT TYPE] ### Quick Reference | Field | Value | | --------------------- | ------------ | | **Typical Severity** | P1 / P2 / P3 | | **Primary Responder** | \[Team/Role] | | **Last Updated** | \[Date] | | **Owner** | \[Name] | ### Identification #### Symptoms * [ ] Symptom 1 * [ ] Symptom 2 * [ ] Symptom 3 #### Alerts * Alert: \[name] in \[system] * Dashboard: \[link] #### Differentiation If you see \[X] but not \[Y], it might be \[different issue] instead. ### Immediate Actions #### Step 1: \[Name] **Why:** \[Purpose] ``` [Commands or steps] ``` **Expected:** \[Result] #### Step 2: \[Name] **Why:** \[Purpose] ``` [Commands or steps] ``` ### Investigation #### Key Questions * [ ] What is the scope? * [ ] When did it start? * [ ] What changed recently? #### Information to Gather | Data | How to Get It | | ---- | ------------- | | | | ### Mitigation #### Option A: \[Name] - Preferred **When:** \[Conditions] **Impact:** \[Side effects] 1. Step 1 2. Step 2 **Verify:** ``` [Command to verify] ``` #### Option B: \[Name] - Fallback **When:** \[Conditions] 1. Step 1 2. Step 2 ### Escalation Escalate to [Contacts](../contacts) if: * [ ] Mitigation doesn't work within \[time] * [ ] Impact expands * [ ] \[Condition] ### Resolution Checklist * [ ] Mitigation verified * [ ] Stakeholders notified * [ ] Timeline documented in [Incident Log](../templates/incident-log-template) * [ ] Post-mortem scheduled if warranted ### Common Root Causes | Cause | Signs | Fix | | ----- | ----- | --- | | | | | ### Related * Related runbook for this scenario * [Incident Response Policy](../incident-response-policy) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Runbook: Build Pipeline Compromise > **Stub runbook.** Customize with your CI/CD platform and procedures. ### Quick Reference | Field | Value | | --------------------- | --------------------------- | | **Typical Severity** | P1 | | **Primary Responder** | DevOps / Infrastructure SME | | **Last Updated** | \[Date] | | **Owner** | \[Name] | ### Identification #### Symptoms * [ ] Unexpected code in deployed artifacts * [ ] CI/CD configuration changed without approval * [ ] Secrets accessed or exfiltrated * [ ] Unauthorized workflow runs #### Confirm Compromise * Review CI/CD audit logs * Compare build artifacts to source * Check for config changes in CI/CD platform ### Immediate Actions 1. [ ] Disable compromised pipelines 2. [ ] Rotate all secrets and tokens 3. [ ] Take down potentially compromised deployments 4. [ ] Audit recent builds and deployments ### Mitigation 1. [ ] Audit CI/CD configuration for unauthorized changes 2. [ ] Rebuild from trusted commit using clean pipeline 3. [ ] Implement additional approval requirements 4. [ ] Review and restrict pipeline permissions ### Prevention * [ ] Require approval for CI/CD config changes * [ ] Use short-lived credentials * [ ] Implement branch protection * [ ] Audit pipeline access regularly * [ ] Use signed commits * [ ] Separate build and deploy permissions ### Related * [Frontend Compromise](./frontend-compromise) * [Dependency Attack](./dependency-attack) * [Incident Response Policy](../incident-response-policy) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Runbook: CDN/Hosting Compromise > **Stub runbook.** Customize with your CDN and hosting provider details. ### Quick Reference | Field | Value | | --------------------- | ------------------ | | **Typical Severity** | P1 | | **Primary Responder** | Infrastructure SME | | **Last Updated** | \[Date] | | **Owner** | \[Name] | ### Identification #### Symptoms * [ ] Malicious files being served * [ ] File hashes don't match expected * [ ] Unauthorized access in provider logs #### Confirm Compromise * Compare served files to known good source * Check CDN/hosting access logs ### Immediate Actions 1. [ ] Purge CDN cache 2. [ ] Take down site or redirect to maintenance page 3. [ ] Rotate all access credentials 4. [ ] Review access logs for unauthorized activity ### Mitigation 1. [ ] Redeploy from verified source (git, not existing infra) 2. [ ] Verify deployment matches expected 3. [ ] Enable additional access controls 4. [ ] Set up file integrity monitoring ### Prevention * [ ] Limit hosting/CDN admin access * [ ] Enable 2FA on all accounts * [ ] Use subresource integrity (SRI) * [ ] Implement Content Security Policy (CSP) * [ ] Regular access audits ### Related * [Frontend Compromise](./frontend-compromise) * [Incident Response Policy](../incident-response-policy) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Runbook: DDoS Attack > **This is an example runbook.** Review and customize for your protocol before use. Add your specific CDN/WAF > provider commands and escalation contacts. ### Quick Reference | Field | Value | | --------------------- | ------------------ | | **Typical Severity** | P2-P3 | | **Primary Responder** | Infrastructure SME | | **Last Updated** | \[Date] | | **Owner** | \[Name] | ### Identification #### Symptoms * [ ] Website/API unresponsive or slow * [ ] Monitoring shows traffic spike * [ ] CDN/hosting alerts * [ ] Error rate increase * [ ] Legitimate requests timing out #### Differentiation | Symptom | Likely Cause | | ------------------------------ | ---------------------------- | | Traffic spike + slow response | DDoS | | Traffic normal + slow response | Application issue | | Single endpoint affected | Targeted attack or bug | | All traffic from few IPs | Simple attack, easy to block | | Distributed traffic | Sophisticated DDoS | ### Immediate Actions #### Step 1: Confirm DDoS **Why:** Distinguish from application issues * [ ] Check CDN/WAF dashboards * [ ] Review traffic patterns * [ ] Check if specific endpoints targeted #### Step 2: Enable DDoS Protection **Why:** Use provider-level mitigation For Cloudflare: ``` [Document your Cloudflare mitigation steps] ``` For AWS: ``` [Document your AWS Shield steps] ``` #### Step 3: Assess Impact * [ ] Which services affected? * [ ] Are critical functions available? * [ ] User impact level? ### Investigation #### Key Questions * [ ] Attack type (volumetric, protocol, application layer)? * [ ] Targeted endpoints? * [ ] Attack source patterns? * [ ] Why now? (retaliation, extortion, distraction?) #### Data to Collect | Data | Source | | ---------------- | --------------------- | | Traffic volume | CDN/hosting dashboard | | Request patterns | Access logs | | Source IPs | WAF/firewall logs | | Targeted paths | Application logs | ### Mitigation #### CDN/WAF Level 1. Enable "Under Attack" mode if available 2. Increase security level 3. Add rate limiting rules 4. Block obvious attack patterns 5. Enable bot protection #### Application Level 1. Enable rate limiting 2. Add CAPTCHA to affected endpoints 3. Cache aggressively 4. Disable non-essential features temporarily #### DNS Level 1. Reduce TTL for flexibility 2. Consider geo-blocking if attack is regional 3. Failover to backup if available ### Escalation * [ ] [CDN/hosting provider](../contacts#infrastructure-vendors) - for attack mitigation support * [ ] [Decision Makers](../contacts#decision-makers) - if extended outage ### Recovery #### Attack Subsiding 1. Monitor traffic patterns 2. Gradually reduce protection levels 3. Watch for resurgence 4. Keep enhanced monitoring for 24-48 hours #### Post-Attack * [ ] Review logs for attack details * [ ] Update protection rules * [ ] Document attack patterns * [ ] Consider permanent mitigations ### Communication #### Internal * Status updates every 30 min during active attack * Clear when degraded vs. fully down #### External (if needed) > We're experiencing elevated traffic that's affecting site performance. We're actively mitigating and will provide updates. Usually not needed for brief DDoS attacks. Avoid drawing attention. ### Prevention After resolving, consider: * [ ] Always-on DDoS protection * [ ] Rate limiting by default * [ ] Geographic restrictions if appropriate * [ ] Improved caching * [ ] Backup/failover infrastructure ### Related * [Third-Party Outage](./third-party-outage) * [Frontend Compromise](./frontend-compromise) * [Incident Response Policy](../incident-response-policy) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Runbook: Dependency Attack > **Stub runbook.** Customize with your package management and build procedures. ### Quick Reference | Field | Value | | --------------------- | ------------ | | **Typical Severity** | P1 | | **Primary Responder** | Frontend SME | | **Last Updated** | \[Date] | | **Owner** | \[Name] | ### Identification #### Symptoms * [ ] Unexpected behavior after dependency update * [ ] Security advisory for a package you use * [ ] Malicious code found in node\_modules or similar * [ ] Lockfile changes you didn't make #### Confirm Dependency Attack ``` npm audit # or yarn audit ``` Check for recent lockfile changes in git history. ### Immediate Actions 1. [ ] Take down site to stop serving malicious code 2. [ ] Identify the malicious package 3. [ ] Pin dependencies to last known good version 4. [ ] Rebuild from clean environment ### Mitigation 1. [ ] Remove or replace malicious package 2. [ ] Update lockfile with known good versions 3. [ ] Rebuild using `npm ci` or `yarn --frozen-lockfile` 4. [ ] Redeploy verified build ### Prevention * [ ] Use lockfiles and commit them * [ ] Use `npm ci` / `yarn --frozen-lockfile` in CI * [ ] Regularly audit dependencies * [ ] Consider using a private registry * [ ] Pin exact versions for critical packages * [ ] Review dependency changes in PRs ### Related * [Frontend Compromise](./frontend-compromise) * [Build Pipeline Compromise](./build-pipeline-compromise) * [Incident Response Policy](../incident-response-policy) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Runbook: DNS Hijack > **Stub runbook.** Customize with your DNS provider details and procedures. ### Quick Reference | Field | Value | | --------------------- | ------------------ | | **Typical Severity** | P1 | | **Primary Responder** | Infrastructure SME | | **Last Updated** | \[Date] | | **Owner** | \[Name] | ### Identification #### Symptoms * [ ] Domain pointing to wrong IP * [ ] Users redirected to malicious site * [ ] SSL certificate errors (attacker using different cert) #### Confirm DNS Hijack ``` dig yourdomain.com # Compare output to expected IP ``` ### Immediate Actions 1. [ ] Regain access to DNS provider account 2. [ ] Enable 2FA if not already enabled 3. [ ] Point DNS to known good infrastructure or maintenance page 4. [ ] Enable DNS lock / registrar lock ### Mitigation \[Document your specific DNS provider procedures here] ### Prevention * [ ] Enable registrar lock * [ ] Use DNSSEC * [ ] Enable 2FA on DNS provider * [ ] Limit DNS admin access * [ ] Monitor DNS records for changes ### Related * [Frontend Compromise](./frontend-compromise) * [Incident Response Policy](../incident-response-policy) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Runbook: Frontend Compromise > **This is an example runbook.** Review and customize for your protocol before use. Add your specific DNS > provider, hosting platform, and deployment procedures. ### Quick Reference | Field | Value | | --------------------- | ------------ | | **Typical Severity** | P1 | | **Primary Responder** | Frontend SME | | **Last Updated** | \[Date] | | **Owner** | \[Name] | ### Identification #### Symptoms * [ ] Users report unexpected transaction requests * [ ] UI behaving differently than expected * [ ] Wallet drainer detected * [ ] Injected scripts in page source * [ ] DNS/domain issues * [ ] Community reports of phishing via official domain #### Attack Vectors | Vector | Signs | | ------------------ | ---------------------------- | | DNS hijack | Domain pointing to wrong IP | | CDN compromise | Malicious files served | | Dependency attack | npm/yarn package compromised | | Build pipeline | CI/CD compromise | | Hosting compromise | Files modified on server | ### Immediate Actions #### Step 1: Take Down or Redirect **Why:** Stop users from interacting with compromised site Options: * [ ] Point DNS to maintenance page * [ ] Disable CDN distribution * [ ] Remove site from hosting * [ ] Add banner/warning if partial control #### Step 2: Warn Users **Why:** Prevent further damage * [ ] Post on Twitter/X * [ ] Post in Discord/Telegram * [ ] Update status page Message template: > Our website may be compromised. Do NOT interact with \[domain] or approve any transactions until further notice. > Your funds in the protocol are safe if you don't sign new transactions. #### Step 3: Assess Scope * [ ] What was changed? * [ ] How long was it compromised? * [ ] How many users potentially affected? * [ ] Were any transactions signed? ### Investigation #### Priority: Identify Attack Vector The first priority is understanding how the attacker gained access so you can close that vector: * [ ] **How did attacker gain access?** (DNS, CDN, dependencies, CI/CD, hosting) Once identified, go to the specific runbook: * DNS hijack → [DNS Hijack](./dns-hijack) * CDN/hosting compromise → [CDN/Hosting Compromise](./cdn-hosting-compromise) * Dependency attack → [Dependency Attack](./dependency-attack) * Build pipeline compromise → [Build Pipeline Compromise](./build-pipeline-compromise) #### Post-Mitigation Investigation After the threat is contained, investigate impact: * [ ] What was injected/changed? * [ ] Which users interacted during compromise window? * [ ] What were users tricked into signing? #### Check These | Component | How to Check | | --------------- | ----------------------------- | | DNS records | `dig` or DNS provider console | | CDN files | Compare to known good | | Build artifacts | Check CI/CD logs | | Dependencies | `npm audit`, lockfile changes | | Hosting files | Compare to repo | ### Mitigation See the specific runbook for detailed mitigation steps: * [DNS Hijack](./dns-hijack) * [CDN/Hosting Compromise](./cdn-hosting-compromise) * [Dependency Attack](./dependency-attack) * [Build Pipeline Compromise](./build-pipeline-compromise) ### Recovery #### Before Restoring Service * [ ] Root cause identified * [ ] Vulnerability fixed * [ ] Fresh deployment from verified source * [ ] All credentials rotated * [ ] Additional security measures in place #### Restoring Service 1. Deploy verified build 2. Verify deployment matches expected 3. Test critical user flows 4. Monitor for anomalies 5. Announce service restored ### Affected User Support If users signed malicious transactions: * [ ] Compile list of affected addresses (from chain data) * [ ] Provide guidance on revoking approvals * [ ] Consider compensation if protocol at fault * [ ] Document for post-mortem ### Escalation * [ ] [Decision Makers](../contacts#decision-makers) - immediately * [ ] [Infrastructure Vendors](../contacts#infrastructure-vendors) - if hosting/CDN involved * [ ] [Legal & Communications](../contacts#legal--communications) - for user communication ### Prevention Checklist After resolving, review: * [ ] DNS provider security (2FA, lock) * [ ] Hosting access controls * [ ] CI/CD security * [ ] Dependency management * [ ] Subresource integrity * [ ] Content Security Policy ### Related * [DNS Hijack](./dns-hijack) * [CDN/Hosting Compromise](./cdn-hosting-compromise) * [Dependency Attack](./dependency-attack) * [Build Pipeline Compromise](./build-pipeline-compromise) * [DDoS Attack](./ddos-attack) * [Third-Party Outage](./third-party-outage) * [Incident Response Policy](../incident-response-policy) {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Runbooks > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Runbooks](/incident-management/incident-response-template/runbooks/overview) * [Runbook: Smart Contract Exploit](/incident-management/incident-response-template/runbooks/smart-contract-exploit) * [Runbook: Key Compromise](/incident-management/incident-response-template/runbooks/key-compromise) * [Runbook: Frontend Compromise](/incident-management/incident-response-template/runbooks/frontend-compromise) * [Runbook: DNS Hijack](/incident-management/incident-response-template/runbooks/dns-hijack) * [Runbook: CDN/Hosting Compromise](/incident-management/incident-response-template/runbooks/cdn-hosting-compromise) * [Runbook: Dependency Attack](/incident-management/incident-response-template/runbooks/dependency-attack) * [Runbook: Build Pipeline Compromise](/incident-management/incident-response-template/runbooks/build-pipeline-compromise) * [Runbook: DDoS Attack](/incident-management/incident-response-template/runbooks/ddos-attack) * [Runbook: Third-Party Outage](/incident-management/incident-response-template/runbooks/third-party-outage) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Runbook: Key Compromise > **This is an example runbook.** Review and customize for your protocol before use. Fill in your key types, what > each controls, and your specific rotation procedures. ### Quick Reference | Field | Value | | --------------------- | ------------ | | **Typical Severity** | P1 | | **Primary Responder** | Security SME | | **Last Updated** | \[Date] | | **Owner** | \[Name] | ### Identification #### Symptoms * [ ] Unauthorized transactions from controlled addresses * [ ] Unexpected multisig proposals * [ ] Key holder reports compromise * [ ] Suspicious signing activity * [ ] Social engineering attempt succeeded #### Key Types | Key Type | Risk Level | Controlled Assets | | --------------- | ----------- | ------------------- | | Deployer | \[High/Med] | \[What it controls] | | Admin/Owner | \[High/Med] | \[What it controls] | | Multisig signer | \[High/Med] | \[What it controls] | | Hot wallet | \[High/Med] | \[What it controls] | ### Immediate Actions #### Step 1: Confirm Compromise **Why:** Avoid false positives, but err on side of caution * [ ] Verify with key holder directly (not via potentially compromised channels) * [ ] Check for unauthorized transactions * [ ] Review recent signing activity #### Step 2: Assess Blast Radius **Why:** Understand what the attacker can do * [ ] What can this key sign? * [ ] Are there timelocks? * [ ] What other systems use this key? #### Step 3: Revoke/Rotate **Why:** Remove attacker access For multisig signers: * [ ] Remove compromised signer * [ ] Add replacement signer For admin keys: * [ ] Transfer ownership to new address * [ ] Or revoke permissions if possible For hot wallets: * [ ] Move remaining funds to secure address #### Step 4: Check for Damage **Why:** Understand if attacker acted * [ ] Review all transactions from compromised key * [ ] Check pending proposals/timelocks * [ ] Audit any systems key had access to ### Investigation #### Key Questions * [ ] How was the key compromised? (phishing, malware, insider, leaked) * [ ] When was it compromised? * [ ] What did the attacker do (if anything)? * [ ] Are other keys at risk? #### Evidence to Collect | Data | Source | | ------------------- | ------------------------ | | Transaction history | Block explorer | | Login/access logs | Infrastructure providers | | Signing requests | Multisig interface | | Communications | If social engineering | ### Mitigation by Key Type #### Multisig Signer 1. Propose removal of compromised signer 2. Collect required signatures 3. Execute removal 4. Add new signer 5. Verify new threshold is appropriate #### Contract Admin Key 1. Prepare ownership transfer transaction 2. Execute transfer to secure address 3. Verify new owner 4. Update documentation #### Hot Wallet 1. Prepare transaction to move all funds 2. Move to cold storage or new hot wallet 3. Update any systems using old address 4. Retire compromised address ### Escalation * [ ] [Decision Makers](../contacts#decision-makers) - immediately for any confirmed compromise * [ ] [Security Partners](../contacts#security-partners) - for investigation support * [ ] [Legal](../contacts#legal--communications) - if funds were stolen ### Prevention Checklist After resolving, review: * [ ] Key storage practices * [ ] Phishing awareness training * [ ] Hardware wallet usage * [ ] Multisig thresholds * [ ] Access logging * [ ] Key rotation schedule ### Related * [Smart Contract Exploit](./smart-contract-exploit) * [Incident Response Policy](../incident-response-policy) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Runbooks Step-by-step guides for specific incident types. Use these during active incidents to reduce cognitive load and ensure consistent response. > **These runbooks are examples and starting points.** They contain generic guidance that must be adapted to your > specific protocol, infrastructure, and team. Review each runbook carefully and customize the commands, contacts, > and procedures before relying on them during an actual incident. Untested runbooks can be worse than no runbook > at all. ### Available Runbooks #### Critical (P1) * [Smart Contract Exploit](./smart-contract-exploit) - Active exploit or critical vulnerability * [Key Compromise](./key-compromise) - Private key or signer compromise * [Frontend Compromise](./frontend-compromise) - Website/UI compromise (routes to specific runbooks below) * [DNS Hijack](./dns-hijack) - Domain/DNS compromise * [CDN/Hosting Compromise](./cdn-hosting-compromise) - CDN or hosting provider compromise * [Dependency Attack](./dependency-attack) - npm/package supply chain attack * [Build Pipeline Compromise](./build-pipeline-compromise) - CI/CD compromise #### High/Moderate (P2-P3) * [DDoS Attack](./ddos-attack) - Denial of service attacks * [Third-Party Outage](./third-party-outage) - External provider issues ### Creating New Runbooks Use [Runbook Template](../templates/runbook-template) as your starting point. Good runbooks: * Are concise. Responders need quick answers * Include actual commands and links * Get tested in tabletop exercises * Get updated after real incidents ### Suggested Runbooks to Add Consider creating runbooks for: * [ ] Oracle manipulation * [ ] Governance attack * [ ] SSL certificate issues * [ ] Deployment failure/rollback * [ ] Data inconsistency *See [Incident Response Policy](../incident-response-policy) for the overall response process.* import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Runbook: Smart Contract Exploit > **This is an example runbook.** Review and customize for your protocol before use. Fill in the placeholder > commands, add your specific contracts and addresses, and test during a tabletop exercise. ### Quick Reference | Field | Value | | --------------------- | ------------------ | | **Typical Severity** | P1 | | **Primary Responder** | Smart Contract SME | | **Last Updated** | \[Date] | | **Owner** | \[Name] | ### Identification #### Symptoms * [ ] Unexpected fund movements * [ ] On-chain monitoring alerts * [ ] Unusual transaction patterns * [ ] Community reports of lost funds * [ ] Abnormal contract state changes #### Alerts * \[Your on-chain monitoring tool] * \[Blockchain explorer alerts] #### Differentiation * If funds moving to known addresses (multisig, treasury) → likely authorized * If single user affected → might be phishing, not protocol exploit * If UI shows wrong values but chain is correct → frontend issue ### Immediate Actions #### Step 1: Assess Scope **Why:** Understand what's at risk before acting * [ ] Check total funds at risk * [ ] Identify affected contracts * [ ] Determine if exploit is ongoing #### Step 2: Contact SEAL 911 **Why:** Get immediate expert support for active exploits See [SEAL 911](../contacts#seal-911) #### Step 3: Pause if Possible **Why:** Stop the bleeding If your contracts have pause functionality: ``` [Document your pause procedure here] ``` **If no pause function:** Consider other containment options (front-running, rescue operations). #### Step 4: Preserve Evidence **Why:** Needed for investigation and potential recovery * [ ] Screenshot/save relevant transactions * [ ] Note block numbers * [ ] Save mempool data if available * [ ] Document attacker addresses ### Investigation #### Key Questions * [ ] What vulnerability was exploited? * [ ] How much was taken/at risk? * [ ] Is the exploit still possible? * [ ] Are other contracts affected? * [ ] Was this reported via bug bounty first? #### Information to Gather | Data | Source | | --------------------- | ----------------- | | Exploit transactions | Block explorer | | Attacker addresses | On-chain analysis | | Vulnerability details | Code review | | Affected user count | Contract state | ### Mitigation #### Option A: Pause Contracts **When:** Pause functionality exists **Impact:** Users cannot interact until unpaused 1. Execute pause function 2. Verify pause is effective 3. Communicate to users #### Option B: Emergency Upgrade **When:** Upgrade mechanism exists **Impact:** Requires governance or multisig action 1. Prepare patched contract 2. Execute upgrade 3. Verify fix #### Option C: Rescue Operation **When:** Funds can be moved to safety before attacker **Impact:** Complex, requires coordination 1. Coordinate with security researchers 2. Prepare rescue transactions 3. Execute with proper sequencing ### Escalation Contact immediately: * [ ] [Decision Makers](../contacts#decision-makers) * [ ] [Security Partners](../contacts#security-partners) * [ ] [Legal](../contacts#legal--communications) if significant fund loss ### Post-Exploit * [ ] Determine fix approach * [ ] Plan for affected users (if any) * [ ] Prepare public communication * [ ] Consider disclosure timeline * [ ] Engage with law enforcement if appropriate ### Common Root Causes | Cause | Signs | Prevention | | ------------------- | ------------------------------ | ------------------------------ | | Reentrancy | Recursive calls in tx | CEI pattern, reentrancy guards | | Access control | Unauthorized caller | Proper modifiers | | Oracle manipulation | Price deviation before exploit | TWAP, multiple sources | ### Related * [Key Compromise](./key-compromise) * [Incident Response Policy](../incident-response-policy) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../../components' ## Runbook: Third-Party Outage > **This is an example runbook.** Review and customize for your protocol before use. Fill in your specific vendors, > dependencies, and failover procedures. ### Quick Reference | Field | Value | | --------------------- | ------------------ | | **Typical Severity** | P2-P3 | | **Primary Responder** | Infrastructure SME | | **Last Updated** | \[Date] | | **Owner** | \[Name] | ### Identification #### Symptoms * [ ] Specific functionality broken * [ ] Errors referencing external service * [ ] Status page shows provider outage * [ ] Timeouts to external endpoints #### Common Dependencies | Service Type | Provider(s) | Criticality | Fallback? | | ------------ | ----------- | --------------------- | --------- | | RPC | | Critical / High / Med | Yes / No | | Hosting | | | | | CDN | | | | | DNS | | | | | Monitoring | | | | | Auth | | | | | Oracle | | | | ### Immediate Actions #### Step 1: Confirm Third-Party Issue **Why:** Verify it's not your own infrastructure * [ ] Check provider status page * [ ] Test provider directly * [ ] Check if other users reporting (Twitter, Discord) #### Step 2: Assess Your Impact * [ ] Which of your services affected? * [ ] What functionality is degraded/broken? * [ ] User-facing impact? #### Step 3: Enable Fallback (if available) * [ ] Switch to backup provider * [ ] Enable cached/degraded mode * [ ] Disable affected features gracefully ### By Service Type #### RPC Provider Outage **Fallback options:** 1. Switch to secondary RPC 2. Use public endpoints temporarily 3. Run own node if available ``` [Document your RPC failover procedure] ``` #### Hosting/CDN Outage **Fallback options:** 1. Failover to secondary hosting 2. Enable maintenance page 3. Redirect to status page #### Oracle Outage **Impact:** Price feeds may be stale or unavailable **Options:** 1. Pause affected operations > Customize this section for your specific oracle dependencies and what operations depend on them. ### Communication #### Internal * Update team on status * ETA if known * What's affected #### External If significant user impact: > We're experiencing issues with \[affected feature] due to a third-party service outage. We're monitoring and will > restore service when the provider recovers. Include: * What's affected * What still works * Where to check for updates ### Monitoring the Outage * [ ] Subscribe to provider status updates * [ ] Set reminder to check every 15-30 min * [ ] Monitor your own metrics for recovery ### Recovery #### When Provider Recovers 1. Verify your services are working 2. Check for any data inconsistencies 3. Monitor for stability 4. Switch back from fallback if used #### Post-Outage * [ ] Document timeline * [ ] Review if fallback worked * [ ] Assess if additional redundancy needed * [ ] Consider SLA review with provider ### Escalation * [ ] [Infrastructure Vendors](../contacts#infrastructure-vendors) - contact provider support * [ ] [Decision Makers](../contacts#decision-makers) - if extended outage or no ETA ### Prevention Reduce third-party dependency risk: * [ ] Multiple RPC providers * [ ] Multi-region hosting * [ ] CDN with failover * [ ] Graceful degradation * [ ] Cached fallbacks where appropriate * [ ] Regular dependency review ### Provider Contacts | Provider | Status Page | Support Contact | | -------- | ----------- | --------------- | | | | | | | | | ### Related * [DDoS Attack](./ddos-attack) * [Incident Response Policy](../incident-response-policy) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Access Management Best Practices Effective access management involves ensuring that users have the right access, at the right time, and that access is promptly revoked when no longer needed. Implementing access management practices helps prevent unauthorized access, and reduces the risk of insider threats. ### Practices for Access Management * **Just-In-Time Access**: Implement just-in-time (JIT) access to provide users with temporary access when needed. This minimizes the risk of long-term access being misused. * **Timely Access Revocation**: Ensure that access is revoked in a timely manner for users who are no longer part of the organization or whose roles within the project have changed. * **Access Reviews**: Conduct regular access reviews to ensure that team members have appropriate access based on their current functions. * **On-boarding and Off-boarding Processes**: Establish clear processes for on-boarding new team members and off-boarding departing team members to ensure that access is granted and revoked as appropriate. * **Access Logging and Monitoring**: Implement logging and monitoring of access to critical services to detect and respond to unauthorized access attempts. ### Best Practices for Access Management 1. Grant users the minimum access necessary to perform their job functions. 2. Ensure that critical tasks require multiple users to perform them, reducing the risk of misuse. 3. When possible, use automated tools to manage access provisioning and revocation based on user lifecycle events. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Iam > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Identity and Access Management](/iam/overview) * [Role-Based Access Control](/iam/role-based-access-control) * [Secure Authentication](/iam/secure-authentication) * [Access Management](/iam/access-management) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Identity and Access Management (IAM) Identity and Access Management (IAM) is defined as managing who has access to your systems and data, and ensuring that access is secure and appropriate. Effective IAM practices help prevent unauthorized access, reduce the risk of insider threats, and ensure that users have the necessary access to perform their roles efficiently. ### Contents 1. [Role-Based Access Control (RBAC)](/iam/role-based-access-control) 2. [Secure Authentication](/iam/secure-authentication) 3. [Access Management Best Practices](/iam/access-management) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Role-Based Access Control (RBAC) Role-Based Access Control (RBAC) is a method of regulating access to systems and data based on the roles assigned to individual users within a project. RBAC ensures that users have the minimum access necessary to perform their job functions, reducing the risk of unauthorized access. ### Key Principles of RBAC * **Role Definition**: Clearly define roles within the project based on the team member's job responsibility. Each role should have a specific set of permissions, for example a community manager could potentially not require administrative permissions to the project's github repository. * **Role Assignment**: Assign roles to team members based on their job responsibilities. Ensure that users only have access to the resources they need. * **Permission Management**: Regularly review and update role permissions to ensure they are aligned with current team functions and security requirements. * **Separation of Duties**: Implement separation of duties to prevent conflicts of interest and reduce the risk of threats. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Secure Authentication Secure authentication is essential for verifying the identity of team members and ensuring that only authorized individuals have access. By implementing strong authentication mechanisms you can protect your project against unauthorized access and lower the risk for potential security breaches. ### Key Authentication Methods * **Multi-Factor Authentication (MFA)**: Require multiple forms of verification (e.g., something you know, something you have, something you are) to enhance security. It is strongly suggested that one does not use SMS as a form of multi-factor authentication, but instead utilizes hardware tokens such as Yubikeys. * **Single Sign-On (SSO)**: Enable SSO in services you use to allow team members to authenticate once and gain access to multiple systems without re-entering credentials, but make sure that the account connected to SSO is secured by strong Multi-Factor Authentication. * **Password Management**: Enforce strong password policies and encourage the use of password managers to generate and store complex passwords. ### Best Practices for Secure Authentication 1. Require MFA for all team members, especially for accessing sensitive systems and data. Encourage the use of hardware tokens (e.g., Yubikeys) over SMS-based MFA. 2. Implement monitoring and alerting for suspicious authentication attempts, such as repeated failed logins or logins from unusual locations. 3. Provide training on secure authentication practices and the importance of protecting authentication credentials. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Guides > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Guides](/guides/overview) * [Account Management](/guides/account-management) * [Endpoint Security](/guides/endpoint-security) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Guides This section contains practical, step-by-step guides that help you implement security best practices across various platforms and tools. Each guide provides actionable instructions you can follow to secure your operations. ### Available Guide Categories #### [Account Management](/guides/account-management/overview) Comprehensive guides for securing your accounts across communication platforms, DevOps tools, and business applications. These guides cover: * **Communication Platforms** - Discord, Telegram, Twitter/X, Signal, Slack * **DevOps & Infrastructure** - GitHub, GoDaddy, Render, Sentry, Vercel * **Business Tools** - Linear, Mercury, Notion, Trello Each account management guide includes security checklists for individuals, team members, and administrators. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Hardware Security Keys ### Summary > 🔑 **Key Takeaway for Hardware Security Keys:** Use FIDO2/WebAuthn security keys on high-value accounts, register > at least two keys per critical account, disable SMS fallback where possible, and test recovery before you need it. Hardware security keys are one of the strongest practical defenses against phishing, credential stuffing, and SIM-swap-based account takeovers. They are especially valuable for email, source control, registrars, cloud platforms, social accounts, and any admin or financial account that could be used to pivot into the rest of your organization. This guide focuses on YubiKeys and similar FIDO2/WebAuthn hardware keys. ### For Individuals These steps apply to personal and work accounts that support FIDO2/WebAuthn security keys or passkeys stored on a hardware key. #### Setup Checklist * [ ] Buy at least **two** security keys from a reputable vendor such as Yubico * [ ] Prefer keys that match your device mix: * USB-C for modern laptops and phones * NFC if you regularly authenticate on mobile * [ ] Label one key **Primary** and the other **Backup** * [ ] Register both keys on every critical account that supports them: * Primary email * GitHub and code hosting * Registrar and DNS providers * Cloud and deployment platforms * Banking, custody, or treasury accounts * Social and communication accounts * [ ] Where offered, prefer: * **Security key** * **Passkey on hardware key** * Other phishing-resistant WebAuthn/FIDO2 options * [ ] Disable **SMS** as a recovery or second-factor method wherever the service allows it * [ ] Save provider-issued backup or recovery codes offline * [ ] Test both the primary and backup key after enrollment #### YubiKey Setup Notes * Register both your primary and spare YubiKeys during the same setup session whenever the service allows it * Set a PIN on the YubiKey or FIDO2 credential where the workflow supports it, and store that PIN separately from the key itself * If your YubiKey supports NFC and it is new, activate NFC before you rely on it for mobile logins * Prefer the service's **Security key** or **Passkey** option on a YubiKey over app-based OTP when phishing-resistant login is available * If a service only supports authenticator-app codes, Yubico Authenticator can keep those codes tied to the YubiKey, but treat that as a fallback rather than equivalent protection to WebAuthn security-key login #### Practical Use * Keep the **Primary** key with you for normal logins * Store the **Backup** key in a separate secure location, not in the same bag or drawer * Maintain a short note in your password manager listing which critical accounts have which keys enrolled * For high-value accounts, avoid storing passkeys in a password manager; keep them on the hardware key or another dedicated phishing-resistant authenticator instead * If a service allows multiple authentication methods, avoid leaving weaker fallback paths enabled unless they are operationally necessary * Replace lost or damaged keys immediately and re-test the remaining enrolled key #### Recovery Discipline * Do not wait until you lose a key to learn how account recovery works * If you lose your only key and do not have a second enrolled key or a usable recovery path, you can lock yourself out of critical accounts at the moment you most need them * Verify that your recovery path does not depend on a phone number if you are trying to reduce SIM-swap risk * If an account only supports app-based MFA or SMS, record that exception clearly and prioritize moving the account to a stronger provider or stronger configuration when possible ### Further Reading * [Opsek YubiKeys Cheatsheet](https://github.com/Opsek/Yubikeys-cheatsheet) * [Yubico Setup Guide](https://www.yubico.com/setup/) * [Yubico: YubiKey Authenticator](https://www.yubico.com/products/yubico-authenticator/) {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Endpoint Security > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [SSH Client and Key Management Hardening](/guides/endpoint-security/ssh-client-and-key-management-hardening) * [Hardware Security Keys](/guides/endpoint-security/hardware-security-keys) * [Password Manager Endpoint Hardening](/guides/endpoint-security/password-manager-endpoint-hardening) * [Zoom Hardening Guide](/guides/endpoint-security/zoom-hardening) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Password Manager Endpoint Hardening ### Summary > 🔑 **Key Takeaway:** Encrypt every device that can unlock your vault, lock it quickly, keep it updated, use > phishing-resistant MFA on the password manager account, minimize browser and clipboard exposure, and rehearse > recovery before an incident. A password manager concentrates access to many critical accounts, so the device and browser that can unlock it deserve extra hardening. ### For Individuals #### Minimum Device Baseline * [ ] Use only supported, regularly updated operating systems and browsers * [ ] Enable full-disk encryption on every device that can access the vault * [ ] Require a real screen lock with a 5-minute-or-less idle timeout and password on wake * [ ] Enable device location, remote lock, and remote wipe features before you need them * [ ] Keep the password manager set to lock on sleep, device lock, and browser or app exit #### Safer Browser and Vault Usage * [ ] Use a dedicated browser profile for work or other high-value accounts * [ ] Keep that profile minimal: ideally only the password manager extension, and otherwise a short allowlist of extensions you actively need and trust * [ ] Prefer user-initiated fill over broad automatic fill on page load * [ ] Verify the domain before filling credentials for high-impact accounts such as registrars, GitHub, cloud, finance, or admin panels * [ ] Avoid logging into the work vault from throwaway browsers, borrowed devices, or lightly managed systems #### Clipboard and Copy/Paste Hygiene * [ ] Prefer direct fill into the browser or app instead of copying secrets to the clipboard * [ ] Disable clipboard history and cross-device clipboard sync on endpoints used for sensitive workflows * [ ] If you must copy a secret, paste it immediately and clear the clipboard or rely on the password manager's auto-clear setting if supported #### Protecting the Password Manager Account * [ ] Use phishing-resistant MFA such as FIDO2/WebAuthn security keys where supported * [ ] For highest-risk operators, prefer hardware security keys over broadly syncable authenticators when possible * [ ] Keep at least two recovery-capable authenticators enrolled * [ ] Do not rely on SMS as the primary recovery or second-factor method * [ ] Store recovery codes or emergency-kit material offline and separately from the device * [ ] Avoid circular dependency: do not make the only copy of recovery material depend on access to the same vault ### Web3-Specific Operational Rules Password managers in Web3 often gate access to registrars, code hosting, cloud, and finance systems. Treat the endpoints that can unlock the vault accordingly. * Use a separate browser profile, and ideally a separate device, for the highest-risk admin workflows * Prefer hardware security keys for the password manager account and highest-impact downstream services * Never store wallet seed phrases, private keys, or recovery phrases in a password manager, browser storage, or notes app * If an endpoint used for registrar, GitHub, cloud, or finance access looks compromised, rotate those credentials first ### Lost or Stolen Device Response Use these steps if a device with possible vault access is lost, stolen, or suspected compromised: 1. Lock, mark lost, or wipe the device as quickly as possible. 2. Revoke the device or active sessions from the password manager or identity provider if the product supports it. 3. Change the password manager account password and review enrolled MFA methods. 4. If the vault may have been exposed, rotate the highest-risk downstream credentials first. 5. Replace recovery material and backup authenticators if their custody is uncertain. If you cannot confirm the vault was locked at the time of loss, treat exposed credentials as the default assumption and rotate accordingly. ### Further Reading * [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-4/) * [CISA: Implementing Phishing-Resistant MFA](https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a) * [NCSC: Password Managers](https://www.ncsc.gov.uk/collection/top-tips-for-staying-secure-online/password-managers) * [Apple: Protect Data on Your Mac with FileVault](https://support.apple.com/guide/mac-help/protect-data-on-your-mac-with-filevault-mh11785/mac) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## SSH Client and Key Management Hardening ### Summary > 🔑 **Key Takeaway for SSH Client and Key Management Hardening:** Use dedicated SSH keys for distinct purposes, > prefer Ed25519 for new software keys, use hardware-backed `*-sk` keys for higher-risk access where practical, > protect keys with passphrases, keep agent forwarding off by default, and maintain a simple revoke-and-reissue plan > for lost devices or role changes. SSH is often the path from a developer laptop into code hosting, CI/CD, bastions, and production infrastructure. Treat SSH keys as privileged access. ### For Individuals These steps apply to developers, operators, admins, and contributors who use SSH from a local workstation. #### Setup Checklist * [ ] Use **Ed25519** for new software keys by default * [ ] Add a **strong passphrase** to every human-held software key * [ ] For higher-risk access, prefer a **hardware-backed security-key SSH credential** such as `ed25519-sk` * [ ] Keep separate keys for: Git hosting, staging/internal infrastructure, production/bastion access, and automation * [ ] Keep `ForwardAgent no` unless there is a specific and reviewed operational need * [ ] Use explicit per-host entries in `~/.ssh/config` with `IdentityFile` and `IdentitiesOnly yes` * [ ] Keep `StrictHostKeyChecking` enabled: use `accept-new` only for lower-risk hosts where trust-on-first-use is acceptable, and use `yes` for bastions and production systems where host verification should be explicit * [ ] Use `UpdateHostKeys yes` only for hosts you already trust and manage, especially where you expect planned key rotation * [ ] Keep `~/.ssh` and private key files accessible only to you * [ ] Review and remove stale keys after device loss, role changes, or offboarding #### Passphrases and Local Protection * Use a passphrase on every human-held software key * Avoid leaving sensitive keys loaded into an agent indefinitely * Prefer confirmation or time-limited agent loading for sensitive keys * Do not store private keys in cloud notes, chat, or shared drives * Avoid copying the same private key between multiple laptops or admin workstations #### `~/.ssh/config` Hygiene Keep `~/.ssh/config` explicit and purpose-specific so your SSH client offers only the intended key to each service. * Use per-host entries with `IdentityFile` and `IdentitiesOnly yes` * Keep `ForwardAgent no` unless there is a reviewed exception * Use stricter host verification for bastions and production hosts than for low-risk systems #### Agent Forwarding and Remote Risk Treat agent forwarding as an exception, not a default workflow. * Keep `ForwardAgent no` by default * Never use `Host *` with `ForwardAgent yes` * Prefer `ProxyJump`, a bastion pattern, or a purpose-specific key on the intermediary host instead Agent forwarding lets a remote system use your loaded identities for as long as the session is live, so it is a poor default for weakly trusted systems. #### Host Verification and `known_hosts` Do not normalize `StrictHostKeyChecking no` or "just click through" behavior for host key changes. * Verify important host fingerprints from official documentation when available * Use `accept-new` only where trust-on-first-use is acceptable for the environment * Use `yes` for bastions, production systems, and other high-sensitivity hosts * Do not rely on `accept-new` for first contact with high-sensitivity systems * Preseed `known_hosts` for CI and automation from a trusted source instead of discovering keys live in the job * Investigate unexpected host key changes instead of bypassing the warning #### File Permissions and Device Hygiene * On Unix-like systems, use `chmod 700 ~/.ssh` * Use `chmod 600` for private keys and for `~/.ssh/config` * On Windows, keep private keys readable only by your user account and administrators If a laptop is lost, stolen, or suspected compromised, assume the SSH material on it may also need to be revoked and reissued. ### For Admins These practices apply to administrators responsible for issuing, reviewing, rotating, and revoking SSH access across a team. #### Program Checklist * [ ] Maintain an inventory for each SSH credential: owner, device, purpose, target systems, creation date, and revoke trigger * [ ] Require one key per person, device, and purpose instead of shared identities * [ ] Prefer hardware-backed SSH credentials for privileged production access where practical * [ ] Review account SSH keys, deploy keys, and automation keys on a regular cadence * [ ] Remove unknown, stale, or unapproved keys during access reviews * [ ] Revoke keys immediately after offboarding, device loss, or suspected compromise * [ ] Keep human access and automation access logically separate * [ ] Document a simple recovery and reissue process for lost devices and security keys #### Git Hosting, CI/CD, and Automation * Human users should have account-level SSH keys with clear labels * CI/CD and deployment systems should use dedicated automation credentials, not a developer's personal laptop key * Review deploy keys carefully because they are often long-lived and easy to forget * Revoke and reissue keys promptly after device loss, offboarding, or suspected compromise #### Higher-Maturity Option: SSH Certificates For larger teams or higher-sensitivity environments, consider using SSH certificates instead of managing long-lived authorized keys on each target system. With SSH certificates, a trusted internal certificate authority (CA) signs user or host keys for a limited period of time. This can make access management easier by allowing teams to: * Issue short-lived SSH access without distributing permanent keys to every host * Centralize approval, expiration, and revocation workflows * Reduce the operational burden of updating `authorized_keys` across many systems * Tie SSH access more closely to role, device, or incident-response requirements SSH certificates introduce their own operational complexity and should be implemented carefully, but they are worth evaluating for organizations that need stronger central control over SSH access. ### Web3-Specific Operational Rules Use these rules consistently: 1. Do not use the same SSH key for Git hosting, deploy systems, and production administration. 2. Treat bastion, production, and incident-response SSH access as privileged and higher assurance. 3. Keep agent forwarding off unless there is a reviewed exception. 4. Investigate host key changes before reconnecting to important systems. 5. Revoke and replace SSH keys immediately after device loss or admin-role changes. 6. Keep automation credentials separate from human workstation credentials. ### Further Reading * [NIST IR 7966: Security of Interactive and Automated Access Management Using Secure Shell (SSH)](https://csrc.nist.gov/pubs/ir/7966/final) * [OpenBSD `ssh_config(5)`](https://man.openbsd.org/ssh_config) * [OpenBSD `ssh-keygen(1)`](https://man.openbsd.org/ssh-keygen.1) * [OpenBSD `ssh-add(1)`](https://man.openbsd.org/ssh-add.1) * [GitHub: Generating a New SSH Key and Adding It to the SSH Agent](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) * [GitHub: Reviewing Your SSH Keys](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-ssh-keys) * [GitHub: GitHub's SSH Key Fingerprints](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints) * [GitLab: SSH Keys](https://docs.gitlab.com/user/ssh/) * [GitLab: Using SSH Keys with GitLab CI/CD](https://docs.gitlab.com/ci/jobs/ssh_keys/) * [Microsoft Learn: OpenSSH Key Management on Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Zoom Hardening Guide > 🔑 **Key Takeaway**: Zoom's remote control and accessibility features are active attack vectors. > Disable remote control, use browser-based Zoom when possible, deploy PPPC profiles on macOS, > and train users to reject unexpected permission requests. ### Why Zoom is a target Zoom's **remote control** feature allows a participant to request full control of another user's computer once screen sharing is active. Threat actors social-engineer victims into sharing their entire screen, then request remote control to install malware and exfiltrate credentials, private keys, and session tokens. The most prominent example is **ELUSIVE COMET** — a threat actor impersonating investors, journalists, and podcast hosts to lure crypto holders onto Zoom calls, pressure them into full-screen sharing (claiming audio/video issues), then take over their machine via remote control. If already compromised, see the [ELUSIVE COMET incident response playbook](/incident-management/playbooks/hacked-elusive-comet). ### Immediate hardening steps Apply these settings in the [Zoom web portal](https://zoom.us/profile/setting). Sign in, click **Settings** in the left sidebar, then navigate to the **Meeting** tab. #### Required These mitigations address the specific attack vectors described in the Trail of Bits ELUSIVE COMET research and should be treated as **non-negotiable** for any organization handling sensitive assets. * [ ] **Disable remote control**: Settings > Meeting > In Meeting (Basic) > Remote control > **OFF** * [ ] **Disable participant screen sharing (host only)**: Settings > Meeting > In Meeting (Basic) > Screen sharing > Who can share? > **Host Only** * [ ] **Never grant Zoom accessibility permissions (macOS)**: If Zoom prompts for accessibility access, **deny it**. These permissions let remote control interact with your entire system. * [ ] **Prefer browser-based Zoom**: Join via `zoom.us/join` instead of the desktop client. No remote control capability, no accessibility permissions. * [ ] **Use SSO/OAuth authentication**: Use SSO or OAuth instead of Zoom-native accounts for centralized credential management and MFA. * [ ] **Deploy PPPC profiles / revoke TCC permissions (macOS)**: See [macOS mitigations](#macos-specific-mitigations) below. * [ ] **Remove Zoom desktop client when possible**: Uninstall entirely to eliminate the attack surface. #### Optional General Zoom security best practices. These do not directly mitigate the ELUSIVE COMET attack but improve overall meeting security hygiene. * [ ] **Enable waiting rooms**: Settings > Meeting > Security > Waiting Room > **ON** * [ ] **Require meeting passcodes**: Settings > Meeting > Security > Require a passcode when scheduling new meetings > **ON** * [ ] **Disable automatic recording**: Settings > Meeting > Recording > Automatic recording > **OFF** (enable only when explicitly needed) ### macOS-specific mitigations macOS TCC governs per-app accessibility permissions. Trail of Bits published scripts to lock this down: #### Revoke existing Zoom accessibility permissions If Zoom already has accessibility access, revoke it immediately: ```bash # Revoke Zoom's accessibility permissions via tccutil tccutil reset Accessibility us.zoom.xos ``` Verify removal in **System Settings > Privacy & Security > Accessibility** — Zoom should no longer appear or should be toggled off. #### Deploy PPPC profiles to block accessibility requests PPPC profiles block Zoom from receiving accessibility permissions even if a user clicks "Allow." Deploy fleet-wide via MDM/Jamf or manually via `profiles`/Apple Configurator. #### Complete Zoom uninstallation All macOS mitigation scripts (PPPC profiles, tccutil, uninstall) are available at: [Trail of Bits — Zoom mitigations](https://github.com/trailofbits/it-releases/tree/main/Zoom%20migitations) ### Organizational policies For teams, DAOs, and organizations handling sensitive assets: #### Prefer alternative meeting platforms for sensitive discussions Use **Google Meet**, **Jitsi**, or other browser-native platforms for calls involving treasury operations, key ceremonies, or sensitive governance decisions. These platforms do not have a remote control feature. #### Enforce browser-based Zoom when Zoom is required If a counterparty insists on Zoom, join through the browser (`zoom.us/join`). The web client lacks the remote control feature entirely and cannot request accessibility permissions. #### Regularly purge the Zoom desktop client Remove the desktop client where not required. On managed fleets, use MDM to block installation. #### Social engineering awareness training Train all team members on the remote control attack pattern: 1. Attacker schedules a Zoom call (often posing as an investor, journalist, or partner). 2. Attacker pressures victim to share their **entire screen** (not just a window). 3. Attacker (or a bot named "Zoom") requests remote control access. 4. Victim approves the request, and the attacker installs malware. > **If a meeting participant asks you to share your screen and then requests remote control, > END THE CALL IMMEDIATELY.** This is the single most effective defense. #### Meeting hygiene policies * Only the host should share their screen by default. * Never share your entire screen — share a specific window if you must. * Do not join meetings from unknown or unsolicited links without verifying the organizer's identity through a separate channel. ### Detection signals Red flags during a Zoom call that suggest an attack in progress: | Signal | Why it matters | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | Asked to share your **entire screen** (not a specific window) | Remote control only works when the full screen is shared | | A participant named **"Zoom"** appears in the call | ELUSIVE COMET uses a bot with this display name to send the remote control request | | A **remote control request** dialog appears | Legitimate meetings almost never require remote control | | Urgency pressure: *"I can't see/hear you, you need to share your whole screen"* | Social engineering tactic to get full-screen access | | Request from unknown **"investors"** or **"journalists"** for a Zoom call | Common ELUSIVE COMET pretext — verify identity through independent channels before joining | | Zoom suddenly requests **accessibility permissions** on macOS | Indicates an attempt to enable remote control capabilities | **Response:** Do not approve any request. Leave the call immediately. If compromised, follow the [ELUSIVE COMET playbook](/incident-management/playbooks/hacked-elusive-comet). ### Further reading * [Trail of Bits — Zoom mitigations (PPPC profiles, tccutil scripts, uninstall scripts)](https://github.com/trailofbits/it-releases/tree/main/Zoom%20migitations) * [ELUSIVE COMET incident response playbook](/incident-management/playbooks/hacked-elusive-comet) — what to do if you've already been compromised * [SEAL Advisories](https://securityalliance.org) — ongoing threat intelligence for the crypto ecosystem * [Zoom Security Settings documentation](https://support.zoom.us/hc/en-us/articles/360043150271-Zoom-security-settings) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Discord Security ### Summary > 🔑 **Key Takeaway for Discord:** To secure your Discord server, focus on implementing robust access controls and > enforcing two-factor authentication for all administrators. Regularly audit roles and permissions, and maintain > vigilant moderation. Educate your community about security best practices to prevent unauthorized access and protect > against potential threats. Discord offers a variety of security features that are essential to use. Despite these, users should stay alert to threats like phishing, which can target server moderators. Such threats may appear as QR code scams, fake login screens, or misleading direct messages pretending to be from Discord support. To enhance the security of your Discord server, take into account these suggestions. They cover important aspects like server settings, roles and permissions, moderation, bots, channels, invites, member screening, logging, and other security measures. *** ### For Individuals These settings apply to your personal Discord account. All team members, moderators, and admins should configure these on their own accounts. #### Account Security Checklist * [ ] User Settings > My Account: Ensure **2FA** is enabled (authenticator app and/or security key), Remove a phone number if you have one added to your account, and after 2FA is setup select **View Backup Codes**, and note down your backup codes offline * [ ] User Settings > My Account: Ensure **SMS Backup Authentication** is **disabled** * [ ] User Settings > Content & Social > Social Permissions: Allow DMs from other server members > **Disabled** * [ ] User Settings > Content & Social > Direct Message Spam: Select **Filter all** to filter all DMs for spam (encourages moderators and community members to adopt the same setting to minimize phishing DMs) * [ ] User Settings > Authorized Apps: Review and **Deauthorize** any unnecessary apps * [ ] User Setting > Devices: Review and remove unnecessary devices, or **Log Out All Known Devices** * [ ] User Settings > Connections: Review and remove any unnecessary connections *** ### For Team Members These guidelines apply to moderators and team members who help manage the server but don't have full administrative access. Team members should: * Understand the permissions their role grants using **Server Settings > Roles > View Server as Role** — this allows you to see what members with a certain role can see and access * Be aware of the server's AutoMod rules for: Spam, Harmful Links, Mention Spam, Inappropriate Words, and any custom keyword filters and exempted roles *** ### For Admins These settings and practices apply to server administrators with elevated privileges. #### Server Settings Checklist ##### Safety Setup * Safety Setup > Moderation: * [ ] Require 2FA for moderation > **Enabled** * This ensures all moderators have an extra layer of security * Safety Setup > Verification Level: * [ ] Choose from: None, Low, Medium, High, Highest * [ ] Set to at least **Medium** (registered on Discord for 5+ minutes) — Recommended: "Moderate" for public servers * Higher levels protect against spammers and raids * Safety Setup > Raid Protection and CAPTCHA: * [ ] Activate all relevant settings to require CAPTCHA for new user actions * [ ] Activity Alerts > **Enabled** * [ ] CAPTCHA suspicious accounts before they are able to join > **Enabled** * [ ] CAPTCHA all accounts before they are able to join during a suspected raid > **Enabled** * This protection uses machine learning to detect and block bot-driven join-raids. When activated, it sends alerts to a specified channel and requires CAPTCHA verification for new users for one hour after detection. * Safety Setup > DM and Spam Protection: * [ ] Hide DMs from suspicious users > **Enabled** * [ ] Filter DMs from unknown users > **Enabled** * [ ] Warn members before they visit outbound links > **Enabled** * [ ] Hide all messages from and delete suspected spammers > **Enabled** ##### AutoMod * Server Settings > Safety Setup > AutoMod: * [ ] Set up rules for: **Spam**, **Harmful Links**, **Mention Spam**, **Inappropriate Words** * [ ] Configure custom keyword filters and exempted roles * [ ] Customize the response to spam (block message, send alert, timeout member) * [ ] Add to the existing automod rule to block keywords in a user's name: Support, Bot, Admin, Tech, Helpdesk, etc. * [ ] Create a private channel that mods, team, and admins have visibility to and set each AutoMod rule to send logs to that channel for review ##### Server Overview * Server Settings > Engagement > Default Notification Settings: Select **Only @mentions** * Reduces potential spam notifications for members, making them more vigilant about suspicious or phishing content ##### Roles * Server Settings > Roles: * [ ] Review admin role members — high-privilege roles with **Administrator** permission should have **2-3 members max** * [ ] Review bot role permissions and confirm members list contains only the bot user * [ ] Review mod role permissions and members list * [ ] Review user role permissions — watch for: **Manage Channels**, **Manage Roles**, **Manage Webhooks**, **Manage Server**, **Administrator** * [ ] Remove any lingering or overly broad permissions, and any roles with excess or unintended members * [ ] Check channel-level permission overrides on private channels > **Note on Role Permissions:** For each role, carefully review the 32 available permissions. Key permissions to > restrict: Administrator, Manage Webhooks, Manage Server, Manage Roles, & Manage Channels. Never give Admin or Kick > permissions to anyone you don't fully trust. > > **Administrator** should ideally be reserved for a single admin role with minimal members. It is recommended to have > no more than 2-3 admins with this privilege in order to reduce risk due to account compromise and insider threats, > but to retain some redundancy. > > Minimal bots actually need **Administrator** permissions. Review what permissions a bot actually needs and do not > default to Admin permissions just because developers request it as the easy option. If a bot does require > Administrator, mitigate this risk by monitoring the Discord audit logs frequently or create alerts on a private > channel to notify when admin permissions are exercised within the server. > > Permissions can also be set at the channel level. It is important to check your private channels for any permission > overrides that may have been set! ##### Integrations * Server Settings > Integrations: * [ ] Review each bot's permissions and remove unnecessary permissions * [ ] Remove any unnecessary integrations & reevaluate necessity of integrations with excessive permissions * Server Settings > Integrations > Manage Bot/App > **Roles & Members** / **Channels**: * [ ] Remove permissions for bots that ask for Admin or other permissions that aren't needed — use least privilege with permissions at the role level and channel level * [ ] Uninstall any bots that aren't actively used or needed * [ ] Confirm all bots and apps are [**Verified**](https://support-dev.discord.com/hc/en-us/articles/23926564536471-How-Do-I-Get-My-App-Verified) * [ ] Restrict command permissions of integrations where possible (Manage > Roles & Members / Channels / Command Overrides) * Server Settings > Integrations > Webhooks: * [ ] Review and remove any unnecessary webhooks * [ ] Reevaluate necessity of webhooks with excessive permissions > **Note on Integration Security:** Integrations and webhooks add 3rd party risk and permission misconfiguration risk. > Ensure that permissions are correct, and either remove external integrations or understand the risk they present. ##### Invites * Server Settings > Invites: * [ ] Review and delete unnecessary or old invites regularly ##### Privacy Settings * Server Settings > Privacy Settings: * [ ] Disable **Direct Messages** — this prevents users from DMing other members in this server ##### Community Features * Server Settings > Community: * [ ] Enable the Community Feature * Unlocks tools like membership screening, server insights, welcome screen, and discovery settings. Helps maintain a structured, secure environment by surfacing official rules and critical info to newcomers. * Server Settings > Server Insights: * [ ] Enable Server Insights for detailed analytics * Use this data to inform moderation strategies and server improvements > **Note on Safety Features:** > > * Activity alerts notify on anomalous DM activity, which could indicate your community is being targeted by scammers > or social engineering attackers. > * Raid Protection and CAPTCHA can also be satisfied by a bot, if preferred over Discord's built-in functionality. > * Hiding/filtering DMs between server members is recommended to prevent scams, spam, and social engineering of your > users. > * In the event of a security incident, Discord provides > [**Security Actions**](https://support.discord.com/hc/en-us/articles/17439993574167-Activity-Alerts-Security-Actions#h_01HAD80CK67WF59GDGR7XGVAN8) > for pausing invites and DMs to allow you to protect your community while responding to ongoing threats. *** #### Role Hierarchy Setup Roles should be structured with higher-privilege roles at the top. Go to Server Settings > Roles, create roles like Cold Admin, Team, Moderator, & Verified, and drag to reorder (higher roles override lower roles): 1. Cold Admin (highest) 2. Team 3. Moderator 4. Verified (lowest) **Recommended permissions by role:** | Role | Recommended Permissions | | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Moderators** | View Channels, View Audit Log, View Server Insights, Kick Members, Ban Members, Timeout Members, Send Messages and Create Posts, Embed Links, Attach Files, Add Reactions, Add External Emoji, Use External Stickers, Manage Messages, Bypass Slowmode, Read Message History, Request to Speak | | **Members** | View Channels, Send Messages and Create Posts, Embed Links, Add Reactions, Read Message History, Request to Speak | Use **Server Settings > Roles > \[Role] > View Server as Role** to see what members with a certain role can see and access. *** #### Channel Management ##### Organization * Use categories to group related channels * Suggested categories: Information, General, Voice Channels, Topic-Specific ##### Per-Channel Settings (Right-click channel > Edit Channel > Permissions): * [ ] Set custom permissions for roles or members in specific channels ##### Channel Settings > Overview * [ ] Slow Mode: Set appropriate cooldown (e.g., 5-30 seconds) for busy channels * [ ] Age-Restricted Channel: Enable for channels with mature content *** #### Member Screening Setup Beyond enabling in Safety Setup: * Implement a verification bot like Wick that does in-channel captcha for users to join the server * Require users to complete an in-channel captcha before accessing the server * Advance Settings: Have verification bot filter based on account age, PFP set, and timeout for incomplete captcha *** #### Invite Best Practices When creating invites: * Set "Expire After" (recommended: 24 hours) * Set "Max Number of Uses" (recommended: 50-100) *** #### Logging Setup * Ensure admin/mod roles have "View Audit Log" permission * Create a private logging channel visible only to admins/mods * Use a logging bot like Logger or Dyno to send detailed logs * Configure audit log output to a private channel for easier monitoring *** #### Security Bots Various third-party Discord bots offer valuable security and protection features, facilitating automated moderation for your server. In the sections below, we'll explore different categories of security bots and highlight popular options for each category. ##### Anti-Impersonation Bots Set up custom rules to prevent other users from joining using the same username and PFP (profile picture) to impersonate you or other important members of the server. A popular bot in this category is [Hashbot](https://hashbot.com). ##### Anti-Raid Bots To prevent spam bots from joining your server all at once, an attack known as raiding, you can also set up bots with particular rules. Beemo is a good example of a bot in this category. ##### Anti-Nuke Bots This is a monitoring system to observe and note any changes (spontaneous or planned) that take place in your discord server. Some key observation markers are channel and role creation/deletions, banning or kicking members, and webhook creation/deletion. ##### Moderation & Link Whitelisting Bots Only allows approved links to be used in the discord server. A popular bot in this category is Goodknight Bot. ##### General Moderation Bots Consider bots like Dyno for advanced moderation and logging, or Carl-bot for reaction roles and custom commands. Set up security Bots as described above. *The bots above are not all-inclusive but rather a recommended list of bots to help protect your Discord server in these categories.* *** #### Establish Clear Server Rules * Create a #rules channel * Use Discord's built-in rules screening feature * Include sections on: Behavior, Content, Moderation Actions, Appeals Process *** #### Regular Reviews | Frequency | Action | | --------------- | ----------------------------------------------------------------------------------------------- | | **Monthly** | Review all role permissions; use a spreadsheet to track changes and justifications | | **Quarterly** | Assess if server rules need updating; announce any changes in a dedicated announcements channel | | **Bi-annually** | Delete or archive inactive channels; remove roles that are no longer needed | Also regularly: * Ensure bots are from reputable sources and receive frequent updates * Review bot permissions after each significant update to avoid newly introduced vulnerabilities * Keep track of newly introduced features such as Threads, Scheduled Events, or Stage Channels and configure their permissions carefully (e.g., who can start or join a Thread) to prevent abuse by spammers or scammers *** #### Cold Admin Accounts A Cold Admin account provides enhanced security because it serves exclusively as the server owner and is not used for everyday activities. If a regular admin account is compromised, attackers gain full access to the server or account, making it challenging to involve support and potentially requiring days or weeks to resolve the issue. Using a Cold Admin means creating a separate account dedicated solely to ownership functions, keeping it isolated from routine operations. ##### What is a Cold Device? A Cold Device is a factory-reset device with no previous configuration. This should be a dedicated phone or laptop — you can use an old iPhone/Android, Windows device, or even a Chromebook to keep costs down. Everyone involved in setup and maintenance must ONLY access the Cold Admin account from a cold device. ##### Cold Admin Setup ##### Step 1: Create a dedicated email account Create a brand new Gmail account specifically for this Discord account. Do not use a VPN during this process, and it's best to use an incognito browser. After creating the Gmail account: * [ ] Set up 2FA immediately (authenticator app recommended, or Security Key for maximum security) * [ ] Ensure "Skip password when possible" is **off** * [ ] Do not add a phone number to the account * [ ] Note down the 10 backup codes **offline on paper** (DO NOT store online) * [ ] Write down the email, password, and backup codes on paper and store securely ##### Step 2: Create the Discord account Head to [https://discord.com](https://discord.com) and create a new account using the Gmail account you just created. * [ ] Write down the email, username, password, and date of birth **offline** * [ ] Use a username that is not related to your project * [ ] Give the profile a profile picture in **My Account > Edit User Profile** * [ ] Go to **Content & Social** and disable DMs from server members and set spam filter to maximum * [ ] Set the account status to **Invisible** so no one can see if it's online (click profile in bottom left > change status) ##### Step 3: Join the server and transfer ownership * [ ] Send the Cold Admin account a friend request from your personal Discord account * [ ] Have the Cold Admin join the Discord server and complete verification like a normal account * [ ] Assign the Cold Admin the highest admin role * [ ] Have the Cold Admin send a few messages in a private team chat * [ ] Wait approximately 24 hours, send a few more messages, then transfer ownership **To transfer ownership:** Go to **Server Settings > Members** > Search for the Cold Admin account > Click the three dots > Select **Transfer Ownership** > Input 2FA > Confirm > ⚠️ **CRITICAL:** Triple-check that you are transferring to the correct Cold Admin account. If you transfer to the > wrong account, recovery will be extremely difficult. ##### Use of Cold Admin Account * **Do not** use the Cold Admin account for day-to-day operations * Log into both the Gmail and Discord account at least once a month (set a phone reminder) * Use only for: inviting/adding bots, making major changes only the server owner can perform * If an incident or compromise occurs, log into the Cold Admin to regain control — the server owner always maintains full access rights *** #### Backup Systems * Use a bot like ServerBackup to regularly backup your server configuration * Store backups securely off-platform *** #### Additional Recommendations * Set up account leveling for new members for gradually enabling permissions * Regularly review server audit logs for admin and mod actions * Use anti-raid bots like Wick or Dyno and configure automatic lock-down settings for suspicious activity * Regularly review **Server Settings > Integrations** for newly added apps or link shorteners; disable suspicious integrations or automate link scanning with a bot that checks URLs against known phishing databases > **Important:** Discord servers should not be used for any confidential communication (i.e., any admin discussions > beyond the scope of server moderation) — even restricted channels and DMs are not end-to-end encrypted. *** #### Stay Updated * Consult the official [Discord Moderator Academy](https://discord.com/moderation) for ongoing best practices and new features * Implement recommended strategies (e.g., improved spam filters, updated role recommendations) *** ### Additional Resources * [Securing Your Server - Discord](https://discord.com/community/securing-your-server) * [Four Steps for a Super Safe Server - Discord](https://discord.com/safety/360043653152-four-steps-to-a-super-safe-server) * [How to setup a Discord server securely - Ledger](https://www.ledger.com/academy/basic-basics/launch-a-crypto-project-securely/how-to-set-up-a-crypto-project-discord-server-securely) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## GitHub Security ### Summary > 🔑 **Key Takeaway for GitHub:** Secure your GitHub account with non-SMS two-factor authentication, enable push > protection, and regularly review connected apps and sessions. For organizations, enforce signed commits, > branch protection rules, and restrict member privileges to minimize supply chain attack risks. This checklist is adapted from [Auditware's W3OSC](https://github.com/W3OSC/web3-opsec-standard) standards. *** ### For Individuals These settings apply to your personal GitHub account. All team members and admins should configure these on their own accounts. #### Individual Account Settings * Account Settings: * [ ] Public profile > Contributions & activity > Make profile private and hide activity > **On** * [ ] Password and authentication > Two-factor authentication > Enable and configure any method other than **SMS/Text message** * [ ] Sessions > Review and revoke any unrecognized or unnecessary * [ ] SSH and GPG keys > Review and remove any unnecessary * [ ] Organizations > Review and leave any unnecessary * [ ] Code security > User > Push protection for yourself > **Enabled** * [ ] Applications > Review and remove any unnecessary * [ ] Developer settings > * [ ] GitHub Apps > Review and remove any unnecessary * [ ] OAuth Apps > Review and remove any unnecessary * [ ] Personal access tokens > Review and remove any unnecessary *** ### For Team Members These guidelines apply to team members who contribute to repositories but don't have administrative access. Team members should: * Ensure their individual account settings are configured according to the checklist above * Enable GPG signing for commits to meet signed commit requirements * Be aware of branch protection rules that may require pull request approvals * Regularly review and rotate personal access tokens * Report any suspicious repository activity to organization admins *** ### For Admins These settings and practices apply to GitHub organization administrators with elevated privileges. #### Repository Settings ##### General Settings * [ ] General > Danger Zone > Repository visibility > **Private** * [ ] Collaborators and teams > Review access and remove any unnecessary * [ ] Ensure there are no more than 3 admins ##### Branch Protection * [ ] Branches > Branch protection rules > For each branch that triggers automated deployments, set the following protections: * Protect matching branches > Require a pull request before merging * Require approvals > **2+** recommended * Rules applied to everyone including administrators > Allow force pushes > **Off** ##### Repository Rules * Rules > Rulesets > New ruleset > New branch ruleset: * [ ] **Name**: EnforceSignedCommits * **Targets**: All branches * **Rules**: * Require signed commits > **On** * [ ] **Name**: BlockForcePushes * **Targets**: All branches * **Rules**: * Block force pushes > **On** ##### Actions Security * Actions > * [ ] Actions permissions > Set minimum permissions needed * **Disable actions** - if not needed * **Allow organization actions and reusable workflows** - if only internal actions are used * **Allow organization, and select non-organization, actions and reusable workflows** - if external actions are used * [ ] Fork pull request workflows > Run workflows from fork pull requests > **Off** * [ ] Workflow permissions > **Read repository contents and packages permissions** * [ ] Allow GitHub Actions to create and approve pull requests > **Off** * [ ] Access > **Not accessible** ##### Security Features * [ ] Webhooks > Review webhooks and delete any unnecessary or overly permissive * [ ] Pages > Branch > **None** (to disable) * Code security > * [ ] Dependency graph > **Enabled** * [ ] Dependabot alerts > **Enabled** * [ ] Dependabot security updates > **Disabled** * [ ] Grouped security updates > **Disabled** * [ ] Dependabot version updates > **Disabled** * [ ] Access to alerts > No additional users (only admins) ##### Access Control * [ ] Deploy keys > Remove all [\[1\]](#1-deploy-keys-warning) * [ ] Secrets and variables > Review secrets and variables and remove any unnecessary * [ ] GitHub Apps > Installed GitHub Apps > Review configurations and uninstall any unnecessary * [ ] Review permissions are appropriate and that repository access is scoped only to relevant repositories #### Organization Settings ##### Member Privileges * Member privileges > * [ ] Base permissions > Any other than **Admin** * [ ] Repository creation > Public > **Off** * [ ] Repository forking > Allow forking of private repositories > **Off** * [ ] Projects base permissions > Any other than **Admin** * [ ] Integration access requests > Allow integration requests from outside collaborators > **Off** * Admin repository permissions > * [ ] Allow members to change repository visibilities for this organization > **Off** * [ ] Allow members to delete or transfer repositories for this organization > **Off** * [ ] Allow repository administrators to delete issues for this organization > **Off** * [ ] Member team permissions > Allow members to create teams > **Off** ##### Organization Rules * Repository > Rulesets > New ruleset > New branch ruleset: [\[2\]](#2-enterprise-features) * [ ] **Name**: EnforceSignedCommits * **Targets > Target repositories**: All branches * **Rules > Branch rules**: * Require signed commits > **On** * [ ] **Name**: BlockForcePushes * **Targets > Target repositories**: All branches * **Rules > Branch rules**: * Block force pushes > **On** ##### Project and Actions Settings * [ ] Planning > Projects > Allow members to change project visibilities for this organization > **Off** * Actions > General > * Policies > **All repositories** * [ ] **Allow organization actions and reusable workflows** or **Allow organization, and select non-organization, actions and reusable workflows** * [ ] Approval for running fork pull request workflows from contributors > **Require approval for all external contributors** * [ ] Fork pull request workflows in private repositories > Run workflows from fork pull requests > **On** * [ ] Workflow permissions > **Read repository contents and packages permissions** * [ ] Allow GitHub Actions to create and approve pull requests > **Off** ##### Security and Access * [ ] Webhooks > Review and remove any unnecessary * [ ] For each webhook, ensure SSL verification is enabled * [ ] Packages > Package creation > Public > **Disabled** * Authentication security > * [ ] Require two-factor authentication for everyone in the organization. > **On** * [ ] Only allow secure two-factor methods > **On** * [ ] Deploy keys > **Disabled** ##### Code Security Configuration * Code security > Configurations > New configuration: * Dependency graph and Dependabot > * [ ] Dependency graph > **Enabled** * [ ] Dependabot alerts > **Enabled** * [ ] Code scanning > Default setup > **Enabled** * [ ] Secret scanning > * [ ] Alerts > **Enabled** * [ ] Validity checks > **Disabled** * [ ] Non-provider patterns > **Enabled** * [ ] Push protection > **Enabled** * [ ] Policy > * [ ] Use as default for newly created repositories > **All repositories** * [ ] Enforce configurations > **Enforce** * [ ] **Save configuration** and **Apply to > All repositories** ##### Access Management * [ ] Secrets and variables > Review secrets and variables and remove any unnecessary * [ ] GitHub Apps > Installed GitHub Apps > Review configurations and uninstall any unnecessary * [ ] Review permissions are appropriate and that repository access is scoped only to relevant repositories * [ ] OAuth app policy > Review policies and edit/deny any unnecessary * Personal access tokens > * [ ] **Restrict access via fine-grained personal access tokens** * [ ] **Require administrator approval** * [ ] **Restrict access via personal access tokens (classic)** * [ ] **Enroll** [\[3\]](#3-audit-logs) *** ### Notes #### \[1] Deploy Keys Warning Do not use deploy keys, they are possession-based access tokens that are a significant security risk. Use [GitHub Apps](https://docs.github.com/en/apps/overview) instead. #### \[2] Enterprise Features This is only available if you have a GitHub Enterprise plan. If you do not, you can set these same rules at the repo level instead. #### \[3] Audit Logs It is recommended to regularly review audit logs for your organization at Logs > Audit log. *** **Related**: For repository hardening guidance, see [DevSecOps - Repository Hardening](/devsecops/repository-hardening). *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## GoDaddy Security ### Summary > 🔑 **Key Takeaway for GoDaddy:** Protect your domain registrar account with non-SMS two-factor authentication, > regularly review delegate access and active sessions, and enable DNSSEC on all domains to prevent DNS spoofing > and domain hijacking attacks. This checklist is adapted from [Auditware's W3OSC](https://github.com/W3OSC/web3-opsec-standard) standards. *** ### For Individuals These settings apply to your personal GoDaddy account. All team members and admins should configure these on their own accounts. #### Individual Account Settings * Account Settings > * Login & Pin > * [ ] 2-Step Verification > **On** (non-SMS) * [ ] Active sign-ins > **Review and remove any unused or unrecognized** * [ ] Delegate Access > **Review and remove any unused or unrecognized** *** ### For Team Members These guidelines apply to team members who have delegate access to GoDaddy accounts but don't have full administrative control. Team members should: * Ensure their individual account settings are configured according to the checklist above * Understand the scope of their delegate access permissions * Report any suspicious domain or DNS activity to account administrators * Never share login credentials or delegate access with unauthorized parties *** ### For Admins These settings and practices apply to GoDaddy account administrators who manage domains and DNS settings. #### Domain Security * [ ] Domain Settings > DNS > DNSSEC > **On** #### Best Practices * Regularly audit delegate access and remove any that are no longer needed * Monitor domain expiration dates and enable auto-renewal for critical domains * Use domain locking features to prevent unauthorized transfers * Review DNS records periodically for any unauthorized changes *** **Related**: For comprehensive DNS security guidance, see [Infrastructure - Domain & DNS Security](/infrastructure/domain-and-dns-security/overview). *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Account Management > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Account Management](/guides/account-management/overview) * [Discord Security](/guides/account-management/discord) * [GitHub Security](/guides/account-management/github) * [GoDaddy Security](/guides/account-management/godaddy) * [Linear Security](/guides/account-management/linear) * [Mercury Security](/guides/account-management/mercury) * [Notion Security](/guides/account-management/notion) * [Render Security](/guides/account-management/render) * [Sentry Security](/guides/account-management/sentry) * [Signal Security](/guides/account-management/signal) * [Slack Security](/guides/account-management/slack) * [Telegram Security](/guides/account-management/telegram) * [Trello Security](/guides/account-management/trello) * [Twitter/X Security](/guides/account-management/twitter) * [Vercel Security](/guides/account-management/vercel) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Linear Security ### Summary > 🔑 **Key Takeaway for Linear:** Secure your Linear account with passkeys, regularly review sessions and connected > applications, and for workspaces, disable invite links, restrict approved email domains, and control > third-party integrations to protect sensitive project data. This checklist is adapted from [Auditware's W3OSC](https://github.com/W3OSC/web3-opsec-standard) standards. *** ### For Individuals These settings apply to your personal Linear account. All team members and admins should configure these on their own accounts. #### Individual Account Settings * Settings > * [ ] Sessions, Personal API keys, & Authorized Applications > **Review and remove any unnecessary or unrecognized** * [ ] Passkeys > Add a passkey (recommended) * [ ] Connected Accounts > **Review and remove any unnecessary or unrecognized** *** ### For Team Members These guidelines apply to team members who use Linear for project management but don't have administrative access. Team members should: * Ensure their individual account settings are configured according to the checklist above * Use passkeys for stronger authentication when available * Be cautious about authorizing third-party applications to access Linear * Report any suspicious workspace activity to administrators *** ### For Admins These settings and practices apply to Linear workspace administrators with elevated privileges. #### Admin Settings * [ ] Administration > * [ ] Members > **Review and remove any unnecessary or unrecognized** * **Security >** * [ ] Invite links > **Off** * [ ] Approved email domains > **Review and remove any unnecessary or unrecognized** * [ ] Workspace restrictions > **Restrict all** * [ ] Integrations & applications > **Control third-party applications** * [ ] API > OAuth Applications, Webhooks, & Member API keys > **Review and remove any unnecessary or unrecognized** * [ ] Applications > **Review and remove any unnecessary or unrecognized** *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Mercury Security ### Summary > 🔑 **Key Takeaway for Mercury:** Secure your Mercury account by enabling two-factor authentication, regularly > reviewing active sessions and linked profiles, and for organizations, enabling ACH authorization and dual admin > approval to prevent unauthorized transactions. This checklist is adapted from [Auditware's W3OSC](https://github.com/W3OSC/web3-opsec-standard) standards. *** ### For Individuals These settings apply to your personal Mercury account. All team members and admins should configure these on their own accounts. #### Account Security Checklist * Personal > * Security > * [ ] Two-factor authentication > **On** * [ ] Active sessions > **Review and remove any unused or unrecognized** * [ ] Linked profiles > **Review and remove any unnecessary or unrecognized** * [ ] Remembered devices > **Review and remove any unused or unrecognized** *** ### For Team Members These guidelines apply to team members who have access to company Mercury accounts but don't have full administrative access. Team members should: * Ensure their individual account settings are configured according to the checklist above * Be aware of their permissions and only perform actions within their authorized scope * Report any suspicious activity or unrecognized transactions to admins immediately *** ### For Admins These settings and practices apply to Mercury account administrators with elevated privileges. #### Company Settings * Company > * [ ] Controls > ACH authorization > **On** * [ ] Approvals > Dual admin approval > **On** * [ ] Integrations > **Review and remove any unused or unrecognized** * [ ] API Tokens > **Review and remove any unused or unrecognized** *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Notion Security ### Summary > 🔑 **Key Takeaway for Notion:** Secure your Notion account by enabling 2-step verification with an authenticator app > (not SMS), disabling support access, and for workspaces, restricting publishing, export, and guest access to > prevent unauthorized data exposure. This checklist is adapted from [Auditware's W3OSC](https://github.com/W3OSC/web3-opsec-standard) standards. *** ### For Individuals These settings apply to your personal Notion account. All team members and admins should configure these on their own accounts. #### Account Security Checklist * Account Settings: * [ ] My account > Password > If enabled (not using SSO), Enable **2-step verification** * Use **Code from authenticator** * DO NOT use **Text me a code** * [ ] My account > Support access > **Disabled** * [ ] My account > Devices > Log out of any unnecessary * [ ] My settings > Privacy > Cookie Settings > Only **Strictly necessary** * [ ] My settings > Privacy > Profile discoverability > **Disabled** * [ ] My connections > Review and disconnect any unnecessary *** ### For Team Members These guidelines apply to team members who have access to shared Notion workspaces but don't have full administrative access. Team members should: * Ensure their individual account settings are configured according to the checklist above * Be mindful of page sharing settings and avoid publishing or sharing pages externally without approval * Report any suspicious activity or unauthorized access requests to workspace admins *** ### For Admins These settings and practices apply to Notion workspace administrators with elevated privileges. #### Workspace Settings ##### Member and Site Management * [ ] People > Review members and guests * [ ] Sites > Review and unpublish any unnecessary pages ##### Security & Data Settings * Security & data > [\[1\]](#1-enterprise-features) * [ ] Disable publishing sites and forms > **On** * [ ] Disable duplicating pages to other workspaces > **On** * [ ] Disable export > **On** * [ ] Allow page access requests from non-members > **Off** * [ ] Disable members inviting guests to pages > **On** * [ ] Allow members to request adding guests > **Off** * [ ] Allow members to request adding other members > **Off** * [ ] Allow any user to request to be added as a member of the workspace > **Off** * [ ] Allow page guests to request to be added as members to the workspace > **Off** ##### Connections Management * Connections > * [ ] Restrict members from adding connections > **Restricted** * [ ] Allow webhooks in automations > **Disabled** * [ ] Review the connections and disconnection any unnecessary *** ### Notes #### \[1] Enterprise Features Some of these settings require an Enterprise workspace plan. These can be omitted, but it is recommended to consider upgrading your plan for the security benefits if the size and/or risk tolerance of your organization warrants the extra protections. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Account Management This section contains practical, step-by-step guides that help you implement security best practices across various platforms and tools. Each guide provides actionable instructions you can follow to secure your operations. ### Communication Platforms Guides for securing your communication and community platforms. * [**Discord Security**](/guides/account-management/discord) - Comprehensive guide to securing your Discord server * [**Signal Security**](/guides/account-management/signal) - Secure messaging with registration lock and privacy settings * [**Slack Security**](/guides/account-management/slack) - Workspace security and admin settings for teams * [**Telegram Security**](/guides/account-management/telegram) - Comprehensive guide to securing your Telegram account and groups * [**Twitter/X Security**](/guides/account-management/twitter) - Comprehensive guide to securing your X (Twitter) account ### DevOps & Infrastructure Guides for securing your development and infrastructure accounts. * [**GitHub Security**](/guides/account-management/github) - Repository security, 2FA, SSH keys, and organization settings * [**GoDaddy Security**](/guides/account-management/godaddy) - Domain security, DNSSEC, and registrar settings * [**Render Security**](/guides/account-management/render) - Cloud platform security, API keys, and team management * [**Sentry Security**](/guides/account-management/sentry) - Error tracking platform security and access control * [**Vercel Security**](/guides/account-management/vercel) - Deployment platform security and team settings ### Business Tools Guides for securing your productivity and business applications. * [**Linear Security**](/guides/account-management/linear) - Project management security with passkeys and workspace settings * [**Mercury Security**](/guides/account-management/mercury) - Banking security, ACH authorization, and dual approval * [**Notion Security**](/guides/account-management/notion) - Workspace security, 2-step verification, and access controls * [**Trello Security**](/guides/account-management/trello) - Board security and session management *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Render Security ### Summary > 🔑 **Key Takeaway for Render:** Secure your Render account by enabling two-factor authentication, regularly reviewing > CLI tokens, API keys, and SSH public keys, and for workspaces, maintaining strict team member access controls > and enabling audit logs. This checklist is adapted from [Auditware's W3OSC](https://github.com/W3OSC/web3-opsec-standard) standards. *** ### For Individuals These settings apply to your personal Render account. All team members and admins should configure these on their own accounts. #### Account Security Checklist * Account Settings > * [ ] Account Security > Two-Factor Authentication > **Enabled** * [ ] CLI Tokens > **Review and remove any unnecessary or unrecognized** * [ ] API Keys > **Review and remove any unnecessary or unrecognized** * [ ] SSH Public Keys > **Review and remove any unnecessary or unrecognized** *** ### For Team Members These guidelines apply to team members who have access to shared Render workspaces but don't have full administrative access. Team members should: * Ensure their individual account settings are configured according to the checklist above * Use the principle of least privilege when accessing workspace resources * Report any suspicious deployments or unauthorized changes to workspace admins *** ### For Admins These settings and practices apply to Render workspace administrators with elevated privileges. #### Workspace Settings * Workspace Settings > * [ ] Team Members > **Review and remove any unnecessary or unrecognized** * [ ] Audit Logs > It is highly recommended that you sign up for an **Organization or Enterprise** plan in order to enable this *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Sentry Security ### Summary > 🔑 **Key Takeaway for Sentry:** Secure your Sentry account by enabling two-factor authentication, regularly reviewing > API tokens and authorized applications, and ensuring organization-wide security policies are enforced. Remove any > unnecessary integrations and audit team member access to minimize attack surface. This checklist is adapted from [Auditware's W3OSC](https://github.com/W3OSC/web3-opsec-standard) standards. *** ### For Individuals These settings apply to your personal Sentry account. All team members and admins should configure these on their own accounts. #### Individual Account Settings * User Settings > * **Account >** * Security > * [ ] Sessions > **Sign out of all devices** * [ ] Two-Factor Authentication > **Add App or U2F** * [ ] Authorized Applications > **Review and remove any unnecessary or unrecognized** * [ ] Identities > **Review and remove any unnecessary or unrecognized** * **API >** * [ ] Applications > **Review and remove any unnecessary or unrecognized** * [ ] User Auth Tokens > **Review and remove any unnecessary or unrecognized** *** ### For Team Members These guidelines apply to team members who use Sentry but don't have full administrative access. Team members should: * Ensure their individual account settings are configured according to the checklist above * Enable two-factor authentication on their account * Regularly review and remove any unnecessary API tokens or authorized applications * Report any suspicious activity or unrecognized access to administrators *** ### For Admins These settings and practices apply to Sentry organization administrators with elevated privileges. #### Organization Settings * Organization > * [ ] Members > **Review and remove any unnecessary or unrecognized** * **Security & Privacy >** * [ ] Require Two-Factor Authentication > **On** * [ ] Allow Join Requests > **Off** * **Data Scrubbing >** * [ ] Prevent Storing of IP Addresses > **Off** * [ ] Integrations > **Review and remove any unnecessary or unrecognized** #### Developer Settings * Developer Settings > * [ ] Organization Tokens > **Review and remove any unnecessary or unrecognized** * [ ] Custom Integrations > **Review and remove any unnecessary or unrecognized** *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Signal Security ### Summary > 🔑 **Key Takeaway for Signal:** Enable registration lock to prevent SIM swap impersonation, configure privacy > settings to hide your phone number, and use disappearing messages. Even if you don't actively use Signal, securing > your account prevents attackers from impersonating you to others. Signal provides the gold standard of end-to-end encryption and privacy features, making it the best platform for truly anonymous and secure communications. Properly configuring your Signal account is essential for maintaining your privacy and security. *** ### For Individuals These settings apply to your personal Signal account. You must be on the phone app to access all of these settings. > **Important**: Use Signal! Chats on Signal are secured with the gold standard of end-to-end encryption and privacy features. > Signal is the best place to have truly anonymous chats. > > If you don't use Signal, you should at least create an account with your phone number and lock it so that you > cannot be impersonated to others via SIM swap attacks. #### Account Security Checklist * Account Settings: * [ ] Settings > Account > Registration Lock > **Enable** * [ ] Settings > Linked Devices > Review the list * [ ] Settings > Calls > Always relay calls (*if privacy is desired*) * [ ] Settings > Privacy > Who can see my number > **Nobody** * [ ] Settings > Privacy > Who can find me by number > **Nobody** * [ ] Settings > Privacy > Disappearing Messages > **Enabled** * *The timer is up to you, but 1 week is recommended* * [ ] Settings > Privacy > Hide Screen in App Switcher > **Enabled** * [ ] Settings > Privacy > Screen Lock > **Enabled** * *The timeout period is up to you, but 1 minute is recommended* * [ ] Settings > Privacy > Payments Lock > **Enabled** * [ ] Settings > Privacy > Advanced > Always Relay Calls > **Enabled** (privacy) * *This leaks your IP address to contacts via calls when disabled* *** #### Best Practices & Additional Tips * [ ] **Review Linked Devices Regularly** * Periodically check your linked devices and remove any that you no longer use or don't recognize. * [ ] **Use a Strong Device PIN** * Signal's security relies on your device's security. Ensure you have a strong PIN or biometric lock on your phone. * [ ] **Be Cautious with Safety Numbers** * Verify safety numbers with contacts when they change to ensure you're communicating with the intended person. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Slack Security ### Summary > 🔑 **Key Takeaway for Slack:** Secure your Slack workspace by enforcing two-factor authentication with authenticator > apps only, requiring admin approval for invitations, regularly reviewing member access levels, and blocking jailbroken > or rooted devices from accessing the workspace. This checklist is adapted from [Auditware's W3OSC](https://github.com/W3OSC/web3-opsec-standard) standards. *** ### For Team Members These guidelines apply to team members who use the Slack workspace. Team members should: * Enable two-factor authentication on their Slack account using an authenticator app * Be cautious of phishing attempts through direct messages or shared links * Report any suspicious messages or unrecognized workspace members to administrators * Avoid accessing the workspace from jailbroken or rooted devices * Be mindful of what sensitive information is shared in channels *** ### For Admins These settings and practices apply to Slack workspace administrators with elevated privileges. #### Workspace Settings * Workspace Settings (\.slack.com/admin/settings) * **Settings >** * [ ] Joining This Workspace > **Review auto-approve domains** or **disable** * **Permissions >** * [ ] Invitations > **Require Admin Approval** #### Member Management * Manage members (\.slack.com/admin) * [ ] Review member list and Account type for each member #### Security Settings * Security Settings (\.slack.com/admin/security) * **Sign in Settings >** * [ ] Two-factor authentication for email sign‑in > **On** * [ ] Allowed 2FA methods > **Authenticator apps only** * **Device Settings >** * [ ] Jailbroken or rooted devices > **Not allowed** *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Telegram Security ### Summary > 🔑 **Key Takeaway:** Enable passkeys and Two-Step Verification, hide your phone number, and stay vigilant with group > chats. Implement verification steps and secure communication practices to protect against interception attacks. While **Telegram** is widely used in the crypto community, it's crucial to understand its security limitations. Telegram **does not** offer end-to-end encryption (**E2EE**) by default, which means your messages could potentially be accessed by third parties. Additionally, Telegram's reliance on phone numbers for account creation can expose users to SIM swapping attacks, and its peer-to-peer call feature can reveal your IP address to other users. If **E2EE** is a priority, consider using [Signal](https://signal.org/). However, if you choose to use **Telegram**, the following best practices can help enhance your security. *** ### For Individuals These settings apply to your personal Telegram account. All team members and admins should configure these on their own accounts. #### Account Security Checklist * Account Settings: * Privacy & Security > * Security > * [ ] Two-Step Verification > **On** * Telegram does not require a login by default. However, you can set up a password that acts as a "second" 2FA method when logging in from a new device. * Telegram sign-ups require a phone number, but you can also enable two-factor authentication via a password—your main protection if you're ever SIM-swapped. **Don't reuse this password anywhere else.** * Do not set a password hint, do add a recovery email * **SMS Codes:** Telegram sends a code via SMS, which is not secure. * **Email Recovery:** Offers email recovery, which is more secure but lacks options for authenticator apps or hardware keys. * **Backup Password:** If you lose this password, access to your account may be compromised. Write it down offline and ensure it is not lost. * [ ] Passkeys > **Set up at least one passkey** * [Passkeys](https://telegram.org/blog/passkeys-and-gift-offers) allow you to log in using biometric data (Face ID, fingerprint) or a device PIN instead of SMS codes. This is phishing-resistant and reduces reliance on SMS-based login, which materially lowers SIM-swap exposure during login. * Go to **Settings > Privacy and Security > Passkeys** to create a passkey. * **Encrypted keys** are stored on your device and can sync via password managers (iCloud Keychain, Google Password Manager, 1Password, etc.). * **Set up passkeys on multiple devices** for redundancy — if one device is lost, you can still log in from another. * **Keep your phone number active** and under your control. Even with passkeys enabled, your Telegram account still depends on a phone number for account ownership and recovery flows. * Passkeys are useful when traveling or when SMS delivery is unreliable, since they reduce dependence on\ receiving login codes by text message. * [ ] Local passcode > **On** (recommended) * This feature adds a passcode to access your Telegram app after a period of inactivity. The default setting is "away for 1 hour." * **Store Passcode Securely:** Do not lose this passcode—store it offline if needed. * **Unique Passcode:** Ensure it is different from your phone's unlock passcode. * Active sessions > * Telegram supports auto-terminating inactive sessions. You can also manually review and end any suspicious active sessions. * [ ] Review and delete all unused sessions * [ ] Terminate old sessions > **1 month** * Privacy > * Consider adjusting the following settings based on your country, usage, and purpose for using Telegram: * [ ] Phone Number > Who can see my phone number > **Nobody** * Making your phone number visible can expose you to unwanted contact or social engineering attacks. Restricting visibility helps safeguard your personal info. * [ ] Phone Number > Who can find me by my number > **My Contacts** * [ ] Phone Number > Exceptions > Remove all * [ ] Last Seen & Online > Who can see my timestamp > **Nobody**/**My Contacts** * [ ] Last Seen & Online > Exceptions > Remove all * [ ] Profile Photo > Who can see my profile photo > **Everybody** * Set to **Everybody** to stop scammers from impersonating your profile picture. * [ ] Bio > Who can see my bio > **Nobody** (depending on use of Telegram) * [ ] Date of Birth > Who can see my date of birth > **Nobody** * [ ] Date of Birth > Exceptions > Remove all * [ ] Forwarded Messages > Who can add a link to my account when forwarding my messages > **Nobody** * [ ] Calls > Who can call me > **Nobody**/**My Contacts** * [ ] Calls > Exceptions > Remove all * [ ] Calls > Peer-to-peer > Use peer-to-peer with > **Nobody**/**My Contacts** > **Note**: Peer-to-peer calls leak your IP address to callers. Set to **Nobody** to preserve anonymity * [ ] Calls > Peer-to-peer > Exceptions > Always allow > Remove all * [ ] Groups & Channels > Who can add me to groups and channels > **Nobody**/**My contacts** * This helps prevent being added to random groups that may impersonate legitimate groups and lead to scams. * [ ] Groups & Channels > Exceptions > Remove all * [ ] Voice Messages > Who can send me voice messages > **Nobody**/**My contacts** * [ ] Voice Messages > Exceptions > Remove all * [ ] Messages > Who can send me messages > **My Contacts and Premium Users** (or **Everybody**/**My Contacts** depending on use of Telegram) * [ ] New chats from unknown users > Archive and Mute > **Enabled** * [ ] Bots and website > **Clear Payment and Shipping Info** * [ ] Auto-Delete Messages > Set a time frame (e.g., 1 week) based on your risk tolerance * Consider the photo you shared with a friend several months ago. While it might have slipped your mind, an attacker who gains access to your account could find such information quite valuable. * Advanced > * [ ] Automatic media download > Disable all types in all cases > **Note**: Automatic media download leaves you exposed to advanced malware attacks * Version and updates > * Ensure you are always using the latest version of Telegram to benefit from the newest security patches and features. * [ ] Check for Updates: Visit your device's app store regularly * [ ] Update automatically > **Enabled** * [ ] Install beta versions > **Disabled** > **Authentication Guidelines**: When establishing a secret chat, > [compare the encryption keys](https://core.telegram.org/techfaq#q-how-are-secret-chats-authenticated) > outside of telegram, in an established/authenticated channel, outside of telegram. When establishing a > peer-to-peer (encrypted) call, > [compare the emojis](https://core.telegram.org/techfaq#q-how-are-voice-and-video-calls-authenticated) > in an established/authenticated channel, outside of telegram. These are your defenses against man-in-the-middle > attacks. You **must** confirm these details if using Telegram for private communications. That said, it is suggested > to use a secure platform like [Signal](https://signal.org/) for confidential communication. *** #### Device-Level Security Securing the device you use for Telegram is crucial for preventing unauthorized access to your account and messages. * [ ] **Enable Full Device Encryption**: * Ensure your device has full disk encryption enabled * For iOS: This is enabled by default with a passcode * For Android: Go to **Settings > Security > Encryption** and follow instructions * [ ] **Set Strong Device Passcodes**: * Use alphanumeric passwords rather than simple PINs * Enable biometric authentication as a secondary measure * [ ] **Keep Your Device Updated**: * Install OS updates promptly to patch security vulnerabilities * Update Telegram to the latest version regularly * [ ] **Install Security Software**: * Use reputable anti-malware software on your device * Consider privacy-focused apps that detect network anomalies * [ ] **Secure Your Backups**: * Ensure any device backups containing Telegram data are encrypted * Be cautious about cloud backups that might store Telegram messages *** #### Advanced Privacy Measures ##### Consider Using a Different Phone Number Even if you implement all the recommended security measures, there are still valid reasons to use a separate phone number. For instance, it can help prevent your contacts from discovering your Telegram account or reduce the risk of accidental number exposure. This is particularly important because the **"Share My Phone Number"** option is enabled by default whenever you add a new contact. ##### Using a VoIP Number Telegram restricts many VoIP providers, but services like [Google Voice](https://voice.google.com/) or [Burner](https://www.burnerapp.com/) might work. Purchase a burner number solely for Telegram if you prefer additional anonymity. ##### Using an Anonymous Number In December 2022, Telegram introduced support for anonymous numbers purchased through its [TON](https://ton.org/) blockchain infrastructure. You can also check out [Fragment](https://fragment.com/) for such options. ##### Use Secret Chats for Enhanced Privacy For conversations that require an extra layer of security, use Telegram's Secret Chats, which offer **end-to-end encryption**. 1. **Start a Secret Chat**: Open the chat with the desired contact, tap on their name, and select **Start Secret Chat** 2. **Benefits**: * Messages are encrypted and can only be read by you and the recipient * Offers self-destruct timers for messages * Prevents forwarding of messages to other chats ##### Data Settings **Go to:** Settings > Privacy and Security > Data Settings * [ ] **Sync Contacts:** Disable (depending on use of Telegram) to prevent syncing your contacts. * [ ] **Suggest Frequent Contacts:** Disable (depending on use of Telegram) to avoid unsolicited contact suggestions. *** #### Best Practices for Safe Use * [ ] **Use Secret Chats:** When messaging someone, create a 'secret' chat to ensure encrypted 1:1 communication, providing end-to-end encryption for sensitive transactions. * [ ] **Verify Group Invites and Authenticity:** Always triple-check group invitations and confirm the legitimacy of group chats through separate channels to avoid joining impostor groups that share malicious links. * [ ] **Beware of Unsolicited DMs:** Never trust direct messages from anyone sending links or posing as "support", "exchanges," or "team" members. * [ ] **Double-Check Payment Details:** Verify payment information through multiple methods before transferring funds to prevent fund redirection. * [ ] **Block and Report Scammers:** Use the block function to prevent further contact, and report spammers/scammers instead of just deleting chats. * [ ] **Be Cautious with Third-Party Bots and Integrations:** * Third-party bots can enhance functionality but may also introduce vulnerabilities. * Only add bots from reputable sources * Limit the permissions you grant to bots * Periodically review and remove unnecessary bots * [ ] **Exercise Caution with Mini Apps:** Avoid logging in or providing information to mini apps that redirect outside of Telegram. Triple-check the username of the mini app to ensure its legitimacy, as Telegram lacks a bot verification system. Never download or run any commands from Telegram on your device. * [ ] **Enhance Privacy with a VPN:** *Advanced tip:* Set up a proxy or VPN to hide your IP address while using the Telegram app. * [ ] **Stay Vigilant Against Scam Ads:** Be aware that anyone can post ads in channels, with 99% being scam ads. Exercise caution when interacting with advertisements. *** #### Platform-Specific Risks: Man-in-the-Group Attack Attackers can exploit Telegram's group chat features to intercept and manipulate communications between two parties. Here's a concise example of how such an attack might occur: ##### Scenario: Intercepting a Payment Deal ##### Step 1: Initial Communication * **Alice** and **Bob** decide to finalize a cryptocurrency deal using a Telegram group chat named **"Crypto Deals"**. ##### Step 2: Attackers Create Cloned Groups * **Attacker 1** creates **Group A** impersonating **Alice**. * **Attacker 2** creates **Group B** impersonating **Bob**. ##### Step 3: Replicating Conversations * **In Group A (Impersonating Alice):** * The attacker, posing as Alice, relays Alice's messages from Group B to maintain the conversation. * **In Group B (Impersonating Bob):** * The attacker, posing as Bob, mirrors Bob's messages from Group A, acting as a middleman without altering the content. ##### Step 4: Swapping Payment Details * **In Group A:** * Fake Alice and Bob agree to the terms of the deal. * Bob shares his payment address. * **In Group B:** * Fake Bob shares his swapped payment address. * The conversation continues normally, with neither Alice nor Bob aware of the swap. ##### Step 5: Execution of the Scam * **Alice** sends the payment to what she believes are Bob's details but are actually those of Fake Bob. * The attacker now controls both ends of the conversation, having successfully redirected the funds. *** ### For Team Members These guidelines apply to team members who help manage Telegram groups/channels but don't have full administrative access. Team members should: * Ensure their individual account settings are configured according to the checklist above * Each admin must follow the guidance for securing their individual accounts * Add a suffix to your username, for example: "MyName | will never DM you" * Understand how to verify the authenticity of admins and official messages * Be aware of the Man-in-the-Group Attack scenario described above *** ### For Admins These settings and practices apply to Telegram group/channel administrators with elevated privileges. #### Channel & Group Settings Checklist ##### Channel Settings * Open channel > click channel name > **Channel settings** * [ ] Sign messages > **Enable** (if non-repudiation is desired) * [ ] Administrators > Review the list and remove any unnecessary ##### Group Settings * Open group > click group name > click three dots > **Manage group** * [ ] Channel type > **Private** (if public discoverability is not necessary) * [ ] Channel type > Content protection > **Enabled** (if confidentiality is needed) * [ ] Sign messages > **Enabled** * [ ] Chat history for new members > **Hidden** * This is not available if Topics are enabled * **Permissions:** * [ ] Send media > should be restricted appropriately * At minimum, **Files** and **Embed links** should be disabled * [ ] Add members > **Disabled** (if not necessary) [\[1\]](#1-member-control) * [ ] Pin messages > **Disabled** * [ ] Change group info > **Disabled** * [ ] Slow mode > At least **10s**, if not obstructive * [ ] Exceptions should be restricted to valid use cases * Team members should have exceptions granted to them for these rather than them being admins, when possible * [ ] **Invite links** > Review and remove unnecessary * Links should be limited by time period or number of users, when not obstructive * [ ] **Administrators** > Review and remove unnecessary & review permissions of each admin * Again, it is recommended to add exceptions for team members rather than add them as admins, when possible * Remove unnecessary permissions, especially **Add new admins** * **Aggressive Anti-Spam** > **Enabled** * [ ] **Members** > Review and remove unnecessary (If a confidential channel) *** #### Admin Permissions Management If you manage Telegram groups or channels, properly configuring admin permissions is crucial for maintaining security. * [ ] **Limit Admin Privileges**: * Go to your group/channel, tap the group name, select **Administrators** * Only grant necessary permissions to each admin * Avoid giving "Add Users" permission to untrusted admins * [ ] **Implement Admin Verification**: * Establish a verification process before promoting members to admin * Use separate channels (like voice calls) to confirm admin identities * Document when admin changes occur and why * [ ] **Configure Group Settings**: * Restrict member actions such as sending media or links * Enable "Slow Mode" for large groups to prevent spam * Use discussion groups for channels to control information flow * [ ] **Audit Admin Activities**: * Regularly review admin actions in the group * Remove inactive or suspicious admins * Consider using admin action logs if available * [ ] **Handle Admin Transitions Securely**: * Have protocols for transferring ownership if needed * Revoke admin rights immediately when team members leave * [ ] **Limit Group Permissions:** Restrict who can add members to groups to prevent unauthorized cloning and protect against raids. *** #### Additional Recommendations * [ ] Add a disclaimer in the description and/or as a pinned message to your channel that states that you will not DM users, and that support will only be offered via the public channel and dedicated support channels [\[2\]](#2-security-disclaimers) * [ ] Add a suffix to admin usernames, for example: "MyName | will never DM you" * [ ] Each admin must follow the guidance for securing their individual accounts *** #### Educate Community Members on Security Practices If you're managing a community on Telegram, educating your members about security is vital for collective protection. * [ ] **Regular Security Announcements**: * Schedule periodic reminders about security best practices * Pin important security announcements in your group/channel * Create dedicated security FAQ channels or posts * [ ] **Clear Verification Procedures**: * Establish and communicate how official communications will occur * Create verification steps for new members to follow * Document how to verify the authenticity of admins and official messages * [ ] **Threat Awareness Training**: * Share examples of common scams targeting your community * Post screenshots of phishing attempts (with sensitive info redacted) * Explain the "Man-in-the-Group Attack" and how to avoid it * [ ] **Incident Reporting Protocol**: * Create clear guidelines for reporting suspicious activity * Designate security-focused admins to handle reports * Acknowledge reports publicly (without specifics) to encourage vigilance * [ ] **Security Resources**: * Develop simple, accessible security guides for members * Share platform-specific security updates when Telegram releases them * Create a security checklist for new community members *** #### Notes ##### \[1] Member Control Restricting the ability to add only to admins allows for revocability of invite links to stop raids or to freeze the channel if needed. ##### \[2] Security Disclaimers Telegram channels and groups should not be used for any confidential communication, as they are not end-to-end encrypted, except for 1:1 "secret chats" (which should not be commingled with unencrypted chats). Example disclaimer: "We will NEVER message you directly to offer support or assistance with our product. For support, please email us at support@\.com. DO NOT interact with anyone DMing and claiming to be a \ member. Please report scams to reports@\.com" *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Trello Security ### Summary > 🔑 **Key Takeaway for Trello:** Enable two-step verification, review and remove unnecessary connected > applications, and regularly audit your active sessions to maintain control over your Trello boards and sensitive > project data. Trello is widely used for project management and collaboration, often containing sensitive business information. Securing your Trello account helps protect your project data, team workflows, and any confidential information stored on your boards. *** ### For Individuals These settings apply to your personal Trello account. #### Account Security Checklist * Account Settings: * [ ] Applications > Review and remove any unnecessary * [ ] Sessions > Manage your recent devices > Review and remove any unnecessary * [ ] Sessions > Two-step verification > **On** *** #### Best Practices & Additional Tips * [ ] **Use a Strong, Unique Password** * Ensure your Trello password is unique and not reused from other services. * [ ] **Review Board Permissions** * Periodically audit who has access to your boards and remove members who no longer need access. * [ ] **Be Cautious with Power-Ups** * Only enable Power-Ups from trusted sources, as they may have access to your board data. * [ ] **Check Email Notifications** * Ensure notifications are enabled so you're alerted to any unexpected board activity or access changes. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## X (Twitter) Security ### Summary > 🔑 **Key Takeaway for Twitter (X):** To secure your Twitter account, prioritize using an authenticator app or security > key over SMS-based 2FA, remove your phone number, and regularly review third-party app permissions. Ensure your > recovery settings are robust and frequently monitor account activity to safeguard your online presence and maintain > community trust. A compromised **X** account can harm not only you but also your community. Attackers often use phishing tactics—like SIM swaps or fake login screens—to seize control of your profile. A few simple steps can significantly reduce these risks. Securing your Twitter account is not particularly hard or time consuming, so consider following the best practices below. *** ### For Individuals These settings apply to your personal X (Twitter) account. All team members and admins should configure these on their own accounts. #### Account Security Checklist * Account Settings: * Settings > Security and account access > * **Security >** * [Two-factor authentication](https://x.com/settings/account/login_verification) > * [ ] Text message > **Disabled** * Two-factor authentication is a great way to keep hackers at bay, but it's not foolproof if you're relying on SMS 2FA and someone gets hold of your phone number. It's generally better to use an authenticator app or a security key. * [ ] Authentication app > **Enabled** * If using an authentication app, store your secret (TOTP) in a reliable app (Authy, Google Authenticator), but disable [syncing](https://retool.com/blog/mfa-isnt-mfa) for added security. * [ ] Security key > **Enabled** (recommended) * If using security keys, keep at least two (e.g., from [Yubico](https://www.yubico.com/)) in case one fails. * [ ] Backup codes > Save a code in a password manager (recommended) * Store this code securely, offline, ideally in a physical format like a printout, to ensure that if one device is compromised, the code remains safe. * [ ] [Password reset protect](https://x.com/settings/security) > **Enabled** * Twitter provides a feature that requires users to input their email or phone number linked to the account before they can initiate a password reset. This adds an extra layer of security by ensuring that hackers must know your email, rather than receiving a hint. * **Apps and sessions >** * [ ] [Connected apps](https://x.com/settings/connected_apps) > Remove all unnecessary * It's possible that you've linked your Twitter account to several apps, and some might have more permissions than necessary. Check each app's permissions and **Revoke** if it's no longer needed or trusted. * [ ] [Sessions](https://x.com/settings/sessions) > Log out of all other sessions * It's possible you've accessed Twitter from devices you don't regularly use, like a friend's phone. Review your active sessions and log out of any that are unfamiliar or unnecessary. Old sessions on unfamiliar devices can be risky. * [ ] Connected accounts > Confirm and disconnect any unnecessary * **Delegate >** * [ ] Allow others to invite you to their account > **Disabled** (if not necessary) * [ ] [Members you've delegated](https://x.com/settings/delegate/members) > Confirm delegate list, remove any unnecessary * It's possible to allow other accounts to access your Twitter account. If your account was previously compromised, attackers could exploit this feature to maintain access even after you've regained control. * [ ] Your account > Account information > [Phone](https://x.com/settings/phone) > **Delete number** [\[1\]](#1-email-security) * There are no good reasons to keep a phone number attached to your account, and it's the easiest way for a hacker to get into your account after SIM swapping you. Getting verified requires you to add a phone number, but you can remove it afterward. * After removing your phone number, it's crucial to navigate to Settings > Security and Account Access > Security > Two-Factor Authentication > Backup Codes. Store these codes offline, just like your seed phrase. Anyone with these codes can bypass your 2FA, so it's extremely important to write them down and keep them secure. Remember, when you change your password, new backup codes are generated. * [ ] Your account > Account information > [Email](https://x.com/settings/email) > Confirm current email * If you've changed your email since creating your Twitter account, ensure your current email is linked to receive security alerts and updates. * [ ] Your account > [Change your password](https://x.com/settings/password) > Use a unique, long, complex password * Using a unique password for Twitter is crucial. If you haven't set one, now is the time to do so. *** #### Best Practices & Additional Tips * [ ] **Disable Email and Phone Discoverability** * **Go to:** [Discoverability and Contacts](https://x.com/settings/contacts) * It is recommended to turn both email and phone discoverability off. * [ ] **Privacy & Safety Settings:** * In [Privacy & Safety](https://x.com/settings/privacy_and_safety), consider disabling "Allow message requests from everyone" to limit spam DMs and phishing attempts and enabling "Filter low-quality messages". * [ ] **Monitor for Suspicious Alerts:** * X (Twitter) may notify you about unusual activity. If you suspect a breach, log out of all sessions, revoke suspicious apps, and change your password immediately. * [ ] **Use Unique Recovery Methods:** * If you choose to use a recovery phone number, which we generally strongly advise against, make sure it isn't your main mobile number. Instead, use a separate VoIP or alternative line to minimize the risk of SIM swapping. * [ ] **Verify Email Authenticity:** * If you received an email about any content moderation, login, or any email from "X"; ensure the email is from "@x.com" *** #### Notes ##### \[1] Email Security It is recommended to ensure the email you use does not match your public name, is publicly known, or is easily guessable. You can easily work around this by supplementing your email address with a "+" suffix, for example `myemailusername+randomcharacters@gmail.com` (works with Gmail and iCloud emails). *** ### For Team Members These guidelines apply to team members who help manage X (Twitter) accounts but don't have full administrative access. Team members should: * Ensure their individual account settings are configured according to the checklist above * Understand any delegate permissions they have been granted * Be aware of phishing tactics—like SIM swaps or fake login screens—used to seize control of profiles *** ### For Admins These settings and practices apply to X (Twitter) account administrators with elevated privileges. The organization account should follow the same security settings as individuals above. #### Typefully Integration If using Typefully for team collaboration: * [ ] Ensure that team members in Typefully [have only the Write permission](https://support.typefully.com/en/articles/8717333-collaboration-in-typefully#h_0d94ada9a9), with a minimum amount of Publishers and Admins. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Vercel Security ### Summary > 🔑 **Key Takeaway for Vercel:** Secure your Vercel account by enabling two-factor authentication, reviewing personal > access tokens, and ensuring team-level security policies are enforced. Configure deployment protection, mark sensitive > environment variables appropriately, and regularly audit team member access and integrations. This checklist is adapted from [Auditware's W3OSC](https://github.com/W3OSC/web3-opsec-standard) standards. *** ### For Individuals These settings apply to your personal Vercel account. All team members and admins should configure these on their own accounts. #### Individual Account Settings For individual Vercel accounts, ensure you have: * [ ] Two-factor authentication enabled on your account * [ ] Review and remove any unnecessary personal access tokens * [ ] Review connected Git accounts and remove any unnecessary connections *** ### For Team Members These guidelines apply to team members who use Vercel but don't have full administrative access. Team members should: * Ensure their individual account settings are configured according to the checklist above * Enable two-factor authentication on their account * Regularly review and remove any unnecessary personal access tokens * Be aware of which projects they have access to and report any unexpected access * Never share environment variables or secrets outside of approved channels *** ### For Admins These settings and practices apply to Vercel team administrators with elevated privileges. #### Team Settings * Team Settings > * Members > * [ ] Team Members > **Review and remove any unnecessary or unrecognized** * [ ] Pending Invitations > **Review and remove any unnecessary or unrecognized** * [ ] Access Groups > **Review and remove any unnecessary or unrecognized** * [ ] Webhooks > **Review and remove any unnecessary or unrecognized** * Security & Privacy > * [ ] Protected Git Scopes > **Ensure Git scope is configured** * [ ] Environment Variable Policies > Enforce Sensitive Environment Variables > **Enabled** * [ ] SAML Single Sign-On > **Disabled** * [ ] Two-Factor Authentication Enforcement > **Enabled** * IP Address Visibility > * [ ] IP addresses in Vercel Dashboard > **Enabled** * [ ] IP addresses in Log Drains > **Enabled** * Deployment Protection > * [ ] Projects > **Ensure all are protected** * [ ] Access > **Review and remove any unnecessary or unrecognized** * [ ] Environment Variables > **Review and ensure all secrets are marked as Sensitive** #### Project Settings * Project Settings > Security > * [ ] Build Logs and Source Protection > **Enabled** * [ ] Git Fork Protection > **Enabled** * [ ] Secure Backend Access With OIDC Federation > **Team** *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Compliance with Regulatory Requirements Compliance with regulatory requirements may be essential for your project. Understanding the needs and ensuring the necessary compliance helps protect your project from potential legal penalties. ### Key Regulatory Frameworks Some examples of regulatory frameworks or standards for web3 are: * **GDPR (General Data Protection Regulation)**: Applies to organizations handling the personal data of EU citizens. It mandates strict data protection measures and grants individuals significant rights over their data, as seen on [https://gdpr.eu/](https://gdpr.eu/). * **MiCA**: Companies seeking to offer crypto services or assets within the EU are in scope. While this may seem daunting, there are different levels of compliance needed depending on the project, as can be seen on [https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica) ### Best Practices for Compliance ## Best Practices for Regulatory Compliance in Terms of Security ### 1. Understand Applicable Regulations * **Identify Relevant Regulations:** Clearly identify all regulatory frameworks that apply to your organization, such as GDPR, HIPAA, CCPA, or PCI DSS. * **Regularly Review Legal Requirements:** Stay updated on changes in regulations that impact your industry, ensuring compliance measures evolve accordingly. * **Engage Legal Counsel:** Work with legal experts to interpret regulations accurately and implement appropriate security controls. ### 2. Develop a Robust Security Policy Framework * **Comprehensive Security Policies:** Develop detailed security policies that align with regulatory requirements, covering areas like data protection, access control, and incident response. * **Policy Documentation:** Maintain thorough documentation of all security policies, procedures, and controls, ensuring they are easily accessible for audits and reviews. * **Regular Policy Updates:** Review and update security policies regularly to reflect changes in regulations and emerging threats. ### 3. Data Protection and Privacy * **Data Classification:** Classify data based on sensitivity and regulatory requirements, ensuring appropriate protection levels for each category. * **Data Minimization:** Collect and retain only the minimum amount of data necessary for business operations, reducing exposure to potential breaches. * **Anonymization and Pseudonymization:** Where possible, apply anonymization or pseudonymization techniques to protect personal data. ### 4. Access Management and Control * **Role-Based Access Control (RBAC):** Implement RBAC to ensure that employees have access only to the data and systems necessary for their roles. * **Multi-Factor Authentication (MFA):** Require MFA for access to sensitive systems and data, adding an extra layer of security. * **Regular Access Audits:** Conduct regular audits of user access rights to ensure compliance with the principle of least privilege. ### 5. Incident Response Planning * **Comprehensive Incident Response Plan:** Develop an incident response plan that aligns with regulatory requirements, detailing steps for identifying, responding to, and reporting security incidents. * **Regulatory Reporting:** Ensure the incident response plan includes protocols for reporting breaches to regulatory authorities within the required timeframes. * **Regular Testing:** Conduct regular simulations and tabletop exercises to test the effectiveness of the incident response plan. ### 6. Continuous Monitoring and Auditing * **Automated Monitoring Tools:** Implement automated tools to continuously monitor compliance with security regulations and detect potential vulnerabilities or breaches. * **Internal Audits:** Conduct regular internal audits to assess compliance with security policies and regulatory requirements. * **External Audits:** Engage third-party auditors to provide independent assessments of your security posture and compliance status. ### 7. Employee Training and Awareness * **Regular Training Programs:** Provide regular training on regulatory requirements, data protection, and security best practices for all employees. * **Phishing and Social Engineering Awareness:** Educate employees about phishing, social engineering, and other common attack vectors that could lead to compliance breaches. * **Role-Specific Training:** Tailor training programs to address the specific regulatory and security responsibilities of different roles within the organization. ### 8. Third-Party Risk Management * **Vendor Due Diligence:** Conduct thorough due diligence on third-party vendors to ensure they comply with relevant security regulations. * **Contractual Obligations:** Include specific security and compliance requirements in contracts with third-party vendors. * **Continuous Monitoring:** Monitor third-party vendors’ compliance with security requirements throughout the relationship. ### 9. Data Encryption and Secure Communication * **Encryption Standards:** Use strong encryption standards for protecting data both at rest and in transit, in line with regulatory requirements. * **Secure Communication Channels:** Ensure that all communication involving sensitive data is conducted over secure channels (e.g., TLS, VPN). * **Key Management:** Implement robust key management practices to protect encryption keys from unauthorized access. ### 10. Documentation and Record-Keeping * **Compliance Documentation:** Maintain detailed records of compliance efforts, including audit results, incident reports, and training logs. * **Retention Policies:** Establish data retention policies that comply with regulatory requirements, ensuring that records are kept for the required duration. * **Audit Trails:** Ensure that all access to sensitive data is logged, creating a clear audit trail for compliance verification. ## Useful Resources Here are some useful resources where you can follow and learn more about the best practices mentioned: 1. **National Institute of Standards and Technology (NIST)** * **NIST Cybersecurity Framework:** A comprehensive resource for implementing cybersecurity best practices and complying with regulatory requirements. * URL: [https://www.nist.gov/cyberframework](https://www.nist.gov/cyberframework) 2. **International Organization for Standardization (ISO)** * **ISO/IEC 27001 Information Security Management:** The leading international standard for information security management, providing guidelines for establishing, implementing, and maintaining an effective security program. * URL: [https://www.iso.org/isoiec-27001-information-security.html](https://www.iso.org/isoiec-27001-information-security.html) 3. **Center for Internet Security (CIS)** * **CIS Controls:** A prioritized set of actions that help organizations comply with regulatory requirements and improve their cybersecurity posture. * URL: [https://www.cisecurity.org/controls/](https://www.cisecurity.org/controls/) 4. **General Data Protection Regulation (GDPR)** * **Official GDPR Portal:** Provides detailed information on GDPR requirements, including guidelines, tools, and resources for compliance. * URL: [https://gdpr.eu/](https://gdpr.eu/) 5. **Health Insurance Portability and Accountability Act (HIPAA)** * **HIPAA Journal:** Offers news, resources, and guidelines for ensuring compliance with HIPAA regulations, particularly in the healthcare sector. * URL: [https://www.hipaajournal.com/](https://www.hipaajournal.com/) 6. **Payment Card Industry Data Security Standard (PCI DSS)** * **Official PCI Security Standards Council:** Provides comprehensive resources, including guidelines and tools for complying with PCI DSS requirements. * URL: [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/) 7. **Cybersecurity & Infrastructure Security Agency (CISA)** * **CISA Best Practices:** Offers guidelines and resources for improving cybersecurity, including incident response planning and third-party risk management. * URL: [https://www.cisa.gov/publication/best-practices](https://www.cisa.gov/publication/best-practices) 8. **Cloud Security Alliance (CSA)** * **CSA Security Guidance for Cloud Computing:** Provides best practices and guidance for ensuring compliance and security in cloud environments. * URL: [https://cloudsecurityalliance.org/artifacts/security-guidance-v4/](https://cloudsecurityalliance.org/artifacts/security-guidance-v4/) 9. **International Association of Privacy Professionals (IAPP)** * **IAPP Resource Center:** Offers a wealth of resources, including whitepapers, research, and tools, to help organizations comply with data protection regulations. * URL: [https://iapp.org/resources/](https://iapp.org/resources/) 10. **SANS Institute** * **SANS Security Resources:** Provides extensive resources, including guides, whitepapers, and training courses, for improving security and regulatory compliance. * URL: [https://www.sans.org/security-resources/](https://www.sans.org/security-resources/) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Security Council Best Practices in Rollup Governance > **Attribution**: This section is based on > [From Stage 0 to Stage 1: Security Council Best Practices in Rollup Governance](https://www.openzeppelin.com/news/security-council-best-practices-guide) > by [OpenZeppelin](https://www.openzeppelin.com), > authored by Bram Hoogenkamp and Michael Lewellen. Security Councils serve as specialized governance bodies that act as the final line of defense against exploits, governance attacks, and systemic failures in decentralized protocols. This guide focuses primarily on rollups and other upgradeable protocols with emergency powers, where a Security Council may need narrowly scoped authority to pause systems, approve emergency actions, or coordinate urgent mitigation. ### Understanding Security Councils Security Councils are designated groups with elevated permissions to respond to emergencies and protect protocol integrity. Their core responsibilities include: * **Threat Identification**: Monitoring for emerging security vulnerabilities and attack vectors * **Emergency Response**: Coordinating rapid actions such as pausing operations or deploying emergency patches * **Protocol Stewardship**: Conducting routine security reviews and maintaining long-term protocol health * **Risk Mitigation**: Implementing preventive measures before threats materialize Unlike traditional governance bodies focused on feature development and parameter adjustments, Security Councils specialize in crisis management and defensive operations. ### Formation and Timing #### When to Establish a Security Council Security Councils should be formed once protocols achieve sufficient maturity: **Prerequisites:** * Clear governance structures with defined decision-making processes * Documented operational standards and security procedures * Active community participation and stakeholder engagement * Identified security risks requiring specialized oversight **Timing Considerations:** * **Too early**: Creates unnecessary overhead when protocols lack complexity requiring Council intervention * **Too late**: Leaves protocols vulnerable during crisis situations without established response frameworks * **Optimal window**: When transitioning from Stage 0 to Stage 1 in rollup maturity, or when governance attack surface increases significantly Regular reviews ensure the Council's structure remains aligned with evolving protocol risks and governance requirements. ### Key Roles and Responsibilities #### Member Composition Effective Security Councils balance diverse expertise: **Technical Security Expertise:** * Smart contract security and auditing experience * Cryptography and protocol design knowledge * Infrastructure and operational security backgrounds **Crisis Management Experience:** * Proven incident response capabilities * Decision-making under pressure * Communication during emergencies **Legal and Compliance Knowledge:** * Understanding of regulatory requirements * Risk assessment frameworks * Documentation and transparency standards #### Selection and Governance **Transparent Selection Process:** * A documented nomination, appointment, or election process appropriate to the protocol's governance model * Public disclosure of selection criteria * Documented qualifications, conflicts of interest, and removal conditions **Term Limits and Rotation:** * Fixed term lengths (typically 6-12 months) * Staggered rotations to maintain institutional knowledge * Clear succession planning #### Service Level Agreements (SLAs) **Establish explicit operational expectations defining:** * Response expectations for credible critical threats (e.g., acknowledge critical threats within 1 hour) * Review timelines for emergency and non-emergency changes (e.g., evaluate proposed changes within 48 hours) * Communication requirements during incidents * Availability expectations for Council members These expectations should be calibrated to protocol risk, signer geography, and operational reality rather than copied as universal defaults. ### Multi-Sig Setup and Custody #### Configuration Models **Individual EOA Signers:** * Simple setup with each member controlling a single externally owned account * Suitable for smaller Councils with high trust requirements * Vulnerable to individual key compromise **Safe-of-Safes Architecture:** * Member organizations maintain their own multi-signature wallets * Council multi-sig requires signatures from multiple member Safes * Reduces single-key compromise risk * Increases operational complexity #### Security Best Practices **Key Management:** * Use hardware wallets exclusively for Council signing operations * Maintain dedicated accounts solely for Security Council actions * Avoid casual backup copies that increase compromise surface area * Store hardware wallets in secure physical locations (safes, safety deposit boxes) **Threshold Configuration:** * Balance accessibility with security (common: 4-of-6, 5-of-7) * Consider time-sensitivity requirements for emergency responses * Document threshold justifications and review periodically **Key Rotation:** * Rotate signing keys after member changes, suspected compromise, custody changes, or on a defined schedule * Document rotation procedures in advance * Test rotation in non-emergency conditions before incidents #### Liveness and Accountability ##### Example: Optimism's LivenessGuard Optimism's Security Council implements a [LivenessGuard](https://specs.optimism.io/protocol/safe-extensions.html#the-liveness-module) (a Safe module) that automatically removes inactive members while preserving security thresholds. This mechanism: * Tracks member signing activity over defined periods * Prevents governance deadlocks from unavailable signers * Maintains operational continuity during emergencies * Creates accountability through transparent activity metrics ### Incident Response #### Response Framework Effective incident response follows structured phases: ##### 1. Detection * Automated monitoring systems for on-chain anomalies * Community reporting channels * Threat intelligence feeds * Internal security audits ##### 2. Assessment * Severity classification using predefined criteria * Impact analysis across protocol components * Likelihood evaluation based on threat intelligence * Scope definition to prevent mission creep ##### 3. Action * Automated pausing mechanisms for critical vulnerabilities * Manual intervention for complex situations * Emergency upgrade procedures with defined approval thresholds * Coordination with broader DAO governance when appropriate ##### 4. Communication * Rapid notification to stakeholders via established channels * Single source of truth during incidents (avoid conflicting information) * Transparent disclosure of publicly-safe information * Reserved communication of sensitive details requiring investigation ##### 5. Resolution and Postmortem * Public incident reports documenting response timeline * Corrective actions and prevention measures * Council performance evaluation * Lessons learned integration into procedures #### Emergency Classification Define emergency categories before crises occur using a decision matrix: | Severity | Likelihood | Examples | Response | | -------- | ---------- | ----------------------------------------- | ------------------------------------------ | | Critical | High | Active exploit draining funds | Immediate pause, emergency upgrade | | Critical | Low | Theoretical attack requiring coordination | Accelerated review, preventive measures | | Medium | High | Governance manipulation attempt | Enhanced monitoring, parameter adjustments | | Medium | Low | Potential future vulnerability | Standard review process | | Low | Any | Minor UI bugs, documentation issues | Normal operations, no Council action | #### Automated vs. Manual Pausing **Automated Mechanisms:** * Trigger-based responses to predefined conditions * Faster response times for known attack patterns * Reduced human error during high-stress situations * Risk of false positives disrupting operations **Manual Intervention:** * Required for complex situations requiring judgment * Allows contextual assessment before action * Slower response times * Potential for delayed response during off-hours In practice, the safest approach is usually narrowly scoped, well-tested automation for detection or limited containment, combined with manual and accountable authorization for broader emergency actions. #### Communication During Incidents **Immediate Disclosure:** * Confirm incident detection and Council activation * Provide high-level impact assessment * Share mitigation actions taken * Set expectations for updates **Reserved Information:** * Exploit technical details while vulnerability remains * Ongoing investigation findings * Internal deliberation processes * Attribution to specific actors (until confirmed) **Post-Incident Transparency:** * Full timeline documentation * Technical root cause analysis * Effectiveness of response measures * Preventive measures for future incidents ### Governance Integration Security Councils must operate within broader DAO governance frameworks: #### Escalation Paths Define clear conditions requiring DAO approval: * Non-emergency protocol upgrades * Changes to Council powers or composition * Parameter modifications outside emergency scope * Major architectural changes **Example Decision Tree:** ``` Is immediate action required to prevent loss of funds? ├─ Yes → Security Council emergency authority └─ No → Does change affect core protocol economics? ├─ Yes → Full DAO governance process └─ No → Council review with timelock ``` #### Power Boundaries Establish explicit limits on Council authority: * Exact emergency actions permitted without DAO approval * Maximum funds, systems, or contracts reachable under emergency authority * Types of contract modifications permitted * Duration of emergency measures before expiration, ratification, or formal review * Required post-incident disclosure and governance review * Geographic or jurisdictional restrictions where relevant Emergency authority should be narrow, time-bounded, and designed to contain incidents, not to bypass normal governance for convenience. Regular parameter reviews ensure powers remain proportional to evolving risks. #### Cross-Protocol Collaboration Security Councils benefit from coordinated efforts: **Shared Monitoring Infrastructure:** * Joint threat intelligence networks * Collaborative vulnerability disclosure * Cross-protocol security audits * Coordinated response to ecosystem-wide threats **Industry Partnerships:** * SEAL 911 emergency war room access for crisis coordination * SEAL Drill Templates for standardized readiness testing * Shared postmortem analysis across protocols * Collective security research initiatives ##### Example: Compound Wargame Simulation The SEAL Chaos Team, OpenZeppelin, and Compound Labs conducted a simulated oracle attack exercise (2023). The SEAL Chaos Team simulated a rogue oracle inflating WETH prices by 28%, risking a $650K USDC drain from Compound's Comet pool: * Automated detection tools identified price manipulation * Coordinated response roles between security teams * Communication protocols tested under simulated pressure * Lessons learned documented for industry benefit ### Readiness Drills and Maintenance #### Operational Preparedness **Scheduled Drills:** * Quarterly incident response simulations * Annual key rotation exercises * Semi-annual communication tests * Scenario-based tabletop exercises **Unannounced Liveness Tests:** * Random signing requirement notifications * Response time monitoring * Member availability verification * Backup communication channel validation **Travel and Availability Policies:** * Physical security protocols during travel * Backup signer designation during planned absence * Geographic distribution requirements * Redundant access to signing infrastructure #### Documentation Standards **Public Transparency:** * Member identities and qualifications * Selection criteria and processes * Term lengths and rotation schedules * Voting thresholds and quorum requirements * Response-time SLAs * High-level incident response framework * Upgrade procedures **Private Records:** * Detailed drill results and performance metrics * Internal decision logs for continuous improvement * Sensitive security assessments * Confidential communications during incidents **Living Documentation:** * Regular updates reflecting lessons learned * Version control for procedural changes * Accessibility for new members * Community feedback integration #### Continuous Improvement Security Councils should evolve through: * Post-drill retrospectives identifying gaps * Regular security landscape assessments * Member feedback on operational challenges * Community input on Council effectiveness * Benchmark comparisons with other protocols ### Integration with SEAL Resources Security Councils can leverage existing SEAL infrastructure: **SEAL 911 War Rooms:** * Emergency coordination channels for active incidents * Expert assistance during crises * Cross-protocol collaboration facilities * See [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines) **SEAL Drill Templates:** * Standardized scenario testing frameworks * Documented best practices from industry incidents * Tabletop exercise materials * Performance metrics for readiness assessment **Incident Management Playbooks:** * Response procedures for common attack vectors * Communication templates * Escalation frameworks * See [Incident Management](/incident-management/overview) ### Best Practices Summary 1. **Establish clear prerequisites** before forming Security Councils to avoid premature overhead 2. **Balance diverse expertise** across technical security, crisis management, and compliance domains 3. **Implement robust key management** with hardware wallets, tested rotation procedures, and liveness mechanisms 4. **Define emergencies explicitly** using severity matrices before crises occur 5. **Maintain transparent communication** with predefined channels and disclosure protocols 6. **Integrate with DAO governance** through clear escalation paths and power boundaries 7. **Conduct regular drills** combining scheduled exercises and unannounced tests 8. **Document thoroughly** with public transparency and private operational records 9. **Collaborate across protocols** through shared monitoring and threat intelligence 10. **Continuously improve** based on drills, incidents, and community feedback ### Additional Resources * [OpenZeppelin Security Council Best Practices Guide](https://www.openzeppelin.com/news/security-council-best-practices-guide) * [Incident Management Framework](/incident-management/overview) * [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines) * [Multisig for Protocols](/multisig-for-protocols/overview) * [Risk Management](/governance/risk-management) *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Governance > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Governance](/governance/overview) * [Compliance & Regulatory Requirements](/governance/compliance-regulatory-requirements) * [Risk Management](/governance/risk-management) * [Security Metrics & KPIs](/governance/security-metrics-kpis) * [Security Council Best Practices](/governance/council-best-practices) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Governance Good governance practices involve setting clear policies, establishing accountability, and continuously monitoring and improving security measures. This section provides some best practices and guidelines for how you could implement governance in your project. ### Contents 1. [Compliance with Regulatory Requirements](/governance/compliance-regulatory-requirements) 2. [Risk Management](/governance/risk-management) 3. [Security Metrics and KPIs](/governance/security-metrics-kpis) 4. [Security Council Best Practices](/governance/council-best-practices) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Risk Management If a project has effective risk management, it is also likely to be successful at identifying, assessing, and mitigating potential threats to the project. By utilizing risk management, you're likely to be able to prioritize security efforts and see where resources are needed. Risk management provides the capabilities to develop and implement strategies to mitigate identified risks by continuously monitoring the security landscape for new threats and vulnerabilities and then communicating risk findings and mitigation strategies to relevant people. ### Best Practices for Risk Management 1. Use established frameworks such as NIST, ISO 27001, or COBIT to help start your risk management efforts. 2. Focus on the most critical risks first, using a risk matrix to prioritize based on likelihood and impact. 3. Conduct regular risk assessments and reviews to keep up with the rapidly evolving threat landscape. 4. Use lessons learned from past incidents and risk assessments to continuously improve your risk management practices. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Security Metrics and KPIs Measuring security performance through metrics and Key Performance Indicators (KPIs) can be very useful for assessing the effectiveness of your security program, and can allow you to make informed decisions on what actions to take with regards to security. Some examples of what could be worth recording are: ### Key Security Metrics 1. Measure the time taken to detect, respond to, and resolve security incidents. 2. Track the total number of security incidents over a specified period. 3. Measure the time taken to fix identified vulnerabilities. 4. Monitor the rate of false positives generated by security tools to assess their accuracy and efficiency. ### Key Performance Indicators (KPIs) * **Mean Time to Detect (MTTD)**: The average time taken to detect a security incident. * **Mean Time to Respond (MTTR)**: The average time taken to respond to a security incident. * **Patch Management Effectiveness**: Percentage of code/systems patched within a defined timeframe. * **User Training Completion Rate**: Percentage of project team members who have completed required security training. * **Security Audit Findings**: Number of findings from security audits and the percentage of findings resolved within a specified period. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Common Vulnerabilities Understanding and mitigating common vulnerabilities is crucial for securing your web and mobile applications. Here are some frequently encountered vulnerabilities: ### General Vulnerabilities * **Account Takeovers**: Having the administrator accounts for your services (DNS, Cloud, Domain Registrar, Email, GitHub, etc.) is likely to be devastating to your project, as a threat actor can then make malicious changes. To protect against this, it is recommended to follow best practices with regards to account security and use hardware 2FA solutions to secure the accounts. ### Web Application Vulnerabilities * **Cross-Site Scripting (XSS)**: Malicious scripts injected into trusted websites, leading to data theft or session hijacking. * **Cross-Site Request Forgery (CSRF)**: Unauthorized commands transmitted from a user trusted by the web application. * **Insecure Direct Object Reference (IDOR)**: Unauthorized access to data by manipulating input parameters. ### Mobile Application Vulnerabilities * **Insecure Data Storage**: Sensitive data stored in an insecure manner on the device. * **Insufficient Transport Layer Protection**: Lack of encryption for data transmitted over the network. * **Insecure Authentication and Authorization**: Weak authentication mechanisms and improper authorization checks. * **Code Tampering**: Modifications to the application code by attackers. Refer to the [OWASP Top 10](https://owasp.org/www-project-top-ten/) and [OWASP Mobile Security Project](https://owasp.org/www-project-mobile-top-10/) for more details on common vulnerabilities and mitigation strategies. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Front End Web App > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Front-End Web Application Security](/front-end-web-app/overview) * [Web Application Security](/front-end-web-app/web-application-security) * [Third-Party Script Security](/front-end-web-app/third-party-script-security) * [Mobile Application Security](/front-end-web-app/mobile-application-security) * [Common Web Vulnerabilities](/front-end-web-app/common-vulnerabilities) * [Security Tools & Resources](/front-end-web-app/security-tools-resources) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Mobile Application Security Mobile applications are increasingly used as front-ends for web3 protocols. As more projects are using mobile applications, it also becomes an increasing target for threat actors. Below, you can find some suggestions to help protect your mobile application: ### Best Practices 1. Follow secure coding practices to prevent common vulnerabilities such as: * Insecure Data Storage * Insufficient Transport Layer Protection * Insecure Authentication * Insecure Authorization 2. Use the trusted execution environment available in the device for secret management. 3. Ensure that APIs used by the mobile application are secure and follow best practices for authentication and authorization by implementing certificate pinning to help prevent man-in-the-middle attacks. 4. Encrypt sensitive data stored on the device and during transmission. 5. Keep the mobile application and its dependencies updated to protect against known vulnerabilities. 6. Leverage security libraries and frameworks designed for mobile application security, such as OWASP Mobile Security Project. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Front-End Web Application Security Best Practices Although often overlooked, ensuring the security of your front-end web and potential mobile applications is crucial for protecting your users. If the front-end web application is compromised, it could have severe effects on your users as they could, for example, start interacting with a malicious contract instead of your official contract. ### Contents 1. [Web Application Security](/front-end-web-app/web-application-security) 2. [Mobile Application Security](/front-end-web-app/mobile-application-security) 3. [Third-Party Script Security](/front-end-web-app/third-party-script-security) 4. [Common Vulnerabilities](/front-end-web-app/common-vulnerabilities) 5. [Security Tools and Resources](/front-end-web-app/security-tools-resources) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Security Tools and Resources There are a very large number of security tools and resources available, and sometimes it can feel overwhelming. There is a wide range of security tools to test your web & mobile applications, such as OWASP ZAP or Burp Suite to scan your application for vulnerabilities, Snyk to check your dependencies, or MobSF for security analysis on Android/iOS applications. For web3, there is also a wide range of tools. Rather than listing specific tools, we are providing links to repositories listing many of these tools: * [https://github.com/safful/Web3-Security-Tools](https://github.com/safful/Web3-Security-Tools) * [https://github.com/OffcierCia/On-Chain-Investigations-Tools-List](https://github.com/OffcierCia/On-Chain-Investigations-Tools-List) * [https://github.com/shanzson/Smart-Contract-Auditor-Tools-and-Techniques](https://github.com/shanzson/Smart-Contract-Auditor-Tools-and-Techniques) * [https://github.com/Anugrahsr/Awesome-web3-Security](https://github.com/Anugrahsr/Awesome-web3-Security) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Third-Party Script Security > 🔑 **Key Takeaway:** Every third-party script running on your frontend shares your page's origin, meaning it > can access cookies, localStorage, session tokens, and call `window.ethereum` methods directly. Use Content > Security Policy, Subresource Integrity, and Trusted Types to control what code executes, verify it has not > been tampered with, and lock down dangerous DOM APIs. Web3 frontends are high-value targets because they sit between users and their wallets. Every script that runs on your page executes with the same permissions as your own code. When a user visits your application and signs a transaction, any script on the page can observe, modify, or replace that interaction. If an attacker compromises a third-party script your frontend loads (a CDN-hosted library, an analytics snippet, a wallet connector), they can silently redirect transactions, drain wallets, or harvest credentials without touching your own code. This is not a theoretical concern. Multiple attacks have exploited third-party scripts to compromise Web3 frontends at scale (see [Past Incidents](#past-incidents) below). Three browser-native mechanisms, **Content Security Policy (CSP)**, **Subresource Integrity (SRI)**, and **Trusted Types**, provide strong defenses against these attacks. Neither requires external tooling or dependencies because they are built into every modern browser. ### Content Security Policy (CSP) A Content Security Policy is an HTTP response header that tells the browser which sources of content are permitted to load on your page. If a script, style, image, or connection does not match your policy, the browser blocks it. This means that even if an attacker injects a ` ``` #### How It Works 1. You generate a SHA-256, SHA-384, or SHA-512 hash of the exact file you expect to load. 2. You include this hash in the `integrity` attribute of the ` ``` With this import map in place, any code that runs `import('ethers')` will resolve to your self-hosted copy, not to an external CDN. Combined with a CSP that restricts `script-src` to your own origin (or uses `strict-dynamic`), this gives you centralized control over module resolution even for dynamic imports. Import maps do not replace SRI. They address a different part of the problem: SRI verifies file integrity; import maps control where files are loaded from. Use them together: import maps to pin resolution to known locations, and SRI on any statically loaded scripts from those locations. ### Trusted Types Trusted Types is a browser API (enforced via CSP) that prevents DOM-based cross-site scripting by locking down dangerous sink APIs. Functions like `innerHTML`, `outerHTML`, `document.write`, `eval`, and `setTimeout(string)` are the most common vectors for DOM XSS. Trusted Types makes it impossible to pass raw strings to these sinks. You must instead pass a "trusted" value created through a policy you define. For Web3 frontends, this is directly relevant. Wallet connection flows, transaction confirmation UIs, and token approval dialogs often manipulate the DOM. If an attacker can inject markup through a compromised dependency that uses `innerHTML`, they can render a fake approval dialog or redirect a transaction. Trusted Types block this class of attack at the API level. #### Enabling Trusted Types Add `require-trusted-types-for 'script'` to your CSP header: ``` Content-Security-Policy: require-trusted-types-for 'script'; trusted-types myapp-policy; ``` Then define a named policy in your application code. At minimum the policy should sanitize HTML input before it reaches the DOM (using a library like DOMPurify), block dynamic script creation, and restrict script URLs to your own origin. The [MDN Trusted Types documentation](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API) and the [Google adoption guide](https://web.dev/articles/trusted-types) cover policy implementation in detail. #### Adoption Strategy Trusted Types can be disruptive to adopt because many libraries (including some wallet connectors) use `innerHTML` internally. Roll it out gradually: 1. **Start in report-only mode** using `Content-Security-Policy-Report-Only` with `require-trusted-types-for 'script'`. This logs violations without breaking anything. 2. **Identify violating code** from the reports. Common culprits are UI libraries, rich text rendering, and third-party widgets. 3. **Create a `default` policy** as a transitional measure. The browser calls it for any assignment that does not already use a trusted type, letting you handle violations centrally before enforcing per-policy. 4. **Enforce** once violations are resolved. Trusted Types are supported across all modern browsers as of early 2026. The CSP directive degrades gracefully on older browsers: it is simply ignored, so it will not break your application. ### Self-Hosting Critical Dependencies The strongest defense against third-party script compromise is to eliminate the third party entirely by bundling dependencies into your own build output. CSP and SRI reduce the risk of loading external scripts; self-hosting removes it. For guidance on vendoring, version pinning, and managing the operational trade-offs, see [Dependency Awareness](/supply-chain/dependency-awareness). ### Past Incidents These attacks demonstrate why third-party script controls are not optional for Web3 frontends: * **npm registry attack (September 2025).** A maintainer's credentials were phished and malicious versions of 18 widely-used packages, including `chalk`, `debug`, and `ansi-styles`, were published. The payload hooked `window.ethereum` to intercept wallet calls and rewrote `fetch`/`XMLHttpRequest` to reroute transactions to attacker-controlled addresses. SRI would have blocked the tampered scripts; a strict `connect-src` policy would have prevented exfiltration. * **Lottie Player (October 2024).** Malicious versions of `@lottiefiles/lottie-player` were published, injecting a crypto drainer into any site displaying Lottie animations. The payload prompted users to connect their wallets and drained funds. Applications loading the library via CDN without SRI were immediately vulnerable. * **Polyfill.io (June 2024).** After a change in ownership, the `polyfill.io` CDN began injecting malicious redirects into a script served to over 100,000 websites, targeting mobile users. Sites using SRI would have blocked the modified script entirely. * **Ledger Connect Kit (December 2023).** A former employee's npm credentials were used to publish a malicious version of `@ledgerhq/connect-kit`. The injected code rendered a fake wallet connection modal that redirected funds. Every application loading the library without integrity checks was affected simultaneously. For a broader catalog of supply chain attack vectors, see [Web3 Supply Chain Threats](/supply-chain/web3-supply-chain-threats). ### Runtime Monitoring Build-time defenses (CSP, SRI, self-hosting) establish the baseline, but you also need visibility into what happens at runtime in production. Attacks do not always come through the vectors you anticipated, and misconfigurations can silently weaken your defenses. #### CSP Violation Reporting Start every new policy in report-only mode using `Content-Security-Policy-Report-Only`. This logs what would be blocked without breaking anything. Review the reports, adjust the policy, and only switch to the enforcing `Content-Security-Policy` header once you are confident it will not break legitimate functionality. After switching to enforcement, keep `report-to` configured so any new violations surface immediately. Set `report-to` in your CSP header and pair it with a `Report-To` header that points to a collection endpoint you control. Every blocked resource generates a report containing the violated directive, the blocked URI, and the page where it happened. Aggregate these to detect injection attempts, misconfigurations after deployments, and third-party scripts loading unexpected resources. #### DOM Mutation Monitoring CSP cannot detect all forms of script injection, particularly when a trusted script's behavior changes (for example, a compromised dependency that starts injecting iframes or modifying wallet-related DOM elements). MutationObservers let you watch for suspicious changes at runtime: flag any script node added without a nonce, and remove unexpected iframes that were not part of your known page structure. This is not a replacement for CSP. It is a detection layer. Use it to catch things that slip through policy gaps or to monitor for unexpected behavior from trusted scripts. #### External Script Change Detection For any script you load from a third-party origin (even with SRI), run a periodic job that fetches the resource and compares its hash to the expected value. A hash mismatch on a resource that should not have changed is an early indicator of a supply chain compromise. Integrate this into your CI pipeline and your production monitoring separately: CI catches changes at build time, production monitoring catches changes at serve time. ### Additional Defenses Beyond the core mechanisms above, consider these complementary measures: * **Iframe sandboxing for third-party widgets.** If you must embed third-party content, load it in sandboxed iframes with restrictive `sandbox` attributes. This isolates it from your main page context and prevents it from interacting with wallet-related DOM or JavaScript. * **Permissions Policy.** The `Permissions-Policy` HTTP header restricts which browser features third-party scripts and frames can access: payment APIs, clipboard, camera, and others. Even if a compromised script runs, it cannot invoke features your application never needed. ### Further Reading * [MDN: Subresource Integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) -> API reference and browser compatibility * [MDN: Securing CDN resources with SRI](https://developer.mozilla.org/en-US/blog/securing-cdn-using-sri-why-how/) -> walkthrough on applying SRI to CDN-hosted assets * [MDN: Import Maps](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap) -> specification and usage guide * [MDN: Trusted Types](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API) -> API reference and browser compatibility * [Google: Trusted Types Adoption Guide](https://web.dev/articles/trusted-types) -> step-by-step policy implementation guide ### Related Frameworks * [Supply Chain Security](/supply-chain/overview): Dependency management, vendor risk, and incident response for compromised components * [Web3 Supply Chain Threats](/supply-chain/web3-supply-chain-threats): Catalog of frontend, smart contract, and infrastructure attack vectors * [Dependency Awareness](/supply-chain/dependency-awareness): Version pinning, lockfile integrity, and vulnerability scanning for the packages your frontend loads * [DevSecOps](/devsecops/overview): Integrating security checks into your build and deployment pipelines * [Domain & DNS Security](/infrastructure/domain-and-dns-security/overview): Preventing DNS hijacking and CDN cache poisoning *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Web Application Security Providing a secure front-end (web application) for users to interact with your web3 protocol is often essential. Web application vulnerabilities have however been exploited in the past to steal user funds, and as such it's important to take web application security into consideration for your project. ### Best Practices 1. Utilize popular and well-maintained web application frameworks when developing your application. 2. Familiarize yourself with common web application vulnerabilities that may affect your decentralized application such as Cross-Site Scripting (XSS). Refer to the [OWASP Top 10](https://owasp.org/www-project-top-ten/) for a comprehensive list. 3. Minimize the introduction of custom components in your framework. Ensure that any custom code undergoes thorough internal and external security testing. 4. Refer to the [Infrastructure/DDoS Protection](/infrastructure/ddos-protection) section for insights on ensuring high availability of your protocol’s front-end. 5. Lock down access to associated back-end services, such as S3 buckets, to prevent unauthorized access. 6. Consider deploying additional versions of your front-end on IPFS to ensure availability and resilience. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## External Security Reviews > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [External Security Reviews](/external-security-reviews/overview) * [Security Policies & Procedures](/external-security-reviews/security-policies-procedures) * [Smart Contracts](/external-security-reviews/smart-contracts) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## External Security Reviews An external security review is a time-boxed, security-based assessment of software systems, applications, and infrastructure to enhance security and identify vulnerabilities. External security reviews are essential for organizations to protect against threats and build trust with users and stakeholders. ### Why Are External Security Reviews Important? According to research, significant value and data have been compromised due to security vulnerabilities in software systems. Modern applications face complex threats from malicious actors, and security issues can lead to data breaches, financial losses, and reputation damage. Beyond preventing security incidents, external security reviews provide several key benefits: * **Enhanced Security**: Find and fix vulnerabilities before they can be exploited * **Team Education**: Level up your engineering team's knowledge through security best practices * **Trust Building**: Demonstrate maturity and safety to users and stakeholders * **Risk Mitigation**: Identify business logic issues and implementation flaws * **Compliance**: Meet regulatory and industry security requirements ### Scope of External Security Reviews Security reviews can encompass multiple layers of an organization's technology stack: * **Applications**: Web applications, mobile apps, APIs, and microservices * **Infrastructure**: Cloud configurations, network security, access controls, and deployment pipelines * **Data Systems**: Databases, data processing pipelines, and storage security * **Third-party Integrations**: External APIs, libraries, and vendor services * **Documentation**: Technical specifications, security policies, and incident response procedures External security reviews are not foolproof and cannot guarantee absolute security. They represent an ongoing commitment to safety rather than a one-time event. ### Contents There are many different kinds of external security reviews, and we have some context on many of them here. 1. [Smart Contract Audits](/external-security-reviews/smart-contracts/overview) 2. [Security Policies and Procedures](/external-security-reviews/security-policies-procedures) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Security Policies and Procedures As part of the external security review, it could be beneficial to also review the internal security policies and procedures as well. Some of the things that could be relevant to review are: 1. Ensure there is a developed and maintained plan for responding to security incidents. 2. Ensure there are defined roles and responsibilities, and enforce the principle of least privilege. 3. Ensure there are processes implemented for managing changes to the codebase and infrastructure. 4. Ensure there are regular training sessions conducted for all team members on security best practices. 5. Ensure adherence to any potentially relevant regulatory and industry standards for your project. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Expectations ### Scoping Phase The team looking for a security review will agree with the auditors/security researchers the exact parameters of the review. What *exact* contracts should they review? What should they not review? This is incredibly important so the can clearly estimate timelines on how long a review may take. This is also where compensation is discussed, usually the more aspects a team wants to review, the more expensive the audit will be. ### Initial Assessment Phase * **Automated Testing**: Auditors will run various automated security tools including static analysis, fuzz testing, formal verification, and unit testing to identify basic vulnerabilities * **Manual Code Review**: Security researchers will manually analyze the code to understand context, complexity, and identify deeper vulnerabilities that automated tools might miss * **Documentation Review**: Auditors will review project specifications and documentation to understand intended functionality ### Deliverables A comprehensive security review will generate the following: #### Initial Report * **Vulnerability Identification**: Security vulnerabilities classified by severity (High, Medium, Low) * **Proof of Concept**: Demonstration of potential exploit scenarios where applicable * **Gas Optimizations**: Recommendations for improving contract efficiency * **Informational Findings**: Code quality improvements and best practice recommendations * **Mitigation Strategies**: Specific recommendations for addressing each identified issue #### Mitigation Phase * **Fix Review Period**: Time allocated for your team to address identified vulnerabilities * **Collaborative Support**: Ongoing communication with auditors during the fix implementation * **Code Re-review**: Assessment of implemented fixes to ensure issues are properly resolved #### Final Report * **Updated Assessment**: Review of all implemented fixes and their effectiveness * **Residual Risk Analysis**: Documentation of any remaining risks or limitations * **Public Publication**: In web3, audit reports are commonly published publicly to build community trust ### Timeline and Cost Expectations The following are *incredibly rough estimates* for timelines/costs based on Solidity smart contract audits from around the industry. Actual timelines and costs will vary significantly based on the complexity of the codebase, the number of contracts, and the specific requirements of the project. #### Duration * **Small Projects** (\< 1000 lines): 1-2 weeks * **Medium Projects** (1000-4000 lines): 2-5 weeks * **Large Projects** (> 4000 lines): 5+ weeks #### Cost Range * **Per Week**: $1,000 - $60,000 depending on complexity and auditor expertise * **Factors Affecting Cost**: Codebase size, complexity, timeline requirements, auditor reputation ### Important Limitations * **No Guarantee**: Audits do not guarantee bug-free code or complete security. However, the engagement with the team should still provide value (teaching better security practices, improving code quality, etc.) * **Snapshot in Time**: Audits assess code at a specific commit hash - any changes create unaudited code * **Ongoing Process**: Security should be viewed as a continuous journey, not a one-time event * **Emergency Preparedness**: Even audited protocols should have incident response plans and emergency communication channels *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Smart Contracts > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Smart Contract Security Reviews](/external-security-reviews/smart-contracts/overview) * [Smart Contract Manual Code Review](/external-security-reviews/smart-contracts/manual-review) * [What to Expect from a Smart Contract Audit](/external-security-reviews/smart-contracts/expectation) * [Preparing for a Smart Contract Audit](/external-security-reviews/smart-contracts/preparation) * [Selecting a Smart Contract Auditor](/external-security-reviews/smart-contracts/vendor-selection) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, MermaidRenderer } from '../../../../components' ## Manual Review Manual review of a smart contract is the process of carefully examining the source code to identify potential vulnerabilities, logic errors, and design flaws. The approach to manual review can vary from person to person or team to team. This document outlines some of the possible things the process can comprise. ### Gather resources 1. **Scope:** This can be a link to the code repository. e.g. GitHub, GitLab link which consists of all the smart contracts required to be reviewed. 2. **Commit hash:** Agree on a specific commit hash from the repository and freeze the previously defined scope. Avoid continuous modifications to the codebase. Any changes should be communicated, and the commit hash should be updated for the code under review. 3. **Documentation and specification:** * Documentation describes how the code works, how to use it, and its expected functionality. * Specification defines the exact requirements, constraints, and behaviors the system must meet, including invariants that must always hold true. * Invariants are the properties of the system that should always hold. Invariants can be useful for checking the expected behavior of the system when certain actions or a transaction flow are executed. Invariants are useful in many testing approaches, including manual reviews, where a reviewer checks whether a specific property can be violated for a function under any sequence of function calls. * Get simplified math formulas if the protocol has any custom/fancy formulas implemented. 4. **Tests:** Tests are important for understanding the expected behavior and ensuring that the system works as intended. The following types of tests can be useful for understanding and verifying the code: * [unit tests](/security-testing/unit-testing): Unit tests ensure that individual functions behave correctly under expected conditions. * [Integration Tests](/security-testing/integration-testing): Integration tests verify that your smart contracts work correctly with real external systems. ### Smart contract high-level overview 1. **Documentation and whitepaper walkthrough:** Go through the whitepaper and documentation to gain a better understanding of the project and to see how the proposed business logic is structured. What are the involved components. 2. **High level idea:** Get a high level idea behind the project: Through diagrams, developer walkthrough. 3. **Structural overview:** Get a structural overview of the project: Check how integration of contracts and functions is happening throughout the protocol. 4. **Create a diagram:** Based on the structural and functional understanding the high level diagram can be created if required. * The diagram can be modified over time as you get more understanding. * The diagram can grow more complex and detailed depending on the time. * There are many tools that can be used like Excalidraw, Miro, Lucidchart, Mermaid etc. * High level structural example of staking diagram: Staking: used in Staking --> Token Staking --> Rewards Staking --> Bridge : bridges token`} /> ### Manual review 1. **Understand the flow:** Understand the flow from [unit](/security-testing/unit-testing) and [Integration](/security-testing/integration-testing) tests. Test cases are important. They give you an understanding of how the setup works and what state needs to be in place for users to start using the system’s entry points. They also give you time to test more offensive or edge-case scenarios (after verifying unit tests) instead of spending most of your time testing general scenarios. * When math formulas or complex interconnected calls are involved, debugging the values of variables helps sometimes to see how the state changes are happening e.g. what is the value of variable `x/totalStakedEth` before the specific internal/external call. or what it becomes after that call. * Debugging can be done in many ways, depending on which framework you are using. Some examples include: * Foundry - native debugger, console logs in the contracts, Tenderly debugger, simbolik. * Hardhat - console logs in the contracts, debuggers like Hardhat-tracer, Tenderly debugger. 2. **Choose the least dependent contract to review first:** This can be done by looking into a diagram and current understanding of the smart contract functionality. For example in this case it's a Token contract that is least dependent (in fact the functionality from that contract is getting used in other contracts so other smart contracts are dependent on it). 3. **Checklist reviews:** * Known smart contract vulnerabilities checklist. * Project specific checklists (e.g. When dealing with bridges it's also important to check bridge specific checklists). * Checklists may vary over time and can become outdated. Below are some examples for reference: * [Smart Contract Security Field Guide](https://scsfg.io/hackers/) * [Smart Contract Security Verification Standard](https://github.com/ComposableSecurity/SCSVS?tab=readme-ov-file#table-of-contents) 4. **Maintain a list of invariants:** Maintain a list of invariants for every function (Can be useful later for other tests/fuzzing/format verification). 5. **Offensively analyze the code:** Offensively analyze the code to identify logical issues, edge cases, and any conditions that could break invariants. 6. **Visit all paths:** Visiting all paths in a smart contract is crucial from a security perspective. For example, in the below `withdraw()` function, every path has its own potential security implications and behavior that needs to be verified. Sometimes these unexpected paths lead us to potential bugs. Generally frameworks provide tools to check test coverage, like the [forge coverage](https://getfoundry.sh/forge/reference/coverage/) command which can be used to generate code coverage reports for tests. > While this section focuses more on manual approach, automated testing approaches like fuzzing and formal > verification can be useful here for checking possible invariant violations across multiple paths. As can be seen below, everything boils down to each path. Even the ternary expression is ultimately a path. ```solidity function withdraw(uint256 amount, bool emergency) public { require(amount > 0, "Withdraw amount must be greater than 0"); uint256 balance = balances[msg.sender]; bool success; if (emergency) { success = (address(this).balance >= amount) ? payable(msg.sender).send(amount) : false; } else { if (balance >= amount) { balances[msg.sender] -= amount; totalBalance -= amount; success = payable(msg.sender).send(amount); } else { success = false; } } if (!success) { // call other contract to handle failed withdrawal } emit Withdrawn(msg.sender, amount, success); } ``` In next example, because every value (`_amount`, `minRequired`) can increase or decrease, the results can vary. If the result is used for some operations like decreasing the `drivingScore` in `burnFuelAndReduce()` for example. E.g. depending on whether the amounts are the same (as they were while filling the fuel) or increased or decreased, the value of `fuelReduction` will change and while subtracting it from the `drivingScore[msg.sender]` it needs to be handled accordingly. which also creates different paths. ```solidity function fillFuelAndCalculate(uint256 _amount) public { require(_amount > minRequired, "ERR"); fuelTank[msg.sender] += _amount; drivingScore[msg.sender] += (_amount * multiplier) / minRequired; } function burnFuelAndReduce(uint256 _amount) public { fuelTank[msg.sender] -= _amount; uint256 fuelReduction = (_amount * multiplier) / minRequired; drivingScore[msg.sender] = drivingScore[msg.sender] > fuelReduction ? drivingScore[msg.sender] - fuelReduction : 0; } ``` 7. **Write down notes, doubts and edge cases:** One reason for writing down questions, ideas, possible issues is, when you start going through these issues as you encounter new path you can see more doubts, possible issues in your mind. So sometimes it becomes a loop where you will keep thinking about new ideas while exploring previous/current one. * Take notes to check your understanding. * Write down any questions to ask developers when you need clarification. * Note down edge cases for later testing. E.g: \[test] Possible reentrancy in unstake() function. * Try to break down the business logic while going through every code block. (again note down the thing that needs to be tested) * Write down things to revisit after the code is fixed. E.g: In the review you noticed that if specific functionality would be added based on doubts asked or based on the suggested fixes etc, there are chances of something to go wrong for example. Note it down and check in the **Fixed code review**. * The minimal markdown file for taking notes might look like this: ```markdown # Project Name ## Scope: GH link: Commit hash: ## Flow: 1. Manual review 2. Functional testing: - Unit testing - Edge case testing 3. Automated testing: - ... 4. ... ## Resources: 1. Specification doc: 2. Whitepaper: 3. Any other documentation and links. ## ToDo: *Things to do/ remaining things.* 1. High level things about audit 2. Developer project walk-through. 3. ... ## Common/Doubts/Research: 1. Relearn about specific cross chain service/protocol that's getting used. ## ContractName.sol *This contains doubts/points/research/potential bugs regarding the ContractName.sol* 1. Confirmed issue 1. 2. Confirmed issue 2. ### Doubts/Research: 1. Checking specific formulas. 2. Checking specific doubt. 3. Check the subtraction on L453 can be a problem. 4. [revisit] Revisit something based on the suggestion given. * Testcases: 1. [test] User should be able to stake. 2. [test] Multiple users should be able to stake. 3. [test] ... ## ContractName2.sol *This contains doubts/points/research/potential bugs regarding the ContractName2.sol* ... --- ## Questions for developers: 1. Explanation for formulas. 2. Questions about intended logic. 3. ... ``` ### Functional testing 1. Check any missing test cases that should be covered. 2. Write and test edge cases from notes taken while manually reviewing contracts. ### Automated review While automated review can be classified as a different approach from manual review, it is useful to use techniques such as [static analysis](/security-testing/static-analysis) to identify low-hanging bugs by triaging warnings from tools like [Slither](https://github.com/crytic/slither), [Wake](https://github.com/Ackee-Blockchain/wake), [Aderyn](https://github.com/Cyfrin/aderyn) etc. > There are other types of automated testing approaches, such as [Fuzz Testing](/security-testing/fuzz-testing) and > [formal verification](/security-testing/formal-verification) can also be helpful at different stages of the audit > life-cycle, though they are less directly related to manual review. ### Report writing 1. **Questions and issue discussion with internal team:** Discuss any questions and identified issues with the internal team or, if applicable, with the team of reviewers working in parallel on the project. This will help you reach a conclusion. 2. **Questions and issue discussion with the developers or project team:** Discuss and convey issues to the developers or project teams, as applicable. The goal is the technical dev. members of team should get issues so they can try to fix them. It can save time in large projects once the report is delivered. 3. **Report writing:** While the structure of a report and the issues/bugs it documents may vary, the following elements are helpful to include: * Public link to the code repository. * The commit hash pointing to the recently reviewed commit. * Issues can include a detailed description, recommendations, severity, status, the commit where the issue was fixed, and acknowledgments from developers. * References to correct functions and line numbers while writing issues. * Example and POC, helpful for critical bugs. * Checking the grammar/style for better readability. ### Updated code review For checking fixed code, it may be necessary to repeat previously performed actions, depending on what has changed. To avoid repeating work, you can: 1. **Code comparison:** This helps in identifying updates and detecting deviations from expected changes. For example, a git diff may reveal changes in functions that should not have been changed. 2. **Reviewing updated code:** Review the updated code to check expected and unexpected changes. 3. **Run all the tests:** Run all available tests on the updated code to ensure the newly updated code does not break any invariant. 4. **Write new tests for the updated code:** If the updated code creates any new control flow paths it's necessary to write tests to visit those paths and to ensure it yields the expected output. 5. **Go through checklists again:** For the updated functionality (depending on what has been changed), review the checklists to ensure that no vulnerabilities remain or have been introduced. 6. **Check things/notes that need to be revisited:** Check items or notes that need to be revisited from the manual review. Sometimes you may have observations noted, e.g., Adding this fix to the code can create this problem. 7. **Update the report:** Update the report and issue status based on the updated code. * Change the status. * Add/update most recently reviewed commit link/hash. * Add comments from the audit team (when required). * These may include, for example, the reason why an issue remains open, any unresolved security concerns, or even new issues created by the fixes, but are not limited to these. * Add comments from the project team (when required). * These may include the reasons why an issue is acknowledged, or mitigations that will not be implemented at the smart contract level, but are not limited to these. ### Final thoughts Having multiple teams/members review each contract individually leads to better results, as it ensures more sets of eyes are examining the code. ### References * [Auditing mental model by Caliber](https://www.calibersec.com/smart-contract-auditing-mental-model/) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Smart Contract Security Reviews Smart contract security reviews are specialized assessments focused on identifying vulnerabilities in blockchain-based smart contracts and protocols. These reviews are critical for web3 projects due to the immutable nature of blockchain deployments and the high-value targets that smart contracts often represent. ### Why Smart Contract Security Reviews Are Critical Smart contracts operate in a unique environment that makes security paramount: * **Immutability**: Once deployed, smart contracts cannot be easily changed * **Financial Risk**: Smart contracts often handle significant value in cryptocurrencies * **Public Accessibility**: All code and transactions are visible on the blockchain * **Adversarial Environment**: Attackers are incentivized by potential financial gains * **Complex Interactions**: DeFi protocols involve intricate interactions between multiple contracts According to industry data, billions of dollars have been lost due to smart contract vulnerabilities, making security reviews essential for protecting user funds and maintaining protocol integrity. ### Smart Contract Security Review Process A security review engagement is typically divided into four phases: * **Scoping Phase**: The project team prepares the codebase and defines specific scope for security researchers * **Initial Assessment Phase**: Researchers conduct preliminary analysis to identify potential security issues * **Mitigation Phase**: The team works on fixing identified issues with ongoing auditor support * **Final Report Phase**: Auditors review implemented fixes and provide a comprehensive final report #### Audit Methodologies * **Static Analysis**: Automated code scanning for known vulnerability patterns * **Dynamic Analysis**: Runtime testing and fuzzing * [**Manual Review**](/external-security-reviews/smart-contracts/manual-review): Expert analysis of business logic and complex vulnerabilities * **Formal Verification**: Mathematical proofs of contract correctness (where applicable) ### Types of Smart Contract Audits #### Private Audits * Dedicated security researchers assigned to your project * Confidential and personalized attention * Higher cost but comprehensive coverage * Direct communication with audit team #### Public/Competitive Audits * Multiple researchers competing for prizes * Diverse perspectives and approaches * More cost-effective option * Broader coverage through competition ### Contents This section contains detailed guidance on different aspects of smart contract security reviews: 1. [Audit Expectations](/external-security-reviews/smart-contracts/expectation) - What to expect during the audit process 2. [Preparation Guide](/external-security-reviews/smart-contracts/preparation) - How to prepare for a successful audit 3. [Vendor Selection](/external-security-reviews/smart-contracts/vendor-selection) - Choosing the right security auditor *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Preparation A common misconception is that when doing a security review, you can just hand off the written code and let reviewers do their work. This approach is inefficient and costly, as auditors will spend time on issues you could have resolved beforehand. Proper preparation maximizes the value of your security review investment and helps auditors focus on complex vulnerabilities rather than basic issues. ### How to Get the Most Out of Your Security Review ### Set a Goal for the Review This is the most important step of a security review and often the most overlooked. By setting a scope that is not too large or undefined, you are more likely to have a successful audit. If the project is very large, you may want to focus on the most critical aspects of the project. ### Internal Due Diligence Conduct internal testing before engaging an external security provider. You can do this by creating and running test vectors for your code, and leverage automated tools to identify low-hanging fruit. Here’s a list of free/open-source tools your project could use: * **Solidity**: slither, mythril, semgrep-smart-contracts * **Golang**: golangci-lint, go-critic, gosec * **Rust**: cargo audit, cargo outdated, clippy, cargo geiger, cargo tarpaulin ### Write Clear Documentation Providing comprehensive documentation is essential for auditors to understand your protocol's intended functionality. Since 80% of all bugs are due to business logic issues, auditors need to understand what your protocol should do, not just what the code does. Documentation should include: * **Project Overview**: Describe your protocol in plain English—what it does and its components. * **Flow Diagrams**: Outline all possible interaction paths within your system. * **Design Choices**: Document design decisions and any known potential issues. * **Known Restrictions / Limitations**: Document centralization risks and known limitations (e.g., limited TVL, token support). * **Dependencies**: List all external dependencies. * **Access Control / Privileged Roles**: Record all roles and their privileges. ### Provide a Robust Test Suite Maintaining a comprehensive test suite that covers significant portions of your codebase allows auditors to focus on finding vulnerabilities rather than understanding basic functionality. Before an audit, ensure you have: * **Unit Tests**: Test individual functions and components * **Integration Tests**: Test interactions between different parts of your system * **Fuzz Testing**: Automated testing with random inputs to find edge cases * **High Code Coverage**: Aim for substantial coverage of your critical code paths * **Formal Verification**: If applicable, use formal methods to prove correctness of critical components ### Conduct an Initial Code Walkthrough The first step in a security audit should be a high-level video walkthrough where you: * Explain your codebase architecture and key components * Describe how the code is intended to function * Highlight critical areas that need special attention * Provide context for design decisions and trade-offs * Guide auditors on where to find answers to common questions This walkthrough helps auditors understand your system quickly and focus their time on security analysis rather than code comprehension. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Vendor Selection Choosing the right security vendor is crucial for getting maximum value from your security review. There are numerous security vendors in both the web3 and web2 ecosystems, each with different specializations and approaches. ### Types of Security Audits Understanding the different types of security audits available helps you choose the right approach for your project: #### Private Security Audits Private smart contract security audits are performed by security companies or solo auditors, typically involving one or multiple security researchers specifically chosen by your team or assigned by the security firm. **Characteristics:** * Confidential engagement with limited access to code * Dedicated focus from chosen security researchers * Personalized attention and direct communication * Typically higher cost but more thorough coverage #### Public/Competitive Security Audits Public or competitive audits involve tens or hundreds of security researchers competing to find the highest number of issues to win a share of a prize pool. **Characteristics:** * Open participation from multiple researchers * Competitive environment drives thorough analysis * Often more cost-effective than private audits, but less personalized * Can identify a broader range of issues through diverse perspectives ### Vendor Selection Criteria #### 1. Track Record and Reputation * Evaluate potential vendors based on their track record, reputation, and experience in your specific technology stack * Look for vendors with a proven history of addressing security challenges similar to your project's needs * Check for published audit reports and client testimonials #### 2. Domain Expertise * **Web3 Focus**: For smart contracts, DeFi protocols, or blockchain infrastructure, choose vendors with deep web3 security expertise * **Web2 Focus**: For traditional infrastructure, APIs, or backend systems, consider vendors with strong web2 security backgrounds * **Specialized Knowledge**: If building an L2, DEX, or other specialized system, prioritize vendors with relevant experience #### 3. Technical Capabilities * Ensure the vendor has experience with your specific: * Programming languages (Solidity, Rust, Go, etc.) * Blockchain platforms (Ethereum, Polygon, Arbitrum, etc.) * Protocol types (DeFi, NFTs, DAOs, etc.) * Architecture patterns (proxy contracts, multisig, etc.) #### 4. Security Methodology * **Tool Usage**: Verify they use appropriate automated security tools * **Manual Review**: Ensure they conduct thorough manual code reviews * **Testing Approach**: If applicable, look for comprehensive testing methodologies including fuzz testing or formal verification ### Due Diligence Process 1. **Request References**: Ask for previous client references and audit examples 2. **Evaluate Methodology**: Understand their specific audit process and deliverables 3. **Assess Communication**: Ensure clear communication channels and responsive support 4. **Review Pricing**: Compare costs against scope and expected value 5. **Timeline Alignment**: Confirm availability matches your project timeline ### Red Flags to Avoid * Vendors who guarantee finding all vulnerabilities * Extremely low pricing without clear scope limitations * Lack of relevant experience in your technology stack * Poor communication or unresponsive during initial discussions * No clear methodology or standardized reporting process ## Audit the Auditors As of today, the best way to evaluate security reviewers is their historical performance. One of the best ways to evaluate this is to review the historical performance of the security team. If you see codebases that they reviewed were hacked, this doesn't mean that the team is bad. There are two types of security teams out there: * Those who have had codebases they have reviewed hacked * Those who have not reviewed enough codebases Additionally, comparing sequential audits of the same codebase can be misleading. If auditor A reviews codebase X, and then auditor B reviews the same codebase and finds more bugs, some insight from auditor A could have been used to find those extra bugs. However, if two auditors review the same codebase at the same time, this can be a much better comparison of the two auditors. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Cross-Chain Compatibility ### Respect Cointype for [Chain-Specific Resolution](https://docs.ens.domains/ensip/9) * Always use the correct cointype parameter when resolving addresses on specific chains * For EVM-compatible chains, derive cointypes from chain IDs according to [ENSIP-11](https://docs.ens.domains/ensip/11) **Rationale**: An ENS name can resolve to a different address for each different blockchain network, which ENS supports through the cointype field in address records (following SLIP-44 standards). With the rise of smart contract wallets and account abstraction, users may have different addresses across different chains. Failing to respect the cointype when resolving addresses can lead to funds being sent to addresses that don't exist on the target chain or that belong to different entities altogether. ### Implement CCIP-Read Support * Properly support and handle CCIP-Read functionality [EIP-3668](https://eips.ethereum.org/EIPS/eip-3668) * Set reasonable timeouts and fallbacks for CCIP-Read operations **Rationale**: CCIP-Read (EIP-3668) enables off-chain data retrieval for ENS resolution, allowing for more complex resolution patterns and greater flexibility for name owners. This protocol allows resolvers to redirect resolution requests to off-chain services that can implement custom logic beyond what's practical on-chain. Applications that ignore CCIP-Read requests limit the functionality available to ENS users and may provide incorrect resolution results. Supporting this standard ensures compatibility with advanced ENS use cases. ### Test Multi-Chain Implementations * Test ENS resolution across all chains your application supports * Implement proper error handling for unsupported chains * Document which chains are supported by your implementation **Rationale**: As blockchain ecosystems expand, users expect applications to work across multiple networks. Testing ENS resolution across different chains ensures consistent behavior regardless of which network a user is connected to. Clear documentation about chain support also helps users understand the limitations of your application. ### Handle Reverse Records Per Chain * Query reverse records on the chain where the address exists, not just mainnet * Consider user context when displaying names, prioritize the reverse record from the chain the user is currently interacting with * Validate reverse record ownership by checking if the returned name actually resolves back to the queried address on that chain **Rationale**: With [ENSIP-19](https://docs.ens.domains/ensip/19), reverse records (address-to-name lookups) can now be set and queried on any chain, not just Ethereum mainnet. This allows users to set different reverse records for the same address across different networks, enabling more contextual and chain-specific identity resolution. Applications that only check mainnet reverse records will miss valid reverse resolutions on other chains where users are actually active, leading to incomplete or incorrect identity displays. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Data Integrity & Verification ### Use On-chain Resolution for Financial Transactions * Always resolve fresh data directly from Ethereum mainnet whenever conducting financial transactions * Do not rely on indexer or API data when moving or managing funds * Preferably run an Ethereum node for high-value transactions, or if not feasible, use reputable L1 RPC providers while still verifying the integrity and audit status of all software involved in the resolution process **Rationale**: Indexers and third-party APIs may have delayed updates or inconsistencies that could lead to payments being sent to outdated or incorrect addresses. By querying L1 directly, applications work with the most current and authoritative ENS data, dramatically reducing the risk of misdirected funds. This is particularly crucial for high-value transactions where the consequences of using stale data could be severe. ### Verify Forward Resolution on [Reverse Records](https://docs.ens.domains/ensip/3) * Always perform forward resolution on reverse records to verify address matches * Check that name → address → name completes a valid loop * Clearly indicate to users when there's a mismatch **Rationale**: ENS supports both forward resolution (name → address) and reverse resolution (address → name). However, reverse records can be set independently, creating the possibility for spoofing or impersonation if not properly verified. By performing forward resolution on the result of a reverse lookup and comparing it to the original address, applications can ensure the bidirectional integrity of the ENS data, preventing potential phishing or impersonation attacks. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Ens > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [ENS Best Practices](/ens/overview) * [ENS Data Integrity Verification](/ens/data-integrity-verification) * [ENS Cross Chain Compatibility](/ens/cross-chain-compatibility) * [ENS Smart Contract Integration](/ens/smart-contract-integration) * [ENS Interface Compliance](/ens/interface-compliance) * [ENS Name Handling & Normalization](/ens/name-handling-normalization) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Interface Compliance ### Verify Resolver Interface Support * Always check if a resolver supports your target interface using EIP-165 * Call supportsInterface() before attempting to use specific resolver methods * Implement graceful fallbacks when interfaces aren't supported * Cache interface support results to minimize redundant on-chain calls **Rationale**: ENS resolvers can implement various interfaces, each providing different functionality (addresses, text records, content hashes, etc.). Not all resolvers implement all interfaces, so checking interface support before calling specific methods prevents failed transactions and improves reliability. This verification step is especially important as the ENS ecosystem evolves and new resolver interfaces are introduced. Without proper interface verification, applications may fail when encountering resolvers with limited functionality or custom implementations. ### Signal Supported Interfaces in Custom Resolvers * When writing custom resolvers, properly implement EIP-165 * Signal all supported interfaces via supportsInterface() * Document which interfaces your resolver supports * Consider incremental implementation of interfaces based on user needs **Rationale**: Implementing EIP-165 interface detection allows other contracts and applications to programmatically discover what functionality your resolver supports. This promotes interoperability and ensures your custom resolver can seamlessly integrate with the broader ENS ecosystem. Proper interface signaling is not just a technical requirement but a key element of good blockchain protocol citizenship. Without it, other contracts and applications can't reliably determine the capabilities your resolver offers, leading to poor user experiences and potential security risks. ### Stay Updated with ENS Improvement Proposals (ENSIPs) * Regularly monitor the [ENS GitHub repository](https://github.com/ensdomains/ensips) for new ENSIPs * Participate in ENSIP discussions to provide implementer feedback * Implement support for new ENSIPs after they reach "Final" status * Plan for deprecation of older interfaces as specified by [ENSIPs](https://docs.ens.domains/ensip/) * Test implementations against the reference implementations provided in ENSIPs **Rationale**: The ENS protocol evolves through the ENSIP process, which introduces new interfaces, standards, and recommended practices. Staying current with these proposals ensures your implementation remains compatible with the broader ecosystem and can leverage new functionality as it becomes available. ENSIPs often address security vulnerabilities, improve user experience, or add valuable new features that users will come to expect. Implementers who track and promptly adopt new ENSIPs gain competitive advantages while contributing to the overall health and advancement of the ENS ecosystem. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Name Handling & Normalization ### Normalize Names per [ENSIP-15](https://docs.ens.domains/ensip/15) * Always normalize ENS names before creating namehash, labelhash, or DNS-encoding * Use established libraries that correctly implement ENSIP-15 normalization (like @adraffy/ens-normalize) * Apply normalization at the earliest possible point in your ENS handling logic * Include normalization checks in validation procedures for user-entered names **Rationale**: ENS uses a specific normalization algorithm defined in ENSIP-15 to ensure consistent handling of Unicode characters and emoji sequences. Failing to normalize names correctly can result in different hash values for what users perceive as the same name, leading to resolution failures, security vulnerabilities, and poor user experience. Proper normalization is fundamental to the correct operation of any ENS integration and must be performed before any cryptographic operations (namehash, labelhash) or encoding. Using established libraries ensures compliance with the complex requirements of ENSIP-15. ### Implement Security Measures for Homograph Attacks * Detect and warn users about visually confusable characters in ENS names * Display names using fonts that clearly differentiate similar-looking characters * Consider displaying the script/language of characters in multi-script names * Implement visual indicators for mixed-script names or potentially deceptive names * When displaying ENS names, highlight or annotate unexpected character sets **Rationale**: Homograph attacks use visually similar characters from different Unicode scripts to create deceptive names (e.g., using Cyrillic 'о' instead of Latin 'o'). While ENSIP-15 addresses some confusables, it cannot eliminate all visual ambiguities. Implementing additional security measures helps users identify potentially deceptive names before interacting with them. These protections are particularly important in financial applications or any context where users might send assets to an ENS name, as homograph attacks can lead to irreversible asset loss. ### Properly Handle Emoji in ENS Names * Ensure your UI correctly displays emoji in ENS names at appropriate sizes * Be aware that emoji rendering varies across platforms and fonts * Handle emoji sequences correctly, including skin tone modifiers and ZWJ sequences * Test thoroughly with emoji-containing names on multiple platforms and browsers * Use libraries that correctly implement UTS-51 (Unicode Emoji) for handling emoji **Rationale**: Emoji are increasingly common in ENS names but introduce technical challenges. Emoji can be composed of multiple code points, including zero-width joiners (ZWJ) and variation selectors, making proper handling critical. Incorrect emoji implementation can cause names to appear differently across platforms or fail to resolve correctly. Emoji rendering also varies significantly between operating systems and browsers, requiring thorough cross-platform testing to ensure consistent user experience. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## ENS Best Practices > 🔑 **Key Takeaway**: To securely implement ENS in your applications, prioritize direct L1 data verification, enforce > proper name normalization, and validate bidirectional resolution. Always verify interface support before interaction, > respect chain-specific cointype parameters, and implement [CCIP-Read](https://eips.ethereum.org/EIPS/eip-3668) > functionality correctly. These practices prevent address spoofing, ensure cross-chain compatibility, and maintain data > integrity throughout the ENS ecosystem. The Ethereum Name Service (ENS) is a distributed, open, and extensible naming system based on the Ethereum blockchain. ENS maps human-readable names like 'alice.eth' to machine-readable identifiers such as Ethereum addresses, other cryptocurrency addresses, content hashes, metadata, and more. ENS also supports 'reverse resolution', making it possible to associate metadata such as primary names or interface descriptions with Ethereum addresses. ### What This Framework Covers This best practices framework includes guidance on: * **[Data Integrity & Verification](/ens/data-integrity-verification)** - Ensuring reliable and secure name resolution * **[Cross-Chain Compatibility](/ens/cross-chain-compatibility)** - Supporting ENS across multiple blockchain networks * **[Smart Contract Integration](/ens/smart-contract-integration)** - Leveraging ENS in smart contract systems * **[Interface Compliance](/ens/interface-compliance)** - Correctly implementing and [verifying ENS interfaces](https://eips.ethereum.org/EIPS/eip-165) * **[Name Handling & Normalization](/ens/name-handling-normalization)** - Properly processing and displaying ENS names These recommendations are designed for developers integrating ENS into applications, wallets, smart contracts, or other blockchain systems. Following these practices will help create more secure, reliable, and user-friendly ENS implementations. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Smart Contract Integration ### Name Your Smart Contracts * Register ENS names for core contracts in your project's ecosystem * Set appropriate reverse records for your contracts * Document contract ENS names in project documentation * Consider naming contracts at deployment time to ensure immediate resolvability * Use a standard pattern for contract naming to improve discoverability **Rationale**: Smart contracts typically have complex hexadecimal addresses that are error-prone when shared or referenced. By assigning ENS names to smart contracts, developers can significantly improve user experience, make documentation more approachable, and reduce the risk of address errors. This practice is especially important for contracts that interact directly with users or serve as key infrastructure components. Human-readable names also aid in contract verification, as users can more easily confirm they're interacting with official protocol contracts rather than potential phishing imitations. ### Leverage ENS as an Infrastructure Component * Use ENS for service discovery between contract components * Build upgradeability mechanisms that leverage ENS for implementation pointers * Consider ENS as a registry for official protocol extensions and integrations * Use ENS records to store protocol metadata in a human-readable format **Rationale**: ENS can serve as more than just a human-readable address layer, it can function as critical infrastructure for contract systems. Using ENS for implementation pointers enables flexible and upgradeable architectures, as contract dependencies can be redirected without requiring contract redeployment. This pattern supports robust governance models while maintaining a consistent user interface. Additionally, using ENS to register official extensions creates a trust layer that helps users identify legitimate protocol integrations, while storing protocol metadata in ENS records improves discoverability and system documentation. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Cloud Data Encryption You should consider using the best practices below to ensure that data stored in the cloud is protected from unauthorized access: ### Best Practices 1. **Use strong encryption algorithms.** * Example: Use AES-256 for data at rest and TLS 1.2 or higher for data in transit. * Ensure that encryption libraries and tools are up-to-date to avoid vulnerabilities. 2. **Ensure data is encrypted in transit and at rest.** * Example: In AWS, enable S3 bucket encryption and use AWS KMS for key management. * Example: In Azure, use Azure Storage Service Encryption and Azure Key Vault for key management. * Example: In Google Cloud, enable encryption for Cloud Storage and use Cloud KMS for key management. 3. **Use cloud provider-managed keys or even better bring your own keys (BYOK) for enhanced control over encryption keys.** * Example: In Google Cloud, use Cloud KMS for managing encryption keys and consider using Customer-Supplied Encryption Keys (CSEK) for BYOK. * Regularly rotate encryption keys to minimize the risk of key compromise. 4. **Implement strict access controls and monitoring to prevent unauthorized access to encrypted data.** * Example: Use IAM roles and policies in AWS to restrict access to sensitive data. * Example: Enable Azure Security Center to monitor and alert on unauthorized access attempts. * Example: In Google Cloud, use IAM policies and Cloud Audit Logs to monitor access. 5. **Continually review that the encryption best practices are being followed everywhere it's relevant.** * Example: Regularly audit your encryption settings and access controls using tools like AWS Config or Azure Policy. * Example: Use automated compliance checks in Google Cloud Security Command Center. 6. **Enable logging and monitoring for encryption activities.** * Example: In AWS, enable CloudTrail to log all API calls related to encryption. * Example: In Azure, use Azure Monitor to track encryption-related activities. * Example: In Google Cloud, use Cloud Logging to monitor encryption key usage. 7. **Implement automated backups and ensure they are encrypted.** * Example: In AWS, use AWS Backup to automate backups and ensure they are encrypted. * Example: In Azure, use Azure Backup to automate and encrypt backups. * Example: In Google Cloud, use Cloud Storage for backup and ensure encryption is enabled. 8. **Educate and train your team on encryption best practices.** * Conduct regular training sessions on the importance of encryption and how to implement it correctly. * Provide documentation and resources for team members to reference. 9. **Use multi-factor authentication (MFA) for accessing encryption keys and management consoles.** * Example: In AWS, enable MFA for IAM users and roles. * Example: In Azure, enable MFA for Azure AD users. * Example: In Google Cloud, enable MFA for Google Cloud accounts. 10. **Regularly update and patch your encryption tools and libraries.** * Ensure that all encryption-related software is kept up-to-date with the latest security patches. * Monitor for vulnerabilities in encryption libraries and apply patches promptly. By following these best practices and utilizing the recommended tools, you can significantly enhance the security of your data stored in the cloud. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Secure Messaging Systems Using secure messaging systems is crucial for protecting the privacy and integrity of your communications. Here are some popular messaging systems that offer end-to-end encryption and those that do not by default. ### End-to-End Encrypted Messaging Systems 1. **Signal** * Offers strong end-to-end encryption for messages, voice calls, and video calls. * Open source and highly recommended for secure communication. * [Signal](https://signal.org/) 2. **Matrix/Element** * An open standard for decentralized communication with end-to-end encryption. * Element is a popular client for the Matrix protocol. * [Matrix](https://matrix.org/) / [Element](https://element.io/) 3. **WhatsApp** * Provides end-to-end encryption for messages, voice calls, and video calls by default. * Owned by Meta (Facebook). * [WhatsApp](https://www.whatsapp.com/) 4. **Wire** * End-to-end encryption for messages and calls * Open source with a strong focus on privacy. * [Wire](https://wire.com/) ### Messaging Systems Without Default End-to-End Encryption These messaging systems supposedly provide encryption for data in transit and at rest, but not end-to-end encryption for messages. 1. **Telegram** * Offers end-to-end encryption only for "Secret Chats". * [Telegram](https://telegram.org/) 2. **Discord** * Does not offer end-to-end encryption for messages. * [Discord](https://discord.com/) 3. **Zoom** * End-to-end encryption for calls, but must be manually enabled. * [Zoom](https://zoom.us) 4. **Slack** * Does not offer end-to-end encryption for messages. * [Slack](https://slack.com/) 5. **Microsoft Teams** * Does not offer end-to-end encryption for messages. * [Microsoft Teams](https://www.microsoft.com/en/microsoft-teams/group-chat-software) For secure communication, it is recommended to use messaging systems that offer end-to-end encryption by default. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Database Encryption Often, databases contain information that should not be publicly available. In order to protect your database, you may consider implementing the following best practices: ### Best Practices 1. Use strong encryption algorithms to encrypt database files and backups. 2. Encrypt sensitive columns within the database, such as those containing personally identifiable information (PII). 3. Use Transparent Data Encryption (TDE) to automatically encrypt and decrypt data stored in the database. 4. Implement robust key management practices, including the use of HSMs and regular key rotation depending on your use case. 5. Enforce strict access controls to prevent unauthorized access to encrypted data. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Email Encryption Email is insecure and un-encrypted by default, but can become more secure by following best practices: ### Best Practices 1. **Implement S/MIME or PGP**: * **S/MIME**: Secure/Multipurpose Internet Mail Extensions (S/MIME) is a widely accepted protocol for sending digitally signed and encrypted messages. It requires a certificate from a trusted Certificate Authority (CA). Popular email clients like Microsoft Outlook and Apple Mail support S/MIME. * **Example**: 1. Obtain an S/MIME certificate from a trusted CA (e.g., Comodo, Symantec). 2. Install the certificate in your email client: * **Outlook**: Go to `File` > `Options` > `Trust Center` > `Trust Center Settings` > `Email Security` > `Import/Export` to import your certificate. * **Apple Mail**: Open `Mail` > `Preferences` > `Accounts` > `Advanced` > `Certificates` to add your certificate. 3. Compose a new email and select the option to sign/encrypt the email. * **PGP**: Pretty Good Privacy (PGP) is another method for encrypting emails. It uses a decentralized trust model and is supported by tools like GnuPG (GPG), which is an open-source implementation. Extensions like Enigmail for Thunderbird or FlowCrypt for Gmail can simplify the process. * **Example**: 1. Install GnuPG (GPG) on your system. 2. Generate a key pair using the command: `gpg --gen-key`. 3. Share your public key with your contacts. 4. Install an email client extension: * **Thunderbird**: Install Enigmail from the Thunderbird add-on store. * **Gmail**: Install FlowCrypt from the Chrome Web Store. 5. Configure the extension with your GPG key. 6. Compose a new email and use the extension to encrypt/sign the email. 2. **Train Project Members**: Conduct regular training sessions to ensure all team members understand how to use email encryption tools effectively. Provide step-by-step guides and resources for troubleshooting common issues. 3. **Use Trusted Email Gateways**: Ensure that your email service provider uses secure and trusted gateways to protect both incoming and outgoing communications. Verify that the provider complies with industry standards and regulations. 4. **Transmit Emails Over TLS**: Ensure that all emails are transmitted over TLS-encrypted connections. This can be configured in your email server settings. TLS (Transport Layer Security) helps protect the data in transit from eavesdropping and tampering. 5. **Open Source Alternatives**: * **GnuPG (GPG)**: An open-source implementation of PGP, widely used for encrypting and signing data and communications. * **Mailvelope**: A browser extension that integrates PGP encryption into web-mail services like Gmail, Outlook, and Yahoo Mail. * **ProtonMail**: A secure email service that offers end-to-end encryption and is open-source. It provides an easy-to-use interface and strong privacy protections. By following these best practices and utilizing the recommended tools, you can significantly enhance the security of your email communications. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Encryption in Transit Encryption in transit refers to how data is encrypted while it flows across networks. This is important as you don't want anyone eavesdropping on your traffic, and by following best practices such as the ones below, you can reduce the risk of that: ### Best Practices 1. Ensure that all data transmitted over the internet is encrypted using TLS/SSL. 2. Use secure VPNs to encrypt data transmitted over public networks such as public WiFi. 3. Use SSH for secure remote access to servers and other infrastructure. 4. Use encryption protocols such as S/MIME or PGP for email communications. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## File Encryption File encryption protects sensitive information stored in files. Use strong encryption algorithms to encrypt sensitive files stored on local and network drives. There are multiple tools available for file encryption; use one that is regarded as trusted. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Full Disk Encryption Full disk encryption protects all data stored on a device in the event that it's stolen or lost. Today, all major Operating Systems for workstations, servers and mobile phones have full disk encryption capabilities built in, and sometimes enabled by default. Check which full disk encryption is built into your operating system, and enable it if not enabled by default. ### Best Practices 1. Ensure that full disk encryption uses strong industry-standard algorithms. 2. Enable full disk encryption by default on all devices, including laptops, desktops, and mobile devices. 3. Implement secure boot to ensure that only trusted software can be loaded during the boot process. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Hardware Encryption Hardware encryption, such as HSM, uses dedicated hardware to encrypt data, providing robust security. Utilizing a HSM is a fairly specialized thing, but consumers are for example often using TPM. ### Best Practices 1. Enable TPM when available on your computer to enhance the security of hardware-based encryption. 2. Consider using self-encrypting drives (SEDs) for storage to ensure data is encrypted at the hardware level. 3. If relevant for your use case, use HSMs to securely generate, store, and manage encryption keys. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Encryption > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Encryption](/encryption/overview) * [Cloud Data Encryption](/encryption/cloud-data-encryption) * [Securing Communications](/encryption/communication-encryption) * [Database Encryption](/encryption/database-encryption) * [Email Encryption](/encryption/email-encryption) * [Encryption In Transit](/encryption/encryption-in-transit) * [File Encryption](/encryption/file-encryption) * [Full Disk Encryption](/encryption/full-disk-encryption) * [Hardware Encryption](/encryption/hardware-encryption) * [Partition Encryption](/encryption/partition-encryption) * [Volume Encryption](/encryption/volume-encryption) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Encryption Encryption is a fundamental aspect of securing data, ensuring that sensitive information remains confidential and protected from unauthorized access. This section covers various types of encryption and best practices for implementing them effectively. ### Contents 1. [Cloud Data Encryption](/encryption/cloud-data-encryption) 2. [Communication Encryption](/encryption/communication-encryption) 3. [Encryption in Transit](/encryption/encryption-in-transit) 4. [Database Encryption](/encryption/database-encryption) 5. [Email Encryption](/encryption/email-encryption) 6. [File Encryption](/encryption/file-encryption) 7. [Full Disk Encryption](/encryption/full-disk-encryption) 8. [Hardware Encryption](/encryption/hardware-encryption) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Partition Encryption ### What is Partition Encryption? Partition encryption is the process of encrypting specific partitions on a storage device. This allows for selective encryption of data, providing flexibility in managing encrypted and un-encrypted data on the same device. Unlike full disk encryption, which encrypts the entire disk, partition encryption targets specific areas, making it ideal for protecting sensitive data without impacting the entire storage system. ### Importance of Partition Encryption Partition encryption is crucial for protecting sensitive information from unauthorized access, especially in environments where different types of data coexist on the same device. It helps prevent data breaches in case of unauthorized access to specific partitions and ensures compliance with data protection regulations. ### Uses of Partition Encryption * **Protecting Sensitive Data**: Ensures that sensitive information stored on specific partitions is secure. * **Compliance**: Helps organizations meet regulatory requirements for data protection. * **Data Breach Prevention**: Reduces the risk of data breaches in case of unauthorized access to specific partitions. * **Secure Decommissioning**: Ensures that data on encrypted partitions is not recoverable when storage devices are decommissioned or repurposed. ### Examples of Partition Encryption * **BitLocker**: A partition encryption feature included with Microsoft Windows that provides encryption for specific partitions. [Learn how to use BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-overview) * **LUKS (Linux Unified Key Setup)**: A disk encryption specification for Linux that provides a standard for partition encryption. [Learn how to use LUKS](https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions) * **VeraCrypt**: An open-source disk encryption software that can encrypt specific partitions. [Learn how to use VeraCrypt](https://www.veracrypt.fr/en/Documentation.html) ### Best Practices for Partition Encryption 1. **Use Strong Encryption Algorithms**: Ensure that the encryption algorithms used are strong and up-to-date, such as AES-256. 2. **Enable Encryption on Sensitive Partitions**: Apply partition encryption to all partitions that store sensitive information. 3. **Regularly Update Encryption Software**: Keep encryption software and tools updated to protect against vulnerabilities. 4. **Implement Access Controls**: Use strong authentication methods, such as multi-factor authentication (MFA), to control access to encrypted partitions. 5. **Backup Encryption Keys**: Securely backup encryption keys to prevent data loss in case of key corruption or loss. 6. **Monitor and Audit**: Regularly monitor and audit encryption settings and access logs to ensure compliance and detect any unauthorized access attempts. By following these best practices and using reliable partition encryption technologies, organizations can significantly enhance the security of their data and protect against unauthorized access and data breaches. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Volume Encryption ### What is Volume Encryption? Volume encryption is the process of encrypting a specific storage volume or partition to protect the data it contains. Unlike full disk encryption, which encrypts the entire disk, volume encryption allows for selective encryption of specific volumes, providing flexibility in managing encrypted and un-encrypted data on the same device. ### Importance of Volume Encryption Volume encryption is essential for protecting sensitive information from unauthorized access, especially in environments where different types of data coexist on the same device. It helps prevent data breaches in case of unauthorized access to specific volumes and ensures compliance with data protection regulations. ### Uses of Volume Encryption * **Protecting Sensitive Data**: Ensures that sensitive information stored on specific volumes is secure. * **Compliance**: Helps organizations meet regulatory requirements for data protection. * **Data Breach Prevention**: Reduces the risk of data breaches in case of unauthorized access to specific volumes. * **Secure Decommissioning**: Ensures that data on encrypted volumes is not recoverable when storage devices are decommissioned or repurposed. ### Examples of Volume Encryption * **Partition Encryption**: Encrypts specific partitions or volumes on a disk, allowing for selective encryption of sensitive data. * **Virtual Encrypted Disks**: Creates virtual encrypted disks within files, providing an additional layer of security for sensitive data. ### Known Technologies for Volume Encryption * **BitLocker**: A volume encryption feature included with Microsoft Windows that provides encryption for specific volumes. * **LUKS (Linux Unified Key Setup)**: A disk encryption specification for Linux that provides a standard for volume encryption. * **VeraCrypt**: An open-source disk encryption software that can create virtual encrypted disks within a file or encrypt specific partitions. ### Best Practices for Volume Encryption 1. **Use Strong Encryption Algorithms**: Ensure that the encryption algorithms used are strong and up-to-date, such as AES-256. 2. **Enable Encryption on Sensitive Volumes**: Apply volume encryption to all volumes that store sensitive information. 3. **Regularly Update Encryption Software**: Keep encryption software and tools updated to protect against vulnerabilities. 4. **Implement Access Controls**: Use strong authentication methods, such as multi-factor authentication (MFA), to control access to encrypted volumes. 5. **Backup Encryption Keys**: Securely backup encryption keys to prevent data loss in case of key corruption or loss. 6. **Monitor and Audit**: Regularly monitor and audit encryption settings and access logs to ensure compliance and detect any unauthorized access attempts. By following these best practices and using reliable volume encryption technologies, organizations can significantly enhance the security of their data and protect against unauthorized access and data breaches. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Case Studies Here are a few deviations from the usual DPRK IT Worker patterns. **As mentioned a few times already, the goal is to always be open-minded about threat actor tactics.** They are known to evolve and adapt while also pushing their methods further. The examples below are anonymized, but they are real cases we have encountered in the past: ### Story 1 **Background:** A GitHub profile created in 2013, with no flagged "copied repositories" (indicating original code), an active and verified Twitter account from 2012, and no history of nickname changes on any platform. The user claimed to be Japanese, which was reflected in his posts and 10+ years of digital activity. The nicknames were "relevant" to Web3/Blockchain (e.g., using a "0x" prefix or "sol" in the name). A Rust developer with experience in Solana was looking to get hired by a Solana project. **Conclusion:** This was a DPRK IT Worker, confirmed by independent sources who had also been "spammed" by the same actor. The most likely reason for avoiding most software flags was a "stolen" account. DPRK operatives managed to get their hands on the GitHub and Twitter handles of a Japanese citizen, which had been lying dormant without ANY activity for 10+ years. They then proceeded to build a history on these accounts for almost two years before starting to apply for jobs and messaging other developers. It's worth noting that no event history was present for this GitHub account, as the original owner had never used it after signing up. This allowed them to build a "perfect" dummy history with no event data present in the GitHub Archive. This absence of data, along with a significant gap in Twitter activity between 2013 and 2022, contributed to flagging this particular actor. ### Story 2 **Background:** An actor who had worked for three years at a popular security company. (An example of a perfect backstory for future employment.) The actor was usually delegated auxiliary tasks, which he completed diligently and on time. He was reluctant to accept promotions or on-site invitations, citing his own business as the reason. The company was fine with this, as he was an auxiliary worker. His GitHub profile was created in 2021 and had a single, yet consistent, name change. The actor used his GitHub account only for work at that company and did not maintain any social media profiles. There was no overly informative README/About page, no avatar, and he consistently used a single Gmail address. **Conclusion:** This was a DPRK IT Worker. By cross-referencing our existing database and performing an extremely deep analysis of commits from actors we suspected were connected to him, we finally found his old nickname associated with two commits to an already known -but old and inactive - account of a known DPRK IT Worker. Confirmation was only possible through a video call with the company's participation. (On-call KYC and a few other tactics were used; the threat actor decided to abandon the call and delete his profiles.) ### Story 3 **Background:** An actor with a consistent identity across all relevant platforms (GitHub, Twitter, LinkedIn). He was referred by a legitimate company and had already been working with the affected company for a year. He claimed to be based in Canada (using an IP from a Laptop Farm), spoke good English, performed his tasks diligently and on time (the company claimed he was selected as a top candidate), had no issues with video calls, and used his own physical appearance (no Gen-AI). **Conclusion:** This was a DPRK IT Worker. **We scanned contributors to a few of his repositories and found that all of them were high-confidence DPRK IT Workers. From their profiles, we managed to pinpoint a history of identity rotations (changes in legal names).** The final confirmation was only possible with the company's participation. The actor was "cut off" from access to company infrastructure and given the pretext of a potential breach the company suspected. This gave them a reason to perform additional KYC - "to make sure the (suspected) dev account is not compromised." The actor was asked to go outside his claimed location and take a "selfie" in front of the house where he supposedly lived. He refused and resigned immediately, blocking all accounts. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## General Information ### What is an insider threat? Who are DPRK IT Workers? 1. An insider threat refers to the risk posed by individuals within an organization who misuse their authorized access to compromise the organization's security. This misuse can involve malicious actions like data theft or sabotage, but also unintentional actions like negligence (e.g. ignoring security updates) or accidents (e.g. sending sensitive document to the wrong email address) leading to security breaches and/or data leaks. 2. DPRK IT workers are individuals from North Korea (the Democratic People's Republic of Korea) who engage in remote IT work for foreign companies, often using false identities. Their work, while often appearing legitimate, is a source of revenue for the North Korean regime, may be involved in malicious activities, and constitutes a serious violation of international sanctions to send payments to North Korea. **"DPRK IT Workers" are synonymous with an "insider threat."** 3. Read: [OFAC's North Korea Information Technology Workers Advisory](https://ofac.treasury.gov/recent-actions/20220516) 4. Read: [Google's advisory on DPRK IT Workers](https://cloud.google.com/blog/topics/threat-intelligence/mitigating-dprk-it-worker-threat) ### Operational structure and short history of DPRK IT Workers 1. North Korean IT workers, operating both within the DPRK and abroad, are a significant source of revenue for the country's regime, particularly for its weapons programs. **They engage in various IT roles (but are not limited to these roles!), often disguising their identity and location to secure freelance contracts and generate income that is remitted back to North Korea.** These workers are primarily based in China and Russia, with some in other parts of Asia, Africa, and Latin America. **North Koreans are also observed to run a network of 'facilitators' (or local accomplices) to help them cover their identities and facilitate remote employment. The facilitator lends his or hers digital and physical identity in exchange for compensation from the DPRK IT Workers.** 2. Reports of North Korean IT workers operating internationally began to surface around the mid-2010s, with a growing awareness of their role in generating revenue for the regime. The number of DPRK IT workers increased, with a wider geographical spread and a diversification of their activities from the late-2010s to the present. 3. Read: [Google's North Korean Cyber Structure and Alignment](https://cloud.google.com/blog/topics/threat-intelligence/north-korea-cyber-structure-alignment-2023) 4. Read: [Google's advisory on DPRK IT Workers expanding scope and scale](https://cloud.google.com/blog/topics/threat-intelligence/dprk-it-workers-expanding-scope-scale) ### What are the goals of DPRK IT Workers? 1. Generating stable revenue for the North Korean regime through remote IT work. 2. Building support networks for North Korean IT-related operations (mules and money laundering). 3. Gaining access to Western companies' technology, infrastructure, and identities (both personal and company, digital and physical). 4. Exfiltrating company secrets (intentionally and unintentionally). 5. Extortion (ransomware and blackmail). 6. Avoiding sanctions (North Korean entities are barred from receiving any form of payment from Western countries). 7. Hacking (establishing permanent access to infrastructure in which they can gain a foothold or infiltrate). 8. Malware (infecting high-value targets for future theft). 9. Read: [DPRK IT Workers pushing malicious code and stealing 1.3M](https://x.com/zachxbt/status/1824047425822310580) 10. Read: [Highlights from the UN Security Council on DPRK IT Workers](https://x.com/tayvano_/status/1777911893224808911) ### How many DPRK IT Workers are there? The exact number is hard to estimate. DPRK IT Workers operate in separate 'cells' (different teams distributed over different locations, often without any direct contact with one another), and their organizational structure is flexible (even chaotic). Some workers focus exclusively on the blockchain space, while others are never seen applying outside of Fortune 500 companies. Estimates by different companies and government agencies vary between 2,000 and 15,000 in total. However, it's worth noting that this number includes multiple identities being re-used by the same actor or inactive accounts. **We estimate that about 3-5% of all Web3 developers are North Korean, and at any given time, there are at least 200-300 DPRK-related accounts actively seeking employment in Web3 companies.** ### Average DPRK IT Worker Profile In the following sections of this framework, we will discuss more advanced methods for detecting deeply nested DPRK IT Workers who may avoid the usual heuristics. However, it is still important to review the most common indicators of North Korean insider threats. If you suspect any of your contributors or have received a report regarding one, this set of questions can help you evaluate if you are dealing with a typical North Korean operative. 1. **Did you meet your contributor in real life?** 1. Yes - Significantly lowers the chance that the contributor is North Korean. 2. No - Red flag. 2. **Is your contributor an Asian man in his 20s or 30s?** 1. Yes - Red flag. 2. No - Lowers the chance that the contributor is North Korean, but they could still be a 'facilitator'. 3. **Does your contributor avoid real-life meetings?** 1. Yes - Red flag. 2. No - Even if they agree to a meeting, North Koreans will often try to postpone it indefinitely. 4. **How often do you sync with your contributor, and is their video on during calls?** 1. Often, with video on - Lowers the chance that the contributor is North Korean. 2. Rarely, or with video off - Red flag. North Koreans will try to appear 'independent' and focus only on technical output. 5. **Does your contributor consistently try to recommend someone else for the job? Are those recommendations also for Asian men in their 20s or 30s?** 1. Yes - North Koreans will try to place other North Koreans in your organization. 2. No - Lowers the chance that the contributor is North Korean. 6. **Is your Asian contributor's name 'westernized' (e.g., Victor Lee, James Kano) or extremely generic/popular (e.g., Scott Brown, James Smith)?** 1. Yes - North Koreans have a tendency to use generic, pre-generated fake names. 2. No - Lowers the chance that the contributor is North Korean. 7. **Does the KYC documentation provided by your Asian contributor show an unorthodox combination of nationality and physical appearance (e.g., an Asian man living in Indonesia with a Latin American passport)?** 1. Yes - North Koreans often repurpose stolen identities to fit their fabricated backstory. 2. No - Lowers the chance that the contributor is North Korean. 8. **Does your contributor have poor English communication skills, despite claiming to live in the US?** 1. Yes - It is atypical for someone with a US passport to have poor English skills in an IT job. 2. No - Lowers the chance that the contributor is North Korean. We cover more detailed indicators in the section [**Techniques, Tactics, and Procedures**](/dprk-it-workers/techniques-tactics-and-procedures) *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Dprk It Workers > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [DPRK IT Workers](/dprk-it-workers/overview) * [DPRK IT Workers: General Information](/dprk-it-workers/general-information) * [DPRK IT Worker TTPs](/dprk-it-workers/techniques-tactics-and-procedures) * [Mitigating DPRK IT Worker Threats](/dprk-it-workers/mitigating-dprk-it-workers) * [DPRK IT Worker Case Studies](/dprk-it-workers/case-studies) * [DPRK IT Workers Summary](/dprk-it-workers/summary) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Mitigating DPRK IT Workers This section discusses ways you can harden your organization against DPRK IT Workers, both before and after a potential hiring. All of the strategies covered in the prior section, [**Techniques, Tactics, and Procedures**](/dprk-it-workers/techniques-tactics-and-procedures), still apply but serve a more 'active' role to identify DPRK IT Workers during recruiting or within your organization. Here, we will discuss mitigation strategies that limit the effects of a DPRK IT Worker infiltration and what you should do after identifying a successful infiltration. ### Hardening your hiring processes 1. Apply all the steps from the sections [Am I Interviewing a DPRK IT Worker?](/dprk-it-workers/techniques-tactics-and-procedures#am-i-interviewing-a-dprk-it-worker) and [Did I hire a DPRK IT Worker?](/dprk-it-workers/techniques-tactics-and-procedures#did-i-hire-a-dprk-it-worker). **It's important to educate all of your non-DPRK employees on these points, especially people responsible for hiring, developer relations, talent hunting, and community management.** 2. Introduce a culture of background checks. Do not take a prospective developer's claims at face value. **Even the most basic OSINT check can often discover deep inconsistencies. Check GitHub commit history, check Twitter history, and Google the full name of the developer.** 1. Is the work experience claimed in the CV reflected on GitHub? 2. Does the potential employee indicate any physical presence anywhere? 3. Is the potential employee writing non-AI-generated posts and replying to anything other than job offers on Twitter? 4. Did you find any name collisions after searching for the potential employee's name in Google? 5. Did you check the potential employee's nickname in Google? Maybe they have already appeared as a threat actor in a past report? 6. **Remember the best discovery rule:** You're looking for misrepresentations, mismatches, and obfuscation, not for North Koreans specifically. Tick your boxes on the first three and only then proceed to decide if you're potentially dealing with a North Korean. 3. **Do not try to undercut developer market salaries.** DPRK IT Workers will always accept low-ball offers without much hesitation. If you're looking for a cheap hire, you are at a higher chance of hiring a DPRK IT Worker. 4. **ALWAYS perform your own due diligence on new remote employees.** Do not settle for recommendations from third parties; they could be victims themselves. 5. You could ask about North Korea on call and observe the reaction. There's a so-called "F\*\*k Kim Jong Un" test, where interviewer is asking to repeat the phrase and North Koreans are banned from saying it and they drop the call immediately. Obviously, it won't be effective for 'facilitators' but it will most likely be effective for North Koreans themselves. Do not rely on it as a panacea. 6. Regardless of our tips of not focusing on "Asian man in his 20-30s" that particular appearance is still the most common (If not cloaked under the generative AI). Similarly, Korean-English accents. ### Hardening your organization 1. Define and implement tight access control rules for all of your employees, especially remote ones. Avoid giving privileged access to workers who did not pass 100% of the tests and filtering criteria for DPRK IT Workers (all the points already discussed). Specific examples of privileged access include: 1. Do not give admin permissions to your GitHub organization and repositories, including for build releases, adding members, and repository settings. 2. Do not give publishing permissions on any package managers. The publishers of your packages are a critical supply chain risk; they need to be 100% vetted. 3. Do not add your remote employees as multisignature wallet signers. The signer role should be reserved only for high-trust individuals, not based on the dedication of the developer you are working with. 4. Do not give unlimited access to cloud instances. Scope permissions to the minimal access required for each individual or team, including setting minimal expiration times for access tokens (e.g. access tokens should expire within hours, not weeks). 2. Define a lead developer - a highly trusted individual you've met in real life and are sure of their background - as the code reviewer, publisher, signer, and image builder. This individual's role should be to double-check all of the remote workers' work and actions within your organization at all times. Make sure the lead developer is not a DPRK IT Worker. 3. Silo your remote workers from the most critical infrastructure. If you choose to provision access to such infrastructure, always create a threat model to understand the 'worst-case' scenario and potential mitigation approaches. 4. Monitor your logs for IP addresses, user sessions, and timestamped access. Monitor your remote contributors' actions for any sudden changes (identity changes) and potential secrets leaks through their private accounts. You can obtain such information from Google, Slack or GitHub Workspaces, depending on your organization setup and tiers. 5. **DO NOT allow hired contributors to use throwaway GitHub accounts for the work at your company!** It's part of the DPRK IT Worker tactics to save their main accounts from being discovered. 6. If your project allows, it may be beneficial to establish a public codebase on GitHub and have your remote workers make at least *some* public contributions related to your project. If all of your codebase is supposed to stay private, at least list all of the contributors (CODEOWNERS) in a special repository created specifically for that purpose. Security researchers like SEAL911 scan such public codebases and will notify you privately if they suspect DPRK IT Workers are contributing to your project. ### I hired a DPRK IT Worker. What now? 1. Contact security professionals if you're unable to handle the situation alone. You can reach out to SEAL911 (@seal\_911\_bot on Telegram). 2. **You do not need to end the engagement abruptly. It's important to maintain a facade while you deal with access revocation and mitigate any immediate risks to your organization.** Act normally, but start preparing an actionable plan immediately and aim to remove the DPRK IT Worker within the next few days at most. If your organization is properly siloed from insider threats, you shouldn't have much of an issue firing the worker almost immediately after conducting a post-mortem review. 3. **Check whether you hired more than one DPRK IT Worker. In the majority of cases, we find more DPRK IT Workers within the same organization.** They do not always come as a recommendation from an already-discovered DPRK IT Worker; they simply already know how to abuse your hiring process. 4. At the same time, **you should immediately cease any further payments to the DPRK IT Worker. It's illegal.** You can cite temporary financial issues as the reason for the delay if confronted by the worker and you still need a bit of time to deal with the situation. 5. List all infrastructure endpoints the DPRK IT Worker had access to, both sensitive and not. Useful, for the next steps. 6. Review the current and past work of the accounts in question. The code does not necessarily need to be malicious, but it can be of overall poor quality. **Pay extra attention to added dependencies or edited CI/CD files.** 7. Review the permissions that these actors have or had in your organization. **Revoke them.** 8. **Review all of the files and links previously provided by the DPRK IT Worker and who opened them.** The issue may extend beyond your technical workers. Look back to see whether you potentially ran malware-infested code or give them remote desktop access to your or your developers' machines. 9. Set up a final confirmation call after all access is revoked and you are certain your organization is safe from any insider threats. **Attempt to perform KYC under some pretense. Do not settle for document scans, as these are easily obtainable.** Insist on a "video call" KYC, where the actor must show the physical document they previously provided next to their face. 10. Attempt to geolocate them. Send a document that tracks the IP address used to open it. Look for VPN usage or IP addresses in the DPRK/Eastern Russian range. 11. Collect all on-chain/payroll data on funds transferred to the actor. If an actor is confirmed as DPRK-related, you will be required to file a Suspicious Activity Report (SAR). We would appreciate you sharing this data with [SEAL911](https://www.securityalliance.org/) later for public security reasons and future investigations. The data will remain private. 12. You do not need to inform the DPRK IT Worker about the actual reasons for termination. You can cite downsizing, poor performance, lack of cultural fit, or any other reason. 13. **In the post-mortem phase, you will need to halt all development on the affected infrastructure.** For companies that hired a DPRK IT Worker as a "Core Engineer," this may sometimes mean several weeks of re-auditing all code and infrastructure. **You should stop and do it.** At the same time, build a threat model to prevent the situation from recurring and to limit its effects if it does happen again. You can remove the DPRK IT Worker's code from your codebase. **DPRK IT Workers will claim this code as part of their work experience in their future job searches.** The decision is ultimately yours. While not removing the code helps security researchers like those at SEAL911 track these workers, our recommendation is to remove it to protect your project and deny adding credibility to DPRK IT Worker. ### Data collection 1. You should collect the following data before firing the DPRK IT Worker. This data will help organizations like SEAL with future mitigation and the discovery of other actors. 1. Full Legal Name 2. Phone 3. Email(s) 4. Location (City/State) 5. LinkedIn 6. Telegram/Discord 7. GitHub 8. Copy of Resume 9. Date Hired 10. Sourcing (Where were they hired from? Telegram, Staffing, Recruiter, etc.) 11. Company Email (Yes/No) 12. IP addresses (from email or any other sources at your disposal) 13. Managed Laptop (Yes/No) 1. Shipment address (for the laptop or other items) 14. KYC data (ID/Passport/Bills document scans) 15. Photos/Screenshots (physical appearance, potentially from a video call) 16. Payment data **(Extremely important!)** 1. On-chain addresses provided for payment 2. Bank data 17. Did they refer anyone else? 18. Were they referred by someone else? ### Overview of risks to your organization 1. **Defrauding the company:** The company is paying someone whose identity they do not know. 2. **Subpar operational security:** DPRK IT workers share credentials among themselves in open channels, have a poor command of Git, and unintentionally or intentionally leak the access they are granted to third parties. 3. **Extortion:** They may try to extort more money after a job is finished. 4. **Future hacking activities:** They may use the knowledge gained for future hacking activities. 5. **Sanctions violations:** The DPRK is a sanctioned entity. No company can legally transfer funds to DPRK-related operations. 6. **Contribution to the North Korean Military:** DPRK IT worker salaries directly contribute to the Military Ministry of North Korea. The workers do not keep the salaries for themselves. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Insider Threats (DPRK) This framework serves as an entry point to understanding the organizational and personal risks related to "Insider Threats," most commonly (though not exclusively) associated with "DPRK IT Workers" - the North Korean hacker-freelancers. This framework is targeted at projects affected by insider threat actors as well as projects wanting to harden their posture against these actors. Throughout this module, we will discuss: * Who insider threat actors are and what they do * How to recognize insider threat actors * How to interact with a potential threat actor * How to mitigate the risks and impact of insider threat actors * How to harden your defenses against insider threat actors * Potential consequences of insider threats for you and your organization ### Table of Contents * [**General Information**](/dprk-it-workers/general-information) * [What is an insider threat? Who are DPRK IT Workers?](/dprk-it-workers/general-information#what-is-an-insider-threat-who-are-dprk-it-workers) * [Operational structure and short history of DPRK IT Workers](/dprk-it-workers/general-information#operational-structure-and-short-history-of-dprk-it-workers) * [What are the goals of DPRK IT Workers?](/dprk-it-workers/general-information#what-are-the-goals-of-dprk-it-workers) * [How many DPRK IT Workers are there?](/dprk-it-workers/general-information#how-many-dprk-it-workers-are-there) * [Average DPRK IT Worker Profile](/dprk-it-workers/general-information#average-dprk-it-worker-profile) * [**Techniques, Tactics, and Procedures**](/dprk-it-workers/techniques-tactics-and-procedures) * [How can DPRK IT Workers find a job in your company?](/dprk-it-workers/techniques-tactics-and-procedures#how-can-dprk-it-workers-find-a-job-in-your-company) * [Am I Interviewing a DPRK IT Worker?](/dprk-it-workers/techniques-tactics-and-procedures#am-i-interviewing-a-dprk-it-worker) * [Did I hire a DPRK IT Worker?](/dprk-it-workers/techniques-tactics-and-procedures#did-i-hire-a-dprk-it-worker) * [After a DPRK IT Worker is hired by your company](/dprk-it-workers/techniques-tactics-and-procedures#after-a-dprk-it-worker-is-hired-by-your-company) * [**Mitigating DPRK IT Workers**](/dprk-it-workers/mitigating-dprk-it-workers) * [Hardening your hiring processes](/dprk-it-workers/mitigating-dprk-it-workers#hardening-your-hiring-processes) * [Hardening your organization](/dprk-it-workers/mitigating-dprk-it-workers#hardening-your-organization) * [I hired a DPRK IT Worker. What now?](/dprk-it-workers/mitigating-dprk-it-workers#i-hired-a-dprk-it-worker-what-now) * [Data collection](/dprk-it-workers/mitigating-dprk-it-workers#data-collection) * [Overview of risks to your organization](/dprk-it-workers/mitigating-dprk-it-workers#overview-of-risks-to-your-organization) * [**Case Studies**](/dprk-it-workers/case-studies) * [Story 1](/dprk-it-workers/case-studies#story-1) * [Story 2](/dprk-it-workers/case-studies#story-2) * [Story 3](/dprk-it-workers/case-studies#story-3) * [**Summary**](/dprk-it-workers/summary) #### Overview of risks to your organization 1. **Defrauding the company:** The company is paying someone whose identity they do not know. 2. **Subpar operational security:** DPRK IT workers share credentials among themselves in open channels, have a poor command of Git, and unintentionally or intentionally leak the access they are granted to third parties. 3. **Extortion:** They may try to extort more money after a job is finished. 4. **Future hacking activities:** They may use the knowledge gained for future hacking activities. 5. **Sanctions violations:** The DPRK is a sanctioned entity. No company can legally transfer funds to DPRK-related operations. 6. **Contribution to the North Korean Military:** DPRK IT worker salaries directly contribute to the Military Ministry of North Korea. The workers do not keep the salaries for themselves. 7. **Supply-chain compromise:** DPRK IT Workers may intentionally introduce vulnerabilities that impact down-stream projects that depend on your software / services (e.g. SafeWallet UI in the ByBit hack). 8. **Reputational damage:** To your brand and loss of trust of your users and customers. 9. **Asset freeze / loss of access to financial services:** your assets may be frozen or seized, and financial institutions (e.g. banks, exchanges) may terminate your access if you are suspected of funding sanctioned entities. 10. **Criminal investigations:** Law enforcement may investigate your involvement and impose fines or press criminal charges against your organization. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Summary * **Who are DPRK IT Workers?** They are North Korean individuals, often operating from abroad (primarily China and Russia), who use fraudulent identities to secure remote IT jobs. Their primary goal is to generate revenue for the North Korean regime, which may involve legitimate work but also opens the door to espionage, data theft, extortion, and future hacking activities. * **How to Spot DPRK IT Workers During Hiring:** * Focus on detecting **fraud and misrepresentation**, not stereotypes. Look for inconsistencies across their CV, digital profiles, and interview answers. * During video interviews, insist the camera is on. Watch for AI-generated faces, obscured or generic backgrounds, and an inability to answer small-talk questions related to their claimed location or nationality. * Scrutinize their GitHub profile for red flags like a recent account creation date with years of "faked" commit history, "copied" repositories from legitimate projects, spam-like contributions, or interactions with other suspicious accounts. * Check their social media (LinkedIn, Twitter) for a lack of personal photos, a history of job-begging posts, and no evidence of a physical presence at conferences or events. * Be wary of highly unorthodox identity combinations, such as an Asian individual living in one country while providing KYC documents from a completely different continent. * **How to Verify an Existing Employee:** * Watch for behavioral patterns like consistently avoiding in-person meetings with repeated excuses or work patterns that don't match their claimed time zone. * Audit workspace logs for suspicious IP addresses (VPNs, proxies, known sanctioned regions). * Be on high alert if an employee suddenly changes their name or GitHub handle, or deletes social media accounts, as this often happens after being discovered elsewhere. * Verify their claimed work history independently. Be cautious if they recommend other candidates, as they often leverage their position to bring in more DPRK operatives. * **How to Harden Your Organization:** * Implement a "least privilege" principle for access control. New and remote employees should not have admin rights, permission to publish packages, or be signers on multisig wallets. * Appoint a trusted, fully-vetted individual to review all code and actions from remote contributors before they are merged or deployed. * Perform your own due diligence on all remote hires. Do not rely solely on third-party recruiters or recommendations, as they can also be victims. * Avoid the temptation to hire based on the lowest salary offer, as DPRK IT workers often work at a significant discount. * **What to Do After Discovering a DPRK IT Worker:** * **Do not fire them immediately.** Maintain a normal appearance to avoid tipping them off while you secure your organization. * **Immediately stop all payments**, as funding them is a sanctions violation. If confronted, use a pretext like "financial issues" to buy time. * **Systematically revoke all access** to code repositories, cloud infrastructure, and internal systems. At the same time, collect all available data (KYC docs, crypto addresses, emails, resumes) for reporting. * **Conduct a full security audit** of all their code contributions, paying close attention to dependencies, build files (CI/CD), and potential backdoors. * Once your systems are secure, terminate their contract using a business-related reason (e.g., downsizing, change in direction) and report the incident to law enforcement. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Techniques, Tactics, and Procedures This section focuses on avoiding, discovering, and confirming the threat of DPRK IT Workers to your organization. The sections dedicated to answering the questions "Am I interviewing a DPRK IT Worker?" and "Did I hire a DPRK IT Worker?" are interchangeable and both provide strategy outlines for avoiding, discovering, and confirming DPRK-related insider threats. Your organization can use tips from these sections to identify a DPRK IT Worker before you hire them, as well as to identify them after you have made the mistake of hiring one. This section focuses on dealing with emergent situations to identify potential DPRK IT workers who are attempting to or already have infiltrated your organization. In the next section, ([**Mitigating DPRK IT Workers**](/dprk-it-workers/mitigating-dprk-it-workers)), we will discuss strategies to harden your organization to minimize both the impact and the chances of infiltration and how to deal with the fallout of hiring a DPRK IT Worker. ### How can DPRK IT Workers find a job in your company? 1. There is no single established channel through which a DPRK IT Worker can approach your company. Applying with an impressive CV and GitHub portfolio through a public channel (LinkedIn/Job Portal) is common; however, we have often observed alternative routes, such as: 1. **Direct outreach to CEO/CTO.** They are persistent until clearly denied the opportunity, and even then, the actor may change their identity and try again. 2. **Initiating contact through open-source contributions.** An actor will submit valid Pull Requests to your repositories and use this as a way to request a job interview. 3. **Recommendation.** A worker will come recommended by another DPRK IT Worker or by a company they previously infiltrated (where the company may or may not be aware the employee is a DPRK IT Worker). 4. **Tech recruiters.** Recruiters often prioritize evaluating skillsets over performing background checks. DPRK IT Workers can appear on their radar and be unwittingly pushed by a legitimate tech recruiter to your company. 5. **Bounty/Hackathon participation.** DPRK IT Workers look for ANY source of revenue, no matter how small or large. If your company runs free-for-all bounty systems, it's extremely likely that some of the contributors are DPRK IT Workers. 6. **Hired through a "dev shop."** If you recruit your employees through an outsourcing agency, you need to ensure their vetting process is appropriate. The outsourcing agency itself can be a victim of DPRK IT Worker infiltration. 2. The bottom line is that there is no single "safe" remote recruitment channel. You should vet your potential employees independently and **look beyond their skillset, which can often be impressive.** We have observed DPRK IT Workers joining companies by utilizing all the channels mentioned above. Establish a high-quality hiring process to avoid recruiting DPRK IT Workers; do not blindly rely on outsourced solutions. ### Am I Interviewing a DPRK IT Worker? 1. The list below can serve as a guide for avoiding hiring a DPRK IT Worker and as an exit-interview guide for verifying if an employee is a DPRK IT Worker. 2. Before discussing the heuristics: **Don't over-focus on stereotypical DPRK IT worker characteristics, such as being an Asian male in their 20s or 30s, using specific headphones, or obscuring their background. What you are looking for is evidence of misrepresentation and fraud. Job fraud is not exclusive to North Koreans - approach it as such.** 3. Below is a list of 'red flags' that can help you evaluate with higher confidence if you are dealing with a DPRK IT Worker. However, always keep the above point in mind! For every 'obvious' DPRK IT Worker, there will be some who are able to evade most, if not all, of the following flags: 1. **Is their video on?** If not, insist they enable their camera. 1. Some DPRK IT Workers have no problem presenting as themselves (without a facilitator, AI, or disabled video). See if you recognize anyone from this [Collection of DPRK IT Workers photos](https://x.com/browsercookies/media). 2. **Is the background visible or obscured?** An obscured background isn't always a red flag, but it can be helpful for the final assessment. 1. DPRK IT Workers love "stock" backgrounds. You'll often find them using the Golden Gate Bridge as a backdrop. Other times, you may notice them sitting in low-quality housing where the workspace is only divided by temporary walls or rugs. 3. Read: [Detect if it's an AI-generated face or deepfake](https://unit42.paloaltonetworks.com/north-korean-synthetic-identity-creation/). 4. **Start with small talk** relevant to their claimed nationality and location. This is especially important if you're dealing with someone presenting as an Asian man but providing, for example, Latin American documents/names while claiming to live in Southeast Asia (an identity mismatch). **Note: While a smaller number of female DPRK IT workers have been identified, they do exist. In other cases, you might encounter hired female facilitators. If the candidate claims to be in your country, offer an on-site interview. Beware, DPRK IT workers may send a stand-in. Verify that the person attending is the same one from the call.** 5. **Keep an open mind** about gender, nationality, and experience. **DPRK IT workers are known to use facilitators from all over the world. This means you might encounter a non-Korean individual on the call who is, in fact, a DPRK IT worker.** Similarly, a DPRK IT worker's portfolio can sometimes be impressive and not far off from their claimed experience. In previous instances, we've found profiles showing 2-3 years of work for reputable organizations. 6. **Go through the candidate's background.** Verify the timelines of their claimed experience (e.g., "You worked at Company X from when to when?"). While the candidate answers, observe if they seem to be reading from a script. Try to mix up details from their claimed experience and note their reaction (e.g., "I see you worked at XYZ," when you know from their CV that they didn't). This is good general advice. If the candidate appears to be relying on ChatGPT for answers (reading from the screen), it's a red flag. 7. **Conduct a language comprehension test.** If the candidate claims to be Japanese, ask them questions in Japanese. Beware, some DPRK IT workers can speak Japanese or Chinese, though their proficiency is often similar to their English skills (A1/A2 level). See: [North Korean failing to answer questions in Japanese despite claiming to be Japanese](https://www.ketman.org/dprk-it-workers-in-freelance-platform-onlyDust.html#:~\:text=With%20the%20sole,can%20watch%20below.) 8. **Ask if the candidate is at home or a co-working space.** 1. Look for movement in the background. 2. If they claim to be at home, you can try a quick KYC check: **ask them to show their ID card next to their face.** 9. **Carefully observe the candidate's screen presentation if they share their screen.** Often, you might notice different GitHub, Gmail, or other social network profiles active on their screen than those claimed in their CV. It's best not to give the candidate a chance to prepare for this. Casually ask, "Could you walk us through your best code on GitHub by sharing your screen?" 10. **Evaluating a potential DPRK IT Worker's GitHub profile:** 1. The account creation date is later than the commits in its hosted repositories (an artificially aged account). This is especially suspicious if many repositories follow this pattern and the user claims experience aligning with the age of these manipulated commits. This can be a false positive but is usually easy to clear up. Some users re-upload their old code, pre-dating the GitHub account creation date. A false positive for this particular flag can be deduced from the overall quality of the account. 2. A high number of followers and accounts followed (e.g., over 200). If the user is a popular developer with a significant online presence, this isn't a red flag. **False positives can occur for accounts that automatically follow back or for Developer Relations (DevRel) and recruitment professionals.** 3. A high number of contributors to the user's repositories. If the user is not a popular developer, this is a red flag. Regular developers typically won't have 100+ contributors to their repositories without a significant online presence. **This flag has a tendency to be polluted with high numbers of contributors on "copied" repositories, where a DPRK IT Worker has "injected" themselves as an author but has also kept the original contributors' usernames.** 4. Quality of opened Pull Requests and Issues. **It's useful to retrieve the full history of Pull Requests and Issues opened by the user and review them for quality.** For advanced DPRK IT workers, these may not differ significantly from those of regular developers. Additionally, if a suspicious user was `@pinged` in a PR or Issue, it might help uncover a previous nickname. Look for automated or spam-like text/code. DPRK IT Workers will often go for "quantity" over "quality." **At the same time, some DPRK IT Workers will be authors of perfectly valid Pull Requests and Issues - an artifact of their previous employment or a better credibility-building effort.** 5. **Overly informative (full of images and stats) GitHub profile README/About page.** 1. This can be a false positive. Regular developers have been observed to overuse this section. 6. **Avatars.** 1. DPRK IT workers often use AI-generated images (not necessarily faces) as their avatars. They typically use freely accessible models like Stable Diffusion or Midjourney. 2. "Cartoonish" avatars are also popular: CGI-style images of fictional characters, Minion avatars, and NFT-related avatars (especially Pengu and Doodles). 3. **Having no avatar at all is also common.** 4. Reference: [Identifying Suspicious GitHub Accounts](https://www.ketman.org/identifying-suspicious-gh-accounts.html) 7. **Social media links.** 1. In many cases, there will be a Twitter link. It's always worth visiting. 1. Check the "Media" page for images uploaded by the account owner. **Can you find any pictures from conferences or showing their physical appearance?** DPRK IT workers usually will not post pictures from physical locations. **The exception to this rule would be "facilitator" or "purchased/stolen" accounts.** 2. Look for job-begging tweets. 3. References: 1. [Nick Franklin Case - A well developed IT Worker persona](https://x.com/tanuki42_/status/1905003045433290940) 2. [Nick Franklin Case - Activity across different platforms](https://x.com/danielvf/status/1905642180749775189) 8. **Suspicious interactions.** 1. Contributions to low-quality external repositories and/or organizations. **DPRK IT workers are known to set up "fake" organizations on GitHub, often populated by other IT workers. Similarly, DPRK IT workers will cross-commit to each other's repositories.** It's worth checking the profiles of contributors to the potential threat actor's repositories: are these contributors legitimate themselves? A full data dump of the GitHub account may be useful, but cherry-picking a few repositories from the profile is often effective enough for a first pass. 1. Reference: [A counter example - Good looking IT Worker GitHub Profiles](https://x.com/blackbigswan/status/1873364567285449160) 9. **Repositories.** 1. "Copied repositories." DPRK IT workers will try to boost their credibility by pushing a clone of a legitimate repository to their own account (Google: "How to fake GitHub history"). They will often edit the `.git` config and insert their own account data. Usually, they won't remove all original contributors but will insert themselves among them. **Use GitHub's search feature to find the original repository by name, commit SHA, or a unique string extracted from within the repository. Compare the actual account creation date with the profile's UI-displayed history: is it consistent, or is the account's creation date more recent than the years of activity displayed?** A simple API query to get the account creation date from GitHub may be necessary here. 2. GitHub's Activity Badge for contributing to an organization. Verify if it's an actual contribution like a PR or commit or just a spam Issue/Comment/PR. This is an often-utilized method for highly popular repositories (e.g., OpenZeppelin, Paradigm) where core developers are reluctant to merge spam PRs. 1. Reference: [DPRK IT Workers faking GitHub Activity Badges](https://x.com/blackbigswan/status/1876953373187920054/photo/1) 11. **Evaluating other immediately available data points:** 1. **Full Name.** 1. Even if a full name is "fake," it can still be a useful data point. DPRK IT workers rotate their identities, but they need to maintain them for at least some time. **Another challenge they face is managing multiple personas; you may catch an "identity confusion" where a DPRK IT worker uses different names in different places, for example, a different name used/mentioned on GitHub than on a call or on other social profiles.** It's also possible to notice different names used with the same (or different) GitHub owner's email addresses. 1. Take extra care with Asian names, especially Chinese names. Chinese citizens often westernize or shorten their full names in various ways. This doesn't necessarily mean they are malicious. 2. In most cases, DPRK IT workers prefer to use Asian (Japanese, Chinese, Korean) names. However, they are also known to use fake names from all around the world, corresponding to where their "facilitators" are based. This includes American names ("James" being an extremely popular choice) and even European names (e.g., Polish, Ukrainian, Hungarian). 1. DPRK IT workers may have access to KYC documents issued for their claimed nationality. **You should be alarmed by highly unorthodox combinations**, such as an Asian man living in Indonesia with Argentinian KYC documents. 2. **Location.** 1. Japan and the USA are extremely popular choices for claimed locations. Additionally, Southeast Asian countries like Thailand, Malaysia, Singapore, or Taiwan are also common. The actual physical location is commonly the DPRK (Pyongyang, border regions), China (border regions), Eastern Russia (Vladivostok), Laos (Vientiane), Indonesia, Vietnam, and parts of Africa. It's possible to obtain the IP address of a potential DPRK IT worker through a DocuSign document that collects HTTP headers. DPRK IT workers are known to utilize "laptop farms," meaning they can hide their IP behind an actual fixed/landline IP address in their claimed country of residence. 3. **OSINT analysis.** 1. We recommend checking each suspicious email address with a service like [https://epieos.com](https://epieos.com). It can provide additional data points, such as a LinkedIn profile, which can uncover further identity mismatches. 1. On LinkedIn, examine the strength of the actor's connection network. #### Defeating Deepfakes: Liveness Verification Pre-recorded deepfake video can fool a casual interviewer, particularly when audio "technical difficulties" are used as cover. Incorporate unpredictable, interactive requests that a pre-rendered deepfake cannot handle: * Ask the candidate to turn their head sideways and hold the position * Have them read a randomly generated phrase displayed on screen for the first time during the call * Request a hand movement across the face mid-stream * Ask them to screen-share and perform a live technical task requiring real-time interaction with their environment > Any candidate who persistently avoids in-person interaction — even for high-value roles — warrants a security > review. This is a documented indicator of DPRK IT worker activity. ### Did I hire a DPRK IT Worker? 1. The list below serves as a guide for confirming your suspicions if one of your employees is a potential DPRK IT Worker. We're focusing on using non-enterprise flags accessible to even the smallest of projects. The assumption is that your project has limited EDR/SIEM logging infrastructure (you should, however, consider implementing some monitoring infrastructure in the future). 1. If your organization has EDR/SIEM capability, read: [DTEX advisory on DPRK Insider Threat Kill Chain](https://www.dtexsystems.com/resources/i3-threat-advisory-inside-the-dprk/) 2. Consider using GitHub Enterprise for your organization to have access to more detailed logs. 2. Before discussing the heuristics: **Don't focus on negating your suspicion; focus on clearing it up. It doesn't matter if you're checking a long-time employee who provides good technical output, is not Korean/Asian, logs into the workspace using a US-based IP, or came recommended. DPRK IT Workers have been known to successfully evade detection for YEARS.** Focus on creating a full profile of your employee and judge it based on the complete picture and any inconsistencies you find. 3. Below is a list of 'red flags' that should prompt immediate action from your side (e.g. a deep background check): 1. **Avoiding real-life meetings.** Even if they initially agree to meet, they might come up with explanations as to why they can't. They often cite 'family reasons' or 'travel abroad.' The situation can repeat itself for every single meeting proposal, regardless of the location. **You can propose to meet at their location as a final test.** 2. **Inconsistencies in work and communication.** It's often the case that a single DPRK IT Worker account is operated by a few individuals, especially if your company communication is sparse. One week you may observe good quality and high output; the next week, a significant drop. Similarly, for communication, you may observe the worker being overly 'mute' on all company sync calls or clueless as to what was discussed in previous meetings. They will also often have issues communicating about their code but not with the code development itself (a sign of more than one worker on a single account). 3. **Timezone.** If your worker claims to be in Texas (GMT-5) but is located in Pyongyang (GMT+9), you may observe work patterns closer to North Korean time than to Texan time. Note that DPRK IT Workers work around the clock and can circumvent this flag easily. 4. **Bogus work history.** Verify if the job history claimed on their CV is real. You can always reach out to the previous company for background information. In most cases, the history will be made up, but there are exceptions. DPRK IT Workers may list legitimate companies for which they did previous work but were let go (without that company's knowledge of their true nature). Sometimes, DPRK IT Workers will list organizations they control, so exercise caution when contacting anyone for background information. 5. **Identity switch.** Be on guard if an employee's profile suddenly changes its nickname/identity. DPRK IT Workers do this often, usually when discovered in one of their previous jobs and for fear that someone will notify your company. **They may suddenly start using a different GitHub handle (this includes suddenly pushing a Pull Request using a different account than usual), delete their social media accounts, or get banned from LinkedIn.** Additionally, they may occasionally 'confuse' their fake identities and log in to your company workspace or a meeting using a completely different account. 6. **Identity mismatch.** It should raise questions if your employee is Asian but provides non-Asian KYC documentation along with poor language skills. **Run a background check on all the data.** Can you find a person with the same name whose identity was potentially stolen or borrowed? Is the address provided legitimate, or does it seem 'random' (e.g., an empty house, a business venue)? Google "(Full Name of your worker) + sentenced" to see if the DPRK IT Worker bought a criminal's identity (an often-seen case with claimed US-based personas). Perform a reverse image search on your worker's profile pictures/avatars. Are there more similar accounts using the exact same image? **Beware that DPRK IT Workers have no issues providing credible-looking KYC documentation; some of these documents even pass authentication checks on specialized services.** 7. **Recommending other suspicious accounts for work.** DPRK IT Workers will leverage their initial foothold in your organization to propose other DPRK IT Workers for a job. Their recommendations will usually follow the same patterns. Many organizations fall for it and hire multiple workers **(sometimes, as much as 50-70% of the entire company is composed of DPRK IT Workers if such tactics succeed).** Additionally, check if the potential DPRK IT Worker hasn't already added some of their 'friends' to your organization without your knowledge. 8. **Proximity to other suspicious/spam accounts.** Don't be fooled by GitHub or Twitter accounts that are over 10 years old. DPRK IT Workers can easily source these. However, check if your worker has any meaningful history of interaction with their followers/following. Or, do all accounts in proximity to your worker appear spam-like or like bots? 9. **Poor social skills.** It's usually (but not always) the case that a DPRK IT Worker will have trouble with 'small talk.' This isn't necessarily because of cultural differences (DPRK IT Workers are educated on Western culture and language as part of their job). It's often because of the sheer volume of remote gigs they handle and how confusing it can be. A DPRK IT Worker will prefer to always steer the conversation toward technical details. 10. **Review Workspace logs (IP addresses).** Check if the IP addresses used to log in to your infrastructure are coming from the same location as claimed by the worker. VPNs, proxies, or Russian ISPs are red flags, as are highly inconsistent IP ranges (a mix of the sources mentioned). Beware that DPRK IT Workers are known to utilize "Laptop Farms." Read: [North Korea Infiltrates U.S. Remote Jobs - With the Help of Everyday Americans](https://archive.ph/Mb68C) 11. **Payments.** North Koreans can organize a 'drop' bank account to receive wire transfers; however, their preferred method of receiving a salary will be through cryptocurrency, usually at a flat rate that they will not try to negotiate. In most cases, DPRK IT Workers will work at a discount to industry standards without complaining (25-50% discount). It may be the case that the worker's CEX account gets frozen, and they will come back to your organization for help unfreezing it (by providing proof of employment). ### After a DPRK IT Worker is hired by your company: 1. **The main goal of a DPRK IT Worker is to keep their job and salary coming for as long as possible.** It's worth understanding that DPRK IT Workers themselves vary in quality. For more 'senior' workers, keeping the job will be easy as their output and technical skills are high. For 'junior' ones, the engagement may end on the basis of poor performance. 1. We have observed cases where DPRK IT Workers are fine with taking a salary cut to help a project stay afloat, as long as they continue to be paid. 2. **The highest risk to your organization, which occurs immediately after you on-board the DPRK IT Worker, is a data and secrets leak.** DPRK IT Workers do not care about your organization's and their operational security. When you assign access to a single DPRK IT Worker, you can be sure more individuals are using the same access. Unbeknownst to you, everything that's private to this single worker is now accessible over a (usually) poorly secured internal DPRK IT Worker network. 3. **We have observed DPRK IT Workers passing access or sensitive information to DPRK Hacking teams.** This is not often the case, as the goal of the DPRK IT Worker is to keep their job and salary as opposed to a one-time hack. However, if the target is high-value, they won't hesitate or may not even have a say in whether or not their employer is targeted for a hack. 4. Some DPRK IT Workers also perform tasks adjacent to malicious campaigns like the "Contagious Interview." Read: [North Korean Threat Actors lure tech job seekers as fake recruiters](https://unit42.paloaltonetworks.com/north-korean-threat-actors-lure-tech-job-seekers-as-fake-recruiters/) and [Two Campaigns by North Korea Bad Actors target job hunters](https://unit42.paloaltonetworks.com/two-campaigns-by-north-korea-bad-actors-target-job-hunters/). Your North Korean employee **may leverage the credibility granted by being employed at your company to conduct malware-related campaigns in the present and future.** This could significantly affect your brand. 5. **A DPRK IT Worker will try to escalate their access if possible**, whether by adding new members (who will also be getting paid) or by getting permissions to release builds and packages. Additionally, **we have encountered situations where DPRK IT Workers were added as signers to the multisig wallets** of the entire project as part of the dev team! 6. **DPRK IT Workers won't report code vulnerabilities to you** and may leave them for future exploitation. First, they generally do not care about and are not invested in the success of your project to protect it from being hacked. Second, they may intentionally leave the backdoor with the intent to use it in the future. Lastly, they may simply miss the vulnerability because they are overworked across numerous remote gigs they're performing at once. In the next section [**Mitigating DPRK IT Workers**](/dprk-it-workers/mitigating-dprk-it-workers) we will be discussing ways to harden your organization and employees against the DPRK IT Worker threat. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Code Signing > 🔑 **Key Takeaway**: Sign every commit and tag with GPG (or SSH/SMIME), > enforce signature verification in CI and branch protection, rotate keys > regularly, and bind developer identity to hardware-backed MFA so that > every change in the repository is traceable to a verified human. Code signing guarantees **integrity** (the code has not been tampered with) and **authenticity** (the change came from the claimed author). Without signing, an attacker who obtains push access can inject malicious code that is indistinguishable from legitimate commits. In Web3 projects, where a single unverified commit could introduce a backdoor into smart contract deployment tooling or steal signing keys, the stakes are especially high. ### Practical guidance #### 1. Require signed commits on protected branches Enable GitHub's **Require signed commits** branch protection rule on `main`, `develop`, and any release branches. This rejects any push that does not carry a verifiable GPG, SSH, or S/MIME signature. * In GitHub: Settings > Branches > Branch protection rules > Require signed commits. * Verify in CI: add `git log --verify-signatures` or `git merge --verify-signatures` as a pipeline check so that unsigned merge commits also fail. #### 2. Require signed pull requests Every PR must be reviewed by another core team member before merging. Configure GitHub to require at least one approving review and enforce that the PR author's commits are signed. * Branch protection: require "Signed commits" and "Pull request reviews" (at least 1 approving review, dismiss stale reviews on push). * Consider requiring reviews from specific teams (CODEOWNERS file) for sensitive paths such as deployment scripts, contract artifacts, or CI workflow files. #### 3. Enforce MFA for all repository members Require Multi-Factor Authentication for every contributor with push access. * Organization-level: enable "Require two-factor authentication for members" in the GitHub organization settings. * Encourage hardware MFA (Yubikey, Titan) over SMS or TOTP. Hardware keys resist phishing via FIDO2/WebAuthn. * For Yubikey GPG signing: generate the GPG subkey directly on the Yubikey's OpenPGP applet so the private key never leaves the device. #### 4. Generate and manage GPG keys properly Good key management is the foundation of code signing. A poorly managed key undermines the entire trust chain. ##### Generating a strong GPG key Use RSA 4096 or Ed25519 (the latter is modern, fast, and secure): ```bash # Ed25519 (recommended for modern setups) gpg --full-generate-key # Choose Ed25519 when prompted, or: gpg --quick-gen-key your@email.com ed25519 sign,auth cert never # RSA 4096 (legacy compatibility) gpg --full-generate-key # Choose RSA 4096 ``` ##### Using subkeys for separation of duties Create separate subkeys for signing and encryption. This lets you keep the master key completely offline while using subkeys daily: ```bash # Add a signing subkey gpg --edit-key YOUR_KEYID gpg> addkey # Choose: RSA 4096, Sign only, expiry 1-2 years # Add an encryption subkey (separate from any encryption subkey you already have) gpg> addkey # Choose: RSA 4096, Encrypt only, expiry 1-2 years gpg> save ``` Your master key stays on an encrypted USB or paper backup. The subkeys go on your regular machine. If a subkey is compromised, you revoke only the subkey — the identity stays intact. ##### YubiKey: move subkeys to hardware Generate GPG keys directly on the YubiKey so the private key material never touches the host system: ```bash # Initialize the YubiKey OpenPGP applet gpg --card-edit gpg> admin gpg> generate # Choose a touch policy (require touch for signing operations) # Or move existing subkeys to the YubiKey: gpg --edit-key YOUR_KEYID gpg> key 1 # Select the signing subkey gpg> keytocard # Move it to YubiKey gpg> key # Deselect gpg> key 2 # Select the encryption subkey gpg> keytocard gpg> save ``` The YubiKey now holds your private keys. The host machine can use them only when the YubiKey is physically present and unlocked. ##### Passphrase management Protect GPG keys with a strong passphrase (20+ characters, random). Use `gpg-agent` caching to avoid re-entering it constantly: ```bash # In ~/.gnupg/gpg-agent.conf: pinentry-program /usr/bin/pinentry-tty default-cache-ttl 86400 # Cache for 24 hours max-cache-ttl 604800 # Expire after 1 week ``` #### 5. Rotate GPG keys regularly Key rotation limits the damage window if a key is compromised. * Define a rotation schedule: every 12 months for standard keys, every 6 months for high-privilege accounts (release managers, deployers). * When rotating: create a new key pair, publish the new public key to GitHub and your keyserver, add a signing subkey, update keyserver records, then revoke the old key with a reason of "superseded." * Maintain a key rotation log: key ID, creation date, expiry date, revocation date, reason. * Protect GPG private keys with a strong passphrase and store the revocation certificate in a secure, offline location (encrypted USB, password manager). #### 5b. Backup and recover keys safely Without proper backup, a lost key means lost identity. Without secure storage, a stolen key means forged commits. **Backup the master key:** ```bash # Export to an encrypted file gpg --export-secret-keys --armor YOUR_KEYID | \ gpg --symmetric --cipher-algo AES256 \ --output master-key-backup.gpg # Store on: encrypted USB (LUKS), paper (print the ASCII armor and seal in a safe), # or a password manager as an encrypted attachment ``` **Generate and store revocation certificates immediately:** ```bash gpg --gen-revoke YOUR_KEYID > revocation-certificate.asc # Store this certificate alongside the backup. If you lose access to the key, # publishing the revocation certificate invalidates the compromised key. ``` **Recovery test:** Periodically verify you can decrypt using your backup without the original key. Store the backup passphrase separately from the backup medium. #### 6. Publish and verify public keys A signature is meaningless if the verifying party cannot obtain the correct public key. * Upload your public key to GitHub (Settings > SSH and GPG keys) and to a public keyserver (keys.openpgp.org, keyserver.ubuntu.com). * Use the same key across all platforms so that the identity is consistent. * In CI, pin trusted public key fingerprints in the pipeline configuration. Reject signatures from unknown keys. #### 6b. Document code signing procedures Maintain clear, accessible documentation so that every team member can set up and maintain signing correctly. * Onboarding guide: how to generate a GPG key, configure git to sign commits, upload to GitHub, and set up a Yubikey for signing. * Troubleshooting: common issues (expired keys, wrong key selected, gpg-agent not running) with solutions. * Policy: rotation schedule, revocation procedures, acceptable signing methods (GPG, SSH, S/MIME), and enforcement mechanism. ### Why is it important Unsigned commits allow impersonation. If an attacker obtains credentials or an active session, they can push commits that appear to come from any author. Without signature verification, there is no cryptographic proof of authorship. Real-world implications: * The Linux kernel community experienced a breach where an attacker attempted to inject a backdoor via a seemingly legitimate commit. Signed commits and review processes are a primary defense against this class of attack. * NIST SP 800-53 Rev. 5 control **AU-10 (Non-Repudiation)** requires that the identity of individuals who perform specific actions be determined and verified. * CISA's Secure Software Development Self-Attestation form requires attestors to confirm that they verify the integrity of software releases, which includes code signing. ### Implementation details | Sub-topic | Related page | | ------------------------------------- | ----------------------------------------------------------------------------------- | | Branch protection & signed commits | [Repository Hardening](/devsecops/repository-hardening) | | CI pipeline enforcement of signatures | [Securing CI/CD Pipelines](/devsecops/continuous-integration-continuous-deployment) | | Artifact signing and provenance | [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation) | ### Common pitfalls * **Lost or expired GPG key**: If you lose your private key or it expires and you cannot revoke it, GitHub cannot verify your past or future commits. Always set an expiry date, generate a revocation certificate immediately, and store it securely offline. * **gpg-agent caching causes signing with the wrong key**: When you have multiple keys, git may sign with the wrong one. Explicitly set `user.signingkey` per repository: `git config user.signingkey `. * **Signing tags but not commits**: Annotated tags are signed, but if the commits they point to are unsigned, an attacker could rebase onto unsigned history. Sign both commits and tags. * **Using SSH signing without understanding trust model**: GitHub supports SSH signing keys, but verification depends on the SSH `allowed_signers` file. If this file is not maintained, signatures verify against any key in the file. Keep `allowed_signers` pinned to current team members. * **CI merges bypassing signature checks**: Some CI workflows auto-merge PRs (e.g., Dependabot). Ensure that bot accounts also sign commits or that the merge commit itself is verified by the CI system. ### Quick-reference cheat sheet | Action | Command | | ------------------------ | ------------------------------------------------------------ | | Generate GPG key | `gpg --full-generate-key` (choose RSA 4096 or ed25519) | | List secret keys | `gpg --list-secret-keys --keyid-format long` | | Set git signing key | `git config user.signingkey ` | | Sign a commit | `git commit -S -m "message"` | | Sign a tag | `git tag -s v1.0.0 -m "release 1.0.0"` | | Verify a commit | `git log --verify-signatures -1` | | Verify a tag | `git tag -v v1.0.0` | | Export public key | `gpg --armor --export > pubkey.asc` | | Generate revocation cert | `gpg --gen-revoke > revoke.asc` | | Upload to keyserver | `gpg --keyserver keys.openpgp.org --send-keys ` | ### References * [GitHub Docs: Managing commit signature verification](https://docs.github.com/en/authentication/managing-commit-signature-verification) * [GitHub Docs: About signature verification for commits](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) * [NIST SP 800-53 Rev. 5, AU-10 Non-Repudiation](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) * [Yubico PGP guide: Generate GPG keys on YubiKey](https://developers.yubico.com/PGP/Card_edit.html) * [GnuPG documentation](https://gnupg.org/documentation/) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Continuous Integration and Continuous Deployment (CI/CD) > 🔑 **Key Takeaway**: Treat CI/CD as a production system: every pipeline > must run tests, scans, and signature checks before allowing a merge; secrets > must never reach untrusted jobs; and build environments must be ephemeral and > deterministic so that no single compromise can tamper with what ships. CI/CD pipelines are the backbone of modern software delivery, but they are also high-value targets. An attacker who controls a pipeline can inject backdoors into every artifact it produces, steal secrets, or deploy malicious code to production. In Web3, where CI often has access to deployment keys and signing wallets, a compromised pipeline can directly lead to on-chain exploits. ### Practical guidance #### 1. Require CI checks before merging Every PR must pass CI before it can be merged. At minimum, the pipeline should include: * **Unit tests** — fast, isolated tests covering core logic. * **Integration tests** — end-to-end flows (e.g., deploy to testnet, verify contract state, run fork tests). * **Dependency vulnerability scan** — detect known CVEs in packages using Dependabot, Snyk, or npm audit. * **Static analysis** — lint code and detect common bugs (Slither for Solidity, Ruff/Pylint for Python, ESLint for JS/TS). * **Secret detection** — scan for accidentally committed keys and tokens (git-secrets, TruffleHog, GitHub secret scanning). Configure branch protection to require all status checks to pass before merging. #### 2. Scan for misconfigurations and leaked credentials Pipelines themselves can introduce vulnerabilities if misconfigured. * Use tools like **tfsec** (Terraform), **Checkov**, or **Falco** to detect IaC misconfigurations. * Enable **GitHub secret scanning** and **push protection** at the organization level to prevent credentials from entering the repository. * Run **zizmor** or **actionlint** to lint GitHub Actions workflows for common security anti-patterns (e.g., `pull_request_target` with untrusted checkout, unchecked `GITHUB_TOKEN` permissions). #### 3. Produce deterministic, reproducible builds A build that varies between runs makes it impossible to verify that the deployed artifact matches the reviewed source code. * Pin all dependency versions: use lockfiles (`package-lock.json`, `poetry.lock`, `Pipfile.lock`) and pin Docker base images by digest (`image@sha256:...`), not by tag. * Use a fixed build container or Nix derivation so that the same source always produces the same output. * For Web3: produce deterministic bytecode by pinning the compiler version (`solc`), optimizer settings, and build environment. Use `--standard-json` input and verify the resulting bytecode matches across independent builds. * Adopt SLSA (Supply-chain Levels for Software Artifacts) levels to track build provenance: generate and sign provenance attestations, verify them before deployment. #### 4. Integrate security scanning into CI Security scanning must be automated and run on every PR, not just periodically. | Scan type | Tools | When to run | | ----------------------- | ----------------------------------------------- | ---------------------------- | | SAST (static analysis) | Slither, Semgrep, CodeQL, Aderyn | Every PR | | SCA (dependency scan) | Dependabot, Snyk, npm audit | Every PR + daily cron | | Secret scanning | TruffleHog, git-secrets, GitHub push protection | Pre-commit + every PR | | DAST (dynamic analysis) | OWASP ZAP, Nikto | Nightly + pre-release | | IaC scanning | tfsec, Checkov, KICS | Every PR touching infra code | | Container scanning | Trivy, Grype, Snyk Container | Every image build | * Fail the pipeline on Critical and High severity findings. * Track Medium/Low findings as issues for triage. * Configure tools to suppress false positives carefully and document the reason. #### 5. Isolate build and test environments Pipeline stages must not share state, secrets, or filesystem access. * Use **ephemeral runners**: a fresh environment per job, no persistent state. GitHub-hosted runners are ephemeral by default; self-hosted runners must be re-provisioned per job. * Separate **untrusted PR runners** from **trusted build/deploy runners**. Fork PRs should never have access to deployment secrets. * Deny outbound network by default for build jobs; allow only required hosts (package registries, API endpoints) via allowlist. * Use **rootless containers** and **seccomp profiles** for build jobs. Never run CI with `--privileged` or `sudo`. * See [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation) for deeper containment patterns. #### 6. Restrict access to pipeline configurations Who can modify CI workflows determines who can alter what runs in the pipeline. * Limit write access to `.github/workflows/` and equivalent CI config directories to a small, trusted group. * Require PR reviews for any change to CI workflow files. Use CODEOWNERS to enforce this: `/.github/workflows/ @security-team @devops-lead`. * Pin third-party GitHub Actions by commit SHA, not by tag. Tags are mutable: `v1` can be retagged to point to malicious code. ```yaml # Unsafe: tag can be changed - uses: actions/checkout@v4 # Safe: pinned by SHA - uses: actions/checkout@b4ffde65f46336ab88eb53be80866792576f8620 ``` * Restrict `GITHUB_TOKEN` permissions to least privilege: set `permissions: {}` at the workflow level and grant only what each job needs. #### 7. Manage secrets securely CI secrets (API keys, deployment keys, signing keys) are the highest-value targets in any pipeline. * Store secrets in a dedicated vault (GitHub Secrets, HashiCorp Vault, AWS Secrets Manager), not in environment files or code. * Never pass secrets to untrusted jobs. In GitHub Actions, fork PRs cannot access repository secrets by default; do not override this with `pull_request_target` unless you fully understand the risk. * Rotate secrets regularly and after any suspected exposure. * Use OIDC federation where possible (GitHub Actions to AWS/GCP/Azure) to eliminate long-lived credentials entirely. * Audit secret access: enable GitHub secret access logs and alert on unexpected reads. #### 8. Sign and verify artifacts Every artifact produced by CI must be signed and verifiable. * Sign Docker images with Cosign or Notary. * Sign smart contract deployment artifacts and verify their hash matches audit-reviewed source. * Generate SLSA provenance attestations during the build. * Verify signatures and provenance in the deployment stage before releasing. #### 8b. Enforce SLSA provenance SLSA (Supply-chain Levels for Software Artifacts) provides a graded framework for build integrity. GitHub Actions can generate provenance using the `slsa-framework/slsa-github-generator` action: ```yaml # In your release workflow - name: Generate SLSA provenance uses: slsa-framework/slsa-github-generator@v2.0.0 with: image-tag: ${{ github.sha }} attestation-name: attestation.intoto.jsonl # Requires OIDC identity federation setup ``` Provenance attestation links the artifact to the exact source commit, builder identity, and build process. Verify provenance before deployment: ```bash # Verify with Cosign (if using Cosign for image signing) cosign verify-attestation \ --certificate-identity=https://github.com//.github/workflows/@refs/tags/ \ --certificate-oidc-issuer=https://token.actions.githubusercontent.com \ \ --type=slsaprovenance \ < /dev/stdin < attestation.intoto.jsonl ``` Adopt SLSA levels progressively: | Level | Requirement | Realistic target | | ----- | -------------------------------------------------------- | ---------------------------- | | L1 | Build process documented, provenance generated | Most teams start here | | L2 | Hosted build service, provenance signed | GitHub Actions with OIDC | | L3 | Hardened build service, no human influence on Provenance | High-security deployments | | L4 | Two-party review, hermetic builds | Critical Web3 infrastructure | #### 8c. Generate and verify SBOMs A Software Bill of Materials (SBOM) enumerates all dependencies and their versions, enabling rapid vulnerability response when a CVE is disclosed. ```yaml # Generate SBOM with Syft in CI - name: Generate SBOM uses: anchore/sbom-action@v0 with: image: ${{ env.IMAGE_TAG }} format: spdx-json output-file: sbom.spdx.json # Upload as artifact - name: Upload SBOM uses: actions/upload-artifact@v4 with: name: sbom path: sbom.spdx.json retention-days: 90 ``` When a vulnerability affects a dependency, the SBOM lets you determine exactly which artifacts are affected and whether a rebuild is needed. Store SBOMs alongside artifacts and retain them for the artifact's lifetime. #### 8d. Set up OIDC federation for cloud access Long-lived cloud credentials in CI are a high-value target. OpenID Connect (OIDC) eliminates them entirely by granting short-lived, scoped tokens on demand. **GitHub Actions → AWS:** ```yaml # In your workflow - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789:role/GitHubActionsRole aws-region: us-east-1 # No long-lived secrets needed — GitHub's OIDC token is exchanged # for temporary AWS credentials ``` **AWS side (trust policy for the IAM role):** ```json { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::123456789:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:sub": "repo:/:ref:refs/heads/main" }, "StringLike": { "token.actions.githubusercontent.com:aud": "https://github.com" } } }] } ``` The role grants access only for pushes to `main`, only for your specific repo, and the token expires within minutes. If the CI system is breached, the attacker gets a short-lived token — not a permanent credential. ### Why is it important CI/CD compromises have led to real-world breaches: * **SolarWinds (2020)**: Attackers compromised the build system and injected a backdoor into Orion software updates, affecting 18,000+ organizations. This demonstrated that a build-system compromise can bypass all downstream code review. * **Codecov (2021)**: Attackers modified a CI script to exfiltrate secrets and environment variables, affecting thousands of customers. * **3Commas (2022)**: Leaked API keys from a compromised CI environment were used to drain user funds from trading bots. NIST SP 800-218 (Secure Software Development Framework) and the SLSA framework both define requirements for build integrity and provenance that directly apply to CI/CD pipeline security. ### Implementation details | Sub-topic | Related page | | ------------------------------- | ----------------------------------------------------------------------------------- | | Isolation for untrusted CI jobs | [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation) | | Network and resource controls | [Network & Resource Isolation](/devsecops/isolation/network-and-resource-isolation) | | Code signing and verification | [Implementing Code Signing](/devsecops/code-signing) | | Repository branch protection | [Repository Hardening](/devsecops/repository-hardening) | | Security testing tools | [Security Testing](/devsecops/security-testing) | ### Common pitfalls * **Using `pull_request_target` with untrusted checkout**: This event gives fork PRs access to repository secrets. If the workflow checks out the PR code with those secrets available, an attacker can exfiltrate them. Use `pull_request` for untrusted code, or use `pull_request_target` only with a trusted checkout (e.g., the base branch). * **Pinning actions by tag instead of SHA**: Tags are mutable. `v2` can be retagged at any time. Always pin by commit SHA and verify with a tool like `zizmor` or `frizbee`. * **Over-permissioned `GITHUB_TOKEN`**: The default token has write access to the repository. Restrict it: set `permissions: read-all` or `permissions: {}` at the workflow level, then add only the permissions each job needs. * **Self-hosted runners without cleanup**: Self-hosted runners persist state between jobs. Secrets, environment variables, and build artifacts from one job may be readable by the next. Use ephemeral runners or implement strict cleanup scripts. * **Skipping CI for "small changes"**: Any bypass of CI checks creates a gap. Even documentation changes can introduce malicious JavaScript in MDX files. Require CI for all branches. ### Quick-reference cheat sheet | Check | How | | -------------------------- | ------------------------------------------------------- | | Require CI on all branches | Branch protection > Require status checks | | Pin actions by SHA | `uses: action@` | | Restrict GITHUB\_TOKEN | `permissions: {}` + per-job grants | | Isolate fork PR secrets | Use `pull_request`, not `pull_request_target` | | Scan for secrets | Enable GitHub push protection + TruffleHog in CI | | Deterministic builds | Pin deps by hash, pin solc version, lock Docker digests | | Sign artifacts | Cosign for containers, GPG for tags, SLSA provenance | | Audit workflow changes | CODEOWNERS on `.github/workflows/` | ### References * [SLSA Specification v1.0](https://slsa.dev/spec/v1.0/) * [NIST SP 800-218, Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final) * [GitHub Docs: Security hardening for GitHub Actions](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions) * [CISA: Software Bill of Materials](https://www.cisa.gov/sbom) * [OWASP CI/CD Security Guide](https://owasp.org/www-project-devsecops-guideline/latest/03-CI-CD/) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Data Security Checklist ### 1. Data Backup & Disaster Recovery Protecting critical data through automated, encrypted backups and tested recovery procedures is essential for business continuity in Web3 operations. * [ ] **Automated backups for critical databases, configurations, and off-chain state** * Configure automated backup schedules for all mission-critical systems, including databases (PostgreSQL, MongoDB, etc.), application configurations, environment variables, and off-chain state data (indexer databases, cache layers, API states). In Web3 contexts, this includes subgraph databases, oracle data feeds, and transaction indexer states. Use tools like AWS Backup, Google Cloud Backup, or open-source solutions like Restic or BorgBackup. Schedule daily incremental backups and weekly full backups at a minimum. * [ ] **Encrypted backups at rest and in transit** * All backup data must be encrypted both when stored (at rest) and during transmission (in transit). Use AES-256 encryption for stored backups and TLS 1.3 for transmission. This prevents unauthorized access even if backup storage is compromised. Cloud providers like AWS S3 offer server-side encryption (SSE-S3, SSE-KMS), while self-hosted solutions should use encrypted volumes (LUKS, dm-crypt) or application-level encryption. * [ ] **Geographically separate storage locations** * Store backup copies in multiple geographic regions to protect against regional disasters, data center failures, or jurisdictional issues. For example, maintain primary backups in US-East and secondary copies in EU-West. This is critical for Web3 projects operating globally. Use different cloud providers or regions (AWS + Google Cloud, or AWS us-east-1 + aws eu-west-1) to avoid single points of failure. * [ ] **Retention and versioning policies** * Implement clear retention schedules that balance compliance requirements, operational needs, and storage costs. A typical policy: keep daily backups for 30 days, weekly backups for 3 months, monthly backups for 1 year. Enable versioning to protect against ransomware or accidental deletion. For blockchain projects, consider longer retention for deployment artifacts, contract ABIs, and transaction history that may be needed for audits or investigations. * [ ] **Regular restoration testing (quarterly minimum)** * Backups are only valuable if they can be restored. Conduct full restoration tests at least quarterly to verify backup integrity and team familiarity with recovery procedures. Document restoration time objectives (RTO) and recovery point objectives (RPO). Practice restoring to a test environment, validate data integrity, and measure how long recovery takes. This identifies backup corruption, configuration drift, or gaps in documentation before a real disaster occurs. * [ ] **Role-Based Access Control (RBAC) for backup access** * Limit backup access to only those who need it using RBAC principles. Separate read-only access (for restoration testing) from write/delete permissions (for backup management). In cloud environments, use IAM policies to restrict S3 bucket access, database backup permissions, and KMS key usage. Require multi-factor authentication for any backup modification or deletion operations. Log all backup access for audit trails. * [ ] **Auditable backup logs and monitoring** * Enable comprehensive logging for all backup operations: creation, access, restoration, deletion, and failures. Send logs to a centralized SIEM (Security Information and Event Management) system or logging platform like Splunk, DataDog, or ELK stack. Set up alerts for backup failures, unauthorized access attempts, or unusual deletion activities. For compliance, retain backup logs for at least 1 year and ensure they are tamper-resistant using immutable or write-once logging/storage controls where appropriate. ### 2. Secure Storage & Encryption Proper classification and encryption of sensitive data protects user privacy, prevents credential theft, and ensures regulatory compliance. * [ ] **Sensitive data classification (PII, credentials, secrets, API keys)** * Conduct a data inventory and classify all data by sensitivity: Public (marketing materials), Internal (business data), Confidential (user PII, financial records), and Restricted (credentials, private keys, secrets). In Web3 projects, Restricted data includes wallet private keys, API keys for infrastructure providers (Infura, Alchemy), database credentials, session tokens, and OAuth secrets. Document what data you store, where it's stored, who has access, and its classification level. This drives encryption decisions and access controls. * [ ] **Encryption at rest using AES-256 or equivalent** * Encrypt all sensitive data at rest using industry-standard AES-256 encryption. For databases, enable Transparent Data Encryption (TDE) in PostgreSQL, MySQL, or MongoDB. For file storage, use encrypted volumes (AWS EBS encryption, Google Cloud persistent disk encryption) or application-level encryption. Web3 projects must encrypt wallet keystores, seed phrases (if temporarily stored during key ceremonies), and smart contract deployment private keys. Never store sensitive data in plaintext. * [ ] **Key Management Systems (KMS) or Hardware Security Modules (HSM)** * Use dedicated KMS or HSM solutions to generate, store, and manage encryption keys securely. Cloud providers offer managed KMS (AWS KMS, Google Cloud KMS, Azure Key Vault) that provide FIPS 140-2 Level 2/3 validation. For higher security requirements or regulatory compliance, use HSMs (FIPS 140-2 Level 3/4). In Web3, KMS is critical for securing deployment keys, multisig signer keys, and oracle operator keys. Never hardcode encryption keys in code or configuration files. * [ ] **Regular key rotation schedules** * Rotate encryption keys on a regular schedule to limit the impact of potential key compromise. Define key rotation schedules based on asset criticality, exposure, provider capabilities, and operational risk. Implement automated key rotation where possible (AWS KMS supports automatic rotation). For Web3 projects, rotate API keys for infrastructure providers every 90 days, database credentials every 180 days, and deployment keys after major releases. Document rotation procedures and maintain key version history. * [ ] **Enforce TLS 1.2+ for all communications** * Mandate TLS 1.2 or higher (preferably TLS 1.3) for all network communications. Disable older protocols (SSL, TLS 1.0/1.1) that have known vulnerabilities. Configure web servers (Nginx, Apache), load balancers, and APIs to require strong cipher suites (AES-GCM, ChaCha20-Poly1305). In Web3, this applies to RPC endpoints, API servers, admin dashboards, and indexer queries. Use tools like SSL Labs to verify TLS configuration quality and scan for weaknesses. * [ ] **No hardcoded secrets in code or configuration files** * Never commit secrets, API keys, private keys, passwords, or credentials to version control systems. Use environment variables, secret management systems (HashiCorp Vault, AWS Secrets Manager, Doppler), or encrypted configuration files. Scan repositories with tools like git-secrets, TruffleHog, or GitHub's secret scanning to detect accidentally committed credentials. For Web3 projects, use hardware wallets or MPC systems for deployment keys rather than filesystem-stored private keys. Implement pre-commit hooks to prevent secret commits. ### 3. Third-Party Integrations Web3 projects rely heavily on external services—from RPC providers to cloud infrastructure. Properly vetting and securing these integrations prevents supply chain attacks and data breaches. * [ ] **Maintain comprehensive inventory of all services and integrations** * Document every third-party service your project uses: infrastructure (AWS, Google Cloud, Vercel), blockchain services (Infura, Alchemy, QuickNode), analytics (Mixpanel, Amplitude), monitoring (DataDog, Sentry), communication (Slack, Discord bots), and development tools (GitHub, CircleCI). Include: service name, purpose, data access level, authentication method, contract/pricing tier, and responsible team member. Update this inventory monthly and review quarterly. This visibility is essential for incident response and security assessments. * [ ] **Security posture review and compliance verification (SOC 2, ISO 27001)** * Before integrating a service, verify its security credentials. Require at minimum SOC 2 Type II attestation for critical services handling sensitive data. For highly regulated environments, require ISO 27001, PCI DSS, or HIPAA compliance as applicable. Review audit reports, penetration test summaries, and security whitepapers. For blockchain infrastructure providers, verify their node security practices, key management procedures, and incident response capabilities. Re-evaluate annually or after major security incidents. * [ ] **Principle of least privilege access** * Grant third-party integrations only the minimum permissions required for their function. For cloud services, use IAM roles with scoped permissions rather than root/admin access. For APIs, use role-based access with limited scopes (read-only where possible). Example: a monitoring service needs read-only metrics access, not write access to databases. For blockchain services, separate RPC endpoints for read operations (public) from write operations (deployment, requiring authentication). Regularly audit and reduce over-privileged integrations. * [ ] **Regular credential rotation for third-party services** * Rotate API keys, OAuth tokens, and access credentials for all third-party integrations on a regular schedule. Critical services (infrastructure, payment, and auth providers) should rotate quarterly. Lower-risk services can rotate annually. Use secret management tools to automate rotation where possible. When team members leave or change roles, immediately rotate any credentials they had access to. For Web3 projects, rotate RPC provider API keys, infrastructure provider access keys, and deployment system credentials regularly. * [ ] **Dependency vulnerability monitoring and patching** * Continuously monitor all third-party dependencies (npm packages, Python libraries, Docker images) for known vulnerabilities. Use automated tools like Dependabot, Snyk, or npm audit in CI/CD pipelines. For Web3 projects, pay special attention to Web3 libraries (ethers.js, web3.js, viem), cryptographic libraries, and smart contract dependencies (OpenZeppelin Contracts). Establish patching SLAs based on exploitability, exposure, asset criticality, and compensating controls. Test patches in staging before production deployment. * [ ] **Data protection clauses in vendor agreements** * Ensure all vendor contracts include strong data protection language. Key clauses: data ownership (you own your data), breach notification (vendor must notify within 24-48 hours), data deletion (vendor must delete data upon contract termination), subprocessor restrictions (vendor must disclose and get approval for subcontractors), audit rights (you can audit vendor's security practices), and liability for breaches. For GDPR/CCPA compliance, require Data Processing Agreements (DPAs). Review contracts annually and before renewals. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, GovernanceSDLCPipeline, ChecklistItem, } from '../../../components' ## Governance Proposal Security Across the SDLC > 🔑 **Key Takeaway**: A governance proposal controls the entire protocol. > Treat it as a software artifact with its own SDLC — plan with explicit > authority, build with invariants that run against live state, review the > full payload (not just the .sol diff), and make the onchain calldata > reproducible so signers and voters can independently verify what they > are approving. Smart contract upgrade proposals concentrate more risk in a single transaction than almost any other operation a protocol performs: they can rewrite logic, move treasury funds, change admin keys, and alter every user position. A mistake, a hostile developer machine, a compromised CI runner, or a signer who blind-signs the payload can each cause the same outcome — a proposal that differs from what was reviewed, executed with full authority. This page maps adversaries onto a four-stage lifecycle and gives a checklist per stage. Two areas get extra attention because they consistently fail in practice and rarely appear in upgrade checklists: **invariant suites that run against live mainnet state** (Stage 2) and **reproducible onchain calldata verified by CI** (Stage 4). ### How to read this page The graphic is the navigation: each stage node is a phase in the proposal lifecycle, and each coloured dot above a stage is one threat that lands there. Dot colours follow the same category palette used on the [Attack Surface Overview](/intro/attack-surface) so the picture is consistent across pages. Click a stage to open its detail panel, click a dot to jump to the specific threat, and use the "Jump to section" link to scroll down to the matching checklist below. Stage 4 is intentionally the densest. Once a proposal is posted onchain the calldata is immutable, which is exactly why supply-chain integrity, signer verification, and post-execution monitoring all have to converge there. ### Stage 1: Plan **Purpose.** Decide what is changing and who is authorized to change it before a single line of code is written. Governance failures at this stage lock in risk that no later audit can fully remove. #### Threats at this stage * **Undefined upgrade authority** — no explicit owner for `upgradeTo()` / ProxyAdmin, unclear multisig role, or a single EOA holding upgrade rights. * **Rogue or compromised proposer** — an insider submits a proposal that looks routine but embeds a parameter change or delegatecall target that hands over control. * **Missing emergency pause / rollback** — no pause switch, no forward-fix plan, no tested rollback, so when execution goes wrong there is no safe stop. * **Unmapped downstream effects** — developers haven't thought through and enumerated every downstream flow-on effect of the proposal in the system being modified, so second-order consequences only surface after execution. The more complex the system, the more this matters. #### Defenses * Documented upgrade architecture (proxy pattern, admin, timelock). * Explicit roles: proposer, reviewer, approver, executor. * Formal change-management process with a written proposal spec. * Tested emergency pause and rollback / forward-fix plan. #### Checklist Document your upgrade mechanism thoroughly: proxy pattern type (UUPS, Transparent Proxy, Diamond/EIP-2535, Beacon Proxy), upgrade authorization model (multisig, timelock, governance), admin key custody, and emergency pause capabilities. Include diagrams showing contract interaction flows before and after upgrades. For UUPS (Universal Upgradeable Proxy Standard), document the `upgradeTo()` function and authorization checks. For Transparent Proxies, document ProxyAdmin ownership. For Diamond patterns, document facet management. Use tools like Slither's `upgradeability` printer to analyze patterns. Define who can propose, review, approve, and execute upgrades. Typical roles: Developer (writes upgrade code), Auditor (security review), Multisig Signers (approval), DevOps (deployment execution), Community (governance vote if applicable). Document each role's responsibilities, required skills, and contact information. For DAO-governed protocols, specify governance proposal requirements, voting thresholds, and timelock durations. Include on-call rotations for emergency upgrades. This prevents confusion during time-critical situations. Establish a structured process for all upgrades: 1) Proposal submission with technical specification and rationale, 2) Security review by internal team, 3) External audit if material changes, 4) Testnet deployment and validation, 5) Governance approval (if applicable), 6) Mainnet deployment during maintenance window, 7) Post-deployment verification, 8) Public disclosure. Use issue tracking (GitHub, Linear) to manage upgrade proposals. Require approval from the security team, the technical lead, and the product owner before proceeding. Document decision rationale for audit trails. Implement circuit breakers that allow rapid response to exploits: `pause()` functions (using OpenZeppelin's Pausable pattern) to halt operations, and clear rollback procedures. Document trigger conditions for emergency pause (e.g., suspicious transactions, exploit detection, oracle manipulation). Define who can activate pause (multisig threshold, emergency admin), how quickly they can act (timelock delays), and rollback options (proxy reversion, emergency upgrade to safe version). Test pause mechanisms on testnet and mainnet clones. Include contact trees for rapid multisig coordination during incidents. Rollback to a previous implementation is not always safe or possible, especially after storage migrations, one-way state changes, or downstream integrations have already reacted. In many cases, the safer path is to pause, contain impact, and deploy a forward fix or a controlled migration. ### Stage 2: Build and Test **Purpose.** Write the implementation, protect its state, and prove with tests — against live mainnet state — that the proposal does what the spec says and nothing more. #### Threats at this stage * **Storage layout collision** — reordered, retyped, or mid-inserted state variables corrupt user balances and admin slots after the proxy points at the new implementation. * **Re-initialization attack** — unprotected `initialize()` on the new implementation lets an attacker reset owner, role admin, or critical parameters after the upgrade lands. * **No proposal-level invariant suite** — without invariants asserting user positions are preserved, a proposal that silently widens an access-control ring or zeroes a reserve can pass unit tests. * **Tests do not fork live state** — tests run against a clean deployment instead of real mainnet state, so interactions with existing user positions, oracles, and integrators are untested. * **Tests don't run against the deployment script** — integration and invariant tests exercise a hand-wired test setup rather than the actual deploy script, so the system state under test is not the system state that ships. A passing suite gives false confidence and has caused real upgrade incidents. * **Fork-test of the unmodified protocol** — forking mainnet at HEAD and running tests without first executing the proposal's calldata tests the status quo, not the post-proposal world. A proposal that breaks an invariant slips through because the fork never saw the change. #### Defenses * Storage layout compatibility checks (OpenZeppelin upgrades, Slither). * Initializer protection and `_disableInitializers()` on implementations. * Least-privilege access control on upgrade functions. * Invariant suite asserting no user position is materially harmed. * Fork mainnet at the HEAD block, execute the proposal's calldata on that fork, then run the integration and invariant suite against the post-execution state — never the unmodified protocol. * Integration and invariant tests execute the actual deployment script, so the system under test is bit-identical to what will ship. #### Checklist Secure upgrade functions with multi-layer authorization. Use OpenZeppelin's `AccessControl` or `Ownable` patterns with multisig ownership (Safe, Gnosis). Require minimum 3-of-5 or 4-of-7 multisig thresholds for production upgrades. For UUPS, protect `upgradeTo()` with `onlyOwner` or `onlyRole(UPGRADER_ROLE)`. Add timelock delays (24-72 hours) to provide community review windows and enable emergency response. Never use single EOA (Externally Owned Account) admin keys for production contracts. Consider on-chain governance with Compound Governor or OpenZeppelin Governor for decentralized protocols. Storage collisions are a common source of upgrade bugs. When upgrading, you must maintain storage layout compatibility: never change the order of existing state variables, never change types of existing variables, never insert new variables in the middle (only append at the end), and gap slots properly. Use OpenZeppelin's `@openzeppelin/hardhat-upgrades` or `@openzeppelin/truffle-upgrades` plugins that automatically validate storage layout compatibility. Manually review storage with Slither's `upgradeability` checks. Test storage integrity by reading state before and after upgrade on testnet. Upgradeable contracts use `initialize()` functions instead of constructors. Protect these with OpenZeppelin's `initializer` modifier to prevent re-initialization attacks that could reset admin controls or drain funds. For UUPS contracts, ensure implementation contracts are initialized in the constructor (`_disableInitializers()` pattern) to prevent direct implementation usage. Verify that proxy initialization cannot be front-run during deployment. Check that new upgrade logic doesn't introduce new initializers that could be exploited. Deploy all upgrades to public testnets matching your production chain (Ethereum → Sepolia/Holesky, Polygon → Amoy, Arbitrum → Arbitrum Sepolia, Optimism → Optimism Sepolia). Use testnet configurations identical to mainnet (same multisig threshold, same timelock delays, same governance parameters). Execute the complete upgrade flow, including multisig signing, timelock queuing, and execution. This catches deployment script errors, gas estimation issues, and interaction bugs before mainnet deployment. Document testnet deployment addresses and transaction hashes. Before and after upgrade, verify that critical state is preserved correctly. Write scripts to snapshot state before upgrade (token balances, user permissions, protocol parameters, accumulated rewards, LP positions) and verify it matches after upgrade. Use Hardhat's `mainnet-forking` to test upgrades against production state locally. Check that storage variables maintain their values, mappings are intact, and state doesn't unexpectedly reset. For DeFi protocols, verify total value locked (TVL) is unchanged, user balances match, and reward calculations continue correctly. Run full test suite against upgraded contracts: unit tests for new functionality, integration tests for contract interactions, end-to-end tests for user workflows, and backwards compatibility tests. Verify that all existing functionality still works (no regressions). Test edge cases and error conditions. For DeFi: test deposits, withdrawals, swaps, liquidations, governance votes, reward claiming. Use coverage tools (hardhat-coverage, solidity-coverage) to ensure >90% code coverage. Include tests for upgradability-specific risks (storage collisions, initializer vulnerabilities, proxy delegation). Compare gas costs before and after upgrade for common operations. Increases of >10-20% warrant investigation and may indicate inefficient code or unintended state bloat. Use Hardhat's gas reporter or Foundry's `forge snapshot` to track gas metrics over time. For high-throughput protocols, benchmark transaction throughput and latency. Optimize critical paths (token transfers, swaps, mints) to minimize user costs. Consider Layer 2 implications if gas costs become prohibitive. Test disaster scenarios on testnet: what if the upgrade transaction fails mid-execution? What if the new implementation has a critical bug? Practice rolling back to the previous implementation version. For timelock-based systems, practice expedited upgrades through emergency multisig. Test `pause()` functionality and verify it halts operations correctly. Simulate oracle failures, reentrancy attacks, and access control bypasses in the new code. Document lessons learned and update procedures accordingly. #### Invariant suites against the proposal A regression suite tells you that the functions you thought of still work. An **invariant suite** tells you that the properties the protocol promises to users are still true — whether the upgrade was supposed to touch them or not. For an upgrade, this is the single most useful class of test, because a malicious or careless proposal usually does not break a named unit test; it quietly changes a state that the tests never asserted on. **What to encode.** Write invariants that answer the question: "given that any code the proposal touches can now behave differently, can a user end up worse off than before?" Common examples: * Total supply of any debt or share token is unchanged by the upgrade (no hidden mint). * Sum of user collateral ≥ sum of user debt × liquidation threshold for every lending position. * For every open vault, `redeem(balanceOf(user))` returns at least as much as before the upgrade. * Role membership (`hasRole(ADMIN_ROLE, x)`) is unchanged except for a pre-declared, reviewed diff. * Oracle reads used by liquidation logic still fall in the same historical range. **Worked example — lending market.** For a proposal that touches the interest-rate model, the invariant suite should assert: 1. Before applying the proposal: snapshot every borrower's collateral ratio. 2. Apply the proposal calldata on a mainnet fork at the head block. 3. For every borrower, the new collateral ratio is ≥ the previous value minus a tightly bounded rounding delta. 4. No position that was solvent before is insolvent after. If step 3 fails for a single borrower, the proposal is not safe to ship even if every unit test passes. **Fork-test the exact calldata.** Do not test an idealized version of the proposal. Encode the raw calldata that will be posted onchain, execute it on a mainnet fork at the head block, and run the invariant suite after. This is what signers and voters will actually approve. **Publish the suite.** Commit the invariants, the fork test, and the proposal calldata to the repo before the onchain proposal is posted. That lets any signer, voter, or watchdog re-run the same checks from a clean checkout and form an independent opinion — which is the whole point. See also [Fuzz Testing](/security-testing/fuzz-testing), [Formal Verification](/security-testing/formal-verification), and [Integration Testing](/security-testing/integration-testing). ### Stage 3: Review and Audit **Purpose.** Get independent eyes on the full change — not just the .sol diff but the deployment scripts, proposal payload, and operational runbooks that actually reach mainnet. #### Threats at this stage * **Audit scoped to .sol only** — the audit covers the Solidity diff but excludes deploy scripts, multisig transaction builders, and initialization code, where many real upgrade bugs hide. * **Deployment-script bug** — a typo in a constructor argument, a wrong address literal, an incorrect parameter, or an incorrect proxy initializer silently ships a broken or hostile deployment. * **Undocumented risk acceptance** — medium/low audit findings are closed without public rationale, so signers and voters do not know what risks were accepted on their behalf. * **Tests diverge from the deployment script** — integration tests set up the system a different way than the deployment script actually will, so the behavior that was tested is not the behavior that ships. A passing suite gives false confidence and has caused real upgrade incidents. #### Defenses * Audit scope includes contracts, deploy scripts, and proposal payloads. * Line-by-line review of upgrade and migration scripts. * Internal code review of the governance proposal by a reviewer who is not the author. * All findings resolved or explicitly, publicly accepted with rationale. * Integration tests execute the actual deployment script, so the system state under test is bit-identical to what will ship. #### Checklist For material upgrades (new features, changes to value transfer logic, access control modifications), obtain independent security audits from reputable firms (Trail of Bits, OpenZeppelin, ConsenSys Diligence, Certora, Spearbit). Share the complete codebase, including proxy contracts, implementation contracts, deployment scripts, and test suites. Provide a clear upgrade specification and threat model. Budget 2-4 weeks for audit, depending on complexity. Address all findings (Critical/High immediately, Medium/Low with documented risk acceptance). Publish audit reports publicly for transparency. Deployment scripts are often overlooked but are critical attack vectors. Review all Hardhat/Foundry scripts, multisig transaction builders, and initialization code. Verify addresses (no hardcoded addresses that could be typos), verify constructor arguments, check that proxy initialization is correct, and ensure multisig configurations match production. Test scripts on the local network and testnet before the mainnet. Use script version control and require code review. For complex migrations (data transfers, token migrations), write formal specifications and verify script correctness with testing frameworks like Foundry or Hardhat. The security firm's scope statement should list, by file and address: proxy contracts, implementation contracts, deploy scripts, proposal-generation scripts, the exact calldata that will be posted onchain, and any governance module involved (Governor, Timelock). Upgrades that audit only the `.sol` diff while leaving the script that composes the calldata unreviewed are a recurring source of incidents. Require the audit report to state the proposal payload hash it reviewed. For every finding that is resolved by "risk accepted" rather than "fixed", publish a short rationale before execution — ideally in the same repo commit that freezes the proposal calldata. Signers and voters should be able to see the list of accepted risks next to the upgrade. This makes it impossible for a reviewer to wave through a finding without anyone else noticing. Integration tests MUST exercise the exact deployment script that will run on mainnet — not a hand-written setup that looks equivalent. If `script/Deploy.s.sol` (or your equivalent) produces a different system state than your test harness parameterizes, then the suite that passed is testing a different system than the one that ships. That divergence is a well-documented source of false confidence and real security incidents where user funds have been stolen. Have the integration tests execute the deployment script itself, then run invariants and behavioral tests against the resulting state. The more complex the system, the more surface area exists for the script and the test to drift apart, so the more strictly this needs to be enforced. See also [External Security Reviews](/external-security-reviews/overview) and [Audit Preparation Guide](/external-security-reviews/smart-contracts/preparation). ### Stage 4: Propose, Verify Onchain Calldata, and Monitor **Purpose.** Everything converges here. The proposal is posted onchain, calldata becomes immutable, multisig signers and voters must verify what they are approving, and the protocol must stay observable long after execution. #### Threats at this stage * **Calldata does not match audited code** — the bytes posted onchain differ from the reviewed source because of a last-minute edit, a different compiler, or a hostile build machine, and no one can tell by eye. * **Governance supply-chain compromise** — a compromised dependency, CI runner, IDE extension, or developer machine rewrites calldata between review and proposal. Pure code audits miss this. * **Blind multisig signing** — signers approve the proposal payload without independently decoding calldata, simulating the transaction, or cross-checking against published reproduction scripts. * **Governance attack on vote** — flash-loaned voting power, bribed delegates, or low quorum push through a malicious proposal inside the voting window. * **No post-execution monitoring** — once the upgrade lands, no one watches the invariants, so a slow-draining exploit enabled by the upgrade can run for days before it is noticed. #### Defenses * Reproducible proposal calldata built from a clean checkout. * CI-verified calldata verified against what is onchain as a third-party witness, matched exactly, byte-for-byte. * Signer runbook: decode calldata, simulate tx, compare hashes. * Timelock delay with upgrade intent visible onchain. * High-threshold multisig, hardware wallets, scheduled windows. * Continuous onchain invariants, alerting, and on-call rotation. #### Reproducible calldata Once a proposal is posted onchain, the calldata is what executes — everything upstream (the code, the audit, the reviewer's opinion) is only relevant if those bytes match it. The problem is that **neither the developer's machine nor the proposer's machine is trustworthy**. Both can be compromised. A malicious IDE extension, a compromised `node_modules`, a tampered Foundry binary, or a live attacker mid-call can rewrite the calldata between the reviewed commit and the posted transaction. The answer is to make the calldata **reproducible from the reviewed source**, and to rebuild it in a trusted CI environment as an independent witness. **Reproduction protocol.** 1. **Freeze the source.** Tag the commit that will produce the proposal calldata. Require all downstream artifacts to reference it. 2. **Pin the toolchain.** Commit exact Solidity version, Foundry/Hardhat version, and library versions. Use a lockfile. 3. **Build locally on a clean checkout.** From a fresh clone of the tagged commit, run the proposal-generation script and record the output calldata (or its keccak hash). 4. **Rebuild in CI.** A GitHub Actions (or equivalent) workflow, running on a pristine ephemeral runner, clones the same commit and runs the same script. The job **fails** if the calldata hash it produces does not match the committed reference hash. 5. **Match against the onchain proposal.** After the proposal is posted, either a signer script or a CI job reads the proposal calldata back from chain and asserts byte-for-byte equality with the CI-verified value. 6. **Publish the reproduction script and its output.** Put the script, the expected calldata hash, and the CI workflow in the repo so that anyone — a signer, a delegate, a security researcher — can re-run the whole thing. The CI run is the third witness. The developer's machine and the proposer's machine are the first two. If any of the three disagree, stop. **Worked example.** A Governor proposal calls `Timelock.schedule(target, value, data, predecessor, salt, delay)`. The reproducible pipeline emits `data` (typically ABI-encoded function calls to the protocol) and the full `schedule(...)` calldata. The published artifact is: `(commitHash, solcVersion, scheduleCalldataHash)`. The CI workflow rebuilds `scheduleCalldataHash` from `commitHash + solcVersion` and fails if it drifts. Signers run a short script that fetches the onchain proposal, decodes it, and asserts the same hash. This closes the gap where every link upstream — code, tests, audit — was fine, but a hostile dev machine quietly changed `target` or `data` before the transaction was broadcast. See also [CI/CD Security](/devsecops/continuous-integration-continuous-deployment), [Repository Hardening](/devsecops/repository-hardening), and [IDE Security](/devsecops/integrated-development-environments). #### Execution hygiene Execute mainnet upgrades through battle-tested multisig setups. Use production-grade thresholds chosen for your asset value, signer reliability, geographic distribution, and emergency-response needs. Higher thresholds can improve security, but they also reduce liveness during incidents. As a reference, you could consider a minimum of 3-of-5 for medium security and 4-of-7 or higher for high security (treasury, protocol ownership). Diversify signers geographically and organizationally (internal team, advisors, investors, community members). Use hardware wallets (Ledger, Trezor) for signer keys, never hot wallets. Practice simulation signing on testnet before mainnet. Document the signing process, verify transaction details with tools like Tenderly or Safe Transaction Builder, and coordinate timing for time-sensitive upgrades. Implement on-chain timelocks (24-72 hours typical) between upgrade approval and execution. This provides transparency, allows community review of upgrade code and transaction parameters, enables emergency response if issues are discovered, and reduces trust in multisig signers. Use battle-tested implementations like OpenZeppelin's TimelockController or Compound's Timelock. For governance-driven protocols, timelocks are essential for decentralization. For routine upgrades, publish upgrade intentions publicly during the timelock period with links to code changes and audit reports. For emergency or security-sensitive fixes, disclosure timing should be carefully coordinated so that the mitigation is live before unnecessary details are broadcast. Announce upgrades in advance through all communication channels: website banner, Twitter, Discord, Telegram, governance forum. Provide 48-72 hours' notice for major upgrades, 1 week for breaking changes. Schedule upgrades for periods when the required engineering, security, governance, and incident response personnel are available and monitoring coverage is strongest. Lower-traffic windows can help, but strong response coverage matters more than simply choosing weekends or off-hours. Clearly communicate expected downtime (if any), required user actions (if any), such as frontend refreshes, re-signing approvals, or migration steps, and expected changes. After the upgrade, publish the summary with transaction hashes, deployed contract addresses, audit reports, and changelog. This builds trust and allows ecosystem participants (frontends, aggregators, analytics) to prepare. Before signing, every signer follows the same short checklist: (1) fetch the onchain proposal and decode its calldata with an independent tool (Tenderly, Safe Transaction Builder, a local `cast decode`); (2) compare the decoded calls and target addresses against the published proposal spec; (3) check the calldata hash against the CI-verified reference; (4) simulate the transaction on a mainnet fork and confirm the invariant suite passes. A signer who cannot complete this checklist should not sign. See [Multisig Runbooks](/multisig-for-protocols/runbooks/overview) and [Security Council Best Practices](/governance/council-best-practices). #### Post-execution monitoring During upgrade execution, maintain active monitoring with multiple team members online. Watch for: transaction confirmation and success, event emission and proper indexing, protocol health metrics (TVL, active users, transaction success rate), gas prices and network congestion, unusual transaction patterns or exploits, social media for user reports or concerns. Use monitoring platforms like Tenderly for transaction traces, Dune Analytics for protocol metrics, and OpenZeppelin Defender for automated monitoring. Have incident response procedures ready. Keep multisig signers on standby for emergency pause if needed. After successful upgrade, monitor intensively for 24-48 hours. The invariant suite from Stage 2 is not just for pre-flight testing. Run the same invariants against live state on a schedule (every block for high-value protocols, every few minutes otherwise). Alert on any breach — total supply drift, collateral-ratio degradation, unexpected role changes, oracle values outside expected range. A slow exploit enabled by an upgrade will often violate exactly the invariants that were supposed to hold, so continuous checking converts a multi-day incident into a minutes-long one. See [Monitoring Overview](/monitoring/overview). Maintain an on-call schedule, and practice tabletop exercises to prepare for governance proposal security incidents. *** ### Additional Web3-Specific Considerations #### Common Proxy Patterns Implementation contract contains upgrade logic, more gas-efficient but riskier (bug in upgrade logic can brick the contract). Use OpenZeppelin's UUPS implementation. Separates upgrade logic into ProxyAdmin contract, safer but higher gas costs. Admin calls go to ProxyAdmin, user calls go to implementation. Supports multiple implementation contracts (facets), allows unlimited contract size, complex but powerful for large protocols. Multiple proxies share one implementation reference (beacon), efficient for deploying many identical upgradeable contracts. #### Real-World Proposal Failures Signature verification bypass in upgraded guardian logic allowed attacker to mint 120,000 wETH ($325M). Insufficient testing of upgrade logic and access controls. Upgrade introduced bug where zero hash was treated as valid proof, allowing anyone to withdraw funds ($190M loss). Lack of proposal audits, reviews, integration and invariant testing locally and in CI were all root causes of this unsafe proposal landing. [Proposal 117](https://compound.finance/governance/proposals/117) upgraded the cETH market's price-feed integration, but the new implementation was incompatible with the Chainlink oracle interface the market consumed, so cETH oracle reads returned invalid values and the market was effectively frozen for borrows and liquidations. The root cause was the absence of integration tests exercising the downstream oracle consumers against the upgraded contracts — the proposal passed review, but no test fork executed it against the live oracle integration. Remediation required a follow-up governance proposal through the timelock, extending market disruption across several days. The yUSDT vault was deployed in 2020 with the wrong fulcrum address — it pointed at `iUSDC` instead of `iUSDT`. The misconfiguration sat in production for roughly 1,000 days before an attacker exploited it in April 2023 to mint over a quadrillion yUSDT and drain roughly $11.5M. Root cause: a parameter error in the deployment script that was never caught by integration tests or a deployment-script review — exactly the failure mode Stage 2 and Stage 3 of this page's checklists are designed to prevent. [Victim contract on Etherscan](https://etherscan.io/address/0x83f798e925BcD4017Eb265844FDDAbb448f1707D). These incidents highlight why rigorous testing, specifically applied to governance proposals and their associated deployment scripts, is essential for safe upgrades. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Devsecops > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [DevSecOps](/devsecops/overview) * [Implementing Code Signing](/devsecops/code-signing) * [Securing CI/CD Pipelines](/devsecops/continuous-integration-continuous-deployment) * [Data Security Checklist](/devsecops/data-security-upgrade-checklist) * [Governance Proposal Security Across the SDLC](/devsecops/governance-proposal-security) * [Securing Development Environments](/devsecops/integrated-development-environments) * [Repository Hardening](/devsecops/repository-hardening) * [Security Testing](/devsecops/security-testing) * [Isolation](/devsecops/isolation) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Integrated Development Environments (IDEs) Integrated Development Environments (IDEs) are essential tools for developers, but they also need to be secured. Consider implementing the following best practices: 1. Install plugins and extensions only from trusted sources, and verify each one through multiple independent channels before installing: * Confirm the publisher matches the expected organization — typosquats and lookalike publishers are common. * Cross-reference the extension's source repository on GitHub; skim recent commits, open issues, and any security advisories. * Check install counts and verified-publisher badges, and prefer signed / officially-published releases over sideloaded builds. Due diligence on extensions is typically low, which is precisely why threat actors target this vector: a single malicious or compromised extension can exfiltrate source, secrets, and session tokens across every project on the machine. Use restricted mode if you don't fully trust a project. 2. Keep IDEs and their plugins/extensions up-to-date to protect against vulnerabilities. 3. Integrate static code analysis tools within the IDE to catch security issues early in the development process. 4. Configure IDEs to follow the principle of least privilege, limiting access to sensitive information and systems. 5. Ensure that potential development environments are isolated from production environments. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## DevSecOps > 🔑 **Key Takeaway**: DevSecOps works when security is embedded from planning through > delivery, automated checks stop unsafe changes before production, and sandboxed > execution contains risk when untrusted code or tooling runs. Traditionally, rapid development and deployment are often prioritized at the expense of security considerations. This is generally speaking no different in web3, but it is important to take integrity, confidentiality, and availability into consideration too. To effectively address this without compromising on rapid development and deployment, it is essential to integrate security into the process, which is where devsecops comes into play. By implementing devsecops, projects can not only deploy faster, but also be more secure. When operating in a devsecops mindset, projects prioritize automation and collaboration between the development, operations and security teams. Some of the key areas to consider are: 1. Integrate security measures early in the development process, such as by utilizing security tools such as fuzzing, static and dynamic analysis tools in your CI/CD process, to identify and mitigate vulnerabilities before they turn into critical issues. 2. Implement automated security testing and monitoring. 3. Development, Operations and Security teams should be aligned and work closely together. 4. Use **sandboxing & isolation** to reduce blast radius when running tooling, builds, plugins, and other potentially risky execution. * See: [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation) ### Contents * [Code Signing](/devsecops/code-signing) - Verify code integrity with GPG-signed commits and pull requests * [Continuous Integration and Deployment](/devsecops/continuous-integration-continuous-deployment) - Secure your CI/CD pipelines * [Data Security Checklist](/devsecops/data-security-upgrade-checklist) - Comprehensive checklist for data security best practices * [Governance Proposal Security Across the SDLC](/devsecops/governance-proposal-security) - Threat-model guide to smart contract upgrade governance across the proposal lifecycle * [Integrated Development Environments](/devsecops/integrated-development-environments) - Secure your development environment * [Isolation & Sandboxing](/devsecops/isolation) - Containment patterns for CI/CD, tool execution, and build pipelines * [Repository Hardening](/devsecops/repository-hardening) - Protect your code repositories * [Security Testing](/devsecops/security-testing) - Integrate security testing into your development workflow *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Repository Hardening > 🔑 **Key Takeaway**: A hardened repository enforces MFA, signed commits, > protected branches, and least-privilege access by default; monitors for > leaked secrets and suspicious activity; and makes every change traceable > to a verified human through code review and signature verification. If a threat actor obtains access to your repository, the consequences can be catastrophic: injected backdoors, stolen secrets, compromised releases, and eroded trust. Repository hardening is the first line of defense, ensuring that even if individual credentials are compromised, layered controls limit the damage. ### Practical guidance #### 1. Require MFA for all repository members Multi-Factor Authentication is the single most effective control against credential theft. * Enable "Require two-factor authentication" at the **organization level** in GitHub. This forces all members, including outside collaborators, to enable MFA before they can access any org repository. * Encourage hardware MFA (Yubikey, Titan) over SMS or TOTP. FIDO2/WebAuthn keys resist phishing and credential replay. * Audit MFA enrollment periodically: review org member settings and remove members who have not enabled MFA. #### 2. Enable protected branches Protected branches prevent unauthorized or unreviewed changes to critical branches. * Protect `main`, `develop`, and any release branches. * Enable these rules at minimum: * **Require a pull request before merging** — at least 1 approving review, dismiss stale reviews on push. * **Require signed commits** — reject unsigned pushes. * **Require status checks to pass before merging** — link to CI checks. * **Require linear history** — prevent merge commits that obscure the commit graph. * **Do not allow force pushes** — prevent history rewriting. * **Do not allow deletion** — prevent branch removal. * For high-sensitivity branches, require **2+ approving reviews** and restrict who can push to specific teams. [Learn more about protected branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches). #### 3. Harden GitHub Actions GitHub Actions workflows have access to repository secrets and can execute arbitrary code, making them a high-value target. * Follow [Security hardening for GitHub Actions](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions). * Pin third-party actions by **commit SHA**, not by tag. Tags are mutable and can be retagged to point to malicious code. * Restrict `GITHUB_TOKEN` permissions: set `permissions: {}` at the workflow level and grant only what each job needs. * Never use `pull_request_target` with an untrusted checkout. This gives fork PRs access to repository secrets. * Use **CODEOWNERS** to require review from the security or DevOps team for any change to `.github/workflows/`. #### 4. Enforce strict access controls Limit who can push to critical branches and repositories. * Use the **principle of least privilege**: grant Admin access only to maintainers who need it. Most contributors need Write access at most, and many need only Read or Triage. * Use **teams** to manage access: assign repository permissions to teams, not individuals. This makes onboarding/offboarding easier and provides a clear audit trail. * For organization repositories, set the **default permission** to Read and explicitly grant Write/Admin to teams that need it. * Review repository collaborator lists quarterly. Remove stale accounts and reduce over-privileged access. #### 5. Require signed commits Signed commits verify the identity of contributors and the integrity of the code. * Enable "Require signed commits" in branch protection rules. * Configure `git config commit.gpgsign true` to sign by default. * Verify signatures in CI: `git log --verify-signatures`. * For automated commits (Dependabot, bots), use a dedicated bot account with its own signing key, or accept unsigned bot commits via a separate, lower-privilege branch. * See [Implementing Code Signing](/devsecops/code-signing) for full guidance. #### 6. Conduct regular security audits Audit the repository for configuration drift, abandoned access, and new vulnerabilities. **Quarterly access review:** list all collaborators and teams, verify each still needs access, reduce permissions where possible. **Workflow audit:** review all GitHub Actions workflows for security issues (over-permissioned tokens, unpinned actions, exposed secrets). **Dependency audit:** run `npm audit`, `pip audit`, or equivalent. Enable Dependabot security updates. **Secret scan:** run TruffleHog or git-secrets on the repository history to find accidentally committed credentials. Use tools like **Scorecard** (OpenSSF) to automate security posture assessment of your repository. #### 6b. Use CODEOWNERS to enforce security reviews CODEOWNERS files define who must review changes to specific paths. Use them to require security or ops team sign-off on sensitive directories: ```bash # .github/CODEOWNERS # Security-sensitive paths — require security team review /.github/workflows/ @myorg/security-team /contracts/ @myorg/security-team @myorg/lead-dev /deploy/ @myorg/security-team @myorg/devops /secrets.env.example @myorg/security-team # Dependencies — require security review for any dependency changes package.json @myorg/security-team package-lock.json @myorg/security-team Gemfile @myorg/security-team requirements.txt @myorg/security-team # Default — all other changes need at least 1 approval from anyone * @myorg/dev-team ``` CODEOWNERS alone does not block merges — pair it with branch protection rules requiring reviews from the specified teams. #### 6c. Enable GitHub Advanced Security features GitHub provides additional security features under "Code security and analysis": **Code scanning (CodeQL):** Automated SAST integrated directly into GitHub. ```yaml # .github/workflows/codeql.yml name: CodeQL on: push: branches: [main, develop] pull_request: branches: [main, develop] jobs: codeql: runs-on: ubuntu-latest permissions: security-events: write actions: read steps: - uses: github/codeql-action/init@v3 with: languages: javascript, python, solidity - uses: github/codeql-action/analyze@v3 ``` **Secret scanning:** Detects committed secrets across all branches. Enable push protection to block secrets before they enter history: Settings → Code security and analysis → Secret scanning → ✅ Scanning + ✅ Push protection. **Dependency review:** Shows the security impact of dependency changes in PRs before they merge. Requires GitHub Advanced Security: Settings → Code security and analysis → Dependency review → ✅ Enable. **Unified security dashboard:** At the organization level, get a unified view of security alerts across all repos. #### 6d. Publish a security policy A `SECURITY.md` file in the repository root tells security researchers how to report vulnerabilities: ```markdown # Security Policy ## Supported Versions | Version | Supported | | ------- | ------------------ | | 1.x | :white_check_mark: | | 0.x | :x: | ## Reporting a Vulnerability Please report vulnerabilities by: 1. **Do not** open a public GitHub issue. 2. Email security@example.com with details. 3. Include a proof of concept if possible. We aim to respond within 48 hours and will keep you informed throughout the disclosure process. ## Bug Bounty We participate in the Immunefi bug bounty program. Rewards up to $50,000 for critical vulnerabilities. See: https://immunefi.com/bounty ``` Link `SECURITY.md` in: * The repository's sidebar (via vocs config) * The PR template * Any public communication about the project #### 7. Manage dependencies and vulnerabilities Dependencies are a major attack surface for supply chain compromises. * Enable **Dependabot** for version updates and security updates. * Review Dependabot PRs promptly; security updates are time-sensitive. * Pin dependencies by hash or exact version in production. Avoid floating ranges (`^1.0.0`) in deployed artifacts. * Use lockfiles (`package-lock.json`, `poetry.lock`) and commit them to the repository. * For Web3: audit Solidity dependencies (OpenZeppelin, forge-std) for known vulnerabilities. Use `npm audit` or `pip audit` for off-chain dependencies. * Consider using a private registry (Artifactory, npm enterprise) to proxy and cache dependencies, preventing dependency confusion attacks. ### Configuration Checklists For detailed GitHub configuration checklists adapted from [Auditware's W3OSC](https://github.com/AuditWare-io/W3OSC): * [Individual GitHub Account Settings](/guides/account-management/github#for-individuals) * [Organization GitHub Repository & Org Settings](/guides/account-management/github#for-admins) ### Why is it important Repository compromises have led to significant incidents: * **PHP/Composer supply chain attack (2021)**: Attacker obtained maintainer credentials and pushed malicious commits to the PHP repository, injecting a backdoor that would have allowed remote code execution. Signed commits and review would have caught this. * **ua-parser-js, event-stream incidents**: Maintainer accounts were compromised to publish malicious npm packages. These could have been prevented by MFA, signed commits, and dependency pinning. * **Action-scrubber attack pattern**: Malicious GitHub Actions can exfiltrate `GITHUB_TOKEN` and repository secrets if workflows are not properly sandboxed and permissioned. NIST SP 800-53 Rev. 5 controls **AC-3 (Access Enforcement)**, **AU-10 (Non-Repudiation)**, and **SC-28 (Protection of Information at Rest)** all apply to repository hardening. ### Implementation details | Sub-topic | Related page | | ------------------------------- | ----------------------------------------------------------------------------------- | | Code signing and key management | [Implementing Code Signing](/devsecops/code-signing) | | CI/CD pipeline security | [Securing CI/CD Pipelines](/devsecops/continuous-integration-continuous-deployment) | | Security testing tools | [Security Testing](/devsecops/security-testing) | | Sandbox isolation for CI | [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation) | ### Common pitfalls * **Admin access granted too broadly**: Many repositories grant Admin to all core contributors. Admins can change branch protection rules, remove reviewers, and modify secrets. Grant Admin only to maintainers who explicitly need it. * **Stale collaborator accounts**: Former team members or contractors who still have access are a common attack vector. Remove access immediately when someone leaves the team. * **Unpinned GitHub Actions**: `uses: action@v3` can be retagged. Always pin by SHA: `uses: action@abc123def456...`. * **Ignoring Dependabot PRs**: Security update PRs are time-sensitive. Establish an SLA for reviewing them (e.g., Critical within 24 hours). * **Disabling branch protection for convenience**: Temporary exceptions become permanent. If a workflow requires an exception, automate it through a documented process, not by disabling the rule. ### Quick-reference cheat sheet | Hardening measure | How to enable | | --------------------------------- | ------------------------------------------------------- | | Org-wide MFA | GitHub Org Settings > Authentication > Require 2FA | | Protected branches | Repo Settings > Branches > Add rule > Enable all checks | | Require signed commits | Branch protection > Require signed commits | | CODEOWNERS review | Create `.github/CODEOWNERS` with path-to-team mappings | | Pin actions by SHA | `uses: action@<40-char-sha>` | | Restrict GITHUB\_TOKEN | `permissions: {}` at workflow level | | Dependabot security updates | Repo Settings > Code security > Enable Dependabot | | Secret scanning + push protection | Org Settings > Code security > Enable both | | Scorecard audit | `npx @ossf/scorecard --repo=/` | ### References * [GitHub Docs: About protected branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) * [GitHub Docs: Security hardening for GitHub Actions](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions) * [OpenSSF Scorecard](https://github.com/ossf/scorecard) * [NIST SP 800-53 Rev. 5, AC-3 Access Enforcement](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) * [Auditware W3OSC](https://github.com/AuditWare-io/W3OSC) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Security Testing > 🔑 **Key Takeaway**: Shift security testing left by running SAST, DAST, > IAST, and fuzzing in CI on every PR; treat findings as actionable pipeline > gates (not just reports); and complement automation with periodic manual > penetration testing for high-value targets. Security testing identifies vulnerabilities before they reach production. The "shift-left" principle means integrating these tests as early as possible in the development lifecycle: in the IDE, in pre-commit hooks, and in CI. The later a vulnerability is found, the more expensive it is to fix. In Web3, where deployed smart contracts are often immutable, finding bugs before deployment is critical. ### Practical guidance #### 1. Static Application Security Testing (SAST) SAST analyzes source code without executing it. It catches common vulnerabilities early and cheaply. * Integrate SAST into the CI pipeline so that every PR is scanned before merge. * For Solidity: use **Slither** (Trail of Bits), **Aderyn** (Cyfrin), and **Solhint**. These detect reentrancy, access control issues, and unsafe arithmetic patterns. * For JavaScript/TypeScript: use **Semgrep**, **CodeQL**, or **SonarQube**. * For Python: use **Semgrep**, **Bandit**, or **Ruff** with security rules. * Configure SAST tools to fail CI on Critical and High findings. Track Medium/Low as issues for triage. * Suppress false positives carefully: document the reason and set an expiry date for re-evaluation. * Run SAST locally in pre-commit hooks or IDE plugins so developers get immediate feedback before pushing. #### 2. Dynamic Application Security Testing (DAST) DAST tests running applications by sending crafted inputs and observing responses. It catches issues that SAST misses: misconfigured servers, authentication bypasses, and runtime-specific vulnerabilities. * Run DAST against deployed test environments (not production). * Tools: **OWASP ZAP** (free, extensible), **Burp Suite** (commercial, professional-grade), **Nuclei** (template-based, fast scanning). * For Web3 APIs: test RPC endpoints, REST APIs, and WebSocket interfaces for injection, authentication bypass, and rate limiting issues. * Schedule DAST scans nightly and before every release. * Test authentication flows: login, session management, privilege escalation, and API key validation. #### 3. Interactive Application Security Testing (IAST) IAST combines SAST and DAST by instrumenting the application at runtime and observing data flow during functional testing. * IAST agents run inside the application process and monitor method calls, data flow, and control flow in real time. * Tools: **Contrast Security**, **Seeker** (Synopsys), **Hdiv Security**. * IAST excels at finding injection vulnerabilities (SQL, command, LDAP, XSS) that SAST may miss due to complex data flow and DAST may miss because it does not cover all code paths. * Integrate IAST into your automated test suite: functional tests drive the IAST agent, which reports vulnerabilities in real time. * Limitations: IAST requires language-specific agents and may impact application performance. Use it in staging environments, not production. #### 4. Fuzz testing Fuzz testing feeds random or semi-random data to application interfaces to discover crashes, assertion failures, and security vulnerabilities. * For Solidity smart contracts: use **Echidna** (Trail of Bits) for property- based testing, **Medusa** (Cryptic Labs) and **Halmos** for symbolic fuzzing. Define invariants (e.g., "total supply equals sum of balances") and let the fuzzer try to break them. * For general software: use **AFL++**, **libFuzzer**, or **Jazzer** (Java). Write fuzz harnesses that target parsing logic, input validation, and protocol handling. * For APIs: use **Hypothesis** (Python) or **fast-check** (JS/TS) for property-based testing in unit tests. * Run fuzzing campaigns as part of CI: fast fuzz tests in PR pipelines (short duration, focused invariants), extended fuzzing overnight (longer duration, broader coverage). * Monitor for new coverage: a good fuzzer should continuously discover new code paths. If coverage plateaus, add new seeds or adjust mutation strategies. #### 5. Software Composition Analysis (SCA) SCA scans dependencies for known vulnerabilities. * Enable **Dependabot** alerts and security updates in GitHub. * Use **Snyk**, **npm audit**, or **pip audit** in CI to scan on every PR. * For Web3: audit Solidity dependencies (OpenZeppelin, Solmate, Forge-std) and off-chain dependencies (ethers.js, viem, web3.js). * Track dependency risk: flag packages with no recent updates, single maintainers, or known vulnerabilities. * Consider using a private package registry (Artifactory, Verdaccio) to proxy and cache dependencies, reducing supply chain risk. #### 6. Manual penetration testing Automated tools cannot replace human creativity in finding complex logic flaws. * Schedule external penetration tests for high-value targets (smart contracts, bridges, oracles, authentication systems) before major releases. * Use bug bounty platforms (Immunefi, HackerOne, Code4rena) for continuous community-driven testing. * After internal testing and automated scans, engage an independent security firm (Trail of Bits, OpenZeppelin, Spearbit) for a formal audit. * Publish audit reports for transparency. Track and remediate all findings. #### 6b. Set realistic severity thresholds Context matters. A "High" finding in a low-impact context might not warrant blocking a merge. Establish explicit triage criteria: | Severity | Definition | Action | | -------- | ------------------------------------------------------------------ | ----------------------------------- | | Critical | Remote code execution, full wallet drain, signature forgery | Block PR immediately | | High | Data exfiltration, unauthorized state change, privilege escalation | Block PR, fix within 24h | | Medium | Denial of service, partial bypass, information disclosure | Block PR, fix within 1 week | | Low | Code quality, best practice violations, minor misconfigurations | Track as issue, fix within 1 sprint | Document severity triage decisions. A finding dismissed as "Low" should have a written rationale and an expiry date for re-evaluation. #### 6c. Integrate Semgrep for custom security rules Semgrep supports custom rules that encode your project's security policies: ```yaml # .semgrep/security-high.yaml rules: - id: hardcoded-private-key pattern: $KEY = /0x[a-fA-F0-9]{64}/ message: Hardcoded private key detected. Use environment variables. severity: ERROR languages: [javascript, python, solidity] # NOTE: This is a simplified example. In production, use a more specific # pattern that matches actual sensitive variables, not any spread argument. - id: sensitive-data-logging pattern: console.log(...$SENSITIVE) message: Do not log sensitive data in production. severity: WARNING languages: [javascript, typescript] - id: prevent-eval pattern: eval($INPUT) message: eval() with user input is a code injection risk. severity: ERROR languages: [javascript, python] ``` Semgrep Rule Registry contains thousands of pre-built rules. Use `semgrep --config=auto` to run all applicable rules, then supplement with project-specific rules. #### 6d. Manage false positives systematically False positives erode trust in the scanning pipeline. If developers learn to ignore alerts, real findings get missed. **Suppress with documentation, not silence:** ```yaml # nosemgrep: hardcoded-private-key # Reason: Test fixtures only — not real keys. # Ticket: SEC-1234, suppress until test fixture refactored. # Expiry: 2027-06-01 ``` Every suppression should include: the finding ID, why it is a false positive, a linked ticket, and an expiry date for re-evaluation. #### 6e. Track coverage and mutation testing Code coverage metrics alone do not measure security, but they indicate whether critical paths are tested: ```bash # Solidity with Foundry forge coverage --report lcov # Target: >90% line coverage for contract code # Python with pytest-cov pytest --cov=src --cov-report=html # Target: >85% line coverage # JavaScript with c8 npx c8 --reporter=lcov mocha # Target: >80% line coverage ``` For smart contracts, supplement coverage with **mutation testing** using Foundry's `forge snapshot` or Echidna invariants. Mutation testing modifies code slightly (changes `>` to `>=`) and verifies that tests catch the change. If tests don't catch mutated code, they aren't testing the right thing. ### Why is it important Undetected vulnerabilities in production lead to exploits. In Web3, the consequences are often irreversible due to smart contract immutability. * **Ronin Bridge ($625M, 2022)**: The bridge's validator set was compromised because monitoring and access controls were insufficient. Penetration testing and security monitoring could have identified the weak access control earlier. * **Wormhole ($325M, 2022)**: A signature verification bug in upgraded guardian logic went undetected. Formal verification and fuzz testing of invariants would have caught this. * **Parity Wallet ($150M, 2017)**: An unprotected `initWallet` function allowed anyone to take ownership. SAST and manual review would have identified the missing access control. NIST SP 800-53 Rev. 5 control **RA-5 (Vulnerability Scanning)** and **SI-2 (Flaw Remediation)** mandate regular vulnerability scanning and timely remediation. ### Implementation details | Sub-topic | Related page | | -------------------------------------- | ----------------------------------------------------------------------------------- | | CI/CD pipeline integration of scans | [Securing CI/CD Pipelines](/devsecops/continuous-integration-continuous-deployment) | | Isolated test environments | [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation) | | Code signing to verify test provenance | [Implementing Code Signing](/devsecops/code-signing) | ### Common pitfalls * **Running SAST but ignoring results**: Scanning is only valuable if findings are triaged and remediated. Establish an SLA: Critical findings block the PR, High within 48 hours, Medium tracked as issues. * **DAST only on production**: Running DAST against production can cause disruptions and misses the opportunity to catch issues before deploy. Run DAST against staging or dedicated test environments. * **Fuzzing without invariants**: A fuzzer without clear properties to test will find crashes but miss logic errors. Define meaningful invariants (e.g., "no user can withdraw more than their balance") that capture business logic. * **Skipping IAST due to performance overhead**: IAST has a performance cost, but running it in staging during automated functional tests catches injection vulnerabilities that SAST and DAST miss. The trade-off is worthwhile for high-value applications. * **Treating security testing as a one-time event**: Security is continuous. New code, new dependencies, and new attack techniques require ongoing testing. Integrate scans into CI, not just pre-release checklists. ### Quick-reference cheat sheet | Test type | When to run | Tools (Web3/Solidity) | Tools (General) | | --------- | --------------------------- | ------------------------ | ----------------------------- | | SAST | Every PR | Slither, Aderyn, Solhint | Semgrep, CodeQL, SonarQube | | DAST | Nightly + pre-release | Custom RPC fuzzers | OWASP ZAP, Nuclei, Burp Suite | | IAST | Staging functional tests | — | Contrast Security, Seeker | | Fuzzing | PR (short) + nightly (long) | Echidna, Medusa, Halmos | AFL++, libFuzzer, Hypothesis | | SCA | Every PR + daily cron | npm audit, pip audit | Dependabot, Snyk | | Pen test | Pre-release + ongoing | Immunefi, Code4rena | HackerOne, Bugcrowd | ### References * [OWASP Testing Guide v4](https://owasp.org/www-project-web-security-testing-guide/) * [NIST SP 800-53 Rev. 5, RA-5 Vulnerability Scanning](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) * [Slither: Static Analyzer for Solidity](https://github.com/crytic/slither) * [Echidna: Fuzzer for Ethereum Smart Contracts](https://github.com/crytic/echidna) * [OWASP Fuzzing Guide](https://owasp.org/www-community/Fuzzing) * [Immunefi Bug Bounty Platform](https://immunefi.com/) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Capability-Based Isolation > 🔑 **Key Takeaway**: Capability-based isolation replaces broad ambient permissions with > short-lived, task-scoped grants tied to context, so compromised workflows cannot exceed > narrowly defined actions. Capability-based isolation limits what automation can do by granting **specific actions under explicit conditions**, instead of broad ambient privileges. In practice: do not give a job “admin” rights when it only needs “read dependency metadata” or “upload artifact to one path”. ### Why this matters in DevSecOps Many incidents are privilege-shape failures, not code execution failures: compromised workflows succeed because credentials are too broad. Capability scoping reduces blast radius by ensuring that even successful compromise has constrained impact. ### Capability model template Define capabilities as structured policy units: | Field | Example | | ---------- | --------------------------------------------------------------- | | Subject | `ci/workflow/build` | | Action | `artifact.upload` | | Resource | `registry.example.com/team/app/*` | | Conditions | branch is protected, artifact has provenance, session \< 15 min | | Effect | allow / deny | ### CI/CD capability tiers #### Tier 1: Validate * read repository * execute tests * no deploy/publish * no production secrets #### Tier 2: Build * pull dependencies from approved registries * upload intermediate artifacts * no release signing keys #### Tier 3: Release * publish signed artifact * write release metadata * deploy only to approved environment targets Map these tiers to separate identities/roles rather than toggling permissions in a single long-lived token. ### Implementation patterns * Use workload identity federation (OIDC) for short-lived credentials. * Create role-per-purpose identities (validate/build/release/deploy). * Bind capabilities to both identity and runtime context (repo, branch, environment, workflow name). * Deny by default; add narrow allow rules. ### Audit and revocation requirements For each capability grant, log: * who/what requested it * when it was issued and expired * what resource/action it enabled * whether execution succeeded or was denied Capability revocation should be immediate and automated for suspicious activity. ### Common anti-patterns * “One token to rule them all” for all pipeline stages. * Reusing static cloud credentials across repositories. * Capability definitions without contextual conditions. * Missing visibility into denied actions (blind spots hide attacks). ### References * [NIST SP 800-53 Rev. 5 (least privilege and access control)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) * [NIST SSDF (SP 800-218)](https://csrc.nist.gov/pubs/sp/800/218/final) * [NIST glossary, *Least Privilege*](https://csrc.nist.gov/glossary/term/least_privilege) * [Kubernetes, *Role Based Access Control*](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) * [Kubernetes, *Pod Security Standards*](https://kubernetes.io/docs/concepts/security/pod-security-standards/) * [SLSA specification](https://slsa.dev/spec/v1.0/) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Execution Sandboxing: A Practical Guide > 🔑 **Key Takeaway**: Start by defining trust zones, then apply matching > controls that keep untrusted validation isolated from release paths > while enforcing ephemeral runners, short-lived credentials, > and deny-by-default egress. This guide translates sandboxing principles into concrete controls for real CI/CD environments. Use it when you need to answer: **“What should we deploy this quarter to materially reduce risk from untrusted execution?”** ### Scope and assumptions This playbook focuses on execution risks from: * untrusted pull requests and dependencies * shared/self-hosted runners * build and release tooling with write privileges * secret exposure and token misuse * unrestricted network egress It is applicable regardless of whether automation is triggered by scripts, bots, or AI-enabled systems. ### 0) Define trust zones first Before implementing controls, classify workflows into trust zones: | Zone | Typical sources | Allowed outcomes | | -------------------- | ------------------------------------------------------ | --------------------------------- | | Untrusted validation | fork PRs, external contributions, unknown dependencies | lint/test/build checks only | | Internal trusted CI | protected branches, approved maintainers | artifact build + internal publish | | Release/deploy | signed tags, release managers, protected environments | production deploy and signing | **Rule:** never run untrusted-zone jobs on release/deploy infrastructure. ### 1) Runner isolation baseline #### Required baseline * Ephemeral runner per job (destroy after completion). * No privileged containers unless explicitly justified and isolated. * No host docker socket mount for untrusted jobs. * Read-only root filesystem where possible. * Separate runner pools per trust zone. #### Good defaults for containerized runners * Drop Linux capabilities by default (`cap-drop=ALL`). * Use seccomp profile and AppArmor/SELinux policy. * Set CPU/memory/pids limits. * Set job timeout and process count limits. ### 2) Safe handling for untrusted PRs Untrusted PR execution is the most common CI breach path. #### Controls 1. Trigger untrusted jobs with minimal token permissions. 2. Do not expose deployment credentials, signing keys, or production secrets. 3. Prevent write operations to protected branches/tags. 4. Restrict artifact publication from untrusted workflows. 5. Apply strict outbound network allowlist. #### GitHub Actions example (least privilege token) ```yaml permissions: contents: read pull-requests: read ``` Only grant elevated scopes per job when required. #### Important workflow safety note Avoid using `pull_request_target` to run untrusted code with privileged context unless you fully understand and constrain checkout, permissions, and secret access behavior. ### 3) Secrets and identity controls #### Prefer short-lived credentials * Use OIDC federation to cloud providers instead of static cloud keys in CI secrets. * Scope roles per workflow purpose (build-only, publish-only, deploy-only). * Apply time-bound sessions and audience restrictions. #### Secret exposure minimization * Inject secrets only into jobs that require them. * Mask and redact logs. * Mount secrets read-only and avoid writing them to workspace. * Rotate credentials and invalidate on suspected leakage. #### Segregate high-impact secrets Signing keys, registry publish credentials, and production deploy tokens should be available only in protected environments with approval gates. ### 4) Network egress control Start from **deny all egress**, then open only required destinations. #### Minimum egress policy structure * allow source control host (fetch) * allow package mirrors/registries needed for build * allow artifact store * deny direct access to internal admin/control planes * deny metadata endpoints unless explicitly required #### Kubernetes example pattern * namespace-per-trust-zone * default deny egress NetworkPolicy * explicit allowlist policies per pipeline stage ### 5) Resource and abuse controls Prevent runaway or abusive workloads: * CPU/memory/pids quotas per job * max execution time per stage * bounded log size and artifact size * concurrency controls for expensive workflows * filesystem quota for temporary storage These controls reduce denial-of-service risk and limit cost impact from malicious or broken tasks. ### 6) Build integrity and provenance Sandboxing reduces runtime blast radius; integrity controls reduce supply-chain risk. Recommended: * Generate provenance attestations for build artifacts. * Sign release artifacts. * Enforce verification before deployment. * Use reproducible/deterministic build settings where feasible. Use SLSA-aligned controls to define maturity targets over time. ### 7) Policy gates (before and after execution) Implement policy-as-code checks at multiple points: * **Pre-execution:** validate workflow configuration (forbidden privileged flags, forbidden secret contexts). * **Runtime:** enforce admission and sandbox policy (seccomp, allowed images, namespace constraints). * **Post-execution:** verify provenance/signatures and deployment policy. ### 8) Logging and incident readiness At minimum capture: * workflow identity (repo, ref, actor, workflow, runner) * command/process telemetry (high-risk operations) * network destinations contacted * secret access events * artifact hashes and provenance metadata Have a playbook for: 1. revoke active tokens 2. quarantine runner pool 3. rotate secrets 4. invalidate suspicious artifacts 5. re-run trusted build from clean source ### 30/60/90 day implementation plan #### First 30 days * Split trusted vs untrusted runner pools. * Enforce least-privilege CI token defaults. * Disable secrets in untrusted PR workflows. * Add job timeouts and resource limits. #### By day 60 * Introduce default-deny egress with allowlists. * Deploy seccomp/AppArmor (or equivalent) profiles. * Migrate static cloud credentials to OIDC short-lived roles. #### By day 90 * Add artifact signing and provenance checks. * Enforce policy-as-code gates for workflow and runtime configuration. * Run a tabletop exercise for CI compromise response. ### Operational checklist * [ ] Untrusted PRs isolated from privileged runners * [ ] Ephemeral runners enabled * [ ] CI token defaults set to read-only * [ ] No long-lived cloud keys in CI * [ ] Egress deny-by-default + destination allowlists * [ ] Seccomp/profile enforcement active * [ ] Resource quotas and timeouts configured * [ ] Artifact signing/provenance verified at release * [ ] Incident response runbook tested ### References * [NIST SP 800-190, *Application Container Security Guide*](https://csrc.nist.gov/pubs/sp/800/190/final) * [NIST SP 800-204A, *Building Secure Microservices-based Applications Using Service-Mesh Architecture*](https://csrc.nist.gov/pubs/sp/800/204/a/final) * [NIST SSDF (SP 800-218)](https://csrc.nist.gov/pubs/sp/800/218/final) * [GitHub Actions security hardening](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions) * [Docker, *Docker Engine Security*](https://docs.docker.com/engine/security/) * [Kubernetes, *Network Policies*](https://kubernetes.io/docs/concepts/services-networking/network-policies/) * [Kubernetes, *Pod Security Standards*](https://kubernetes.io/docs/concepts/security/pod-security-standards/) * [Linux kernel documentation, *Seccomp BPF*](https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html) * [SLSA specification](https://slsa.dev/spec/v1.0/) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Execution Sandboxing > 🔑 **Key Takeaway**: Execution sandboxing reduces blast radius by running > automation in ephemeral least-privilege environments and enforcing isolation > across process, filesystem, identity, and network, with stronger boundaries > for higher-risk workflows. Execution sandboxing means running workloads inside controlled boundaries so that compromise of a job, script, or tool does **not** become compromise of your platform. In DevSecOps, this applies to: * CI jobs and build/test pipelines * package manager hooks and third-party actions * deployment automation and release tooling * developer scripts and internal bots * AI-enabled automation (one category of tool execution) ### Core security properties A production-grade sandbox should provide: 1. **Isolation**: workload cannot freely access host resources or adjacent tenants. 2. **Least privilege**: runtime identity and tokens are scoped to minimum required actions. 3. **Constrained side effects**: filesystem, network, and API access are explicitly bounded. 4. **Ephemerality**: runtime is short-lived and reset between jobs. 5. **Auditability**: execution is logged with enough detail for incident response. ### Boundary design: what to isolate Treat these as separate enforcement planes: | Plane | Typical risks | Required controls | | --------------- | ------------------------------------- | -------------------------------------------------------------- | | Process/syscall | container escape, host tampering | seccomp, no `--privileged`, capability drops, AppArmor/SELinux | | Filesystem | credential theft, workspace poisoning | read-only rootfs, isolated workspace, explicit writable mounts | | Identity | token abuse, cloud account takeover | short-lived credentials, OIDC federation, scoped IAM | | Network | data exfiltration, lateral movement | default-deny egress, destination allowlist, proxy/inspection | | Resources | denial of service, budget burn | CPU/memory/pids/time limits, quotas, max concurrency | ### Choosing the runtime isolation level | Runtime option | Isolation strength | Operational overhead | Typical fit | | ------------------------------------------------- | ------------------ | -------------------- | ----------------------------------------------------------- | | Standard containers | Moderate | Low | Low-risk build/test steps with strict hardening | | Hardened containers (rootless + seccomp/AppArmor) | Moderate-strong | Medium | Most CI validation workflows | | Sandboxed containers (gVisor/Kata) | Strong | Medium-high | Untrusted code in shared infrastructure | | MicroVMs (Firecracker) | Strong | High | High-risk multi-tenant runners and privileged pipelines | | Full VMs | Strongest boundary | High | Regulated workloads or high-impact deployment/signing paths | ### CI/CD-specific patterns #### 1) Split trust zones * **Zone A: Untrusted PR validation** (forks, external code) * no long-lived secrets * restricted CI token permissions * no deploy/publish capability * **Zone B: Trusted branch/release** * controlled secret access * protected environments and approvals * provenance + signing requirements #### 2) Use ephemeral runners Each job should run on fresh infrastructure and be destroyed after completion. Avoid shared mutable state and persistent credentials between jobs. #### 3) Restrict privileged paths Build, sign, publish, and deploy should be distinct stages with explicit policy gates and auditable approvals. ### Common failure modes * Treating “containerized” as automatically secure. * Running untrusted PR code on persistent or privileged runners. * Reusing static secrets in CI variables. * Allowing unrestricted egress from build jobs. * Granting broad default CI token permissions. ### References * [NIST SP 800-190, *Application Container Security Guide*](https://csrc.nist.gov/pubs/sp/800/190/final) * [NIST SP 800-53 Rev. 5, *Security and Privacy Controls*](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) * [Docker, *Docker Engine Security*](https://docs.docker.com/engine/security/) * [Kubernetes, *Pod Security Standards*](https://kubernetes.io/docs/concepts/security/pod-security-standards/) * [Linux kernel documentation, *Seccomp BPF*](https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html) * [gVisor documentation](https://gvisor.dev/docs/) * [Kata Containers documentation](https://github.com/kata-containers/documentation) * [Firecracker documentation](https://github.com/firecracker-microvm/firecracker/tree/main/docs) *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Isolation > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation) * [Execution Sandboxing](/devsecops/isolation/execution-sandboxing) * [Capability-Based Isolation](/devsecops/isolation/capability-based-isolation) * [Sandboxing for Tool Execution](/devsecops/isolation/sandboxing-for-tool-execution) * [Network & Resource Isolation](/devsecops/isolation/network-and-resource-isolation) * [Sandboxing & Policy Enforcement](/devsecops/isolation/sandboxing-and-policy-enforcement) * [Execution Sandboxing: A Practical Guide](/devsecops/isolation/execution-sandboxing-practical-guide) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Network & Resource Isolation > 🔑 **Key Takeaway**: Treat network and compute as hard containment boundaries: deny egress by default, > segment trust zones to prevent lateral movement, and enforce strict resource limits to block abuse > and runaway jobs. Network and compute controls are critical containment layers for sandboxed execution. Without them, a compromised build or tool can: * exfiltrate source code and secrets * scan internal services and pivot laterally * abuse infrastructure through runaway jobs * create cost spikes via unbounded resource usage ### Network isolation model #### 1) Default deny egress Start with no outbound access. Add explicit allow rules only for required destinations (SCM host, package registries, artifact storage, approved APIs). #### 2) Separate trust zones Use distinct network boundaries for: * untrusted PR validation * internal trusted builds * release/deploy pipelines Do not allow direct network paths from untrusted workloads to sensitive control planes. #### 3) Constrain DNS and metadata access * Restrict DNS resolvers and block arbitrary external name resolution where feasible. * Deny access to cloud metadata endpoints from untrusted jobs unless explicitly required. #### 4) Centralize outbound controls For mature environments, route egress through policy-enforcing gateways/proxies to monitor and block prohibited destinations. ### Resource isolation model Enforce limits at runner and workload level: * CPU and memory limits per job/container * process count (`pids`) limits * filesystem and artifact size limits * execution timeout limits * concurrency limits per workflow/repository These controls are both security and reliability controls. ### CI/CD implementation checklist * [ ] Untrusted jobs run in isolated runner pool * [ ] Default-deny egress applied to untrusted zone * [ ] Destination allowlists documented per pipeline stage * [ ] Metadata service access restricted * [ ] CPU/memory/pids limits configured * [ ] Job and step timeouts enforced * [ ] Max artifact/log size capped ### Example control matrix | Workload type | Egress policy | Resource policy | | ------------------ | ----------------------------------------------- | ------------------------------------ | | Fork PR validation | deny-by-default, minimal allowlist | strict CPU/memory/time limits | | Internal CI build | allow required registries/APIs only | moderate limits, queue controls | | Release/deploy | highly specific allowlist to deployment targets | conservative limits + approval gates | ### Common anti-patterns * “Allow all egress” for convenience in CI. * Reusing a single runner network profile for all trust levels. * Missing job timeouts (infinite loops become outages). * Unlimited artifact uploads from untrusted workflows. ### References * [NIST SP 800-190, *Application Container Security Guide*](https://csrc.nist.gov/pubs/sp/800/190/final) * [NIST SP 800-53 Rev. 5 (network and resource control families)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) * [Kubernetes, *Network Policies*](https://kubernetes.io/docs/concepts/services-networking/network-policies/) * [Kubernetes, *Resource Management for Pods and Containers*](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) * [Docker, *Docker Engine Security*](https://docs.docker.com/engine/security/) * [gVisor documentation](https://gvisor.dev/docs/) * [Firecracker documentation](https://github.com/firecracker-microvm/firecracker/tree/main/docs) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Sandboxing & Isolation > 🔑 **Key Takeaway**: Assume execution can be untrusted and apply layered > containment across identity, runtime, filesystem, network, and resources, > increasing isolation strength with workload risk. This section is the DevSecOps guide for **running untrusted or semi-trusted execution safely**: CI jobs, pull request validation, build scripts, plugins, package hooks, internal automation, and AI agents (as one automation category among many). The core objective is simple: **assume compromise can happen, then contain blast radius by design**. ### What to protect (threat model quickstart) Treat sandboxing decisions as a threat-modeling exercise across four dimensions: | Dimension | Questions to answer | | ------------ | --------------------------------------------------------------------------------------------------------------------------- | | Assets | What can be stolen or modified? (source code, signing keys, CI secrets, deployment credentials, artifacts, production APIs) | | Entry points | What can trigger execution? (fork PRs, dependencies, build scripts, test fixtures, webhooks, external APIs) | | Privileges | What authority does runtime hold? (filesystem write, network egress, cloud IAM, package publish, deployment rights) | | Impact | What is worst-case outcome? (secret exfiltration, artifact tampering, lateral movement, production change, financial loss) | **Default assumption:** code from external contributors, third-party actions, and newly introduced dependencies are untrusted until verified. ### Decision tree: choose isolation depth Use this practical decision flow before assigning a runtime: 1. **Does the workload process untrusted input or untrusted code?** * If yes, run in an ephemeral sandbox (container with hardened profile at minimum; microVM/VM for higher assurance). 2. **Can the workload access secrets, signing keys, cloud credentials, or production systems?** * If yes, enforce stronger isolation boundary, short-lived credentials, and explicit approval gates. 3. **Is outbound network required?** * If no, deny all egress. * If yes, allowlist destinations and force traffic through inspection/proxy controls. 4. **Can it modify persistent state (artifact repo, registry, infra, chain, database)?** * If yes, require policy checks + attestation + auditable identity before execution. 5. **Is this multi-tenant shared runner infrastructure?** * If yes, isolate per job with ephemeral workers and avoid secret reuse across jobs. If you answer “yes” to multiple high-risk questions, prefer **microVM/VM isolation plus strict policy enforcement**. ### Layered control map (defense in depth) No single mechanism is sufficient. Apply multiple layers together: | Layer | Control objective | Typical controls | | ---------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------ | | Identity | Bind execution to least privilege identity | OIDC federation, short-lived tokens, scoped IAM roles | | Execution boundary | Prevent host escape / cross-tenant impact | seccomp, AppArmor/SELinux, rootless containers, gVisor/Kata/Firecracker | | Filesystem & secrets | Prevent sensitive data exposure | read-only rootfs, isolated workdir, mounted secret scopes, no long-lived credentials | | Network | Prevent exfiltration and lateral movement | default-deny egress, DNS restrictions, NetworkPolicy, egress proxy | | Resource governance | Prevent abuse and runaway cost | CPU/memory/pids/time limits, quotas, job timeout, concurrency caps | | Integrity & provenance | Detect tampering and unauthorized changes | signed artifacts, provenance attestations, immutable logs, SLSA controls | | Policy & response | Enforce and verify continuously | policy-as-code gates, runtime audit logs, alerting, incident playbooks | ### Baseline controls for CI/CD and runners At minimum, enforce the following: * Separate **untrusted PR runners** from trusted build/deploy runners. * Use **ephemeral runners** (fresh environment per job, no state reuse). * Disable or heavily constrain secrets for forked PR jobs. * Restrict CI token scopes to least privilege (`read` by default). * Deny outbound network by default; allow only required hosts. * Run with syscall and privilege restrictions (`seccomp`, no privileged mode, no host mounts unless strictly required). * Sign and attest release artifacts before publish/deploy. ### Start here (section map) * [Execution Sandboxing](/devsecops/isolation/execution-sandboxing) — principles and runtime design choices. * [Execution Sandboxing: A Practical Guide](/devsecops/isolation/execution-sandboxing-practical-guide) — implementation blueprint for teams and platforms. * [Network & Resource Isolation](/devsecops/isolation/network-and-resource-isolation) — egress controls, quotas, and anti-exfiltration patterns. * [Sandboxing for Tool Execution](/devsecops/isolation/sandboxing-for-tool-execution) — controlling high-risk tool calls and side effects. * [Capability-Based Isolation](/devsecops/isolation/capability-based-isolation) — breaking broad permissions into constrained capabilities. * [Sandboxing & Policy Enforcement](/devsecops/isolation/sandboxing-and-policy-enforcement) — integrating policy-as-code with runtime isolation. ### References * [NIST SP 800-190, *Application Container Security Guide*](https://csrc.nist.gov/pubs/sp/800/190/final) * [NIST SP 800-53 Rev. 5, *Security and Privacy Controls*](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) * [Linux kernel documentation, *Seccomp BPF*](https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html) * [Docker, *Docker Engine Security*](https://docs.docker.com/engine/security/) * [Kubernetes, *Pod Security Standards*](https://kubernetes.io/docs/concepts/security/pod-security-standards/) * [SLSA specification](https://slsa.dev/spec/v1.0/) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Sandboxing & Policy Enforcement > 🔑 **Key Takeaway**: Policy decides what may run and sandboxing limits damage if it fails, > so both must be enforced before, during, and after execution to close control gaps. Sandboxing and policy enforcement solve different problems and must be used together: * **Policy** decides what should be allowed. * **Sandboxing** limits damage when allowed actions fail, are abused, or are bypassed. Using only one layer leaves material gaps. ### Three policy checkpoints | Checkpoint | Purpose | Typical examples | | -------------- | -------------------------------------------- | -------------------------------------------------------------- | | Pre-execution | block unsafe configuration before run starts | deny privileged runner flags, deny forbidden workflow triggers | | Runtime | enforce constraints during execution | seccomp/AppArmor, pod security admission, network policy | | Post-execution | verify integrity before promotion/deploy | signature verification, provenance checks, policy attestations | ### CI/CD control stack A practical stack for pipelines: 1. **Workflow policy** * lint and validate pipeline definitions * require least-privilege token settings 2. **Runner/runtime policy** * enforce non-privileged execution * require sandbox profile and resource limits 3. **Artifact/release policy** * enforce signed artifacts and provenance before publish/deploy 4. **Environment policy** * require approvals for production mutation paths ### Threat-to-control mapping | Threat | Policy control | Sandbox control | | ---------------------- | ---------------------------------------------- | ------------------------------------------- | | Secret exfiltration | deny secret injection into untrusted workflows | filesystem isolation + egress allowlist | | Runner compromise | deny privileged execution configs | syscall filtering + ephemeral runner | | Supply-chain tampering | require trusted source and attestation | isolated build runtime + immutable logs | | Unauthorized deploy | branch/environment approvals | isolated deploy runner with scoped identity | ### Maturity model #### Level 1 (baseline) * static policy checks for CI configuration * isolated runners for untrusted PRs * least-privilege CI tokens #### Level 2 (intermediate) * runtime admission/enforcement policies * default-deny network egress * short-lived credentials via federation #### Level 3 (advanced) * signed provenance verification on promotion * policy decision logging with centralized audit * periodic control validation exercises (breakout tests/tabletops) ### Common anti-patterns * Writing policy that is never enforced at runtime. * Treating sandbox exceptions as permanent defaults. * Failing open when policy engine is unavailable. * Skipping auditability for policy decisions. ### References * [NIST SP 800-53 Rev. 5 (policy, audit, and access controls)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) * [NIST SP 800-190, *Application Container Security Guide*](https://csrc.nist.gov/pubs/sp/800/190/final) * [NIST SSDF (SP 800-218)](https://csrc.nist.gov/pubs/sp/800/218/final) * [Kubernetes, *Pod Security Standards*](https://kubernetes.io/docs/concepts/security/pod-security-standards/) * [Kubernetes, *Admission Controllers*](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) * [SLSA specification](https://slsa.dev/spec/v1.0/) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' ## Sandboxing for Tool Execution > 🔑 **Key Takeaway**: Every tool invocation should pass policy, run in a > constrained sandbox, and leave auditable evidence, with stronger gates > for high-impact actions like deploy, merge, and publish. Tool execution is where automation becomes real-world side effects: file changes, API mutations, infrastructure updates, deployments, or financial transactions. This is often the highest-risk path in DevSecOps workflows. ### Design principle Treat every tool call as an untrusted request until it passes policy checks. A secure flow is: 1. **Intent validation** (is this action allowed?) 2. **Capability check** (does this runtime identity hold required permission?) 3. **Sandboxed execution** (bounded filesystem/network/resources) 4. **Audit and verification** (what happened, by whom, with what result?) ### Tool risk tiers | Tier | Example actions | Minimum controls | | -------- | -------------------------------------------- | ------------------------------------------------------------------ | | Low | read repo files, query status APIs | read-only tokens, no secret access | | Medium | create PR comments, upload artifacts | scoped write perms, output size limits | | High | merge, deploy, publish package, modify infra | approval gates, protected environment, strong sandbox | | Critical | key usage, signing, production data mutation | dedicated isolated runtime, multi-party approval, full audit trail | ### Practical controls #### Restrict execution context * run tool calls in ephemeral runtime * use read-only root filesystem where feasible * block host mounts unless explicitly required * apply seccomp/AppArmor/SELinux enforcement #### Restrict identity and credentials * issue short-lived, scoped credentials * bind tokens to specific tool purpose and environment * disable ambient credentials in untrusted workflows #### Restrict network side effects * deny-by-default egress * allowlist specific endpoints per tool * block direct access to internal admin APIs from low-trust jobs #### Restrict invocation behavior * maximum execution time * command/input/output size limits * prevent recursive tool chaining unless explicitly allowed * require explicit confirmation for high-risk operations ### Policy examples for CI/CD tooling * “Untrusted PR jobs may run read-only analysis tools but cannot trigger deployment tools.” * “Release tooling may publish only signed artifacts generated in the same pipeline.” * “Infrastructure mutation tools require protected branch + approval + provenance verification.” ### Common anti-patterns * Directly mapping user input to shell execution without policy mediation. * Reusing broad admin credentials across multiple tools. * Allowing tool calls to inherit unrestricted network access. * Missing audit logs for high-impact tool operations. ### References * [NIST SP 800-53 Rev. 5 (least privilege, audit, execution controls)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) * [NIST SP 800-190, *Application Container Security Guide*](https://csrc.nist.gov/pubs/sp/800/190/final) * [Linux kernel documentation, *Seccomp BPF*](https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html) * [Docker, *Docker Engine Security*](https://docs.docker.com/engine/security/) * [Kubernetes, *Pod Security Standards*](https://kubernetes.io/docs/concepts/security/pod-security-standards/) * [Firecracker documentation](https://github.com/firecracker-microvm/firecracker/tree/main/docs) * [gVisor documentation](https://gvisor.dev/docs/) *** ## Champions {/* This file is a duplicate of the CONTRIBUTING.md at the root level. Both files contain the same content: the root-level file is there to be highlighted in the repository dashboard, while this copy is used to render the content on the website. This file is automatically synced to the root level CONTRIBUTING.md during the build process (stripped of MDX-specific elements). ⚠️ When making changes, only edit this file - the root CONTRIBUTING.md will be updated automatically when running the build command. */} import { ContributeFooter, TagFilter, TagProvider, MermaidRenderer } from '../../../components' ## **Contributing guidelines** The Security Frameworks is an open and collaborative initiative. Whether you are part of the Security Alliance or not, we welcome your contributions. Help us build the documentation and improve security in the blockchain ecosystem. This handbook is designed for easy collaboration and automatic deployment through continuous integration. If you'd like to join our effort, feel free to fix typos, contribute new sections, or propose enhancements. If you want to take on a more active role for a specific domain, see [Framework Stewardship](/contribute/stewards). **Before contributing, please read our [Code of Conduct](https://github.com/security-alliance/frameworks/blob/develop/CODE_OF_CONDUCT.md)** to ensure that all interactions remain respectful, inclusive, and constructive. **Before contributing to SEAL Certifications** specifically, please read the [SEAL Certifications Contributing Guide](/certs/contributions.mdx) for details on the certification framework and project specifics. Join our [Discord](https://discord.gg/securityalliance) server, let others know what you are working on in the `frameworks-contribs` group channel, and collaborate with other contributors writing about related topics. ### Live versions The source code for the Security Frameworks is hosted on GitHub: [github.com/security-alliance/frameworks](https://github.com/security-alliance/frameworks). * The **main branch** powers the stable Frameworks website ([https://frameworks.securityalliance.org/](https://frameworks.securityalliance.org/)) with reviewed and finalized content. * The **development branch** ([https://frameworks.securityalliance.dev/](https://frameworks.securityalliance.dev/)) contains ongoing updates, new sections, and draft content. When contributing, **please submit your Pull Requests to the development branch**. Once changes are reviewed and approved, they will periodically be merged into the **main branch** for publication on the stable site. ### Ways to contribute There are several ways to contribute, depending on your preference and the scope of your changes. First, check existing PRs or branches to make sure your work has not been previously submitted. If you are unsure whether your idea is a new page, a section under an existing page, or a whole new framework, open an issue or reach out on [Discord](https://discord.gg/securityalliance) before you start writing. We are happy to help you scope it. #### 1. Quick edits * Use the **"Contribute today!"** button at the bottom of any page. * Make fixes, formatting, and clarifications, favoring major modifications over just a few grammar mistakes. * Changes go through GitHub's web interface without requiring local setup. #### 2. Add a new page or expand an existing one This covers writing a new page, adding a section to an existing page, or rewriting existing content. The [`template.mdx`](https://github.com/security-alliance/frameworks/blob/develop/docs/pages/config/template.mdx) is the starting point for any new page. It lays out the required sections (key takeaway, intro, the basics, your content, further reading), the optional ones, the frontmatter rules, and the import paths. The structure is the same one used across every page on the site, which is what makes the Frameworks readable as a whole rather than as a pile of individual contributions. Open it before you start writing, even if you are only adding a section to an existing page, since the same structural rules apply. **Keep each page focused on a single topic.** If your content would require more than 5-6 top-level sections (## headings), it is covering too much ground in one place. Split it into separate pages within a framework folder, one page per major angle of the topic. Each sub-page should be self-contained enough that a reader can land on it directly without needing to read the others first. The workflow: 1. **Fork the repository** to your own GitHub account. For how to set up the project locally, see [Development environment setup](#development-environment-setup) below. 2. **For a new page**, copy `template.mdx` into the relevant framework folder under `docs/pages/`, replace the placeholder content, and follow the instructions inside it. **For changes to an existing page**, edit the file directly; the same structural and frontmatter rules apply. 3. **Make your changes** in MDX on your fork. Add yourself to the file's `contributors` field in the frontmatter, and create your profile in [`docs/pages/config/contributors.json`](https://github.com/security-alliance/frameworks/blob/develop/docs/pages/config/contributors.json) if you do not already have one. This is how attribution works on the site. 4. **Update the sidebar** (`vocs.config.tsx`) so your new page appears in site navigation. New content should always be added with the `dev: true` flag, which keeps it on the development site only. Reviewed content gets promoted to the stable site periodically when we merge `develop` into `main`. See [Sidebar / Navigation](#sidebar--navigation) below. 5. **Run the build locally** to make sure everything renders without errors. See [Error checking](#error-checking). 6. **Open a Pull Request against the `develop` branch.** Use the Cloudflare Pages preview linked from the PR to verify the rendered site and make any final adjustments before review. All feedback and discussion should stay on the PR itself. 7. **Notify reviewers** by tagging the relevant steward (you can find stewards on the [Spotlight Zone](/contribute/spotlight-zone) page, listed alongside the framework they own) or a maintainer, and request reviews directly in your PR. You can also paste your PR in the `frameworks-contribs` Discord channel for additional visibility. 8. Once reviewed and approved, your changes will be merged into `develop`. Periodically, reviewed content from `develop` is merged into `main` for the stable site. **⚠️ Please sign and verify all commits.** If you have unsigned commits, follow the [Fixing unsigned commits](#fixing-unsigned-commits) section below to update them. #### 3. Add a new framework A framework is a domain of security knowledge with enough depth and structure to warrant its own dedicated space on the site, an introduction, a set of pages covering different angles of the topic, and a steward who maintains it over time. Adding one is a bigger commitment than a single page, but it is also how the Frameworks grow. The workflow is the same as [adding a new page](#2-add-a-new-page-or-expand-an-existing-one) above, with these extra steps at the start: 1. **Create a new folder** at `docs/pages//`. Use kebab-case (only normal dashes, no underscores or other separators). 2. **Write `overview.mdx`** in that folder using the [page template](https://github.com/security-alliance/frameworks/blob/develop/docs/pages/config/template.mdx). The overview introduces the framework as a whole and lists every sub-page in the framework with a brief description. The template's "Overview pages only" comment shows the format. 3. **Write the framework's other pages**, each one using the same template. 4. **Run the build command.** Beyond the usual error checking, this also generates the auto-generated index file your new framework needs to display correctly. Look at the existing frameworks under `docs/pages/` for examples of how pages are organized within a framework, how the overview ties them together, and how internal cross-links are structured. From there, follow the rest of the page-contribution workflow above (sidebar registration, attribution, PR, review). #### Want to take on more? If you are interested in a framework that does not currently have an active steward, you can become one yourself. See the [Stewards guide](/contribute/stewards) for details on responsibilities, the open frameworks looking for stewards, and how to get started. ### Development environment setup Choose the development approach that works best for you: #### Option A: DevContainer with VSCode The easiest way to get started is to use our pre-configured devcontainer with VSCode: 1. **Prerequisites**: VSCode with [Dev Containers extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) 2. **Open the project**: VSCode will detect the devcontainer configuration 3. **Reopen in container**: Command Palette (Ctrl+Shift+P) → "Dev Containers: Reopen in Container" 4. **Start developing**: All tools are pre-installed and ready to use #### Option B: DevContainer CLI Only (No VSCode Required) Since you won't require extensions for the initiative to work, you can just create a devcontainer using the CLI and access it through whatever means suit you best. **Using DevContainer CLI (Recommended):** * Install [DevContainer CLI](https://github.com/devcontainers/cli) ```bash git clone https://github.com/security-alliance/frameworks.git cd frameworks && git checkout develop devcontainer up --workspace-folder . devcontainer exec --workspace-folder . bash # Get the IP address of the container, by running `hostname -I | awk '{print $1}'`. Should be printed automatically in the terminal after the creation as well # Inside container: pnpm exec just serve # Access the docs at http://:5173 ``` #### Option C: Local installation If you prefer to install dependencies locally on your machine: **Prerequisites:** * Node.js (v22 or later) and pnpm (for running Vocs locally) * [markdownlint-cli2](https://github.com/DavidAnson/markdownlint-cli2) (For linting markdown files) * [Docker](https://docs.docker.com/get-docker/) (Optional: For running the devcontainer) * [GitHub CLI](https://cli.github.com/) (Optional: For using `gh` to interact with GitHub) **Setup:** 1. Install all prerequisites listed above 2. Clone the repository: ```bash git clone https://github.com/security-alliance/frameworks.git cd frameworks && git checkout develop ``` 3. **Install Node.js dependencies:** ```bash pnpm install ``` 4. Start the local development server ```bash pnpm exec just serve ``` 5. Once the server is running, access the site on port `5173`. **(Optional) Authenticate with GitHub CLI**: The GitHub CLI (`gh`) is already preinstalled in the devcontainer. You can authenticate by running `gh auth login` in the terminal, making it easy to interact with GitHub directly from your development environment. ### Page requirements The [page template](https://github.com/security-alliance/frameworks/blob/develop/docs/pages/config/template.mdx) is the source of truth for what every page should contain: required and optional sections, frontmatter rules, import paths, and writing guidance. Open it before you start writing. The sections below cover the parts of contributing that live outside the page itself: how the sidebar works, how to make sure the build passes, and the writing style we expect across all pages. #### Frontmatter Every page needs a `title`, a `description`, `tags`, and `contributors`. The shape looks like this: ```yaml --- title: "Your Page Title | Security Alliance" description: "Your description here, 140-160 characters." tags: - Engineer/Developer - Security Specialist contributors: - role: wrote users: [your-github-username] - role: reviewed users: [] --- ``` Two things worth knowing up front: * **Titles** stay under 60 characters including the `| Security Alliance` suffix; use `| SEAL` for longer titles. Avoid generic names like "Overview" or "Guide" alone. * **Contributors are managed centrally.** Your `users:` entries reference profiles in [`docs/pages/config/contributors.json`](https://github.com/security-alliance/frameworks/blob/develop/docs/pages/config/contributors.json). Add yourself there if you do not already have an entry. The full rules (description length, searchable terms, role list for tags, the auto-generation behavior for new tags, and worked examples) live in the [page template](https://github.com/security-alliance/frameworks/blob/develop/docs/pages/config/template.mdx?plain=1). #### Sidebar / Navigation Because of how we handle the `.org` and `.dev` domains in different branches, when contributing **new pages** you must also **update `vocs.config.tsx`** so that the page appears in the site's sidebar. New content should always be added with `dev: true`. Reviewed content gets promoted to the stable site periodically when we merge `develop` into `main`. Example of a category with multiple pages: ```tsx { text: 'Monitoring', // Category name visible in the sidebar collapsed: true, dev: true, // Indicates this category is in development items: [ { text: 'Overview', link: '/monitoring/README', dev: true }, // Indicates this page is in development { text: 'Guidelines', link: '/monitoring/guidelines', dev: true }, { text: 'Thresholds', link: '/monitoring/thresholds', dev: true }, ] }, ``` A new page added to an existing, already-promoted category should still be set with `dev: true`, even if the parent category does not have the flag. The `dev: true` belongs at the page level until that page is reviewed. This ensures that new content appears correctly in the site's navigation for readers on the `.dev` site while staying hidden from the stable `.org` site until ready. #### Error checking Before pushing changes, always make sure your build works without errors: * Run `pnpm exec just build` or `pnpm run docs:build` * Preview the updated content locally at port `4173` with: `pnpm exec just preview` or `pnpm run docs:preview` This helps catch build or formatting issues early so reviewers see clean contributions. ### Fixing unsigned commits If you accidentally made unsigned commits in your fork, you'll need to rewrite them so they show as **Verified** before opening a PR. #### 1. Rebase your recent commits * Understand how many commits you have to fix * Run this command, replacing `N` with the number of commits to go back (starting from the latest one): ```bash git rebase -i HEAD~N ``` #### 2. Mark commits to fix In the editor that opens: * Change `pick` → `edit` for each unsigned commit. * Save and exit. #### 3. Re-sign each commit For each commit you're editing: ```bash git commit --amend -S --no-edit git rebase --continue ``` Repeat until all commits are re-signed. #### 4. Push your changes Since history was rewritten, you need to **force-push**: ```bash git push --force ``` #### 5. Verify Check locally: ```bash git log --show-signature ``` Or look at your branch on GitHub, commits should show a green **Verified** badge. ### Style guide Wiki pages follow standard MDX. The audience of this wiki is technical, and the content should reflect that. There are many guides on technical and documentation writing you can learn from; for example, you can check [this lecture](https://www.youtube.com/watch?v=vtIzMaLkCaM) to get started. #### Writing guidelines * Write in an objective, explanatory tone; avoid unnecessary simplifications. * Use concise sentences and break down complex ideas with bullet points, tables, images, or block-quotes. * Always link your resources and verify them. * Introduce acronyms and technical jargon before using them. * Web3 changes fast; write the content to be as future-proof as possible. * Do **not** submit content entirely generated by AI; however, we recommend using it to fix grammar or phrasing. * Consider tutorials or hands-on guides for practical steps. * Use visualizations (mermaid, diagrams, tables) to clarify concepts. * Add recommended reading or dependencies at the top of a page if relevant. * Focus on delivering credible, formal, technical content without unnecessary high-level introductions; use examples, comparisons, or anecdotes to clarify complex topics. #### Content standardization * Use **American English** consistently. * Follow consistent terminology, capitalization, and nomenclature (see [Ethereum.org style guide](https://ethereum.org/contributing/style-guide/content-standardization)). * Usage of images and visualizations is encouraged. If you are using an image created by a third party, make sure its license allows it and provide a link to the original. For creating your own visualizations, we suggest [excalidraw.com](https://github.com/excalidraw/excalidraw). * Feel free to use [emojis](https://docsify.js.org/#/emoji?id=emoji) or [icons](https://icongr.am/fontawesome) where it fits, for example in block-quotes. #### Visual representation / drawings * Like GitHub, we also support Mermaid! You can use codeblocks using the `mermaid` keyword, and you can create beautiful graphical representations. There's a [playground](https://www.mermaidchart.com/play#pako\:eNqrVkrOT0lVslIqyExVKMksyUlVCM9ILFEIy89JSc3NLypRSMlPLc5TL1HISCxLtY_JU4CBGCW3IE9XP5fgGCUFKwUjVBlHX0-fSLCEMYqEn3-wK1jYxDQmT6kWAEyMIfc) where you can jump straight to draw! * Adding images is welcome and encouraged. Please follow the steps below to include them correctly: 1. After making your changes and opening a PR, add the images you want to include in the PR's comments (by uploading them directly) 2. During the review, a maintainer will upload your images to our S3 bucket and reply with the links you should use. 3. Once you receive the new links, update your PR to add the images' links. > ⚠️ Please do not add images directly to the repository. > This helps us avoid bloating the Git history and ensures all images follow our standardized storage and delivery method. #### Linking resources * Prefer descriptive names for external links (e.g., `inevitableeth.com` instead of "this wiki"). * Avoid overwhelming readers with too many inline links; consider a **Resources** section at the bottom. * Use relative paths for internal links and heading IDs for specific sections. * Provide archived mirrors or snapshots for important external references. #### In-page notices * Use block-quote notices at the top of pages for context. * **Incomplete pages** should include a stub notice: > ⚠️ This article is still in progress. Help the framework by contributing and expanding it. Pages with minimal content which need more work to cover the topic need to include a notice: > ⚠️ This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia\:Stub), help the framework by > [contributing](/contribute/contributing) and expanding it. ### Anything else? This page is also open for contributions. Suggest improvements to our style and guidelines in the GitHub repo. ### About this page Originally inspired by the [Ethereum Protocol Fellows](https://github.com/eth-protocol-fellows/protocol-studies). *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Contribute > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Contributing Guide](/contribute/contributing) * [Spotlight Zone](/contribute/spotlight-zone) * [Framework Stewardship](/contribute/stewards) import { Contributors, ContributeFooter, TagFilter, TagProvider, BadgeLegend } from '../../../components' ## Spotlight Zone This is the current list of individuals who have made substantial contributions to the project and deserve recognition. To understand what each badge represents, refer to the [Badge Legend](#badge-legend) at the bottom of this page. *** import { ContributeFooter, TagFilter, TagProvider } from '../../../components' ## Stewardship ### What is a Framework Steward? A framework steward is the resident expert for one (or more) of the security domains covered by the [Security Frameworks](https://frameworks.securityalliance.org). The role is a natural extension of contribution: stewards are people who have demonstrated genuine depth in a specific area, through the content they've written or reviewed, and who SEAL trusts to maintain the quality and direction of that domain going forward. It is a technical role, but also a community one. Stewards bring a sense of ownership to their domain, and being embedded in the contributor community often leads to finding and connecting with people who care deeply about the same problems. ### Why become a steward? Because what gets written here is what practitioners across Web3 will actually read and rely on. When you become a steward, your approval is required before anything merges into your framework. That is real influence over what the community considers best practice, not in a symbolic way, but in a direct, technical one. Beyond that: the people you will meet are worth it. The stewards community is small and deliberately kept that way. These are security professionals who care enough about the ecosystem to put time into building something that matters. And finally, your work here compounds. The Security Frameworks are a living resource that practitioners, teams, and organizations will keep coming back to. The depth you bring to your framework keeps getting read long after the initial contribution. ### How the role is earned Most stewards got here because they genuinely cared about a topic and wrote something useful. The role is a recognition of that, not a prerequisite for it. There is no application form. The typical path looks like this: 1. A contributor writes or reviews content for a specific framework, either independently or as part of a broader effort. 2. We notice the quality and depth of that work, or the contributor reaches out expressing interest in a more active role. 3. If there is mutual trust and the fit is clear, we designate them as steward: they are added to the [contributors database](https://github.com/security-alliance/frameworks/blob/develop/docs/pages/config/contributors.json) with the `Framework-Steward` badge, and they get their own entry in the [Spotlight Zone](/contribute/spotlight-zone), the public-facing recognition page where stewards are listed alongside the frameworks they own. If you are interested, the most direct path is to start contributing to the framework you care about. You can also reach out on [Discord](https://discord.gg/securityalliance) if you want to discuss it first. ### Responsibilities Once designated as steward for a framework, your responsibilities are focused: * **Review incoming contributions**: When a pull request touches your framework, you will be tagged as a required reviewer. The PR will not be merged without your approval. You become the quality and accuracy gate for your domain. * **Help grow the framework**: The Security Frameworks are a work in progress, and many domains still have room to grow. If you know people with the right expertise, bring them in, whether as contributors to your framework or to the project more broadly. The goal is to make these frameworks as broad and battle-tested as possible, and stewards are well-positioned to make that happen. * **Advise on structural decisions**: When changes that affect the organization or direction of the repo are being considered, stewards are consulted as domain experts. Your input carries weight on decisions that touch your framework. ### What this looks like in practice **On GitHub**: You are tagged as a required reviewer on any PR that touches your framework. Nothing merges without your sign-off. **On Discord**: Our [Discord server](https://discord.gg/securityalliance) has a dedicated stewards channel. You will be added to it and pinged when a relevant PR comes in, when we want your perspective on something, or when you want to share something more privately before it goes to the broader community. It is also where you will meet the other stewards, a small group of people who are genuinely invested in Web3 security and often worth knowing. **On the Spotlight Zone**: Your stewardship is publicly recognized on the [Spotlight Zone](/contribute/spotlight-zone) page, where your profile appears alongside the framework you own. ### Open frameworks The following frameworks are currently looking for a steward. If any of these match your expertise, this is a good place to start: * Awareness * DevSecOps * DPRK IT Workers * Encryption * External Security Reviews * Front-End & Web App Security * Governance * IAM * Infrastructure * Multisig for Protocols * Privacy * Secure Software Development * Security Automation * Supply Chain * Threat Modeling * Treasury Operations * User & Team Security * Vulnerability Disclosure If none of these match your expertise but you see a gap that isn't covered anywhere on the site, that is worth something too. A new framework can start small, a single page or a rough outline, and grow from there through iteration. If you have a topic in mind, reach out on [Discord](https://discord.gg/securityalliance) and we can figure out together whether it makes sense to build it out. Otherwise, start contributing to whichever framework fits your background. Either way works. *** {/* This file is the template for new framework pages. Copy it as your starting point, replace the placeholder content, and remove any instructional comments before opening a PR. The structure below is a proposed layout, not a strict mold. Some sections are marked (required), every page needs these. The rest are optional building blocks; pick the ones that fit your content. Pages on this site mix conceptual, procedural, and reference material, often within the same page, and the template is meant to support that. Keep each page focused on a single topic. If your content would require more than 5-6 top-level sections (## headings), it is covering too much ground in one place. Split it into separate pages within a framework folder, one page per major angle of the topic. Each sub-page should be self-contained enough that a reader can land on it directly without needing to read the others first. Do NOT remove the imports and the components below (e.g. or ). They are required for every page to render correctly. For the full contribution workflow (environment setup, signed commits, sidebar updates, build commands), see docs/pages/contribute/contributing. Heading hierarchy: # for the page title, ## for sections, ### for subsections. Never skip levels (e.g., jumping from ## directly to ####), as it breaks the table of contents and screen-reader navigation. */} {/* ============================================================================ ADDING A WHOLE NEW FRAMEWORK? READ THIS. OTHERWISE SKIP TO THE IMPORT BELOW. ============================================================================ If you are contributing a single page or rewriting an existing one, this block does not apply to you. Skip ahead. If you are unsure whether your topic is a new framework, a section in an existing one, or a single page, open an issue first so we can align on scope before you start writing. If you are creating a new framework (a new folder under docs/pages/ with multiple pages), the workflow is: 1. Create a new folder: docs/pages//. Use kebab-case. Do not use underscores or any other separator. Only normal dashes are allowed. 2. Write an overview.mdx in that folder using this template. The overview page introduces the framework as a whole and ends with a "Pages" section listing every sub-page with a one-line description (see the OVERVIEW PAGES note further down in this file). 3. Write the rest of the framework's pages, each one using this template. 4. Register the new framework in the sidebar with the `dev: true` flag, so it appears on the dev site but stays off production until reviewed. 5. Run the build command. This generates the auto-generated index file and handles the other site-side artifacts your new framework needs to display correctly. 6. Reference implementation: see docs/pages/supply-chain/ as a working example of a complete framework. For full details on the workflow above (sidebar syntax, build command, signed commits, PR conventions), see docs/pages/contribute/contributing. ============================================================================ */} {/* IMPORT PATH: the '../../../components' path below works for pages placed at docs/pages/{framework-folder}/{your-page}.mdx (one level deep inside a framework folder). If your page sits one level deeper, for example docs/pages/{framework-folder}/{subfolder}/{your-page}.mdx, add one more '../' so the import becomes '../../../../components'. */} import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Title of this Page > 🔑 **Key Takeaway**: \[Required. One or two sentences a reader can walk away > with if they read nothing else. Not a summary of the page; the *point* of the > page. Avoid filler conclusions like "By doing this..." or "Having these > practices...". Prefer concrete claims over abstract ones.] \[Required. This block sits directly under the Key Takeaway with no heading of its own, so the page opens as continuous reading. Write two or three short paragraphs in plain language that introduce the topic and establish the stakes. The Frameworks are read by people at every level of expertise, from seasoned security engineers to community managers learning the basics, so do not assume the reader already knows what you are talking about. Explain what the topic is, who it affects, and why it matters in the Web3 context specifically.] ### The basics \[Required. The foundational, definitional layer. Use this section to lay out the core concepts, components, or vocabulary the rest of the page builds on. For a topic like supply chain security, this is where you would explain what makes up a supply chain in the Web3 context. For a topic like threat modeling, this is where you would explain what a threat model is and what it contains. Rename this section to something specific to your topic if a better name exists ("What Makes Up a Web3 Supply Chain", "Anatomy of a Phishing Attack", "Components of a Threat Model"), but do not skip the layer itself. A reader who is new to the topic should be oriented before any deeper content begins.] ### \[Your section title] \[Required. This is where the substance of your page lives. You are an expert on this topic; break it into the sections that make sense for what you have to teach, name them after their actual content, and write each one in the format that fits best. Use ### subsections within each one as needed. Common formats to mix and match within a section: * **Walkthrough**: numbered steps, top to bottom. Use when order matters. * **Checklist**: bullet points the reader can tick. Use when order does not matter. * **Decision tree or matrix**: table or branching guide. Use when the right answer depends on the reader's situation. * **Plain explanation**: paragraphs. Use when the content is conceptual or when format would get in the way. When discussing failure modes or common mistakes, anchor them to a specific recommendation rather than collecting them in a separate "pitfalls" section. For example: "Rotate signing keys quarterly. Teams often skip this because no incident forces it, which is exactly when key compromise causes the most damage." This keeps the warning where it is useful instead of in a generic list.] ### Real-world examples \[Optional. Include only if you can point to a specific incident, breach, post-mortem, or named scenario. Skip the section entirely if you do not have one. When you do include an example, link to the source: an incident write-up, a CISA advisory, a CVE, a post-mortem, or a credible reporting source.] {/* ============================================================================ OVERVIEW PAGES ONLY: include the "Pages" section below. If this is the overview.mdx for a framework, include a Pages section that lists every sub-page in the framework with a one-line description, like this: ## Pages 1. [Dependency Awareness](/supply-chain/dependency-awareness): managing external packages, version pinning, lockfile integrity, and protection against typosquatting. 2. [Web3 Supply Chain Threats](/supply-chain/web3-supply-chain-threats): threat vectors specific to Web3, from frontend library hijacking to infrastructure compromise. Keep this list in sync with the sidebar config when pages are added, renamed, or removed. If this is a regular sub-page (not an overview), delete this comment and skip straight to "Further Reading & Tools" below. ============================================================================ */} ### Further Reading & Tools \[Required. Two types of links belong here: 1. Related pages within the frameworks or entire frameworks. Use paths relative to your page, with a short description of why the reader would follow the link: * [Wallet Security](/wallet-security/overview): specific wallet security practices * [DevSecOps](/devsecops/overview): integrating dependency scanning into CI/CD 2. External articles, standards, or tools cited in the content. Use full URLs: * [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/) * [CISA Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) Every external claim made in the page body should be traceable to a link here or to an inline citation. Use descriptive link text. No bare URLs, no "click here", no "this article".] *** ## Using the Contributors Database This page demonstrates how to use the centralized contributors database. Instead of specifying all the contributor details in each file, you can now simply reference contributors by their ID. ### How to Reference Contributors #### Basic Contributors List In your markdown frontmatter, simply list the contributor IDs: ```markdown --- title: Your Page Title contributors: - mattaereal # Simple ID reference - fredriksvantes - zedt3ster --- ``` #### Role-Based Contributors You can also specify contributors with their roles, which will display them in organized sections: ```markdown --- title: Your Page Title contributors: - role: wrote users: [mattaereal, charlie_dev] - role: reviewed users: [fredriksvantes, zedt3ster] - role: fact-checked users: [nftdreww] --- ``` This will display contributors in three sections: "Written by", "Reviewed by", and "Fact checked by". ### Benefits of the Centralized Approach 1. **Consistency**: Contributor information is stored in one place 2. **Maintenance**: Update contributor details (avatar, GitHub, Twitter, etc.) in a single location 3. **Simplicity**: Just reference contributor IDs in your Markdown files 4. **Extensibility**: Easily add new social links or other information to the database 5. **Roles**: Assign specific roles to contributors for better attribution ### Contributors Database Location The contributors database is stored in `docs/pages/config/contributors.json`. Here's an example of what a contributor entry looks like: ```json { "mattaereal": { "name": "matta", "avatar": "https://github.com/mattaereal.png", "github": "https://github.com/mattaereal", "twitter": "https://twitter.com/mattaereal", "website": "https://theredguild.org", "features": ["lead"], "role": "Security Researcher", "description": "Initiative lead and maintainer", "company": "The Red Guild | SEAL" } } ``` ### Available Fields * `name`: Name of the contributor to display * `avatar`: URL to the contributor's avatar image * `github`: GitHub profile URL * `twitter`: Twitter profile URL * `website`: Personal website URL * `features`: Special designations (e.g., \["lead", "core", "steward", "featured"]) * `role`: Professional role or title * `description`: Short biography or description * `company`: Organization or company affiliation ### Role-Based Display When using the role-based format, contributors will be displayed in sections based on their roles. The standard roles are: * `wrote`: People who authored the content * `reviewed`: People who reviewed the content for accuracy * `fact-checked`: People who verified the factual correctness This creates a clear attribution system showing who contributed to each page in what capacity. import { TagList, ContributeFooter } from '../../../components' ## Discord For a comprehensive guide on securing your Discord server, see the [**Discord Security Guide**](/guides/account-management/discord). *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Community Management > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Community Management](/community-management/overview) * [Discord Security](/community-management/discord) * [Twitter/X Security](/community-management/twitter) * [Telegram Security](/community-management/telegram) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Community Management Communities might be key to many Web3 projects, but they also represent a significant security challenge. From casual users to top-level executives, everyone within an organization can be targeted by social engineering tactics across platforms like Telegram, Discord, X (formerly Twitter), Google, and more. When a community channel is compromised—whether by phishing, fraudulent links, or account takeovers—it can quickly become a vehicle for wider attacks, putting both users and organizational reputations at risk. Here, we present essential best practices to safeguard your community. In the following sections, we will explore platform-specific recommendations in more depth. ### Best Practices for Community Security #### Strong Passwords and Two-Factor Authentication (2FA) * Use unique, complex passwords for each service and store them securely in a reputable password manager. Refer to the [**Operational Security Framework**](/opsec/overview) and [**Wallet Security Framework**](/wallet-security/overview) for more information on this. * Secure the email account linked to your community platforms with a unique password and 2FA. * Always enable 2FA. Prefer hardware-based tokens (e.g., Yubikey) or mobile authenticator apps over SMS-based methods, which are vulnerable to SIM-swapping. * If you use an authenticator app like Authy, 1Password, or Aegis to generate time-based one-time passwords (TOTP), Ensure that the secret keys are stored encrypted and protected with robust security measures. * Configure your app to require a password, PIN, or biometric authentication (e.g., fingerprint or face recognition) to unlock access to the tokens. This prevents unauthorized access and ensures the tokens remain secure even if someone gains physical or remote access to your device. * Keep password generation and 2FA codes separate; do not use your password manager to generate 2FA codes. Otherwise, if the password manager is compromised, it could render the 2FA ineffective, allowing unauthorized access to your accounts. * Encourage community members to adopt these practices as well. #### Phishing Awareness * Educate members on recognizing and reporting phishing attempts. * Clearly communicate to community members that your team will never send the first direct message to them. This is important because attackers often impersonate team members and initiate direct messages to trick users into believing they are legitimate, thereby gaining their trust and potentially compromising their security.\ However, statements such as “will never DM first” or labels like “Official,” “Support,” or platform status indicators (e.g., premium badges) must not be treated as proof of legitimacy. * Publicly define all official communication channels and clearly state which platforms are not used.\ If a platform is unsupported, declare this alongside official links (e.g., “We do not operate a Telegram community”).\ Where possible, reserve common impersonation handles and maintain placeholder accounts that redirect users to official channels. Refer to the [**Security Awareness framework**](/awareness/overview) to learn more about social engineering techniques and security training best practices. #### Operational Security (OpSec) * Be mindful of the devices you use to manage community channels. Malware or compromised hardware can give attackers an entry point. * Regularly update software, run antivirus checks, and avoid installing untrusted applications that may compromise your security. For a comprehensive understanding of Operational Security, including additional strategies and guidelines, please refer to the dedicated [**Operational Security framework**](/opsec/overview). #### Emergency Response Plan * Prepare a clear protocol for handling security incidents, including how to quickly remove compromised accounts and warn community members. * Adopt a proactive mindset: it's not a matter of if but when a breach will occur. Having a plan in place helps you act decisively and contain damage. As part of the communication team, it is crucial to know when and how to communicate effectively during an incident. This involves understanding the appropriate timing and messaging to ensure clarity and prevent misinformation. For more insights on where this role fits within an incident, refer to the [**Incident Management framework**](/incident-management/overview). *** import { TagList, ContributeFooter } from '../../../components' ## Telegram For a comprehensive guide on securing your Telegram account and groups, see the [**Telegram Security Guide**](/guides/account-management/telegram). *** import { TagList, ContributeFooter } from '../../../components' ## X (Twitter) For a comprehensive guide on securing your X (Twitter) account, see the [**Twitter/X Security Guide**](/guides/account-management/twitter). *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Certification Guidelines This document provides guidelines for completing security certification questionnaires. It covers how to score individual control questions and when to pursue certification through self-assessment or third-party review. ### Scoring Controls Score each control as: * **Implemented**: Fully operational with verified evidence * **Partially Implemented**: Incomplete or lacks sufficient evidence * **Not Implemented**: Control absent * **N/A**: Not applicable (provide justification) ### Evidence Collection For each control scored "Implemented," provide: * Procedure documentation: Policies, versions, approval dates * Operational proof: Logs, records, tickets showing active use, interviews with team members * Testing/validation: Drill results, incident reports, test outcomes * Ownership details: Responsible party, review frequency, last update * Technical artifacts: Configurations, screenshots, system exports ### Self-Assessment The self-assessment option is suitable for organizations wishing to internally validate their security posture. Self-assessment does not grant official certification, but rather serves as an internal checkpoint to track your security posture over time. ### Third-Party Review Third-party reviews are recommended for organizations seeking formal certification, and involve an external SEAL-certified assessor evaluating your security posture. #### Certification Criteria Third-party reviewers will issue certification when: * All controls are "Implemented" or "N/A" with justification * Evidence substantiates all claims * Overall security posture meets framework requirements Any controls scored as "Partially Implemented" or "Not Implemented" must be remediated during the review process before certification can be issued. #### Review Process 1. Complete initial assessment with evidence 2. Reviewer verifies claims against submitted evidence 3. Address any findings or requests for additional documentation 4. Receive certification report with findings and recommendations import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Certified Partners ### Current Status: Request for Qualifications (RFQ) SEAL Certifications is currently in the process of establishing our certified auditor partner program. We are actively seeking qualified auditing firms to become authorized certification issuers. #### Timeline * **Now - December 31st, 2025**: RFC Phase & Auditor RFQ Period * **Q1 2026**: Begin issuing formal certifications with certified auditor partners ### Becoming a Certified Auditor SEAL will work with a select group of third-party auditing firms to provide certification audits. SEAL-certified auditors will demonstrate expertise in blockchain security and operational security practices, and will be authorized to conduct audits against the SEAL Certification Framework and issue on-chain attestations. If your firm is interested, please fill [out this form](https://securityalliance.typeform.com/CertsAuditor) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, CertifiedProtocolsWrapper } from '../../../components' ## Certified Protocols The following protocols have successfully completed SEAL certifications and received on-chain attestations via the Ethereum Attestation Service (EAS). For more details on each certification, click on the respective badges or view the relevant SFC document. import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## SEAL Certifications Changelog Revision history across all SFC certifications. Each cert carries a `version` in its page header; this page aggregates what changed, when, and why so protocols re-certifying after a revision can scope the delta quickly. ### 2026-04-17 — Feedback integration round 1 #### New * **[SFC - Identity & Accounts](/certs/sfc-identity-accounts)** (v1.0): new horizontal cert covering organizational account management — inventory (social media, email, SSO, registrar, custody, repo admin, cloud root, SaaS), phishing-resistant MFA, password manager with individual accountability, recovery methods restricted to org channels, account lifecycle, takeover monitoring, third-party access. Addresses a gap where org-account takeover (Twitter, status page, registrar) was not covered despite being a top-tier attack vector for crypto protocols. #### Retired * **SFC - Workspace Security**: retired. Its crypto-relevant content (accounts, credentials, MFA, takeover monitoring) moved to the new Identity & Accounts cert. Content on device management, EDR/MDM, BYOD, physical/travel security, formal training programs with phishing sims, insider threat assessment as standalone, and data classification was intentionally dropped as out of SEAL SME and better covered by ISO 27001 / SOC 2 / CIS. #### SFC - Multisig Operations (v1.0 → v1.1) * `ms-2.1.2` strengthened from "evaluate" to "implement" contract-level security controls. * `ms-4.1.1` transaction process consolidated from 8 bullets to 5. #### SFC - Treasury Operations (v1.0 → v1.1) * Scope note added distinguishing internal vs professional treasury operations (OTC desks, market-making, custody-as-a-service). * `tro-1.1.4` "SLAs" replaced with "timeframes". * `tro-2.1.1` impact thresholds reframed as an example scheme; review trigger broadened. * `tro-2.1.2` renamed from "fund allocation limits" to "portfolio concentration limits"; wording softened. * `tro-2.1.3` (NEW): per-actor and per-path exposure limits. * `tro-3.1.1` session timeout bullet made actionable; geographic restrictions clause dropped. * `tro-3.1.2` hardware-key MFA added for privileged credential access; owner/admin isolation line moved to `tro-3.1.5`. * `tro-3.1.5` (NEW): privileged access and root account management. * `tro-4.1.1` trusted-parser bullet added; consolidated 8 bullets to 5. * `tro-4.1.2` consolidated 4 bullets to 3. * `tro-5.1.1` "TVL history" and "insurance coverage" dropped from baseline; exposure limits softened. * `tro-6.1.1` consolidated 9 bullets to 4. * `tro-6.1.2` consolidated 7 bullets to 4. * Header pointer to SFC - Identity & Accounts added for custody platform account management. * Control count: 20 → 22. #### SFC - DevOps & Infrastructure (v1.0 → v1.1) * `di-1.1.2` supply-chain mention dropped from the baseline (supply chain is already covered substantively in Section 2). * `di-1.1.4` rewritten to cover both the tool approval process and the maintained approved-tools list in a single control; list review cadence made explicit. * `di-2.1.1` repo access review cadence tightened; account controls now reference SFC - Identity & Accounts. * `di-2.1.4` dependencies consolidated from 6 bullets to 3. * `di-3.1.1` pipeline runner hardening bullet added; consolidated to 5 bullets. * `di-4.1.1` network architecture bullet added (segmentation, minimal public exposure, firewall/security group rules). * `di-4.1.2` account controls now reference SFC - Identity & Accounts; break-glass bullets consolidated. * Control count unchanged: 16. #### SFC - DNS Registrar (v1.0 → v1.1) * `dns-3.1.1` slimmed to reference SFC - Identity & Accounts for account management; DNS-specific registrar RBAC bullet retained. #### SFC - Incident Response (v1.0 → v1.1) * Header pointer to SFC - Identity & Accounts added for org account takeover coordination. * `ir-1.1.1` IR team roles consolidated from 7 bullets to 3. * `ir-1.1.2` IR contacts consolidated from 7 bullets to 4. * `ir-2.1.1` **(NEW)**: threat model for protocol operations, including external dependencies and single points of failure (cross-chain messaging providers, oracle providers, critical infrastructure). Placed before monitoring coverage so monitoring is anchored to a known threat picture. Existing Section 2 controls shifted: previous `ir-2.1.1` → `ir-2.1.2`, `ir-2.1.2` → `ir-2.1.3`, `ir-2.1.3` → `ir-2.1.4`. * `ir-2.1.3` alerting and paging (previously `ir-2.1.2`) consolidated from 8 bullets to 4. * `ir-5.1.1` IR drills consolidated from 7 bullets to 4. #### Cross-cutting * Control IDs now rendered next to the title in each control card (UI improvement). * Account-control pattern (MFA, credential management, access reviews, lifecycle) de-duplicated out of vertical certs; Identity & Accounts is the authoritative source. DNS and DevOps reference it directly; Treasury and Incident Response carry a header pointer and retain domain-specific bullets. #### Workbook compatibility * Control IDs are stable across this revision. No renames. New controls (`tro-2.1.3`, `tro-3.1.5`, `ir-2.1.1`, all `ida-*`) will simply be unpopulated when importing old workbooks, which is expected. Shifted IR Section 2 IDs mean old `ir-2.1.1`/`ir-2.1.2`/`ir-2.1.3` data in workbooks will not align to the new IDs without manual re-mapping. * Users with saved state for Workspace Security will lose that state (that cert is removed). Other certs retain their localStorage state across the revision. import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Contributions Like the rest of Frameworks, SEAL Certifications are open-source and accept contributions from the community. However, due to the nature of Certifications, contributions are subject to more stringent review and approval processes managed by Isaac, the initiative lead, and the other Certifications maintainers. * If you have suggestions for improving existing Certifications, or ideas for a new Certification, please open an issue in the frameworks repo with the `certifications` tag. We welcome feedback and ideas from the community! * If you're a protocol interested in having your project certified, you can reach out to us through our [protocol interest form](https://securityalliance.typeform.com/CertsWaitlist). * If you're a security firm interested in becoming a SEAL-approved auditor, please reach out through our [interest form](https://securityalliance.typeform.com/CertsAuditor). For more information on contributing to SEAL Certifications, or the rest of Frameworks, please see the [Contributing Guide](/contribute/contributing). {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Certs > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [SEAL Certification Framework](/certs/overview) * [Certified Auditors](/certs/certified-partners) * [SFC: DevOps & Infrastructure](/certs/sfc-devops-infrastructure) * [SFC: DNS Registrar](/certs/sfc-dns-registrar) * [SFC: Identity & Accounts](/certs/sfc-identity-accounts) * [SFC: Incident Response](/certs/sfc-incident-response) * [SFC: Multisig Operations](/certs/sfc-multisig-ops) * [SFC: Treasury Operations](/certs/sfc-treasury-ops) * [Certification Guidelines](/certs/certification-guidelines) * [SEAL Certifications Changelog](/certs/changelog) * [Contributing to SEAL Certifications](/certs/contributions) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, ExportAllCerts } from '../../../components' ## SEAL Certification Framework SEAL Certifications is an open-source operational security certification program for crypto protocols. Smart contract vulnerabilities were once the dominant cause of crypto exploits; operational failures now dominate. Compromised signers, poorly managed multisigs, DNS takeovers, leaked credentials, unmonitored infrastructure, and missing incident response playbooks account for the majority of major incidents. Code audits don't catch these, because the code isn't the issue. SEAL Certifications target exactly this gap. The framework evaluates the operational practices that determine whether a protocol can actually defend itself, detect an incident, and respond when things go wrong. ### Certification Modules The framework covers six modules, each independently scopeable: * **[Multisig Ops](/certs/sfc-multisig-ops)** — Governance, signer security, transaction verification, emergency procedures * **[Treasury Ops](/certs/sfc-treasury-ops)** — Treasury architecture, transaction security, custody, DeFi risk management * **[Incident Response](/certs/sfc-incident-response)** — Threat modeling, monitoring, response playbooks, drills * **[DevOps & Infrastructure](/certs/sfc-devops-infrastructure)** — Development environment, source code, CI/CD, cloud infrastructure, supply chain * **[DNS & Registrar](/certs/sfc-dns-registrar)** — Domain management, DNS controls, registrar security, email authentication * **[Identity & Accounts](/certs/sfc-identity-accounts)** — Organizational account inventory, phishing-resistant MFA, credential management, takeover monitoring See the [changelog](/certs/changelog) for revision history across modules. ### How Certification Works SEAL maintains the framework and accredits auditing firms. Accredited firms perform the assessments; SEAL issues the on-chain certification. An engagement runs through five steps: 1. **Scoping.** Align on which controls apply and what infrastructure is in scope. 2. **Evidence collection.** The protocol team gathers documentation and evidence that their practices meet the framework controls. 3. **Assessment.** The firm reviews evidence against the open-source framework criteria. 4. **Remediation** (if needed). The firm provides recommendations to close any gaps. The protocol team implements fixes. 5. **Certification.** Protocols that meet the standard receive a formal on-chain attestation via the Ethereum Attestation Service (EAS), publicly and cryptographically verifiable. A typical engagement runs a few weeks. Protocols can also use the framework independently for self-assessment at any time. See [Certification Guidelines](/certs/certification-guidelines) for the full process and [Certified Auditors](/certs/certified-partners) for accredited firms. ### Program Status The framework has been validated through pilot analyses with protocols across DeFi, staking, treasury management, and infrastructure, plus feedback sessions with auditing firms and independent security researchers. Controls have been refined through that process and are now published. The program is moving from pilot validation into active certification, starting with supervised first engagements through accredited firms. ### Get Involved * **Protocols** interested in a certification engagement or a consultation with the SEAL team on the framework: [sign up here](https://securityalliance.typeform.com/CertsWaitlist). * **Auditing firms and independent security researchers** interested in becoming an accredited third-party certification issuer: [apply here](https://securityalliance.typeform.com/CertsAuditor). ### FAQ
What's the difference between self-assessments and certified audits? Self-assessments are completed by the protocol team using the SEAL Certifications framework as a guide. They help protocols internally evaluate their own security posture and identify gaps. Self-assessments are not verified by a third party. Certified audits are completed by a third-party accredited firm through SEAL's [partner program](/certs/certified-partners). The firm independently evaluates the protocol's security controls against the framework. Upon successful completion, protocols receive a formal attestation on-chain.
What is an attestation? Attestations are certificates issued on-chain through the [Ethereum Attestation Service (EAS)](https://ethereum.org/en/developers/docs/standards/tokens/eas/) by SEAL to protocols that successfully complete a certified audit. Attestations serve as verifiable proof that a protocol has met the requirements of a given SEAL certification. Attestations do not indicate a protocol is free from security issues. Blockchain security evolves continuously and novel vulnerabilities arise regularly. Attestations demonstrate that a protocol has implemented a set of standardized operational practices to manage and mitigate risk.
What if a protocol doesn't meet all the certification requirements? Protocols that don't meet all requirements receive a report from the auditor detailing the gaps. If the protocol addresses the gaps, they can work with the auditor to complete a re-assessment.
What kind of evidence is required? Evidence varies by certification and control. Protocols generally provide documentation, screenshots, or other artifacts demonstrating implementation of each control: a signer registry for multisig, incident response playbooks, DNS configuration records, and so on.
Who can see our attestation? Attestations are publicly accessible on-chain through EAS. Detailed audit reports and evidence shared during the assessment process are confidential between the protocol and the auditor.
Can we use the SEAL badge? Protocols that successfully complete a certified audit receive a badge from SEAL to display on their website or documentation.
Is there a list of certified protocols? SEAL will maintain a public list of certified protocols as the program launches.
How can auditors become accredited? SEAL accredits third-party auditing firms through a supervised first engagement. See [Certified Auditors](/certs/certified-partners) for the process.
Can a protocol lose its certification? Yes. Certifications can be revoked if a protocol is found to be non-compliant for an extended period. Certifications are also time-limited and require periodic re-assessment.
import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, CertList } from '../../../components' ## SFC - DevOps & Infrastructure The SEAL Framework Checklist (SFC) for DevOps & Infrastructure provides guidelines for securing development environments, source code management, CI/CD pipelines, and cloud infrastructure. It covers governance, supply chain security, deployment controls, and infrastructure access. *Revision {frontmatter.version} · Updated {frontmatter.revised} · [Changelog](/certs/changelog)* For more details on certifications or self-assessments, refer to the [Certification Guidelines](/certs/certification-guidelines). import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, CertList } from '../../../components' ## SFC - DNS Registrar The SEAL Framework Checklist (SFC) for DNS Registrar provides best practices for securely managing domain names and DNS configurations. *Revision {frontmatter.version} · Updated {frontmatter.revised} · [Changelog](/certs/changelog)* For more details on certifications or self-assessments, refer to the [Certification Guidelines](/certs/certification-guidelines). import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, CertList } from '../../../components' ## SFC - Identity & Accounts The SEAL Framework Checklist (SFC) for Identity & Accounts provides guidelines for managing organizational accounts (social media, email, SSO, registrar, SaaS, privileged platforms) such that account compromise cannot redirect users, funds, or trust. *Revision {frontmatter.version} · Updated {frontmatter.revised} · [Changelog](/certs/changelog)* **Scope**: This is a horizontal cert covering the cross-cutting account-management pattern that applies to multiple surfaces (domains, code, custody, social media). Other certs reference it for account-control concerns while retaining their domain-specific substance (e.g., [SFC - DNS Registrar](/certs/sfc-dns-registrar) handles DNSSEC and registry locks; this cert handles registrar account hygiene). For more details on certifications or self-assessments, refer to the [Certification Guidelines](/certs/certification-guidelines). import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, CertList } from '../../../components' ## SFC - Incident Response The SEAL Framework Checklist (SFC) for Incident Response provides structured guidelines to help teams remain prepared for security incidents affecting blockchain protocols. It covers team structure, monitoring, alerting, and response procedures. *Revision {frontmatter.version} · Updated {frontmatter.revised} · [Changelog](/certs/changelog)* **Related**: Organizational account takeover monitoring and response coordinates with [SFC - Identity & Accounts](/certs/sfc-identity-accounts) (ida-4.1.1). IR handles incident response flow; I\&A handles account-control baselines. For more details on certifications or self-assessments, refer to the [Certification Guidelines](/certs/certification-guidelines). import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, CertList } from '../../../components' ## SFC - Multisig Operations The SEAL Framework Checklist (SFC) for Multisig Operations provides best practices for managing multisig wallets securely. It covers governance, risk management, signer security, operational procedures, and emergency operations. *Revision {frontmatter.version} · Updated {frontmatter.revised} · [Changelog](/certs/changelog)* For more details on certifications or self-assessments, refer to the [Certification Guidelines](/certs/certification-guidelines). import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, CertList } from '../../../components' ## SFC - Treasury Operations The SEAL Framework Checklist (SFC) for Treasury Operations provides structured guidelines for securely managing and operating an organization's treasury covering governance, access control, transaction security, monitoring, and vendor management. *Revision {frontmatter.version} · Updated {frontmatter.revised} · [Changelog](/certs/changelog)* **Scope note**: These baselines target internal treasury operations (DAO treasuries, protocol treasuries, operational wallets). Professional treasury operations such as OTC desks, market-making, or custody-as-a-service may warrant additional or differentiated baselines beyond this scope. **Related**: Custody platform account management (phishing-resistant MFA, credential management, recovery methods, account lifecycle) is governed by [SFC - Identity & Accounts](/certs/sfc-identity-accounts). Treasury-specific controls below focus on transaction security and platform configuration. For more details on certifications or self-assessments, refer to the [Certification Guidelines](/certs/certification-guidelines). import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Core Awareness Principles > 🔑 **Key Takeaway**: Security awareness is built on fundamental principles like threat recognition, risk assessment, > and zero trust verification. These principles form the foundation of a security-conscious culture where every > individual plays a vital role in protecting organizational assets. ### Key concepts * **Threat Recognition**: Understand that threats come in various forms—phishing, social engineering, malware, and insider risks. For instance, a social media message urging immediate action might be a scam designed to exploit urgency. * **Risk Perception**: Assessing risk means evaluating both the likelihood of an attack and the potential impact. For example, if you frequently receive messages from unknown sources on a platform like Twitter, you should view these interactions with increased skepticism. * **Zero Trust Mindset**: Always verify before trusting. Even messages from familiar contacts should be confirmed if they involve unexpected requests or sensitive information. * **Filtering Credible Information**: In an era of information overload, it's critical to identify and rely on reputable sources. This means following established security blogs, official alerts from cybersecurity agencies, or verified community channels. * **Organizational Responsibility**: Security is a shared responsibility that requires commitment at all levels of the organization. Leadership must demonstrate strong commitment by prioritizing and investing in security initiatives, while every team member should understand their role in maintaining security. > **Real-World Example**: A company might receive a seemingly routine email from a "vendor" requesting updated banking > details. An employee with a strong zero trust mindset will independently verify the request through known contact > numbers or an established internal process, thereby avoiding a potential fraud. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Cultivating a Security-Aware Mindset > 🔑 **Key Takeaway**: Developing a security-aware mindset is about building habits that prioritize caution and > verification. By questioning unusual requests, pausing before acting, and leveraging peer support, you transform > security from a set of rules into an intuitive approach to daily interactions. ### Behavioral Best Practices #### Practical Tips * **Question Unusual Requests:** Always verify any request for sensitive information or financial transactions through a separate communication channel. * **Pause Before Reacting:** Take a moment to think before clicking a link or downloading an attachment. **Example:** If you get an unexpected file from a colleague, call them directly to confirm they sent it. * **Peer Verification:** Leverage your team by asking a colleague's opinion if something seems off. > **Scenario Example** > A community manager receives a direct message on Discord that looks like it comes from a well-known project partner, > asking for private credentials. Instead of immediately responding, they cross-check the message in a team meeting or via > a known contact method. ### Awareness in Community Settings #### Unique Challenges on Social Platforms * **Platform-Specific Red Flags:** Each community platform—Discord, Twitter, Telegram—has its own quirks. **Example:** On Telegram, unsolicited group invites with suspicious usernames could be phishing attempts. * **Community Role Awareness:** Moderators and administrators should be extra cautious since they have higher privileges. **Example:** A moderator on a crypto project Discord might notice a sudden spike in login attempts from an unfamiliar IP range. * **Culture of Reporting:** Foster an environment where suspicious behavior is immediately reported and discussed, not brushed aside. > **Scenario Example** > During a routine community chat, several members report receiving odd messages that urge them to click on a link. The > community manager organizes a quick session to remind members of red flags and the correct reporting channels, > reinforcing collective vigilance. ### Organizational Strategies for Security Culture * **Leadership Commitment:** Ensure that leadership demonstrates a strong commitment to security by prioritizing and investing in security initiatives. Leaders should model security-conscious behavior and allocate appropriate resources to security efforts. * **Regular Communication:** Communicate the importance of security regularly through team meetings, newsletters, and other channels. Keep security topics visible and relevant to all team members. * **Security Policies and Procedures:** Develop and enforce clear security policies and procedures that outline expectations and responsibilities for all team members. * **Encourage Reporting:** Create an environment where team members feel comfortable reporting security incidents, suspicious activities, and potential vulnerabilities without fear of retribution. * **Recognition and Rewards:** Recognize and reward team members who demonstrate exemplary security practices and contribute to the organization's security efforts. * **Continuous Improvement:** Continuously assess and improve the project's security culture through feedback, assessments, and audits. * **Shared Responsibility:** Instill a sense of responsibility for security at all levels of the project, emphasizing that security is everyone's job. * **Collaboration:** Promote collaboration and information sharing among team members to enhance overall security awareness and response capabilities. > **Scenario Example** > A project implements a monthly "Security Spotlight" where different aspects of security are highlighted, and team > members can share their experiences or ask questions. This regular touchpoint keeps security top-of-mind and encourages > ongoing dialogue about best practices. ### Essential Security Practices #### Password Management * **Strong, Unique Passwords:** Use complex, unique passwords for each account to prevent credential stuffing attacks. **Example:** A passphrase like "correct-horse-battery-staple" (with four random words) is both strong and memorable, while being more secure than shorter passwords with special characters like "P\@ssw0rd!". * **Password Managers:** Utilize a reputable password manager to securely store and generate complex passwords. **Example:** Tools like Bitwarden, 1Password, or KeePassXC can generate and store unique passwords for all your accounts. #### Multi-Factor Authentication (MFA) * **Enable MFA Everywhere Possible:** Add an extra layer of security beyond just passwords. **Example:** Even if someone obtains your password, they still can't access your account without the second factor. * **Choose Secure MFA Methods:** Hardware tokens and authenticator apps are more secure than SMS-based verification. **Example:** Use YubiKeys or authenticator apps like Authy instead of SMS, which can be vulnerable to SIM swapping attacks. #### Secure Communication * **End-to-End Encryption:** Use messaging platforms with end-to-end encryption for sensitive communications. **Example:** Signal provides strong encryption for messages, ensuring only the intended recipient can read them. * **Verify Communication Channels:** Be cautious of unexpected platform changes for important communications. **Example:** If a colleague suddenly asks to switch from your company's official channel to a personal messaging app for work discussions, verify this request directly. #### Device Security * **Keep Systems Updated:** Regularly update your operating system and applications to patch security vulnerabilities. **Example:** Schedule automatic updates or set a weekly reminder to check for and install updates. * **Secure Your Workspace:** Be mindful of physical security in shared or public spaces. **Example:** Use privacy screens when working in public and lock your device when stepping away. ### Incident Response Awareness #### Recognizing Security Incidents * **Know the Warning Signs:** Understand what constitutes a potential security incident. **Example:** Unexpected account lockouts, strange system behavior, or unusual access requests could indicate a breach. * **Immediate Actions:** Know what steps to take when you suspect a security incident. **Example:** Disconnect from networks, document what happened, and report to your security team immediately. #### Reporting Procedures * **Clear Reporting Channels:** Ensure everyone knows how and where to report security concerns. **Example:** Have a dedicated email address or communication channel specifically for security reports. * **No-Blame Culture:** Encourage prompt reporting by focusing on solutions rather than blame. **Example:** Acknowledge and thank team members who report potential issues, even if they turn out to be false alarms. > **Scenario Example** > A team member notices unusual login attempts to their account. Instead of ignoring it or feeling embarrassed, they > immediately report it to the security team, who can then investigate whether this is part of a larger attack pattern > affecting other users. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Awareness > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Security Awareness](/awareness/overview) * [Core Awareness Principles](/awareness/core-awareness-principles) * [Understanding Threat Vectors](/awareness/understanding-threat-vectors) * [Cultivating A Security Aware Mindset](/awareness/cultivating-a-security-aware-mindset) * [Staying Informed And Continuous Learning](/awareness/staying-informed-and-continuous-learning) * [Security Resources & Further Reading](/awareness/resources-and-further-reading) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Security Awareness > **Key Takeaway** > Stay vigilant, your awareness is your strongest defense against cyber threats. Recognizing red flags and questioning > unexpected requests can prevent costly breaches. This framework is all about understanding the threat landscape, recognizing risk signals, and cultivating a security-aware mindset. It serves as a high-level guide to help individuals and organizations identify potential vulnerabilities and remain vigilant—without overlapping with the detailed, technical scenarios covered in other sections. ### Introduction & Objectives The modern digital landscape is filled with sophisticated attacks, including web3-specific threats like crypto drainers and rug pulls. This section lays the foundation for why a high level of security awareness is essential. It's about empowering you to notice, question, and respond appropriately when something feels off. Trust, but verify! #### Objectives * Recognize Threats: Understand common tactics used by cybercriminals, including both traditional and web3-specific attack vectors. * Adopt a Proactive Stance: Learn how early recognition can stop an attack in its tracks. * Foster a Security Culture: Build an organizational environment where security is everyone's responsibility. * Implement Effective Training: Develop structured approaches to security education for all team members. * Separate Awareness from Implementation: Focus here on "being aware" rather than the step-by-step controls, which are covered in other sections. ### Contents 1. [Core Awareness Principles](/awareness/core-awareness-principles) - Foundational security concepts and mindsets that form the basis of security awareness 2. [Understanding Threat Vectors](/awareness/understanding-threat-vectors.mdx) - Comprehensive overview of attack methods, indicators, and preventive measures 3. [Cultivating a Security-Aware Mindset](/awareness/cultivating-a-security-aware-mindset.mdx) - Behavioral practices and organizational strategies for building a security culture 4. [Staying Informed & Continuous Learning](/awareness/staying-informed-and-continuous-learning.mdx) - Training frameworks, educational approaches, and information sources 5. [Resources & Further Reading](/awareness/resources-and-further-reading.mdx) - External tools, references, and resources for ongoing security education *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Resources & Further Reading > 🔑 **Key Takeaway**: Expanding your security knowledge requires reliable resources and continuous engagement with the > security community. By leveraging curated learning materials, self-assessment tools, and professional networks, you > can deepen your expertise and stay ahead of emerging threats. ### Additional Learning Materials * **Security Awareness Blogs:** Subscribe to blogs like "Security Week" or "Dark Reading" for the latest on cyber threat trends. * **Self-Assessment Tools:** Use downloadable checklists and online quizzes to periodically test your awareness. * **Community Forums & Discussion Groups:** Engage with professional security communities on platforms such as Reddit's r/cybersecurity or specialized Discord groups. * **Case Studies and Whitepapers:** Read detailed incident reports and analysis (available from sources like Verizon's Data Breach Investigations Report) to learn from past events. **Example Resources:** * Personal security checklist: [Digital Defense](https://digital-defense.io) (we are currently developing a version of this based on frameworks, will be available at [https://check.frameworks.securityalliance.dev](https://check.frameworks.securityalliance.dev)). * Interactive phishing simulation: [Phishing Dojo](https://phishing.therektgames.com). * [SEAL's blog](https://securityalliance.org/news) on frameworks. ### Recommended Security Newsletters * [SANS NewsBites](https://www.sans.org/newsletters/newsbites/) - Twice-weekly summaries of the most important security news * [FIRST.org](https://www.first.org/) - Forum of Incident Response and Security Teams newsletters and resources * [The Hacker News](https://thehackernews.com/) - Cybersecurity news and analysis * [Krebs on Security](https://krebsonsecurity.com/) - In-depth security news and investigation ### Security Podcasts and Media * [Daily Stormcast](https://isc.sans.edu/podcast.html) - Daily 5-10 minute updates from SANS Internet Storm Center * [Darknet Diaries](https://darknetdiaries.com/) - Stories from the dark side of the internet * [Security Now](https://twit.tv/shows/security-now) - Weekly deep dives into security topics * [Risky Business](https://risky.biz/) - Weekly information security podcast ### Security Training Resources * [OWASP](https://owasp.org/) - Open Web Application Security Project resources and guides * [Cybrary](https://www.cybrary.it/) - Free and premium cybersecurity training * [SANS](https://www.sans.org/) - Professional information security training * [Phishing.org](https://www.phishing.org/) - Anti-phishing training and awareness resources ### Web3-Specific Security Resources * [DeFi Security Summit](https://defisecuritysummit.org/) - Conference focused on DeFi security * [SEAL news](https://securityalliance.org/news) & [SEAL Discord](https://discord.gg/seal) - Security Alliance's initiatives related to news and events * [Immunefi](https://immunefi.com/learn/) - Educational resources about web3 security * [Consensys Diligence](https://consensys.io/diligence/blog/) - Smart contract security blog * [Blockthreat](https://blockthreat.io/) - Web3 security news and analysis * [The Red Guild](https://blog.theredguild.org/) - Web3 security awareness and education ### Web3 Security Tools * **Token Approval Management:** * [Unrekt](https://app.unrekt.net/) - Check and revoke token approvals * [Etherscan Token Approval Checker](https://etherscan.io/tokenapprovalchecker) - Monitor smart contract approvals * **Wallet Security:** * [wise-signer](https://wise-signer.cyfrin.io/) - Game to learn how to verify transaction information on your wallets * [Qualified Signer Certification](https://updraft.cyfrin.io/certifications/qualified-web3-signer) - Certification for verifying transaction information * [Software and Hardware Wallets comparison](https://wallet.page) - Compare security features of different crypto wallets * [Hardware Wallets comparison](https://www.hardware-wallets.net/) - Compare security features of different hardware wallets * [Wallet Scrutiny](https://walletscrutiny.com/) - Analyze wallet security and features * [Hardware Wallet Resources](https://trezor.io/learn) - Educational content about hardware wallet security ### Security Tools and Services * **Password Managers:** * [Bitwarden](https://bitwarden.com/) - Open-source password management * [1Password](https://1password.com/) - Premium password management solution * [KeePassXC](https://keepassxc.org/) - Free, open-source, cross-platform password manager * **Two-Factor Authentication:** * [Authy](https://authy.com/) - Multi-device 2FA application * [YubiKey](https://www.yubico.com/) - Hardware authentication device * **Secure Communication:** * [Signal](https://signal.org/) - End-to-end encrypted messaging * [ProtonMail](https://protonmail.com/) - Encrypted email service *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Staying Informed & Continuous Learning > 🔑 **Key Takeaway**: Security is not a one-time achievement but an ongoing journey of learning and adaptation. By > establishing regular training routines, staying current with emerging threats, and fostering a culture of continuous > improvement, you ensure your security awareness remains effective against evolving challenges. ### Comprehensive Security Training Framework #### Training Approaches * **Bite-Sized Learning:** Security training doesn't need to be lengthy or overwhelming. Short, focused sessions of relevant information can be more effective than infrequent, lengthy presentations. Example: Weekly 5-minute security tips delivered via team chat or email. * **Role-Based Training:** Tailor security training to specific roles and access levels within your organization. Example: Developers might need more in-depth training on secure coding practices, while community managers might focus more on social engineering awareness. * **Recurring Schedule:** Make security training a regular, ongoing activity rather than a one-time event. Example: Monthly security topics with quarterly refreshers on critical subjects. * **Practical Application:** Include hands-on exercises that allow people to apply what they've learned. Example: Conduct simulated phishing tests followed by immediate feedback and learning opportunities. * **Interactive Training Methods:** Use interactive training methods, such as SEAL Wargames or workshops to engage team members and enhance learning. * **Real-World Scenarios:** Incorporate real-world scenarios and case studies to illustrate the impact of security breaches and the importance of preventive measures. * **Assessments and Quizzes:** Use assessments and quizzes to evaluate the effectiveness of training and identify areas where additional training may be needed. #### Training Delivery * **Regular Awareness Sessions:** Schedule quarterly webinars or short training refreshers focusing on the latest trends and emerging threats. * **Interactive Simulations:** Participate in phishing simulations or scenario-based exercises that allow you to practice identifying and responding to threats in a risk-free environment. * **Security Awareness Campaigns:** Implement periodic campaigns that focus on specific security themes to reinforce key messages. Example: A "Phishing Awareness Month" with targeted activities and resources. #### Measuring Training Effectiveness * **Baseline Assessments:** Conduct assessments before and after training to measure improvement. * **Behavioral Metrics:** Track security-related behaviors such as reporting rates for suspicious emails or incidents. * **Feedback Collection:** Gather participant feedback to continuously improve training content and delivery methods. ### Essential Training Topics * **Phishing and Social Engineering:** Educate team members on recognizing and responding to phishing attacks and social engineering tactics, with special focus on web3-specific threats. * **Password Management:** Provide best practices for creating and managing strong passwords and using password managers. * **Data Protection:** Teach methods for protecting sensitive data, including encryption, access controls, and secure data handling practices. * **Incident Reporting:** Instruct team members on how to report security incidents and suspicious activities promptly. * **Secure Coding Practices:** For developers, provide training on secure coding practices and common vulnerabilities in web3 environments. * **Device and Account Security:** Cover best practices for securing devices and accounts, including updates, encryption, and access controls. * **Emerging Threats:** Keep team members informed about new and evolving security threats relevant to your organization. ### Trusted Information Sources #### Security Newsletters * **Industry News:** Subscribe to newsletters from sources such as FIRST.org for broader cybersecurity trends. Example: The SANS NewsBites provides twice-weekly summaries of the most important security news. * **Vendor Updates:** Follow security updates from the software and hardware vendors in your project stack. Example: Subscribe to security bulletins from cloud providers, operating system vendors, and key software dependencies. #### Security Communities * **Online Forums and Groups:** Join online communities dedicated to security topics. Example: The SEAL Discord provides a space to discuss security challenges specific to web3 projects. * **Local and Virtual Meetups:** Attend security-focused events to network and learn. Example: Conferences like DeFi Security Summit offer insights into emerging threats and defenses. #### Security Blogs and Podcasts * **Technical Blogs:** Follow security researchers and organizations that regularly publish detailed analyses. Example: Trail of Bits blog provides in-depth technical security content. * **Security Podcasts:** Listen to podcasts that cover current security topics. Example: The Daily Stormcast from FIRST.org offers brief daily updates, while Darknet Diaries provides longer-form stories about notable security incidents. ### Implementing a Learning Culture * **Share Knowledge:** Create channels for team members to share security articles, news, and insights. Example: A dedicated Slack channel for security-related content. * **Recognize Vigilance:** Acknowledge and reward security-conscious behavior. Example: Highlight team members who identify and report potential security issues. * **Learn from Incidents:** Use security incidents (both internal and external) as learning opportunities. Example: After major industry breaches, conduct brief sessions to discuss what happened and how similar issues could be prevented in your organization. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Understanding Threat Vectors > 🔑 **Key Takeaway**: Understanding the various ways attackers can target you and your organization is essential for > effective defense. By recognizing common attack patterns like phishing, social engineering, and emerging threats in > digital spaces, you can better protect yourself and your team from potential security breaches. ### Traditional Attack Vectors #### Social Engineering & Phishing * **Phishing Emails:** Look for red flags like misspellings, odd URLs, and urgent language. **Scenario Example:** An email that claims "Your account will be locked in 24 hours" but uses a suspicious domain. * **SMS & Messaging Scams:** Attackers may use text messages or direct social media messages to bypass email filters. **Scenario Example:** A text message that claims to be from a delivery service asking for a confirmation code. * **Voice Phishing (Vishing):** Phone calls that pretend to be from a trusted organization, often using spoofed caller IDs. **Scenario Example:** A staff member receives a voicemail warning about a potential security breach and instructing them to call a specific number immediately. * **Pretexting:** Attackers create a fabricated scenario to steal personal information or gain access. **Scenario Example:** Someone pretending to be a new contractor who needs urgent access to systems or information. * **Baiting:** Offering something enticing to entrap the victim. **Scenario Example:** Leaving infected USB drives in public places or offering free downloads that contain malware. * **Tailgating:** Physically following authorized personnel into restricted areas without proper credentials. **Scenario Example:** An unknown person following an employee through a secure door by claiming they forgot their access card. * **Shoulder Surfing:** Observing someone's screen, keyboard, or device to gather information. **Scenario Example:** A threat actor monitoring your screen in a shared co-working space to capture sensitive information or credentials. #### Malware & Technical Attacks * **Ransomware:** Malicious software that encrypts files and demands payment for decryption. **Scenario Example:** An organization finds their critical files encrypted with a ransom note demanding cryptocurrency payment. * **Man-in-the-Middle Attacks:** Intercepting communications between two parties. **Scenario Example:** An attacker on a public Wi-Fi network intercepts unencrypted traffic to steal credentials. * **Credential Stuffing:** Using stolen username/password combinations to attempt access to multiple services. **Scenario Example:** After a data breach at one service, attackers try the same credentials on financial or email accounts. ### Web3-Specific Threats #### Crypto-Focused Attacks * **Crypto Drainers:** A common attack where a threat actor suggests users can participate in an airdrop by visiting a provided link. Unsuspecting users who click the link are directed to a counterfeit website, where they are asked to authenticate their wallet and sign a transaction. Once signed, the threat actor gains access to steal funds from the wallet. * **Rug Pulls:** In the context of web3 and cryptocurrencies, these scams typically involve fraudulent schemes designed to swindle individuals out of their digital assets. For example, an enticing new project may promise revolutionary technology and unprecedented returns. However, the project developers quickly vanish, leaving investors with worthless tokens and empty promises. * **Token Approval Exploits:** Attackers may trick users into approving smart contracts that give unlimited access to tokens in their wallet. These "allowances" permit the approved contract to transfer any amount of a specific token without further permission. Always verify what permissions you're granting when signing transactions and set specific approval limits when possible. #### Smart Contract Vulnerabilities * **Reentrancy Attacks:** Exploiting a contract's execution flow to repeatedly withdraw funds. **Scenario Example:** A malicious contract calls back into the victim contract before the first execution is complete, draining funds with each call. * **Flash Loan Attacks:** Using uncollateralized loans to manipulate market prices and exploit vulnerabilities. **Scenario Example:** An attacker borrows a large amount of cryptocurrency, manipulates a price oracle, exploits a vulnerability, and repays the loan in a single transaction. ### Common Indicators & Red Flags #### Behavioral Cues * **Inconsistencies:** Look for changes in tone or style in communications from known contacts. **Scenario Example:** A normally formal manager sends a casual message with unexpected requests. * **Unusual Requests:** Requests for urgent transfers of money, sensitive information, or changes in process should always trigger caution. * **Environmental Anomalies:** Spotting unexpected logins or unfamiliar devices in account activity reports can indicate compromised accounts. #### Technical Indicators * **Unexpected Authentication Prompts:** Sudden requests to re-authenticate without clear reason. **Scenario Example:** Being asked to provide credentials on a site you're already logged into. * **Browser Certificate Warnings:** Alerts about invalid or expired security certificates. **Scenario Example:** Your browser displays a warning that a connection is not secure when visiting a familiar website. * **Unusual System Behavior:** Slowdowns, crashes, or unexpected pop-ups. **Scenario Example:** Your computer suddenly runs significantly slower or displays unfamiliar advertisements. #### Checklist for Suspicious Communications * Does the message contain spelling errors or unusual formatting? * Is the sender's email or username slightly different from the norm? * Are there requests for urgent action without proper verification channels? * Does the message create a sense of fear, urgency, or excitement? * Is there an unexpected attachment or link? * Does the request bypass normal security procedures? ### Preventive Measures #### General Security Practices * **Double-Check Requests:** Always verify the identity of individuals requesting sensitive information, especially if the request is unusual or urgent. **Scenario Example:** If you receive an email from your CEO asking for an urgent wire transfer, call them directly using a known phone number to confirm. * **Use Secure Channels:** Communicate through official channels and avoid sharing sensitive information over unsecured methods. **Scenario Example:** Use your organization's established communication platforms rather than responding to external email links. #### Web3-Specific Protections * **Check & Remove Token Approvals:** Regularly check which smart contracts have approvals to handle funds in your wallet and revoke unnecessary approvals to improve your security posture. **Useful Tools:** * [Unrekt](https://app.unrekt.net/) * [Etherscan Token Approval Checker](https://etherscan.io/tokenapprovalchecker) * **Scrutinize Transaction Requests:** Never sign a transaction unless you are completely sure exactly what you are signing. Be especially skeptical of offers that seem too good to be true. * **Hardware Wallets for Critical Assets:** Use hardware wallets for storing significant cryptocurrency holdings. **Scenario Example:** Keeping your long-term investments on a hardware wallet while only maintaining small amounts in hot wallets for daily transactions. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## AI Browsers AI browsers are interfaces that enable models to interact with external content, such as web pages, APIs, and online data sources. While they expand the model's context and capability, they also broaden the attack surface by introducing unvalidated, dynamic inputs from the open web. Traditional security assumptions about trusted networks and static inputs do not hold. ### Real-Time Inspection and Enforcement Protecting AI browsers requires real-time inspection of both retrieved content and the model's outbound actions, with enforcement mechanisms that prevent unsafe behavior regardless of source. AI browsers used to read blockchain explorers, governance forums, or DeFi dashboards can be influenced by manipulated metadata or spoofed data sources. On-chain visibility does not guarantee safety without runtime validation. ### Consider using * Operant AI - real-time visibility and controls across MCP servers and agent tool connections * Zenity - step-level execution monitoring with inline controls for unsafe browser actions * Akamai Firewall for AI - edge runtime inspection for prompts and responses * Wiz AI-SPM - posture management visibility into AI app configuration and data exposure *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## AI Workflows: Developers vs Non-Developers AI workflows differ significantly based on user intent and technical context. Developer workflows involve code, APIs, model orchestration, and embedded systems where execution paths are explicit and controllable. Non-developer workflows, such as marketing, sales, legal, and business process automation, leverage AI through tools and UIs without deep visibility into model behavior. ### Runtime Enforcement over Post-Hoc Auditing Security must adapt accordingly: developer tools can integrate enforcement primitives programmatically, while non-developer tools require automated, transparent guardrails that protect users without requiring specialized expertise. Both contexts benefit from runtime enforcement rather than post-hoc auditing. Non-developer AI tools used in Web3 communities, such as DAO communications or treasury reporting, often operate on public blockchain data but still require safeguards against misinterpretation or malicious input shaping. ### Consider using * Palo Alto Prisma AIRS - runtime security with policy enforcement and automated red-teaming * CalypsoAI - cognitive-layer analysis of agent reasoning and plan execution * Obsidian Security - browser-level enforcement for AI data policies and prompt inspection * Nightfall AI - AI-native DLP across SaaS, endpoints, browsers, and AI applications *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Data Exfiltration via Generative Systems AI systems that process sensitive inputs such as documents, logs, or enterprise data are vulnerable to exfiltration attacks. Without proper runtime controls, models can be coaxed into extracting and exporting confidential information through subtle prompt manipulation or through multimodal vectors. ### Real-Time Behavior Constraints Traditional DLP systems focus on pattern matching and user intent, but generative agents require real-time behavior constraint mechanisms that block unsafe outputs before they are released. Runtime inspection of both input and output modalities is essential to prevent leakage. AI agents with access to wallet metadata, private dashboards, or off-chain analytics can be coerced into leaking sensitive operational or financial information, even when underlying blockchain data is public. ### Consider using * Cyberhaven - dynamic data tracing and AI-based lineage for DLP and insider risk * Nightfall AI - AI-based detection across SaaS, endpoints, email, browsers, and AI data flows * Proofpoint (Acuvity) - runtime inspection and enforcement across AI apps, agents, and MCP servers * Reco AI - SaaS AI exposure discovery, permission auditing, and exfiltration pathway detection *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## DevSecOps Isolation & Sandboxing (Brief Reference) For AI systems that execute tools, run code, or touch sensitive environments, strong isolation is a runtime safety baseline. Keep AI Security focused on threats and controls, and use the DevSecOps isolation pages below for detailed containment patterns. ### Go to DevSecOps isolation guidance * [Isolation folder index](/devsecops/isolation) * [Sandboxing & Isolation overview](/devsecops/isolation/sandboxing-and-isolation) * [Execution Sandboxing](/devsecops/isolation/execution-sandboxing) * [Execution Sandboxing: A Practical Guide](/devsecops/isolation/execution-sandboxing-practical-guide) * [Capability-Based Isolation](/devsecops/isolation/capability-based-isolation) * [Network & Resource Isolation](/devsecops/isolation/network-and-resource-isolation) * [Sandboxing for Tool Execution](/devsecops/isolation/sandboxing-for-tool-execution) * [Sandboxing & Policy Enforcement](/devsecops/isolation/sandboxing-and-policy-enforcement) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Execution-Path Enforcement Execution-path enforcement is a security principle where controls are placed at the point where actions are taken, not where they are merely observed. In AI systems, this means intercepting and evaluating model inputs and intended outputs (including tool calls) immediately before execution. This approach contrasts with legacy detection or monitoring, which assumes human review or reactive response. By enforcing allow, warn, or block decisions at runtime, execution-path controls prevent unsafe behavior proactively, aligning security outcomes with business and safety requirements. For AI agents that construct transactions, manage keys, or interact with smart contracts, execution-path enforcement is critical to prevent unintended or irreversible on-chain actions. ### Consider using * Zenity - granular execution step analysis with intent-aware risk correlation * Microsoft Defender for AI - real-time controls at tool invocation * Cisco AI Defense - runtime MCP traffic guardrails for agentic threats * Operant AI - active trust-boundary enforcement across agent ecosystems * AccuKnox - eBPF and LSM-based runtime enforcement in Kubernetes AI workloads *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Ai Security > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [AI Security](/ai-security/overview) * [Prompt Injection Defenses](/ai-security/prompt-injection-defenses) * [AI Browsers](/ai-security/ai-browsers) * [AI Workflows: Developers vs Non-Developers](/ai-security/ai-workflows-developers-vs-non-developers) * [Data Exfiltration via Generative Systems](/ai-security/data-exfiltration-via-generative-systems) * [Execution-Path Enforcement](/ai-security/execution-path-enforcement) * [DevSecOps Isolation & Sandboxing Reference](/ai-security/devsecops-isolation-sandboxing-reference) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## AI Security ### The AI Security Imperative Artificial intelligence has moved from the lab into the core of modern infrastructure. It now sits inside enterprise systems, consumer products, and decentralized networks. AI models help make decisions, execute financial transactions, generate code, interact with customers, and coordinate autonomous workflows. As this layer becomes embedded in critical systems, the security assumptions many organizations rely on are being quietly overturned. #### New Openings for Abuse AI systems behave differently from traditional software. Conventional applications rely on structured inputs and predictable execution paths. AI models, by contrast, interpret natural language, process images and other multimodal data, and produce outputs shaped by probabilistic reasoning. That flexibility creates new openings for abuse. Instead of targeting memory corruption or injection flaws, attackers can manipulate instructions, context, and model behavior itself. Many established security controls were built around network traffic and code execution. They were not designed to monitor or constrain how a model reasons over a prompt. #### AI-Related Security and Privacy Incidents Recent data makes the scale of the issue clear. [Stanford's 2025 AI Index Report](https://hai.stanford.edu/ai-index/2025-ai-index-report) recorded a 56.4 percent year over year increase in publicly disclosed AI-related security and privacy incidents. [Adversa AI's 2025 incident analysis](https://adversa.ai/top-ai-security-incidents-report-2025-edition/) found that 35 percent of real-world AI security failures stemmed from straightforward prompt-based attacks, with some incidents leading to losses above $100,000 without traditional exploit code. [CrowdStrike's 2025 Global Threat Report](https://www.crowdstrike.com/en-us/global-threat-report/) observed AI system breakout times as short as 51 seconds, often before security teams were alerted. The same report noted that 79 percent of detections were malware-free, with attackers operating through the semantic layer rather than conventional execution paths. #### Decentralized Ecosystems and Irreversible Actions In Web3 and decentralized ecosystems, the stakes rise even further. AI agents interacting with smart contracts, wallet signatures, and governance mechanisms operate in environments where actions are often irreversible. [Hacken's Web3 Security Report](https://hacken.io/insights/q1-2025-security-report/) estimated more than $2 billion in crypto losses in the first three months of 2025 alone, alongside a sharp increase in AI-related exploits compared to 2023\. Research on frameworks such as ElizaOS has shown how adversaries can tamper with agent memory and context to trigger unauthorized transfers or protocol-level violations. A single manipulated transaction can drain a treasury or distort a governance vote. Without runtime controls tailored to AI behavior, these systems carry meaningful systemic risk. ### AI Threat Vectors and Prompt Injection Defenses The rise of large language models as core infrastructure has created a new category of security risk. Prompt injection now sits at the top of OWASP's 2025 Top 10 for LLM Applications and has been identified in more than 73 percent of production AI systems reviewed in recent security audits. The technique targets the basic behavior that makes these models useful: they follow instructions. In traditional software, the line between code and data can be clearly separated and enforced. In language models, instructions and data are expressed in the same format. Any input can influence behavior, because that is exactly how the system is designed to work. #### Obfuscation and Indirect Prompt Injection This design makes familiar input validation techniques unreliable. Blocklists and simple filtering approaches are easy to bypass. Adversarial prompts can be encoded in Base64, disguised with Unicode characters, embedded in ASCII art, translated across languages, or introduced gradually over several conversational turns. Studies have reported attack success rates approaching 76 percent across major frontier models using obfuscation alone. Indirect prompt injection through retrieval augmented generation has reached success rates near 90 percent by inserting only a handful of malicious documents into otherwise massive data stores. #### Financial and Operational Consequences The impact goes far beyond chat responses. As AI systems begin executing code, calling APIs, querying internal databases, constructing transactions, and interacting with external services, the stakes increase. A successful injection can move from producing misleading text to triggering actions with financial and operational consequences. In enterprise environments, that can mean unauthorized data access, exposure of credentials, or manipulation of automated workflows. In Web3 ecosystems, where agents connect to wallets, DeFi protocols, and governance systems, a compromised prompt can initiate irreversible on-chain activity such as token transfers, altered governance votes, or treasury losses. ### Sections in this framework The sections that follow outline the major threat vectors facing AI-driven systems, including prompt injection, browser-based manipulation, data exfiltration, and execution path weaknesses. They also highlight established security providers whose tools address each category. A short cross-reference is included for DevSecOps isolation guidance. The objective is to clarify the defensive landscape so that security teams, developers, and protocol designers can build layered protections that fit their specific deployment models and risk tolerance. * [Prompt Injection Defenses](/ai-security/prompt-injection-defenses) * [AI Browsers](/ai-security/ai-browsers) * [AI Workflows: Developers vs Non-Developers](/ai-security/ai-workflows-developers-vs-non-developers) * [Data Exfiltration via Generative Systems](/ai-security/data-exfiltration-via-generative-systems) * [Execution-Path Enforcement](/ai-security/execution-path-enforcement) * [DevSecOps Isolation & Sandboxing (Brief Reference)](/ai-security/devsecops-isolation-sandboxing-reference) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Prompt Injection Defenses As LLMs execute based on statistical patterns rather than explicit checks, malicious or cleverly structured prompts can cause the model to ignore safety instructions, reveal sensitive data, or perform unintended actions. Effective mitigation requires intercepting and sanitizing inputs at the execution layer rather than relying solely on upstream policies or prompt templates. Security controls should classify and constrain inputs before they are interpreted by a model. ### On-Chain Data as Untrusted Input In smart contract tooling, DAO governance assistants, and wallet agents, prompt injection can lead to incorrect transaction construction or misleading governance actions. Inputs originating from on-chain data or community proposals should be treated as untrusted by default. ### Consider using * CrowdStrike Falcon AI Detection and Response - tracks 150+ prompt injection techniques * Mighty - multimodal prompt injection security API at model ingress and egress * Prompt Security - runtime enforcement for agentic AI with cross-agent policy controls * Lakera Guard - real-time prompt injection detection with dynamic threat intelligence * Robust Intelligence (Cisco) - AI validation plus AI firewall guardrail enforcement * Imperva AI Application Security - LLM-focused protection beyond traditional WAF assumptions ***