# 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 come with some way to connect to the internet, such as via a USB connection. This technically makes > them "hot" when connected. However, the key distinction is that they are not continuously online and are designed to > minimize exposure to online threats. #### 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**: Using smart contracts to manage keys and transactions without exposing private keys. * **Multisig Wallets**: Require multiple signatures to authorize a transaction, enhancing security. #### 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](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](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](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 * [Account Abstraction](/wallet-security/account-abstraction) * [Cold Vs Hot Wallet](/wallet-security/cold-vs-hot-wallet) * [Custodial Vs Non Custodial](/wallet-security/custodial-vs-non-custodial) * [For Beginners & Small Balances](/wallet-security/for-beginners-&-small-balances) * [Hardware Wallets](/wallet-security/hardware-wallets) * [Intermediates & Medium Funds](/wallet-security/intermediates-&-medium-funds) * [Safe Multisig: Step-by-Step Verification](/wallet-security/secure-multisig-safe-verification) * [Secure Multisig Best Practices](/wallet-security/secure-multisig-best-practices) * [Secure Multisig Signing Process](/wallet-security/secure-multisig-signing-process) * [Seed Phrase Management](/wallet-security/seed-phrase-management) * [Signing Schemes](/wallet-security/signing-schemes) * [Signing Verification](/wallet-security/signing-verification) * [Software Wallets](/wallet-security/software-wallets) * [Squads Multisig: Step-by-Step Verification](/wallet-security/secure-multisig-squads-verification) * [TEE-based Encumbered Wallets](/wallet-security/encumbered-wallets) * [Tools & Resources](/wallet-security/tools-&-resources) * [Verifying 7702](/wallet-security/verifying-7702) * [Verifying Standard Transactions](/wallet-security/verifying-standard-transactions) * [Wallet Security](/wallet-security/overview) 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. ### 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. * **Supply Chain Integrity:** Hardware wallets must only be purchased directly from the manufacturer or an authorized reseller to avoid receiving a tampered device. * **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 * **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. ### Initial Setup #### Purchase & Verification * Verify tamper-resistant packaging is untouched * Check for authenticity indicators on packaging #### Device Configuration * Update firmware to latest version before creating accounts * Configure PIN - Use unique, strong PIN (different from other devices) * Generate seed following device instructions * Create accounts as needed ### 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-&-small-balances) - Recommended setups for users with non-critical funds. * [Wallets For Intermediates & Medium Funds](/wallet-security/intermediates-&-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-verification) - An overview of secure transaction signing and verification. * [Verifying Standard Transactions (EOA)](/wallet-security/verifying-standard-transactions) - How to safely verify transactions from standard wallets. * [Multisig Signing Process](/wallet-security/secure-multisig-signing-process) - Detailed guide for secure multisig transaction signing. * [Using EIP-7702](/wallet-security/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-&-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. * 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. #### 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. * **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. ### 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' ## 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-&-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 ![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-&-medium-funds) * [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) * [Emergency Procedures](/multisig-for-protocols/emergency-procedures) * [Tools & Resources](/wallet-security/tools-&-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-&-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.** 5. **Sign**: If the hashes match, 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 ### 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' ## 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. * Never use a device obtained from an untrusted source, such as a conference, hackathon, or third-party online marketplace, as it may be tampered with. * Password managers or digital storage * Traveling with seed phrases * Storing all pieces in same location #### 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' ## 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. * **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/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/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/secure-multisig-squads-verification)**: Concrete, end-to-end Squads verification flow (proposal anatomy, simulations, decoded program data). * **[Verifying Multisig Transactions](/wallet-security/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/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-&-resources)**. *** ## 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. ### 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. ### 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. * **[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. *** 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 augments a security team and 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 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 * [Bug Bounties](/vulnerability-disclosure/bug-bounties) * [Security Contact](/vulnerability-disclosure/security-contact) * [Vulnerability Disclosure](/vulnerability-disclosure/overview) 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. ### SECURE.md File #### Importance A SECURE.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](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. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## User Team Security > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Overview](/user-team-security/overview) * [Phishing Social Engineering](/user-team-security/phishing-social-engineering) * [Security Aware Culture](/user-team-security/security-aware-culture) * [Security Training](/user-team-security/security-training) ## 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 minimum 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 * [Custodial Account Registration Documents](/treasury-operations/registration-documents) * [Custodial Treasury Security: Classification Framework](/treasury-operations/classification) * [Enhanced Controls for High-Risk Custodial Accounts](/treasury-operations/enhanced-controls) * [Treasury Operations Security](/treasury-operations/overview) * [Treasury Transaction Verification (Large Protocols & High-Value Movements)](/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 not processed. Procedures should be put in place with concrete run books for these situations. Safe words should not appear in run books or any digital format. **Anti-Social-Engineering Protocols:** Establish code phrase during 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 video call with minimum 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 help 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 the 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' ## Standard Operating Environment 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 * [Create Maintain Threat Models](/threat-modeling/create-maintain-threat-models) * [Identity Mitigate Threats](/threat-modeling/identity-mitigate-threats) * [Threat Modeling](/threat-modeling/overview) 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 Dependency awareness is the practice of understanding and managing all the external libraries, frameworks, and components that a software project relies on. Dependencies can introduce vulnerabilities and risks, which means it's important to keep track of them and ensure they are secure. ### Importance of Dependency Awareness 1. **Security Risks** * Dependencies can contain vulnerabilities that may be exploited by threat actors. 2. **Compliance** * Ensuring that dependencies comply with licensing and regulatory requirements is essential to avoid legal issues. 3. **Maintainability** * Understanding dependencies and their impact on the project will help understand if it's possible to update a dependency used by your application. ### Best Practices for Dependency Awareness 1. **Use Dependency Management Tools** * Leverage tools that can automatically track and manage dependencies. Examples include: * **Web2:** * **Snyk:** Monitors and fixes vulnerabilities in dependencies. * **Dependabot:** Automatically updates dependencies in GitHub projects. * **Solidity:** * **Ethlint:** Analyzes and lints Solidity code, including dependencies. * **MythX:** Scans for vulnerabilities in smart contract dependencies. 2. **Regularly Update Dependencies** * Regularly update dependencies to the latest secure versions after verifying them. 3. **Monitor for Vulnerabilities** * Continuously monitor dependencies for known vulnerabilities using tools like Snyk, npm audit, and GitHub Security Alerts. 4. **Audit Dependencies** * Perform regular audits of dependencies to ensure they are necessary and secure. Remove unused or outdated dependencies. 5. **Use Trusted Sources** * Only use dependencies from trusted and reputable sources. Avoid using unverified or poorly maintained libraries. *** {/* 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 * [Dependency Awareness](/supply-chain/dependency-awareness) * [Supply Chain Levels Software Artifacts](/supply-chain/supply-chain-levels-software-artifacts) * [Supply Chain Security](/supply-chain/overview) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Supply Chain Security Supply chain security involves managing and securing all the components, dependencies, and processes involved in the development, deployment, and maintenance of software. In the context of blockchain and web3 projects, supply chain security could for example be parts of the web application stack, or external libraries used by the smart contract. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Supply Chain Levels for Software Artifacts Supply chain levels for software artifacts provide a framework for categorizing and securing software components based on their risk levels. This approach helps projects prioritize their security efforts towards software components with the highest risk levels. ### Framework for Supply Chain Levels 1. **Level 1: Critical Artifacts** * These artifacts are essential to the core functionality of the software and pose a high risk if compromised. * Examples: Core libraries. 2. **Level 2: High-Risk Artifacts** * Artifacts that are important but not critical. Their compromise could lead to significant security issues. * Examples: Middleware, database connectors, oracles, authentication modules. 3. **Level 3: Moderate-Risk Artifacts** * Artifacts that are used frequently but have a lower risk profile. Their compromise could cause inconvenience but not catastrophic failure. * Examples: User interface libraries, utility functions, data processing modules. 4. **Level 4: Low-Risk Artifacts** * Artifacts that have minimal impact on security if compromised. * Examples: Logging libraries, test utilities. ### Best Practices for Securing Supply Chain Levels 1. **Critical Artifacts** * Implement strict access controls and require code reviews for all changes. * Use robust security testing, including static and dynamic analysis. * Monitor continuously for vulnerabilities and apply patches promptly. 2. **High-Risk Artifacts** * Enforce strong access controls and conduct regular security assessments. * Perform regular updates and vulnerability scans. * Implement automated security testing in CI/CD pipelines. 3. **Moderate-Risk Artifacts** * Apply standard security practices, including access controls and regular updates. * Use automated tools to scan for vulnerabilities periodically. * Ensure that dependencies are from trusted sources. 4. **Low-Risk Artifacts** * Follow basic security hygiene, such as using trusted sources and applying updates. * Perform occasional security reviews and audits. *** 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 and 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 * [Formal Verification](/security-testing/formal-verification) * [Fuzz Testing](/security-testing/fuzz-testing) * [Integration Testing](/security-testing/integration-testing) * [Mutation Testing](/security-testing/mutation-testing) * [Security Testing](/security-testing/overview) * [Static Analysis](/security-testing/static-analysis) * [Unit Testing](/security-testing/unit-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. With out unit tests, we `mocked` working with external systems, integration tests however will 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 infesable and unnecessary, especially as the codebase grows in size. Instead 100% should be strived for, 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 examines 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 * [Compliance Checks](/security-automation/compliance-checks) * [Infrastructure As Code](/security-automation/infrastructure-as-code) * [Security Automation](/security-automation/overview) * [Threat Detection Response](/security-automation/threat-detection-response) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Infrastructure as Code Infrastructure as Code (IaC) is the managing and provisioning 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 * [Code Reviews Peer Audits](/secure-software-development/code-reviews-peer-audits) * [Secure Code Repositories Version Control](/secure-software-development/secure-code-repositories-version-control) * [Secure Coding Standards Guidelines](/secure-software-development/secure-coding-standards-guidelines) * [Secure Software Development](/secure-software-development/overview) * [Threat Modeling Secure Design Principles](/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 * [On Chain Adoption Guide](/safe-harbor/on-chain-adoption-guide) * [Scope Terms](/safe-harbor/scope-terms) * [SEAL Whitehat Safe Harbor](/safe-harbor/overview) * [Self Adoption Guide](/safe-harbor/self-adoption-guide) * [Self Checklist](/safe-harbor/self-checklist) * [Whitehat](/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. **Deploy your AgreementV2 contract** (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 AgreementV2 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, deploy your AgreementV2 contract**: * Use the SEAL Self-Adoption Tool to generate the deployment parameters * Deploy via the AgreementFactoryV2 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**: * Default for most EVM chains: `0x1eaCD100B0546E433fbf4d773109cAD482c34686` * Full address list: [Registry Addresses](https://github.com/security-alliance/safe-harbor) * Select the method: `adoptSafeHarbor(address agreementAddress)` and input your deployed AgreementV2 contract address * Add the transaction and simulate it: * You should see a `SafeHarborAdoption` event with your multisig as the `entity` * 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/v2/AdoptSafeHarborV2.s.sol` **Steps:** 1. Generate your **scope JSON** via the SEAL tool or manually prepare it using `registry-contracts/agreementDetailsV2.json` as a template 2. Paste the JSON into: `registry-contracts/agreementDetailsV2.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 `DEPLOY_REGISTRY` to `true` in your `.env` file * The script can handle both deployment and registration **Manual Method:** 1. Deploy your agreement: `AgreementFactoryV2.create(AgreementDetailsV2 memory details, address registry, address owner)` 2. Register it: `SafeHarborRegistryV2.adoptSafeHarbor(address agreementAddress)` 3. Use the deployed [Registry & Factory Addresses](https://github.com/security-alliance/safe-harbor/blob/main/README.md) ### Key Contracts * **Agreement Factory:** Deploys AgreementV2 contracts * **Safe Harbor Registry:** Registers adoption and makes it official * **Deployed Addresses:** [View Registry & Factory Addresses](https://github.com/security-alliance/safe-harbor/blob/main/README.md) *** 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 Whitehat Logo > 💡 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. Legal Logo ### Who's Adopted Safe Harbor > Safe Harbor is already protecting $16B+ in assets across leading DeFi protocols. Current adopters include Uniswap, > Pendle, PancakeSwap, Balancer, Silo Finance, Zksync, and more. See the > [full up-to-date list](https://safeharbor.securityalliance.org/). | Uniswap Logo | Pendle Logo | ZkSync Logo | Balancer Logo | | :-----------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :-------------------------------------------------------------------------------------------------------------------------------------: | | [Gov Proposal](https://www.tally.xyz/gov/uniswap/proposal/79) | Non-DAO Adoption | [Gov Proposal](https://www.tally.xyz/gov/zksync/proposal/35395412545014978447594654620386134175315194219985614464693911512436668500487?govId=eip155:324:0x496869a7575A1f907D1C5B1eca28e4e9E382afAb) | [Gov Proposal](https://snapshot.box/#/s\:balancer.eth/proposal/0x8c3fd2550184ec28653c46e959782f1a3127ca8aa6a5652494a9c29ad77d9b55) | ### How Does Safe Harbor Work? * **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? 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 Help from SEAL For protocols that want white-glove support, SEAL offers guided onboarding at no cost. We'll walk you through scoping, governance language, on-chain registration, etc. → [Apply for the SEAL Onboarding Waitlist](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. ### Whitehats Work > 💡 SEAL911 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 the protocol is hacked and the hacker gets 100% of 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. **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 As a 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 AgreementV2 contract (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://bafybeigvd7z4iemq7vrdcczgyu2afm7egxwrggftiplydc3vdrdmgccwvu.ipfs.w3s.link](https://bafybeigvd7z4iemq7vrdcczgyu2afm7egxwrggftiplydc3vdrdmgccwvu.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 to 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 is the protocol's (\[asset recovery address]) {/* TODO: (../security-contact.md) is this link this: /vulnerability-disclosure/security-contact ? */} 3. Who the \[security contact] 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](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] {/*TODO: link not found (./key-terms.md#prospective--retrospective-whitehats)*/} whitehats differs 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 chose 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 frontran. #### 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/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] {/*TODO: link not found (./key-terms.md#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 by an important thing for people inside 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 * [Data Removal Services](/privacy/data-removal-services) * [Digital Footprint](/privacy/digital-footprint) * [Encrypted Communication Tools](/privacy/encrypted-communication-tools) * [Financial Privacy Services](/privacy/financial-privacy-services) * [Privacy](/privacy/overview) * [Privacy Focused Operating Systems Tools](/privacy/privacy-focused-operating-systems-tools) * [Secure Browsing](/privacy/secure-browsing) * [Vpn Services](/privacy/vpn-services) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Privacy Privacy is a fundamental aspect of security. Protecting your personal and 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 browser 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' ## VPN Services Virtual Private Networks (VPNs) can help increase online privacy. They encrypt your internet traffic and hide your IP address, increases the protection of your data from eavesdroppers and provide you additional anonymity online. ### Choosing a VPN Service When selecting a VPN service, consider the following factors: 1. **Privacy Policy** * Ensure the VPN provider has a strict no-logs policy, meaning they do not store any information about your online activities. 2. **Encryption Standards** * Look for VPNs that use strong encryption standards, such as AES-256, to protect your data. 3. **Server Locations** * A wide range of server locations allows you to access content from different regions and improves connection speeds. 4. **Speed and Performance** * Choose a VPN that offers high-speed connections and minimal impact on your browsing and streaming experience. 5. **Security Features** * Look for additional security features such as kill switch, DNS leak protection, and multi-hop connections. ### Recommended VPN Services 1. **MullvadVPN** * **Pros**: Strong privacy policy, fast speeds, wide range of server locations, robust security features. * **Cons**: More expensive than some competitors. 2. **ProtonVPN** * **Pros**: Strong focus on privacy, no-logs policy, free tier available, high security standards. * **Cons**: Fewer servers compared to competitors, can be slower on free tier. 3. **NordVPN** * **Pros**: No-logs policy, strong encryption, numerous servers, additional security features (e.g., Double VPN, CyberSec). * **Cons**: Some servers can be slow, interface can be cluttered. 4. **Surfshark** * **Pros**: Affordable, no-logs policy, unlimited simultaneous connections, strong security features. * **Cons**: Relatively new, smaller network of servers. 5. **ExpressVPN** * **Pros**: Strong privacy policy, fast speeds, wide range of server locations, robust security features. * **Cons**: More expensive than some competitors. ### Best Practices for Using a VPN 1. **Always Connect to a VPN on Public Wi-Fi** * Public Wi-Fi networks are often unsecured, making them prime targets for attackers. Always use a VPN when connected to public Wi-Fi. 2. **Enable the Kill Switch** * A kill switch ensures that your internet connection is cut off if the VPN connection drops, preventing your data from being exposed. 3. **Regularly Update Your VPN Software** * Ensure that you are using the latest version of your VPN software to benefit from the latest security updates and features. 4. **Use Multi-Hop Connections for Extra Security** * Some VPNs offer multi-hop connections, which route your traffic through multiple servers for additional security. 5. **Avoid Free VPNs** * Free VPNs often come with limitations, such as data caps and slower speeds, and may not offer the same level of privacy and security as paid services. *** 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 * [Appendices](/opsec/appendices) * [Browser](/opsec/browser) * [Continuous Improvement Metrics](/opsec/continuous-improvement-metrics) * [Control Domains](/opsec/control-domains) * [Core Concepts](/opsec/core-concepts) * [Endpoint](/opsec/endpoint) * [Google](/opsec/google) * [Improvement](/opsec/improvement) * [Integration](/opsec/integration) * [Mfa](/opsec/mfa) * [Old](/opsec/old) * [Operational Security](/opsec/overview) * [Passwords](/opsec/passwords) * [Principles](/opsec/principles) * [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' ## 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. > ❗ 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 WiFi? 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 kind 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 * [Guide](/opsec/travel/guide) * [Operational Security while traveling](/opsec/travel/overview) * [Tldr](/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] > {/*TODO: link not found:/security-testing/static-application-security-testing*/} \[Dynamic Application Security Testing] > {/*TODO: link not found:../security-testing/dynamic-application-security-testing.md*/}, 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 *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Principles > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Five Steps](/opsec/principles/five-steps) * [Principles](/opsec/principles/principles) * [Principles & Concepts Overview](/opsec/principles/overview) * [Web3 Considerations](/opsec/principles/web3-considerations) 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 descentralized 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] {/* TODO: link not found: ../awareness/social-engineering.md */} 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 reoccurrence #### 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. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Old > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Cloud Third Party](/opsec/old/cloud-third-party) * [Core Opsec Principles](/opsec/old/core-opsec-principles) * [Data Protection](/opsec/old/data-protection) * [Device Endpoint Security](/opsec/old/device-endpoint-security) * [Digital Identity Access](/opsec/old/digital-identity-access) * [Governance](/opsec/old/governance) * [Governance Program Management](/opsec/old/governance-program-management) * [Human Centered Security](/opsec/old/human-centered-security) * [Incident Response](/opsec/old/incident-response) * [Incident Response Recovery](/opsec/old/incident-response-recovery) * [Lifecycle](/opsec/old/lifecycle) * [Monitoring](/opsec/old/monitoring) * [Monitoring Detection](/opsec/old/monitoring-detection) * [Network Communication](/opsec/old/network-communication) * [Overview](/opsec/old/overview) * [Physical Security](/opsec/old/physical-security) * [Risk Management](/opsec/old/risk-management) * [Risk Management Overview](/opsec/old/risk-management-overview) * [Threat Modeling Overview](/opsec/old/threat-modeling-overview) * [Web3 Specific Opsec](/opsec/old/web3-specific-opsec) 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/) *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Web3 Specific Opsec > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Overview](/opsec/old/web3-specific-opsec/overview) 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. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Risk Management > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Risk Assessment Prioritization](/opsec/old/risk-management/risk-assessment-prioritization) * [Risk Management](/opsec/old/risk-management/overview) * [Trade Off Analysis](/opsec/old/risk-management/trade-off-analysis) 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 {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Physical Security > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Overview](/opsec/old/physical-security/overview) 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. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Network Communication > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Overview](/opsec/old/network-communication/overview) * [Telegram](/opsec/old/network-communication/telegram) * [Wireless Security](/opsec/old/network-communication/wireless-security) 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. Considering 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 {/* 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 * [Alert Thresholds](/opsec/old/monitoring/alert-thresholds) * [Log Management](/opsec/old/monitoring/log-management) ## Log Management & SIEM ## Countermeasure Selection & Implementation ## Identify Information & Assets {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Lifecycle > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Countermeasures](/opsec/old/lifecycle/countermeasures) * [Identify](/opsec/old/lifecycle/identify) * [Lifecycle](/opsec/old/lifecycle/overview) * [Risk Prioritization](/opsec/old/lifecycle/risk-prioritization) * [Threat Modeling](/opsec/old/lifecycle/threat-modeling) * [Vulnerability Assessment](/opsec/old/lifecycle/vulnerability-assessment) 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 {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Incident Response > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Containment Recovery](/opsec/old/incident-response/containment-recovery) * [Playbooks](/opsec/old/incident-response/playbooks) ## 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. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Human Centered Security > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Detecting And Mitigating Insider Threats](/opsec/old/human-centered-security/detecting-and-mitigating-insider-threats) * [Overview](/opsec/old/human-centered-security/overview) * [Personal Opsec](/opsec/old/human-centered-security/personal-opsec) * [Social Engineering Defense](/opsec/old/human-centered-security/social-engineering-defense) * [Travel Security](/opsec/old/human-centered-security/travel-security) 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. *** {/* 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 * [Security Policies Roles](/opsec/old/governance/security-policies-roles) * [Third Party Vendor Governance](/opsec/old/governance/third-party-vendor-governance) ## Security policies & roles ## Third-party/vendor governance {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Digital Identity Access > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Overview](/opsec/old/digital-identity-access/overview) * [Password Secrets Management](/opsec/old/digital-identity-access/password-secrets-management) * [Sim Swapping](/opsec/old/digital-identity-access/sim-swapping) ## 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. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Device Endpoint Security > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Overview](/opsec/old/device-endpoint-security/overview) * [Standard Operating Environment](/opsec/old/device-endpoint-security/standard-operating-environment) 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. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Data Protection > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Overview](/opsec/old/data-protection/overview) 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. *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Cloud Third Party > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [G Suite Security](/opsec/old/cloud-third-party/g-suite-security) * [Overview](/opsec/old/cloud-third-party/overview) 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 Placeholder for Multi-Factor Authentication content ## 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 * [Devsecops](/opsec/integration/devsecops) * [Governance](/opsec/integration/governance) * [Integration](/opsec/integration/overview) * [Privacy](/opsec/integration/privacy) 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. **Blockchain Security Framework**: Emerging standards for blockchain security 2. **Smart Contract Security Standard**: Best practices for contract security 3. **OWASP for Smart Contracts**: Adapting web security principles to contracts 4. **Token Security Standards**: Security standards for token implementations 5. **Cross-Chain Security Standards**: Emerging standards for cross-chain security ### 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 {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Improvement > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Post Mortem](/opsec/improvement/post-mortem) * [Security Kpis](/opsec/improvement/security-kpis) ## 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 > 🔑 **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. ### Essential Security Measures > 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). #### Configure 2FA 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). 1. **Go to** [Google 2-Step Verification](https://myaccount.google.com/signinoptions/two-step-verification) 2. **Disable:** "Voice or text message" if it's enabled 3. **Enable:** "Authenticator app" and/or "Passkeys and security keys". You can also can continue using **Google prompts**. 4. **Store Backup Codes:** Keep them offline in a secure place #### Remove Recovery Methods By default, Google allows account recovery using phone numbers and emails. Attackers can exploit these if they compromise your phone or email. 1. **Go to**: [Google Recovery Phone](https://myaccount.google.com/signinoptions/rescuephone) 2. **Remove:** Any phone number listed 3. **Optional**: If you're confident you won't need standard recovery processes: 1. **Go to**: [Google Recovery Email](https://myaccount.google.com/recovery/email) 2. **Remove:** Any recovery email present #### Manage Active Sessions Keeping track of active sessions helps you detect unauthorized access. 1. **Go to**: [Google Device Activity](https://myaccount.google.com/device-activity) 2. **Terminate:** Any session you don't recognize #### Manage OAuth Applications Some apps request extensive permissions (e.g., full inbox or file access). Regularly review these to minimize risks. 1. **Go to**: [Google Connections](https://myaccount.google.com/connections) 2. **Review:** Each connected app's permissions; remove if unnecessary or excessive #### Hide Personal Information Publicly visible personal info can aid attackers in impersonating you. 1. **Go to**: [Google Profile](https://myaccount.google.com/profile) 2. **Check Visibility:** If any info is set to "Anyone," switch it to private if unnecessary * **Birthday:** Consider making it private ### Advanced Security Measures #### Extended Security Settings 1. **Start from**: [Google Security](https://myaccount.google.com/security). 2. **Go to**:"Your connect to third-party apps & Services". 3. **Revoke**: all applications that should not be connected. 4. **Go to**: "Log out of all unknown devices" 5. **Turn off**: "skip password when possible" (below previous step) 6. **Go to**: "How you sign in with Google" 7. **Setup**: your 2FA or Security Key in this section 8. **Ensure you do not have a recovery phone setup. No SMS 2FA or phone number on your account at all.** Once these steps are completed, please change your password. Remember to 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. 1. **Go to** [Google Advanced Protection Program](https://myaccount.google.com/advanced-protection/landing) 2. **Enroll:** Follow the on-screen steps ### Best Practices & Additional Tips * **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](pushsecurity.com). *** {/* 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 Placeholder for Endpoint Security content 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 * [Implementation Process](/opsec/core-concepts/implementation-process) * [Security Fundamentals](/opsec/core-concepts/security-fundamentals) * [Web3 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 * [Control Domains](/opsec/control-domains/overview) * [Organizational](/opsec/control-domains/organizational) * [People](/opsec/control-domains/people) * [Physical Environmental](/opsec/control-domains/physical-environmental) * [Technical](/opsec/control-domains/technical) 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 {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Technical > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [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) ## Network & communication security ## Two-factor & hardware authentication {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Physical Environmental > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Secure Workspace Travel](/opsec/control-domains/physical-environmental/secure-workspace-travel) * [Tamper Evidence](/opsec/control-domains/physical-environmental/tamper-evidence) ## Secure workspace & travel security ## Tamper-evidence & "evil-maid" {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## People > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [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) ## Insider-threat mitigation ## Security training & culture ## Social-engineering defense ## Compliance & regulatory alignment {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Organizational > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Compliance Regulatory Alignment](/opsec/control-domains/organizational/compliance-regulatory-alignment) * [Supply Chain Security](/opsec/control-domains/organizational/supply-chain-security) ## 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 * [Appendices](/opsec/appendices/overview) * [Case Studies](/opsec/appendices/case-studies) * [Glossary](/opsec/appendices/glossary) * [Policies](/opsec/appendices/policies) 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 - [ ] 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 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 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/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](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 4. 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/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 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 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-&-medium-funds) 3. **Coordinate replacement** - Plan signer replacement transaction with team 4. **Execute replacement** - Replace compromised signer on multisig, following steps for signer rotation in [Secure Multisig Best Practices](/wallet-security/secure-multisig-best-practices) 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-&-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 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-&-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 import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Hardware Wallet Setup ### Recommended devices **Ledger:** * Ledger Stax * Ledger Nano S Plus **Trezor:** * Trezor Model One * Trezor Safe 3 ### Initial setup #### Purchase & Verification * Purchase only from manufacturer or authorized resellers * Verify tamper-resistant packaging is untouched * Check for authenticity indicators on packaging #### Device configuration * Update firmware to latest version before creating accounts * Configure PIN - Use unique, strong PIN (different from other devices) * Generate seed following device instructions * Create accounts as needed ### Backup device Every signer MUST maintain a backup device. If the first device fails it is better to have a second one ready to go without having to access the seed phrase. * 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' ## 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-&-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-&-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-&-medium-funds) - Device security requirements * [ ] [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key protection procedures * [ ] [Safe Multisig: Step-by-Step Verification](/wallet-security/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 * [Backup Signing And Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) * [Communication Setup](/multisig-for-protocols/communication-setup) * [Emergency Procedures](/multisig-for-protocols/emergency-procedures) * [Hardware Wallet Setup](/multisig-for-protocols/hardware-wallet-setup) * [Implementation Checklist](/multisig-for-protocols/implementation-checklist) * [Incident Reporting](/multisig-for-protocols/incident-reporting) * [Joining A Multisig](/multisig-for-protocols/joining-a-multisig) * [Offboarding](/multisig-for-protocols/offboarding) * [Overview](/multisig-for-protocols/overview) * [Personal Security Opsec](/multisig-for-protocols/personal-security-opsec) * [Planning And Classification](/multisig-for-protocols/planning-and-classification) * [Registration And Documentation](/multisig-for-protocols/registration-and-documentation) * [Setup And Configuration](/multisig-for-protocols/setup-and-configuration) * [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements) 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 doxxing. #### 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 of the options is going using 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 standard signer rotation procedures ([Signer Rotation](/wallet-security/secure-multisig-best-practices#signer-rotation)) 3. **Verify removal** - Confirm your address has been removed from the multisig 4. **Update documentation** - Ensure documentation reflects the change ### 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-&-medium-funds) * Need to sign a transaction? → Signing & Verification: [Safe Multisig](/wallet-security/secure-multisig-safe-verification) and [Squads](/wallet-security/secure-multisig-squads-verification) * 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 #### 3. For Signers * [Hardware Wallet Setup](/wallet-security/intermediates-&-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/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 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 ### Communication Security #### Basic requirements **Signal with verified safety number verification** for multisig communications: You MUST check the codes with the person you are interacting 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 #### 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 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 doxxing. ### 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 ### 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 [Signer Rotation](/wallet-security/secure-multisig-best-practices#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 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 ### 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 #### Other Modules Do not install any other modules or guards without explicit governance approval and security review. ### 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-&-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)). 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)) ### 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. #### 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/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' ## 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. ### Best Practices #### Define Monitoring Objectives 1. Determine the critical metrics to monitor, such as large fund transfers, token minting events, and changes in contract ownership. #### Implement Monitoring Tools 1. Use automated monitoring tools that can continuously track blockchain activities and generate alerts for anomalies. 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, such as email, SMS, and messaging apps where available, to ensure timely response. #### 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. #### Incident Response 1. Develop and maintain an [incident response plan](/incident-management/overview) to handle alerts and anomalies as soon as possible. *** {/* 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 * [Guidelines](/monitoring/guidelines) * [Monitoring](/monitoring/overview) * [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. *** 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. ### 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 setup 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 cause for investigation. *** 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 contents by role, but we're not quite there yet. 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 under 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 currently being implemented, and we're currently 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 * [How to Navigate the Website](/intro/how-to-navigate-the-website) * [Introduction](/intro/introduction) * [Overview Of Each Framework](/intro/overview-of-each-framework) * [What it is](/intro/what-is-it) * [What it isn't](/intro/what-it-isnt) 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. ### 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. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### Vulnerability Disclosure This section discusses best practices for handling and disclosing vulnerabilities in Web3 projects, including establishing security contacts and managing bug bounty programs. ### 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. ### 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. ### 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. ### 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. ### Threat Modeling This framework provides guidance on creating and maintaining threat models, as well as identifying and mitigating potential threats to Web3 projects. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### ENS This section covers Ethereum Name Service security considerations, including data integrity, cross-chain compatibility, smart contract integration, interface compliance, and name handling. ### Safe Harbor This framework provides guidance on establishing safe harbor protocols for security researchers, including key terms, protocols, technical outlines, and whitehat guidelines. ### 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. *** 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 * [Asset Inventory](/infrastructure/asset-inventory) * [Cloud Infrastructure](/infrastructure/cloud) * [Ddos Protection](/infrastructure/ddos-protection) * [Domain And Dns Security](/infrastructure/domain-and-dns-security) * [Identity And Access Management](/infrastructure/identity-and-access-management) * [Infrastructure](/infrastructure/overview) * [Network Security](/infrastructure/network-security) * [Operating System Security](/infrastructure/operating-system-security) * [Zero Trust Principles](/infrastructure/zero-trust-principles) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Network Security Network security is a very wide subject, and the steps you take are significantly dependent on if you're managing your own network, if you're utilizing a cloud provider, or if you're using a service provider. With that said, there are some general best practices to consider: ### Best Practices 1. Infrastructure should deny all incoming traffic by default. When opening ports, consideration should be made as to which ports and incoming IPs are needed. SSH, RDP, and Database ports should not be open to the entire Internet. 2. Divide your network into segments to limit the impact of a potential breach. 3. Implement firewalls to control and monitor incoming and outgoing network traffic based on predetermined security rules. 4. Use IDPS to detect and prevent potential security breaches. 5. Use VPNs to provide secure remote access to your network. 6. Encrypt sensitive data in transit using secure protocols. 7. Use ACLs to define and control which systems or users can access network resources. 8. Conduct regular network security audits to identify and address vulnerabilities. 9. Keep any potential network devices and software updated with the latest security patches. *** 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 eggs in one basket means a failure on said service would cause downtime, however by using a single service and ensuring it’s following all best practices with regards 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, 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. **Preconditions**: * Domain is using the provider's nameservers * Registrar supports DS records * If 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. 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: ``` # 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 ";" ``` ### 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). #### 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 password 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 * 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 #### 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. **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. *** {/* 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 * [DNS Basics & Common Attacks](/infrastructure/domain-and-dns-security/dns-basics-and-attacks) * [DNSSEC, CAA, and Email Security](/infrastructure/domain-and-dns-security/dnssec-and-email) * [Domain & DNS Security — Overview](/infrastructure/domain-and-dns-security/overview) * [Monitoring, Alerts, and Incident Response](/infrastructure/domain-and-dns-security/monitoring-and-alerting) * [Registrar Security & Registry Locks](/infrastructure/domain-and-dns-security/registrar-and-locks) 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 aa team member, outsider or observer's point of view, communication is very important to be able to understand what's happening, and it also provide 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. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Incident Detection and Response You don't want to be that project which has funds stolen, and then don'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. *** {/* 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 * [Communication Strategies](/incident-management/communication-strategies) * [Incident Detection And Response](/incident-management/incident-detection-and-response) * [Incident Management](/incident-management/overview) * [Lessons Learned](/incident-management/lessons-learned) * [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. *** 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. [Lessons Learned](/incident-management/lessons-learned) 4. [Playbooks](/incident-management/playbooks/overview) 5. [SEAL 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines) *** 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 all 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 which type of drainer you were impacted on, 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 * [Decentralized Ir](/incident-management/playbooks/decentralized-ir) * [ELUSIVE COMET Attack](/incident-management/playbooks/hacked-elusive-comet) * [Malware Infection](/incident-management/playbooks/malware) * [North Korea (DPRK) Attack](/incident-management/playbooks/hacked-dprk) * [Playbooks](/incident-management/playbooks/overview) * [Seal 911 War Room Guidelines](/incident-management/playbooks/seal-911-war-room-guidelines) * [Wallet Drainer Attack](/incident-management/playbooks/hacked-drainer) 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 or take over any accounts or caused 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 that the theft occurred in (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. *** 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. ### 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' ## 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, 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 * [Access Management](/iam/access-management) * [Identity and Access Management](/iam/overview) * [Role Based Access Control](/iam/role-based-access-control) * [Secure Authentication](/iam/secure-authentication) 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 an 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. *** 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 soon 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/) *** {/* 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 * [Compliance Regulatory Requirements](/governance/compliance-regulatory-requirements) * [Governance](/governance/overview) * [Risk Management](/governance/risk-management) * [Security Metrics Kpis](/governance/security-metrics-kpis) 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) *** 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 so very 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 * [Common Vulnerabilities](/front-end-web-app/common-vulnerabilities) * [Front-End Web Application Security Best Practices](/front-end-web-app/overview) * [Mobile Application Security](/front-end-web-app/mobile-application-security) * [Security Tools Resources](/front-end-web-app/security-tools-resources) * [Web Application Security](/front-end-web-app/web-application-security) 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 Often an overlooked area, but 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 for example could 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. [Common Vulnerabilities](/front-end-web-app/common-vulnerabilities) 4. [Security Tools and Resources](/front-end-web-app/security-tools-resources) *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Security Tools and Resources There is a very large amount 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' ## 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 * [Expectation](/external-security-reviews/smart-contracts/expectation) * [Manual Review](/external-security-reviews/smart-contracts/manual-review) * [Preparation](/external-security-reviews/smart-contracts/preparation) * [Smart Contract Security Reviews](/external-security-reviews/smart-contracts/overview) * [Vendor Selection](/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 consist 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 the certain actions or a transaction flow is 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 higher 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 a 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 sometime 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 are. * 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 least dependent contract to review one by one:** 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 functions (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 go 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 the amounts are 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 needs 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 review of the security reviewers that we have is the historical performance of security reviewers. 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 * [Cross Chain Compatibility](/ens/cross-chain-compatibility) * [Data Integrity Verification](/ens/data-integrity-verification) * [ENS Best Practices](/ens/overview) * [Interface Compliance](/ens/interface-compliance) * [Name Handling Normalization](/ens/name-handling-normalization) * [Smart Contract Integration](/ens/smart-contract-integration) 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, in order 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 provides 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 contains 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 means how data is being 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 * [Cloud Data Encryption](/encryption/cloud-data-encryption) * [Communication Encryption](/encryption/communication-encryption) * [Database Encryption](/encryption/database-encryption) * [Email Encryption](/encryption/email-encryption) * [Encryption](/encryption/overview) * [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 * [Case Studies](/dprk-it-workers/case-studies) * [General Information](/dprk-it-workers/general-information) * [Insider Threats (DPRK)](/dprk-it-workers/overview) * [Mitigating DPRK IT Workers](/dprk-it-workers/mitigating-dprk-it-workers) * [Summary](/dprk-it-workers/summary) * [Techniques, Tactics, and Procedures](/dprk-it-workers/techniques-tactics-and-procedures) 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 only for such 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 if you did not hire 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 if you did not potentially run 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. ### 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 Code signing ensures that the code has not been tampered with, and verifies the identity of the developer. Here are some best practices that could be followed: 1. Ensure all Pull Requests (PRs) are signed with the user’s GPG key. 2. Every PR must be reviewed by another core team member before being merged into the stable/main/master branch, with github settings set to reflect this. 3. Require Multi-Factor Authentication (MFA) for all users where applicable and available. Encourage the use of hardware MFA such as Yubikeys. 4. Rotate GPG keys regularly to mitigate the risk of key compromise. 5. Maintain clear documentation on the code signing procedures for your team members. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Continuous Integration and Continuous Deployment (CI/CD) Continuous Integration and Continuous Deployment are there to ensure good code quality and create rapid and secure deployments. Some best practices are: 1. Ensure every PR undergoes CI testing (e.g., GitHub Actions) that must pass before merging. CI tests should at least include unit tests, integration tests, and checks for known vulnerabilities in dependencies. 2. The CI/CD pipeline should check for misconfigurations and leaked credentials. 3. Produce deterministic builds with a strict set of dependencies and/or a build container that can reliably produce the same results on different machines. 4. Integrate security scanning tools to detect vulnerabilities in code and dependencies during the CI process. 5. Use isolated environments for building and testing to prevent contamination between different stages of the pipeline. 6. Implement strict access controls for CI/CD pipelines to limit who can modify the pipeline configurations. *** {/* 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 * [Code Signing](/devsecops/code-signing) * [Continuous Integration Continuous Deployment](/devsecops/continuous-integration-continuous-deployment) * [DevSecOps](/devsecops/overview) * [Integrated Development Environments](/devsecops/integrated-development-environments) * [Repository Hardening](/devsecops/repository-hardening) * [Security Testing](/devsecops/security-testing) 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. Ensure IDEs are configured securely, with plugins and extensions only installed from trusted sources. Some IDEs have features that allow for automated execution of files in folders. 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 Traditionally, rapid development and deployment is 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 prioritizes 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. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Repository Hardening If a threat actor obtains access to your repository, it could have very severe consequences. In order to help avoid this, you could consider implementing the following best practices: 1. Require Multi-Factor Authentication (MFA) for all repository members. 2. Enable protected branches to prevent unauthorized changes to critical branches. [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. Follow the [Security hardening for GitHub Actions](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions) to avoid token stealing and other vulnerabilities. 4. Implement strict access controls to limit who can push to critical branches and repositories. 5. Conduct regular security audits of the repository to identify and mitigate potential vulnerabilities. 6. Require all commits to be signed to verify the identity of contributors and ensure the integrity of the code. 7. Regularly update dependencies and use tools to check for and manage vulnerabilities in dependencies. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Security Testing Security testing is a crucial part of the DevSecOps process, as it helps identify vulnerabilities early on so that they can be taken care of before they become an issue in production. 1. Integrate SAST tools into the CI/CD pipeline to analyze source code for vulnerabilities. 2. Use DAST tools to test running applications for security issues. 3. Combine SAST and DAST approaches with IAST tools for comprehensive security testing. 4. Implement fuzz testing to discover security vulnerabilities by inputting random data. *** ## Champions {/* This file is a duplicate of the CONTRIBUTE.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. **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-reviewers’ 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 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**.** #### 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 section or expand an existing one All contributions should follow this workflow: 1. **Fork the repository** to your own GitHub account. 2. **Follow the `template.mdx` page** when creating or expanding content. It contains pre-defined components and structure required for consistency in MDX files. 3. **Make your changes** in MDX (typos, improvements, or new content) on your fork. 4. **Open a Pull Request (PR) against the `develop` branch** of this repository. Once submitted, you can see the deployment through Vercel’s automation and make any final adjustments. 5. **Notify reviewers** by tagging a steward or maintainer, requesting reviews directly in your PR. 6. Additionally, you can paste your PR and/or potential associated issues to the `framework-reviewers` Discord channel. 7. Once reviewed and approved, your changes will be merged into `develop`. 8. Don't forget to add yourself to the YAML header of the file you're modifying, given that is the way we provide attribution. You should also create your profile inside the contributors list, at `docs/config/contributors.json`. 9. Periodically, reviewed content from `develop` is merged into `main` for the stable site. If you’re interested in a framework that doesn’t currently have an active steward, you can **become one yourself**. See the [Stewards guide](/contribute/stewards) for details on responsibilities and how to get started. **⚠️ Please sign and verify all commits.** (If you have unsigned commits, follow the “Fixing Unsigned Commits” section below to update them) ### Development environment setup Choose the development approach that works best for you: #### Option A: DevContainer with VSCode The easiest way to get started is using 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 mean you think suits you best. **Using DevContainer CLI (Recommended):** * Install [DevContainer CLI](https://github.com/devcontainers/cli) ```bash git clone 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 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 at 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. ## 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. ### Contributor tasks beyond content changes When contributing to the Security Frameworks, there are several additional responsibilities to ensure your updates integrate smoothly into the site and maintain proper structure: #### 1. Page tags * Assign appropriate tags at the top of your pages in the frontmatter to help categorize content by role, topic, or skill level: ```yaml --- tags: - Engineer/Developer - Security Specialist --- ``` * Proper tagging makes your contribution discoverable and filterable on the site. #### 2. Contributors metadata * Add yourself and other relevant contributors to the page frontmatter: ```yaml --- contributors: - role: wrote users: [your-github-username] - role: reviewed users: [reviewer1, reviewer2] --- ``` * Contributors are **managed centrally**: 1. **Contributor database:** `docs/pages/config/contributors.json` 2. **Usage guide:** `docs/pages/config/using-contributors.mdx` * This helps track contributions and ensures proper attribution for edits and reviews. #### 3. 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.ts`** so that the page appears in the site’s sidebar. For content still in review, remember to set `dev: true`. Example of a category with multiple pages: ```tsx { text: 'Monitoring', // Category name visible in the sidebar collapsed: false, 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 }, ] }, ``` 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. #### 4. 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. ### 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. * You can use mermaid diagrams for visualizations #### 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 * [Champions](/contribute/champions) * [Contribute](/contribute/contributing) * [Spotlight Zone](/contribute/spotlight-zone) * [Stewardship](/contribute/stewards) import { Contributors, ContributeFooter, TagFilter, TagProvider } from '../../../components' ## Spotlight Zone This is the current list of individuals who have made substantial contributions to the project and deserve recognition. *** import { ContributeFooter, TagFilter, TagProvider } from '../../../components' ## Stewardship ### What is a Framework Steward? A framework steward is the champion and caretaker for an individual security framework (most frameworks here -> [https://frameworks.securityalliance.org](https://frameworks.securityalliance.org) are currently available for adoption). This role goes beyond casual contribution. It's about taking ownership and helping guide the framework's development through community engagement. ### The Steward's Role A framework steward is a project management role, responsible for: * **Rallying collaborators**: Recruit contributors who share your passion for specific security challenges * **Managing contributions**: Help triage [GitHub issues](https://github.com/security-alliance/frameworks/issues) and coordinate improvements * **Advocating for adoption**: Work with SEAL to promote your framework within your networks and the broader Web3 community * **Creating content**: Work with SEAL to write blog posts, host workshops, or share best practices related to your framework * **Representing the community**: Be a voice for practitioners who use and rely on these standards The core SEAL team will support you throughout this journey, helping you focus on specific challenges rather than drowning in administrative tasks. ### Why Become a Steward? #### Recognition and Growth * **Earn achievement badges**: Receive public recognition with roles like Security Framework Ambassador or DAO Safeguards Steward * **Build your reputation**: Establish yourself as a thought leader in Web3 security * **Develop new skills**: Gain experience in open-source governance, technical writing, and community building #### Tangible Benefits * **Access exclusive events**: Receive tickets to security conferences and invite-only Security Alliance gatherings * **Showcase your expertise**: Get featured through SEAL's official channels, including our [blog](https://www.securityalliance.org/news) and [social media](https://twitter.com/_SEAL_Org) * **Connect with peers**: Build relationships with other security professionals who share your interests #### Lasting Impact * **Shape industry standards**: Help develop frameworks that could become foundational to Web3 security * **Prevent security incidents**: Your work will directly contribute to a safer ecosystem * **Leave a legacy**: Carve your name into the DNA of Web3 security practices for years to come ### Stewardship in Action: What It Looks Like #### Time Commitment Being a steward doesn't mean giving up your day job. We're looking for contributors who can dedicate approximately 3 hours per week to their framework. This might include: * Reviewing [pull requests](https://github.com/security-alliance/frameworks/pulls) and GitHub issues * Participating in sporadic steward meetings * Creating occasional content or presentations * Engaging with the community on [Discord](https://discord.gg/securityalliance) #### Support Structure You won't be working alone. You will have: * Access to a dedicated channel on our [Discord server](https://discord.gg/securityalliance) * Coordination calls with the SEAL team as needed * Documentation templates and contribution guidelines * Access to technical advisors when needed ### How to Apply Ready to become a framework steward? Here's how to get started: 1. Review the proposed frameworks at [frameworks.securityalliance.org](https://frameworks.securityalliance.org) and identify which one aligns with your expertise and interests. 2. Join our [steward candidates Telegram channel](https://t.me/+Yd9OpSt1UvcyMjU5) and introduce yourself to let us know which Framework you want to adopt. We're looking for diverse perspectives and experiences, and you don't need to have decades of experience. Passion, dedication, and a willingness to learn are just as important. ### Join Us in Building a Safer Web3 The "Adopt a Framework" campaign isn't just about improving documentation. You'll be part of a movement where security becomes a shared responsibility across the Web3 ecosystem. By becoming a steward, you're taking an active role in preventing the next major hack, protecting user funds, and ensuring that innovation can continue without compromising safety. We're just getting started, and we need your expertise. Have questions about the stewardship program or ideas for improving it? You can use the [potential stewards Telegram channel](https://t.me/+Yd9OpSt1UvcyMjU5) for that too! 🙂 *** {/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} ## Config > *Note:* This page is auto-generated. Please use the sidebar to explore the docs instead of > navigating directory paths directly. ### Pages * [Template](/config/template) * [Using Contributors](/config/using-contributors) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Title of this Page Key Takeaway prompt: Without removing or modifying anything in the document, just after the heading, describe in a succint way (no more than 40 words), all the key points or tl;dr so that anyone can get a good grasp of the contents just by reading it. Don't add unnecessary sentences that sound like conclusions, like "By ensuring this..." "Doing all these...", "Having these security practinces...". Use the following format > 🔑 **Key Takeaway**: \[Context / Problem statement. In this first part, we introduce the topic, in no more than a few paragraphs. For example for Threat Modeling inside Operational Security Framework: "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." It can be this short, or it can have more context] ### Practical guidance 1. **Step-by-Step Actions** – numbered list users can follow. 2. **Best-Practice Checklist** – bullet list they can literally tick. 3. **Role-Based Tips** – highlight differences for Ops, HR, Dev, etc. (This mirrors OWASP Cheat Sheet brevity.) ### Why is it important Explain consequences of ignoring this guidance and link to real incidents or CISA/NIST advisories supporting each risk. ### Implementation details | Sub-Topic | Related Page | | -------------------- | -------------------------- | | Device Hardening | `../endpoint-security/...` | | Network Segmentation | `../network-security/...` | Cross-linking reduces duplication, following docs-as-code best practice. ### 5 Common pitfalls & examples Real-world breach snippets or failure stories that illustrate mistakes to avoid. {/* :contentReference[oaicite:6]{index=6} */} ### 6 Quick-reference / Cheat sheet A compact table or numbered list for on-the-job use, inspired by OWASP cheat sheets. {/* :contentReference[oaicite:7]{index=7} */} ### 7 Further Reading & Tools Automatically generated from the `references:` field or add authoritative links here. {/* CITATION SOURCES turn0search0 Jekyll front-matter basics – validates YAML metadata structure. turn0search2 NIST practice guides use an executive-summary section. turn0search3 CISA report templates also open with Executive Summary. turn0search4 OWASP Cheat Sheet series shows concise prescriptive guidance. turn0search5 Kubernetes style guide recommends short sections & headings. turn0search6 Google developer style guide echoes those principles. turn0search7 Version-history tables are a best practice for change control. turn0search8 Jekyll step-by-step docs reinforce YAML front-matter placement. turn0search11 CISA advisories supply risk context references. turn0search12 OWASP Cheat Sheet project cited for quick-reference idea. turn0search13 Kubernetes “page content types” shows cross-linking strategy. turn0search10 NIST CSF overview underpins risk-management rationale. */} *** ## 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 `src/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, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Discord Security > 🔑 **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. ### Essential Security Measures #### Server Settings a) **Enable 2FA Requirement for Moderation** * Go to Server Settings > Safety Setup > Moderation * Toggle on "Require 2FA for moderation" * This ensures all moderators have an extra layer of security b) **Set Appropriate Verification Level** * Go to Server Settings > Safety Setup > Verification Level * Choose from: None, Low, Medium, High, Highest * Recommended: "Moderate" for public servers (requires users are registered on discord for longer then 5 min.) * Higher levels protect against spammers and raids c) **Enable Explicit Content Filter** * Go to Server Settings > Safety Setup > Content Filter * Set to "Scan messages from all members" * This automatically blocks messages containing explicit images in non-age-restricted channels * Age-restricted channels are exempt from this filter d) **Enable Raid Protection and CAPTCHA** * Go to Server Settings > Safety Setup > Raid Protection and Captcha * Activate all relevant settings to require CAPTCHA for new user actions * This protection uses machine learning to detect and block bot-driven join-raids * When activated: * Sends alerts to a specified channel * Requires CAPTCHA verification for new users for one hour after detection #### Roles and Permissions a) **Implement Role Hierarchy** * Go to Server Settings > Roles * Create roles like: Cold Admin, Team, Moderator, & Verified. * Drag to reorder; higher roles override lower roles * Restructure the role hierarchy by dragging roles higher or lower in the roles list: * Cold Admin * Team * Moderator * Verified b) **Restrict Administrative 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 * Good permissions for moderators: Manage Channels, Manage Roles, Manage Messages, Ban Members, Delete Messages * Good permissions for members: View Channels, View audit logs, Create Invite, Manage Messages, Read Message History, Connect, Speak & Use Voice Activity, & Ban/Kick/Timeout c) **Use Channel-Specific Permissions** * Right-click on a channel > Edit Channel > Permissions * Set custom permissions for roles or members in specific channels d) **Use the "View Server as Role" Feature** * Go to Server Settings > Roles > Select a role > View Server as Role * This allows you to see what members with a certain role can see and access ### Advanced Security Measures #### Moderation a) **Set Up Auto-Moderation Rules** * Go to Server Settings > AutoMod * Set up rules for: Spam, Harmful Links, Mention Spam, Inappropriate Words * Configure custom keyword filters and exempted roles * Customize the response to spam, like blocking the message, sending an alert, or timing out the member * Add to the existing automod rule to block keywords in a users name, and put Support, Bot, Admin, Tech, Helpdesk, etc. b) **Configure Timeout Duration** * Go to Server Settings > Safety Setup > Timeout * Set default duration (e.g., 60 minutes) * Educate moderators on using timeouts effectively c) **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 #### Extra Moderation Best Practices a) **Leverage "Default Notifications to Mentions Only"** * Go to **Server Settings > Overview** and set **Default Notifications** to **Mentions Only**. * Reduces potential spam notifications for members, making them more vigilant about suspicious or phishing content. b) **Stay Alert to New Features & Potential Exploits** * Keep track of newly introduced features such as Threads, Scheduled Events, or Stage Channels. * Configure their permissions carefully (e.g., who can start or join a Thread) to prevent abuse by spammers or scammers. c) **Regularly Check Third-Party Bot Security** * Ensure bots are from reputable sources and receive frequent updates. * Review bot permissions after each significant update to avoid newly introduced vulnerabilities. #### Bots a) **Audit Bot Permissions** * Go to Server Settings > Integrations * Review each bot's permissions * Remove unnecessary permissions * 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. b) **Remove Unnecessary Bots** * Uninstall any bots that aren't actively used or needed c) **Implement Security/Moderation Bots** * Consider bots like: * Dyno for advanced moderation and logging * Carl-bot for reaction roles and custom commands * Set up security Bots #### Security-Specific 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 Wick Bot. ##### 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. *The bots above are not all-inclusive but rather a recommended list of bots to help protect your Discord server in these categories.* ### Enhanced Server Configuration #### Channels a) **Organize Channels Logically** * Use categories to group related channels * Suggested categories: Information, General, Voice Channels, Topic-Specific b) **Set Slow Mode Where Needed** * Channel Settings > Overview > Slow Mode * Set appropriate cooldown (e.g., 5-30 seconds) for busy channels c) **Use Age-Restricted Channels Appropriately** * Channel Settings > Overview > Age-Restricted Channel * Enable for channels with mature content #### Invites a) **Disable Permanent Invites** * Server Settings > Invites * Un-check "Allow anyone with administrative permissions to create invites" b) **Set Invite Expiration and Usage Limits** * When creating an invite: Set "Expire After" and "Max Number of Uses" * Recommended: 24 hours expiration, 50-100 uses c) **Regularly Audit Active Invites** * Server Settings > Invites * Review and delete unnecessary or old invites #### Member Screening a) **Enable Membership Screening** * Server Settings > Safety Setup > Membership Screening * Toggle on "Enable Membership Screening" b) **Set Up Screening Questionnaire** * Add questions about server rules, age verification, etc. * Require members to agree to rules before joining c) **Set Up Membership Requirements** * Require users to react to a message or post an introduction * This helps filter out bots and spam accounts from joining #### Logging a) **Enable Audit Logs** * Ensure admin/mod roles have "View Audit Log" permission b) **Set Up a Private Logging Channel** * Create a private channel visible only to admins/mods * Use a logging bot like Logger or Dyno to send detailed logs ### Best Practices & Administrative Security #### Regular Reviews a) **Conduct Periodic Permission Audits** * Monthly: Review all role permissions * Use a spreadsheet to track changes and justifications b) **Review and Update Server Rules** * Quarterly: Assess if rules need updating * Announce any changes in a dedicated announcements channel c) **Check for Unused Channels/Roles** * Bi-annually: Delete or archive inactive channels * Remove roles that are no longer needed #### Cold Admin Accounts a) **Set Up a "Cold" Admin Account** * Create a new account on a separate device never used for chatting or clicking links * This account is highly resistant to phishing and provides an extra layer of security for the server owner b) **Secure the Cold Account** * Create a new email account for the cold account * Factory reset the device used for this account c) **Use the Cold Account for Critical Actions** * Manage bots, modify server settings, and respond to compromises * Never use this account for regular server activities d) **Disable QR Code Login on Cold Device** * In **User Settings > Privacy & Safety**, deselect any quick login or QR scan options. * Prevents attackers from using QR phishing tactics to hijack this high-privilege account. #### Additional Community Features a) **Enable the Community Feature (Newer Discord Update)** * Go to **Server Settings > Community** to activate 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. b) **Review Updated Discord Moderation Resources** * 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). ### Platform-Specific Security Considerations #### Additional Security Measures a) **Verification Systems** * Implement a verification bot like Wick * 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 b) **Raid Protection** * Use anti-raid bots like Wick or Dyno * Configure automatic lock-down settings for suspicious activity c) **Privacy Settings** * Server Settings > Privacy Settings * Disable "Allow direct messages from server members" d) **Integration Whitelisting** * Server Settings > Integrations > Allow new integrations to be added by: * Set to "Only Administrators" to prevent unauthorized bot additions e) **Server Insights** * Enable Server Insights for detailed analytics * Use this data to inform moderation strategies and server improvements f) **Backup Systems** * Use a bot like ServerBackup to regularly backup your server configuration * Store backups securely off-platform g) **Audit New Integration/Link Safety Settings** * 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. h) **Enable Safe Direct Messaging for All Users** * In **User Settings > Privacy & Safety**, select **Keep Me Safe** for direct messages. * Encourages moderators and community members to adopt the same setting to minimize phishing DMs. ### 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](https://www.ledger.com/academy/basic-basics/launch-a-crypto-project-securely/how-to-set-up-a-crypto-project-discord-server-securely) {/* Test change: vie 23 may 2025 19:59:52 -03 */} *** {/* 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) * [Telegram](/community-management/telegram) * [Twitter](/community-management/twitter) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Community Management Communities might be the key of 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. * Publicly define all official communication channels used by your organization. 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, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## Telegram Security > 🔑 **Key Takeaway:** Stay vigilant with group chats on Telegram. Implement verification steps and secure communication > practices to protect against sophisticated 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. ### Essential Security Measures #### Configure 2FA 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.** 1. **Go to**: **Settings > Privacy and Security > Two-Step Verification** 2. **Set**: A strong password and recovery email (store both in a password manager) #### Hide Your Phone Number Making your phone number visible can expose you to unwanted contact or social engineering attacks. Restricting visibility helps safeguard your personal info. 1. **Go to**: **Settings > Privacy and Security > Phone Number** 2. **Who can see my phone number?**: Select **Nobody** 3. **Who can find me by my number?**: Select **My contacts** #### Disable P2P Calling By default, Telegram calls can connect you *directly* to the other user, potentially revealing your IP address. 1. **Go to**: **Settings > Privacy and Security > Calls** 2. **Use peer-to-peer with**: Select **Nobody** #### Manage Inactive Sessions Telegram supports auto-terminating inactive sessions. You can also manually review and end any suspicious active sessions. 1. **Go to**: **Settings > Devices > Active sessions** 2. **Review**: Delete any sessions you don't recognize 3. **Auto-terminate**: Set inactive sessions to end after **1 month** #### Implement Device-Level Security Securing the device you use for Telegram is crucial for preventing unauthorized access to your account and messages. 1. **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 2. **Set Strong Device Passcodes**: * Use alphanumeric passwords rather than simple PINs * Enable biometric authentication as a secondary measure 3. **Keep Your Device Updated**: * Install OS updates promptly to patch security vulnerabilities * Update Telegram to the latest version regularly 4. **Install Security Software**: * Use reputable anti-malware software on your device * Consider privacy-focused apps that detect network anomalies 5. **Secure Your Backups**: * Ensure any device backups containing Telegram data are encrypted * Be cautious about cloud backups that might store Telegram messages ### Advanced Security 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. #### Turn On Auto-delete Messages 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. 1. **Go to**: **Settings > Privacy and Security > Auto-Delete Messages** 2. **Set**: Choose a time frame (e.g., 1 week) based on your risk tolerance #### 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 #### Regularly Update the Telegram App Ensure you are always using the latest version of Telegram to benefit from the newest security patches and features. 1. **Check for Updates**: Visit your device's app store regularly 2. **Enable Automatic Updates**: If possible, turn on automatic updates to stay current #### Be Cautious with Third-Party Bots and Integrations Third-party bots can enhance functionality but may also introduce vulnerabilities. 1. **Use Trusted Bots**: Only add bots from reputable sources 2. **Review Permissions**: Limit the permissions you grant to bots 3. **Regular Audits**: Periodically review and remove unnecessary bots #### Manage Group and Channel Admin Permissions If you manage Telegram groups or channels, properly configuring admin permissions is crucial for maintaining security. 1. **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 2. **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 3. **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 4. **Audit Admin Activities**: * Regularly review admin actions in the group * Remove inactive or suspicious admins * Consider using admin action logs if available 5. **Handle Admin Transitions Securely**: * Have protocols for transferring ownership if needed * Revoke admin rights immediately when team members leave ### Enhanced Privacy Settings #### Passcode Lock * **Settings > Privacy and Security > Passcode Lock:** This feature adds a passcode to access your Telegram app after a period of inactivity. The default setting is "away for 1 hour." * **Recommendations:** * **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. #### Privacy and Security Settings **Go to:** Settings > Privacy and Security ##### Security ##### Two-Step Verification * **Overview:** 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. * **Security Measures:** * **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. * **Important:** * **Backup Password:** If you lose this password, access to your account may be compromised. * **Secure Storage:** Write it down offline and ensure it is not lost. ##### Additional Privacy Settings Consider adjusting the following settings based on your country, usage, and purpose for using Telegram: * **Phone Number:** Set to **Nobody** to prevent exposure. * **Last Seen & Online:** Set to **Nobody** to enhance privacy. * **Profile Picture:** Set to **Everybody** to stop scammers from impersonating your profile picture. * **Bio:** Set to **Nobody** (depending on use of Telegram). * **Date of Birth:** Set to **Nobody**. * **Forwarded Messages:** Set to **Nobody**. * **Calls:** Set to **Nobody** or **Contacts Only** (depending on use of Telegram). * **Voice Messages:** Set to **Contacts Only** (depending on use of Telegram). * **Messages:** Set to **Everybody** or **Contacts Only** (depending on use of Telegram). * **Invites:** Set to **Contacts Only** or **Nobody** to prevent being added to random groups that may impersonate legitimate groups and lead to scams. #### 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 & Tips 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. * **Limit Group Permissions:** Restrict who can add members to groups to prevent unauthorized cloning and protect against raids. #### Educate Community Members on Security Practices If you're managing a community on Telegram, educating your members about security is vital for collective protection. 1. **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 2. **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 3. **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 4. **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 5. **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 * **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. *** import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## X (Twitter) Security > 🔑 **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. ### Essential Security Measures #### Remove your phone number 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. 1. **Go to:** [Phone Settings](https://x.com/settings/phone) 2. **Remove:** Click **Delete phone number** if one is listed. 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. #### Configure 2FA 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. Also, ensure your backup codes are stored safely, ideally printed on paper rather than saved on your device. 1. **Go to:** [Login Verification](https://x.com/settings/account/login_verification) 2. **Disable:** Un-check **Text message** 3. **Enable:** Choose **Authentication app** and/or **Security key** 1. 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. 2. If using security keys, keep at least two (e.g., from [Yubico](https://www.yubico.com/)) in case one fails. 4. Under **Additional methods**, below, select **Backup codes** and create a new backup code. 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. #### Enable password reset protect 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. 1. **Go to:** [Security Settings](https://x.com/settings/security) 2. **Toggle On:** Check **Password reset protect**. ### Advanced Security Measures #### Revoke access from delegated accounts 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. 1. **Go to:** [Delegate Members](https://x.com/settings/delegate/members) 2. **Review:** Remove any unfamiliar accounts. #### Revoke access from unnecessary apps It's possible that you've linked your Twitter account to several apps, and some might have more permissions than necessary. To check and manage these permissions, follow these steps: 1. **Go to:** [Connected Apps](https://x.com/settings/connected_apps) 2. **Review:** Check each app's permissions and **Revoke** if it's no longer needed or trusted. #### Log Out of Unnecessary 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. 1. **Go to:** [Sessions](https://x.com/settings/sessions) 2. **Log Out:** For any device or session you don't recognize. #### Verify Your Email is Current If you've changed your email since creating your Twitter account, ensure your current email is linked to receive security alerts and updates. 1. **Go to:** [Email Settings](https://x.com/settings/email) 2. **Confirm:** Update to your current email if needed. #### Refresh Your Password Using a unique password for Twitter is crucial. If you haven't set one, now is the time to do so. 1. **Go to:** [Password Settings](https://x.com/settings/password) 2. **Change:** Select a long, complex password. ### 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. * If you received an email about any content moderation, login, or any email from "X"; ensure the email is from "@x.com" *** 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. ### 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. #### Scoring Individual Questions * **Yes**: Control is currently implemented and operational * **N/A**: Control doesn't apply to your organization (provide justification) #### Evidence Collection (Recommended) While not required for self-assessment, we recommend maintaining documentation for each "Yes" response: * Procedure documents * Operational records * Test results * System configurations This documentation can be useful for future audits or third-party reviews, and can help track your own security posture over time. ### Third-Party Review Third-party reviews are recommended for organizations seeking formal certification, and involves an external SEAL-certified assessor evaluating your security posture. #### Scoring Individual Questions * Implemented: Fully operational with verified evidence * Partially Implemented: Incomplete or lacks sufficient evidence * Not Implemented: Control absent * N/A: Not applicable (provide justification) #### Required Evidence Per Control For each control scored "Implemented," provide: * Procedure documentation: Policies, versions, approval dates * Operational proof: Logs, records, tickets showing active use * Testing/validation: Drill results, incident reports, test outcomes * Ownership details: Responsible party, review frequency, last update * Technical artifacts: Configurations, screenshots, system exports #### Certification Criteria Third-party reviewers will issue certification when: * All critical controls are "Implemented" or "N/A" with justification * Evidence substantiates all claims * "Partially Implemented" controls have documented remediation plans * Overall security posture meets framework requirements #### 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, CertifiedProtocols } 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' ## 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're welcome to 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 * [Certification Guidelines](/certs/certification-guidelines) * [Certified Auditors](/certs/certified-partners) * [Certified Protocols](/certs/certified-protocols) * [Contributions](/certs/contributions) * [DNS Registrar](/certs/sfc-dns-registrar) * [Incident Response](/certs/sfc-incident-response) * [Multisig Operations](/certs/sfc-multisig-ops) * [Overview](/certs/overview) * [Treasury Operations](/certs/sfc-treasury-ops) * [Workspace Security](/certs/sfc-workspace-security) import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## SEAL Certification Framework SEAL Certifications is a certification framework developed by SEAL to provide standardized guidelines and evaluation criteria for assessing the security of DeFi protocols. SEAL Certifications provides targeted modular certifications (e.g., [Incident Response](/certs/sfc-incident-response.mdx), [Treasury Ops](/certs/sfc-treasury-ops.mdx)) that can independently validate specific aspects of a protocol's security posture. Using SEAL Certifications will help ensure that protocols follow best practices for their security operations, and provides a standard set of criteria for comparing the security of different protocols. SEAL Certifications is fully open-source and freely available for any protocol to use. ### How it Works Unlike broad certifications like SOC 2 or ISO 27001, SEAL Certifications focus on specific areas based on the highest impact needs of protocols, based on what SEAL has observed throughout the industry and in interviews with pilot protocols. Each certification focuses on a specific area of security and includes controls relevant to that area. Protocols can use certifications independently to evaluate their security posture through self-assessment, or they can pursue formal certification through a third-party audit by a SEAL-partnered auditor. After completing a certification with a third-party auditor, protocols can publicly display their certification status and are issued an on-chain badge to demonstrate their completion of the certification. ### Current Status: RFC Phase We are currently in a Request for Comment (RFC) Phase until December 31st, 2025. During this period: * Protocols can begin working through the 5 modular proposed certifications to bring their security standards up to best practices * Protocols can sign up for the waitlist for a free 1-hour consultation with the SEAL team to walk through the certification criteria, identify security gaps, and provide valuable feedback [on this form](https://securityalliance.typeform.com/CertsAuditor) * Auditors interested in becoming accredited third-party certification issuers can apply [on this form](https://securityalliance.typeform.com/CertsAuditor) We welcome feedback on the current certifications, suggestions for new modular certifications, and general input on the framework. ### Certifications Being Developped * **[DNS Security](/certs/sfc-dns-registrar.mdx)** - Domain management, DNS configurations, registrar protection * **[Incident Response](/certs/sfc-incident-response.mdx)** - Detection, response procedures, team coordination, emergency operations * **[Multisig Ops](/certs/sfc-multisig-ops.mdx)** - Governance, signer security, transaction verification * **[Treasury Ops](/certs/sfc-treasury-ops.mdx)** - Treasury architecture, transaction security, DeFi risk management * **[Workspace Security](/certs/sfc-workspace-security.mdx)** - Device security, account management, credential handling ### FAQ
When will Certifications start being issued? SEAL is currently working with several auditors and protocols to finalize the certification process. We expect to begin issuing certifications in Q1 2026. In the meantime, protocols are welcome to begin using the SEAL Certifications framework for self-assessments and internal evaluations.
What's the difference between self-assessments and certified audits? Self-assessments are completed by the protocol team themselves, using the SEAL Certifications framework as a guide. They are useful for protocols to internally evaluate their own security posture and identify areas for improvement. Self-assessments are not verified by a third party and do not result in a formal certification or an endorsed badge. Certified audits are completed by a third-party vendor through SEAL's [partner program](/certs/certified-partners.mdx). They involve a thorough and independent evaluation of the protocol's security controls against the SEAL Certifications framework. Upon successful completion of a certified audit, 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 Certifications certification. Attestations do not indicate that a protocol is completely secure or free from issues. Blockchain security is always evolving and novel vulnerabilities arise regularly. Instead, attestations demonstrate that a protocol has implemented a set of standardized best-practices to manage and mitigate security risks.
What if a protocol doesn't meet all the certification requirements? Protocols going through a certified audit that don't meet all the certification requirements will receive a report from the auditor detailing the gaps in their security posture. If the protocol decides to address the gaps, they can work with the auditor to complete a re-assessment of the controls.
What kind of evidence is required? Evidence requirements vary by certification and control. Generally, protocols need to provide documentation, screenshots, or other artifacts demonstrating the implementation of each control. This might mean a list of signer addresses for a multisig, incident response playbooks, or screenshots of DNS configurations.
Who can see our attestation? Attestations are publicly accessible on-chain through the EAS. The detailed audit reports and evidence provided during the audit process are confidential between the protocol and the auditor.
Can we use the SEAL logo / badge? Protocols that successfully complete a certified audit will receive a badge from SEAL. Protocols are welcome to display this badge on their website or documentation to demonstrate their certification.
Is there a list of certified protocols? SEAL will maintain a list of protocols that have successfully completed certified audits after the certification program is fully launched. {/* SEAL maintains a list of protocols that have completed certified audits. You can find the list [here](/certs/certified-protocols.mdx). */}
How can auditors become certified? SEAL works with a group of third-party auditing firms to provide certification audits. For more information on the process or now to become certified, see our [Certified Auditors](/certs/certified-partners.mdx) page.
Can a project lose their certification? Yes, certifications can be revoked if a protocol is found to be non-compliant with the certification requirements for an extended period of time. Certifications are also time-limited and require periodic re-assessment to maintain.
import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, CertList } from '../../../components' ## SFC - DNS Registrar The SEAL Framework Checklist (SFC) for DNS Registrar provides best practice for securely managing domain names and DNS configurations. 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 remain prepared for security incidents affecting blockchain protocols. It covers team structure, monitoring, alerting, and response procedures. 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. 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. 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 - Workspace Security The SEAL Framework Checklist (SFC) for Workspace Security provides guidelines to help secure organizational workspaces covering device management, account security, communications, and training. For more details on certifications or self-assessments, refer to the [Certification Guidelines](/certs/certification-guidelines). import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' ## 1. 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' ## 3. 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. ### 3.1. 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. ### 3.2 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. ### 3.3 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. ### 3.4 Essential Security Practices #### 3.4.1. 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. #### 3.4.2. 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. #### 3.4.3. 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. #### 3.4.4. 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. ### 3.5. Incident Response Awareness #### 3.5.1. 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. #### 3.5.2. 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 * [Awareness Framework](/awareness/overview) * [Core Awareness Principles](/awareness/core-awareness-principles) * [Cultivating A Security Aware Mindset](/awareness/cultivating-a-security-aware-mindset) * [Resources And Further Reading](/awareness/resources-and-further-reading) * [Staying Informed And Continuous Learning](/awareness/staying-informed-and-continuous-learning) * [Understanding Threat Vectors](/awareness/understanding-threat-vectors) 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' ## 5. 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. ### 5.1. 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. ### 5.2. 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 ### 5.3. 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 ### 5.4. 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 ### 5.5. 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 ### 5.6. 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 ### 5.7. 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' ## 4. 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. ### 4.1. Comprehensive Security Training Framework #### 4.1.1. 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. #### 4.1.2. 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. #### 4.1.3. 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. ### 4.2. 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. ### 4.3. Trusted Information Sources #### 4.3.1. 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. #### 4.3.2. 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. #### 4.3.3. 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. ### 4.4. 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' ## 2. 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. ### 2.1. Traditional Attack Vectors #### 2.1.1. 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. #### 2.1.2. 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. ### 2.2. Web3-Specific Threats #### 2.2.1. 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. #### 2.2.2. 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. ### 2.3. Common Indicators & Red Flags #### 2.3.1. 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. #### 2.3.2. 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. #### 2.3.3. 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? ### 2.4. Preventive Measures #### 2.4.1. 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. #### 2.4.2. 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. ***