From a3863aa7db6528969cf5c82bb832c1cf7aa3eb83 Mon Sep 17 00:00:00 2001 From: Sara Russo Date: Wed, 17 Dec 2025 13:44:27 +0100 Subject: [PATCH] fixed spellchecker + linter outputs --- .markdownlint.json | 6 +- docs/pages/certs/certification-guidelines.mdx | 48 +++--- docs/pages/certs/certified-partners.mdx | 7 +- docs/pages/certs/certified-protocols.mdx | 6 +- docs/pages/certs/contributions.mdx | 14 +- docs/pages/certs/overview.mdx | 81 +++++++--- .../pages/certs/sfc-devops-infrastructure.mdx | 4 +- docs/pages/certs/sfc-incident-response.mdx | 4 +- docs/pages/certs/sfc-multisig-ops.mdx | 3 +- docs/pages/certs/sfc-treasury-ops.mdx | 5 +- docs/pages/certs/sfc-workspace-security.mdx | 3 +- docs/pages/config/template.mdx | 2 +- docs/pages/contribute/contributing.mdx | 3 +- .../playbooks/decentralized-ir.mdx | 18 +-- .../seal-911-war-room-guidelines.mdx | 88 +++++------ .../dns-basics-and-attacks.mdx | 18 ++- .../dnssec-and-email.mdx | 89 +++++++---- .../monitoring-and-alerting.mdx | 57 +++++-- .../domain-and-dns-security/overview.mdx | 47 ++++-- .../registrar-and-locks.mdx | 79 +++++++--- .../backup-signing-and-infrastructure.mdx | 65 ++++---- .../communication-setup.mdx | 6 +- .../emergency-procedures.mdx | 9 +- .../hardware-wallet-setup.mdx | 10 +- .../implementation-checklist.mdx | 10 +- .../incident-reporting.mdx | 9 +- .../joining-a-multisig.mdx | 22 ++- .../multisig-for-protocols/offboarding.mdx | 1 - .../pages/multisig-for-protocols/overview.mdx | 16 +- .../personal-security-opsec.mdx | 41 ++++- .../planning-and-classification.mdx | 46 +++--- .../registration-and-documentation.mdx | 12 +- .../setup-and-configuration.mdx | 32 ++-- .../use-case-specific-requirements.mdx | 19 ++- docs/pages/opsec/risk-management-overview.mdx | 16 +- docs/pages/opsec/risk-management/overview.mdx | 16 +- docs/pages/opsec/threat-modeling-overview.mdx | 14 +- docs/pages/opsec/travel/guide.mdx | 18 ++- docs/pages/opsec/travel/tldr.mdx | 3 +- docs/pages/safe-harbor/overview.mdx | 2 +- .../treasury-operations/classification.mdx | 29 ++-- .../treasury-operations/enhanced-controls.mdx | 48 ++++-- docs/pages/treasury-operations/overview.mdx | 17 +- .../registration-documents.mdx | 5 +- .../transaction-verification.mdx | 36 +++-- .../wallet-security/encumbered-wallets.mdx | 149 ++++++++++++------ .../intermediates-&-medium-funds.mdx | 26 +-- docs/pages/wallet-security/overview.mdx | 24 ++- .../secure-multisig-best-practices.mdx | 71 ++++++--- .../secure-multisig-safe-verification.mdx | 34 ++-- .../secure-multisig-signing-process.mdx | 22 ++- .../secure-multisig-squads-verification.mdx | 17 +- .../seed-phrase-management.mdx | 31 +++- .../wallet-security/signing-verification.mdx | 16 +- .../wallet-security/tools-&-resources.mdx | 7 +- wordlist.txt | 42 +++-- 56 files changed, 1013 insertions(+), 510 deletions(-) diff --git a/.markdownlint.json b/.markdownlint.json index 36c7cbff..9fc42f2d 100644 --- a/.markdownlint.json +++ b/.markdownlint.json @@ -34,7 +34,11 @@ "TagProvider", "TagFilter", "ContributeFooter", - "Contributors" + "Contributors", + "CertifiedProtocols", + "CertList", + "CertifiedProtocolsWrapper", + "MermaidRenderer" ] }, "MD037": false, diff --git a/docs/pages/certs/certification-guidelines.mdx b/docs/pages/certs/certification-guidelines.mdx index c4586083..2876e497 100644 --- a/docs/pages/certs/certification-guidelines.mdx +++ b/docs/pages/certs/certification-guidelines.mdx @@ -15,11 +15,13 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -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. +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. +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 @@ -30,42 +32,44 @@ The self-assessment option is suitable for organizations wishing to internally v While not required for self-assessment, we recommend maintaining documentation for each "Yes" response: -- Procedure documents -- Operational records -- Test results -- System configurations +* 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. +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. +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) +* 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 +* 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 +* 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 @@ -74,4 +78,4 @@ Third-party reviewers will issue certification when: 3. Address any findings or requests for additional documentation 4. Receive certification report with findings and recommendations - \ No newline at end of file + diff --git a/docs/pages/certs/certified-partners.mdx b/docs/pages/certs/certified-partners.mdx index b798f0ff..cbdd0bfd 100644 --- a/docs/pages/certs/certified-partners.mdx +++ b/docs/pages/certs/certified-partners.mdx @@ -19,7 +19,8 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Cer ## 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. +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 @@ -28,7 +29,9 @@ SEAL Certifications is currently in the process of establishing our certified au ## 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. +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) diff --git a/docs/pages/certs/certified-protocols.mdx b/docs/pages/certs/certified-protocols.mdx index 8dc3bf54..ff2b3a08 100644 --- a/docs/pages/certs/certified-protocols.mdx +++ b/docs/pages/certs/certified-protocols.mdx @@ -15,8 +15,10 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Cer -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. +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. - \ No newline at end of file + diff --git a/docs/pages/certs/contributions.mdx b/docs/pages/certs/contributions.mdx index a3aca4bb..da9b1fec 100644 --- a/docs/pages/certs/contributions.mdx +++ b/docs/pages/certs/contributions.mdx @@ -15,12 +15,16 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -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. +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). +- 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). - \ No newline at end of file + diff --git a/docs/pages/certs/overview.mdx b/docs/pages/certs/overview.mdx index af2e6eb3..f91ebb11 100644 --- a/docs/pages/certs/overview.mdx +++ b/docs/pages/certs/overview.mdx @@ -15,104 +15,141 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -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. +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. +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. +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) +- 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 Developed -- **[DevOps & Infrastructure](/certs/sfc-devops-infrastructure.mdx)** - Development environments, CI/CD pipelines, infrastructure security, supply chain +- **[DevOps & Infrastructure](/certs/sfc-devops-infrastructure.mdx)** - Development environments, CI/CD pipelines, + infrastructure security, supply chain - **[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 +- **[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, insider threats +- **[Workspace Security](/certs/sfc-workspace-security.mdx)** - Device security, account management, credential + handling, insider threats ## 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. +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. +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. +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. +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 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. +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. +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. +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. +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. +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 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). */} +{/* SEAL maintains a list of protocols that have completed certified audits. You can find the list +here: [Certified Protocols](/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. +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. +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.
diff --git a/docs/pages/certs/sfc-devops-infrastructure.mdx b/docs/pages/certs/sfc-devops-infrastructure.mdx index 08906b12..a520d569 100644 --- a/docs/pages/certs/sfc-devops-infrastructure.mdx +++ b/docs/pages/certs/sfc-devops-infrastructure.mdx @@ -104,7 +104,9 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Cer # SFC - DevOps & Infrastructure -The SEAL Framework Checklist (SFC) for DevOps & Infrastructure provides guidelines for securing development environments, source code management, CI/CD pipelines, and cloud infrastructure. It covers governance, supply chain security, deployment controls, and smart contract operations. +The SEAL Framework Checklist (SFC) for DevOps & Infrastructure provides guidelines for securing development +environments, source code management, CI/CD pipelines, and cloud infrastructure. It covers governance, supply chain +security, deployment controls, and smart contract operations. For more details on certifications or self-assessments, refer to the [Certification Guidelines](/certs/certification-guidelines). diff --git a/docs/pages/certs/sfc-incident-response.mdx b/docs/pages/certs/sfc-incident-response.mdx index 5f477371..0a918e6f 100644 --- a/docs/pages/certs/sfc-incident-response.mdx +++ b/docs/pages/certs/sfc-incident-response.mdx @@ -206,7 +206,9 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Cer # 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. +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). diff --git a/docs/pages/certs/sfc-multisig-ops.mdx b/docs/pages/certs/sfc-multisig-ops.mdx index 5d1f2ba5..96add17a 100644 --- a/docs/pages/certs/sfc-multisig-ops.mdx +++ b/docs/pages/certs/sfc-multisig-ops.mdx @@ -156,7 +156,8 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Cer # 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. +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). diff --git a/docs/pages/certs/sfc-treasury-ops.mdx b/docs/pages/certs/sfc-treasury-ops.mdx index e7d61cc5..c93e3d4d 100644 --- a/docs/pages/certs/sfc-treasury-ops.mdx +++ b/docs/pages/certs/sfc-treasury-ops.mdx @@ -204,11 +204,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Cer # 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. +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). - diff --git a/docs/pages/certs/sfc-workspace-security.mdx b/docs/pages/certs/sfc-workspace-security.mdx index dbdc5356..4b562261 100644 --- a/docs/pages/certs/sfc-workspace-security.mdx +++ b/docs/pages/certs/sfc-workspace-security.mdx @@ -248,7 +248,8 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Cer # 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. +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). diff --git a/docs/pages/config/template.mdx b/docs/pages/config/template.mdx index 7fc60a90..168315c6 100644 --- a/docs/pages/config/template.mdx +++ b/docs/pages/config/template.mdx @@ -50,7 +50,7 @@ Explain consequences of ignoring this guidance and link to real incidents or CIS ## Implementation details | Sub-Topic | Related Page | -|-----------|--------------| +| ----------- | -------------- | | Device Hardening | `../endpoint-security/...` | | Network Segmentation | `../network-security/...` | diff --git a/docs/pages/contribute/contributing.mdx b/docs/pages/contribute/contributing.mdx index 3ca7cdb3..8f5ba3ee 100644 --- a/docs/pages/contribute/contributing.mdx +++ b/docs/pages/contribute/contributing.mdx @@ -10,7 +10,8 @@ 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. +⚠️ 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' diff --git a/docs/pages/incident-management/playbooks/decentralized-ir.mdx b/docs/pages/incident-management/playbooks/decentralized-ir.mdx index 16de30ed..6c0ce2f8 100644 --- a/docs/pages/incident-management/playbooks/decentralized-ir.mdx +++ b/docs/pages/incident-management/playbooks/decentralized-ir.mdx @@ -25,7 +25,7 @@ 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. | @@ -39,7 +39,7 @@ Use it as a menu, not a mandate. ## 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 | @@ -53,7 +53,7 @@ Use it as a menu, not a mandate. ## 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 | @@ -73,7 +73,7 @@ issue). 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 | @@ -82,7 +82,7 @@ issue). ## 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 | @@ -101,7 +101,7 @@ Keep a one-liner command ready for each action and store it in the runbook. 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. | --- @@ -109,7 +109,7 @@ Keep a one-liner command ready for each action and store it in the runbook. ## 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 | @@ -120,7 +120,7 @@ Keep a one-liner command ready for each action and store it in the runbook. ## 8. Quick-Start Templates | Need | Template location | -|------|-------------------| +| ------ | ------------------- | | Incident channel message | /templates/incident-kickoff.md | | Retrospective form | /templates/retro-form.md | @@ -129,7 +129,7 @@ Keep a one-liner command ready for each action and store it in the runbook. ## 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. | diff --git a/docs/pages/incident-management/playbooks/seal-911-war-room-guidelines.mdx b/docs/pages/incident-management/playbooks/seal-911-war-room-guidelines.mdx index ff061787..e1609246 100644 --- a/docs/pages/incident-management/playbooks/seal-911-war-room-guidelines.mdx +++ b/docs/pages/incident-management/playbooks/seal-911-war-room-guidelines.mdx @@ -102,37 +102,37 @@ Record events to construct an overall timeline of the incident. Events worth rec 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 | +| 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 | +| 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 | +| 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 @@ -146,22 +146,22 @@ Record funds movement to gather the impact of the incident and organize recovery 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 | +| 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 | -| ---------------------------------------------------------------- | --------- | ------------------------------------- | +| 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 | +| [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 @@ -198,19 +198,19 @@ is being shared; be wary. ### 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! | +| 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 diff --git a/docs/pages/infrastructure/domain-and-dns-security/dns-basics-and-attacks.mdx b/docs/pages/infrastructure/domain-and-dns-security/dns-basics-and-attacks.mdx index e3158545..5b69d0c3 100644 --- a/docs/pages/infrastructure/domain-and-dns-security/dns-basics-and-attacks.mdx +++ b/docs/pages/infrastructure/domain-and-dns-security/dns-basics-and-attacks.mdx @@ -14,7 +14,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Mer 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] @@ -51,24 +51,30 @@ export const dnsFlowDiagram = `flowchart TD ## 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): +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. +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) +- 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 diff --git a/docs/pages/infrastructure/domain-and-dns-security/dnssec-and-email.mdx b/docs/pages/infrastructure/domain-and-dns-security/dnssec-and-email.mdx index bff75e11..c29ecb00 100644 --- a/docs/pages/infrastructure/domain-and-dns-security/dnssec-and-email.mdx +++ b/docs/pages/infrastructure/domain-and-dns-security/dnssec-and-email.mdx @@ -22,11 +22,16 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ## 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. +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. +**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**: -**Preconditions**: - Domain is using the provider's nameservers - Registrar supports DS records - If registrar supports CDS/CDNSKEY auto-publish, enable that if offered @@ -41,7 +46,7 @@ DNSSEC (DNS Security Extensions) provides cryptographic authentication of DNS re - `13` (ECDSAP256SHA256) - Recommended - `8` (RSASHA256) - `15` (ECDSAP384SHA384) - - **Digest Type**: + - **Digest Type**: - `2` (SHA-256) - Recommended for widest compatibility - `4` (SHA-384) - **Digest**: Hex string of the hash @@ -52,6 +57,7 @@ DNSSEC (DNS Security Extensions) provides cryptographic authentication of DNS re - 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 @@ -76,20 +82,28 @@ DNSSEC (DNS Security Extensions) provides cryptographic authentication of DNS re - 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. + +- 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. +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. +**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 +- **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: @@ -111,42 +125,53 @@ 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. +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. +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. +**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. +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. +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. +**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). +**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. +**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 @@ -154,29 +179,32 @@ MTA-STS enforces encrypted connections between mail servers, preventing man-in-t 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. + + 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 @@ -185,29 +213,35 @@ MTA-STS enforces encrypted connections between mail servers, preventing man-in-t - 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. +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. +**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 @@ -215,7 +249,8 @@ _dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com" - 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. +**Recommendation**: Start with aggregate reports only (`rua=`). They provide sufficient visibility into authentication +issues without the privacy and reliability concerns of failure reports. --- diff --git a/docs/pages/infrastructure/domain-and-dns-security/monitoring-and-alerting.mdx b/docs/pages/infrastructure/domain-and-dns-security/monitoring-and-alerting.mdx index 83bc9dee..58e850fb 100644 --- a/docs/pages/infrastructure/domain-and-dns-security/monitoring-and-alerting.mdx +++ b/docs/pages/infrastructure/domain-and-dns-security/monitoring-and-alerting.mdx @@ -23,60 +23,79 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ## 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. +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 + +- **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 + - **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 + - **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. +- [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. +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. +**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. +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 @@ -86,50 +105,60 @@ Passive DNS monitoring tracks historical DNS resolution data across the internet ### 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** +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 + - **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 @@ -137,24 +166,28 @@ Passive DNS monitoring tracks historical DNS resolution data across the internet ## 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 diff --git a/docs/pages/infrastructure/domain-and-dns-security/overview.mdx b/docs/pages/infrastructure/domain-and-dns-security/overview.mdx index e8b4a278..86f54a82 100644 --- a/docs/pages/infrastructure/domain-and-dns-security/overview.mdx +++ b/docs/pages/infrastructure/domain-and-dns-security/overview.mdx @@ -21,46 +21,67 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -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. +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. +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: +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. +- **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 + +- **[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 + +- [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 +- [DNS Security in Web3: Attacks & Monitoring Setup + Explained](https://web3secnews.substack.com/p/the-hidden-dns-threats-that-could) - Comprehensive Web3 DNS security + guide --- diff --git a/docs/pages/infrastructure/domain-and-dns-security/registrar-and-locks.mdx b/docs/pages/infrastructure/domain-and-dns-security/registrar-and-locks.mdx index 8d02da45..4bb73f23 100644 --- a/docs/pages/infrastructure/domain-and-dns-security/registrar-and-locks.mdx +++ b/docs/pages/infrastructure/domain-and-dns-security/registrar-and-locks.mdx @@ -22,7 +22,9 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ## 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. +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) @@ -43,15 +45,21 @@ These registrars are designed for personal use and lack the security measures ne - **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. +**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. +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. +**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 @@ -59,17 +67,25 @@ Registry lock prevents unauthorized transfers at the registry level, not just th - `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. +**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. +**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. +**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. +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. +**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**: @@ -95,13 +111,15 @@ Multi-factor authentication (MFA) adds an extra layer of security beyond just pa - 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. +**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. +**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) @@ -109,13 +127,18 @@ Use a dedicated email address for domain security that's completely separate fro ⚠️ 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. + +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. +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 @@ -123,27 +146,33 @@ Limit and monitor who has access to your domain registrar account, as each perso ## 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. +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. +**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. +**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 @@ -151,9 +180,11 @@ WHOIS records contain personal information about domain owners that is publicly - **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 lookup**: `rdap yourdomain.com` displays domain status, EPP codes, nameservers, registrar info, and + expiration dates **Example RDAP output**: @@ -229,28 +260,36 @@ WHOIS records contain personal information about domain owners that is publicly ``` **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. +**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. +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. +**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) diff --git a/docs/pages/multisig-for-protocols/backup-signing-and-infrastructure.mdx b/docs/pages/multisig-for-protocols/backup-signing-and-infrastructure.mdx index f56e1922..9ace99ee 100644 --- a/docs/pages/multisig-for-protocols/backup-signing-and-infrastructure.mdx +++ b/docs/pages/multisig-for-protocols/backup-signing-and-infrastructure.mdx @@ -26,7 +26,9 @@ import { -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. +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 @@ -34,27 +36,28 @@ If the default interfaces for either Safe or Squads are down or suspected of bei **Eternal Safe - Decentralized fork of Safe\{Wallet\}** -- GitHub: https://github.com/eternalsafe/wallet -- Hosted (IPFS): https://eternalsafe.eth.limo (requires bring your own RPC) +- 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. +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** +**Squads Public Client - Open source Squads V4 interface: ** -- GitHub: https://github.com/Squads-Protocol/public-v4-client +- 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** +**Safe Mobile Apps: ** -- GitHub: https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile -- App Store: https://apps.apple.com/us/app/safe-mobile/id6748754793 -- Play Store: https://play.google.com/store/apps/details?id=global.safe.mobileapp +- 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 @@ -78,29 +81,32 @@ Ensure signer preparedness: ### 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. +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** +**Blockscout - Open source Etherscan alternative: ** -- https://www.blockscout.com/ +- [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 +- 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/ +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/ +**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/ +**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. +**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 @@ -108,8 +114,8 @@ Both explorer.solana.com and Solscan are reliable options for Solana transaction #### Access Options -- **GitHub**: https://github.com/eternalsafe/wallet -- **Hosted (IPFS)**: https://eternalsafe.eth.limo (requires bring your own RPC) +- **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 @@ -135,11 +141,13 @@ Both explorer.solana.com and Solscan are reliable options for Solana transaction #### 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). +**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. +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:** @@ -151,7 +159,8 @@ https://eternalsafe.eth.limo/transactions/tx/?safe=base:0xA79C6968E3c75aE4eF3883 #### 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. +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 @@ -159,14 +168,15 @@ Once all signatures are collected, execute the transaction. **Note**: Prior to e #### Access Options -- **GitHub**: https://github.com/Squads-Protocol/public-v4-client -- **Hosted**: https://backup.app.squads.so/ +- **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 and access via http://localhost:8080 +1. If running locally, follow setup instructions in [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client) + and access via `http://localhost:8080` 2. Enter RPC URL in settings ![Squads RPC configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-rpc-configuration.png) 3. Enter multisig address in the **lower** text box (Search for Multisig Config) and select the detected Multisig Config @@ -174,7 +184,8 @@ Once all signatures are collected, execute the transaction. **Note**: Prior to e #### 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 +1. Create, approve, or execute transactions. _Smart Links_ are not needed for Solana as all transactions are on chain + and accessible via the RPC without an API ![Squads transaction interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-transaction-interface.png) ## Security Considerations diff --git a/docs/pages/multisig-for-protocols/communication-setup.mdx b/docs/pages/multisig-for-protocols/communication-setup.mdx index 69f41676..fac39280 100644 --- a/docs/pages/multisig-for-protocols/communication-setup.mdx +++ b/docs/pages/multisig-for-protocols/communication-setup.mdx @@ -6,6 +6,7 @@ tags: contributors: - role: wrote users: [isaac, geoffrey, louis, pablo, dickson] + - role: reviewed users: [pinalikefruit, engn33r] --- @@ -23,6 +24,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ## 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 @@ -31,6 +33,7 @@ Set up dedicated communication channel for multisig operations: ## 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 @@ -38,10 +41,11 @@ Configure backup communication on different platform: ## 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 - \ No newline at end of file + diff --git a/docs/pages/multisig-for-protocols/emergency-procedures.mdx b/docs/pages/multisig-for-protocols/emergency-procedures.mdx index 31b71adb..42b656d3 100644 --- a/docs/pages/multisig-for-protocols/emergency-procedures.mdx +++ b/docs/pages/multisig-for-protocols/emergency-procedures.mdx @@ -20,7 +20,8 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -When security incidents occur, quick and decisive action is critical. This page covers procedures for key compromise, lost access, and communication breaches. +When security incidents occur, quick and decisive action is critical. This page covers procedures for key compromise, +lost access, and communication breaches. ## Key Compromise @@ -37,7 +38,8 @@ When security incidents occur, quick and decisive action is critical. This page 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) +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 @@ -52,6 +54,7 @@ When security incidents occur, quick and decisive action is critical. This page ### 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** @@ -69,6 +72,7 @@ Since you can't sign with your key, verify identity through alternative methods: ### 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 @@ -225,6 +229,5 @@ Current multisig status: - [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key recovery procedures - [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account security measures - diff --git a/docs/pages/multisig-for-protocols/hardware-wallet-setup.mdx b/docs/pages/multisig-for-protocols/hardware-wallet-setup.mdx index af53d899..7ef50477 100644 --- a/docs/pages/multisig-for-protocols/hardware-wallet-setup.mdx +++ b/docs/pages/multisig-for-protocols/hardware-wallet-setup.mdx @@ -23,21 +23,25 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ## 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 @@ -45,11 +49,13 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ## 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. +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 - \ No newline at end of file + diff --git a/docs/pages/multisig-for-protocols/implementation-checklist.mdx b/docs/pages/multisig-for-protocols/implementation-checklist.mdx index a215fe98..aa9f0a3a 100644 --- a/docs/pages/multisig-for-protocols/implementation-checklist.mdx +++ b/docs/pages/multisig-for-protocols/implementation-checklist.mdx @@ -20,7 +20,8 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -This checklist ensures all multisig participants have the knowledge and skills necessary for secure operations. Complete all applicable sections before beginning multisig operations. +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 @@ -65,7 +66,8 @@ This checklist ensures all multisig participants have the knowledge and skills n ### 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 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 @@ -194,6 +196,7 @@ Additional requirements from [Use Case Specific Requirements](/multisig-for-prot Trainer: _________________ Date: _________________ Trainee has demonstrated competency in: + - [ ] Transaction verification procedures - [ ] Emergency response protocols - [ ] Security best practices @@ -221,7 +224,8 @@ Additional training required after: ## Related Documents -All documents in this framework serve as training materials. Refer to individual documents for detailed procedures and requirements specific to your role. +All documents in this framework serve as training materials. Refer to individual documents for detailed procedures and +requirements specific to your role. diff --git a/docs/pages/multisig-for-protocols/incident-reporting.mdx b/docs/pages/multisig-for-protocols/incident-reporting.mdx index cfc651c2..cdb39f2f 100644 --- a/docs/pages/multisig-for-protocols/incident-reporting.mdx +++ b/docs/pages/multisig-for-protocols/incident-reporting.mdx @@ -23,6 +23,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ## What to Report ### Security incidents (report immediately) + - Key compromise or suspected compromise - Account takeovers (email, communication platforms, etc.) - Device theft or loss @@ -31,6 +32,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr - 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 @@ -38,6 +40,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr - Difficulty following security procedures ### Near misses (report when convenient) + - Social engineering attempts - Suspicious emails or messages - Security procedure confusion or errors @@ -46,18 +49,21 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ## 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 @@ -126,6 +132,5 @@ Additional notes: [Any other relevant information] ``` - - \ No newline at end of file + diff --git a/docs/pages/multisig-for-protocols/joining-a-multisig.mdx b/docs/pages/multisig-for-protocols/joining-a-multisig.mdx index 618070b5..f183b659 100644 --- a/docs/pages/multisig-for-protocols/joining-a-multisig.mdx +++ b/docs/pages/multisig-for-protocols/joining-a-multisig.mdx @@ -24,23 +24,28 @@ It is recommended to always create a fresh address on a hardware wallet for each ## 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. +Creating a proof of address ownership provides important documentation and security assurances to the protocol for all +multisig signers. Entity affiliations are acceptable - the goal is accountability, not doxing. ### Preparing and sharing address & Signature -Sign the message like [@social_handle | name | entity] is looking to join [Multisig Name] X DAO multisig with address 0x... with the private key you intend to use as a signer. One of the options is going using MyCrypto web UI: -1. Connect your wallet to https://app.mycrypto.com/sign-message +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. + +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. @@ -50,7 +55,8 @@ Share the message: 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 + +1. Go to [https://app.mycrypto.com/verify-message](https://app.mycrypto.com/verify-message) 2. Enter json & click Verify: ```json @@ -61,8 +67,8 @@ Note: Enter plain text message (not the hex version MyEtherWallet will give!) an } ``` -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. - +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. - \ No newline at end of file + diff --git a/docs/pages/multisig-for-protocols/offboarding.mdx b/docs/pages/multisig-for-protocols/offboarding.mdx index c1a2694e..5d0f6526 100644 --- a/docs/pages/multisig-for-protocols/offboarding.mdx +++ b/docs/pages/multisig-for-protocols/offboarding.mdx @@ -40,6 +40,5 @@ When leaving a multisig, follow these steps: - Share any relevant context or pending items with remaining signers - Provide contact information if needed for transition questions - diff --git a/docs/pages/multisig-for-protocols/overview.mdx b/docs/pages/multisig-for-protocols/overview.mdx index 5cec6854..b7e750b2 100644 --- a/docs/pages/multisig-for-protocols/overview.mdx +++ b/docs/pages/multisig-for-protocols/overview.mdx @@ -23,9 +23,14 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ## 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) + +- 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) +- 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 @@ -38,9 +43,11 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ## 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 @@ -48,10 +55,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr - [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 +- [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 @@ -59,6 +68,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr - [Offboarding](/multisig-for-protocols/offboarding) - Safely leave a multisig role ### 4. Reference + - [Implementation Checklist](/multisig-for-protocols/implementation-checklist) - Verify readiness for multisig operations diff --git a/docs/pages/multisig-for-protocols/personal-security-opsec.mdx b/docs/pages/multisig-for-protocols/personal-security-opsec.mdx index e240269c..95903d45 100644 --- a/docs/pages/multisig-for-protocols/personal-security-opsec.mdx +++ b/docs/pages/multisig-for-protocols/personal-security-opsec.mdx @@ -23,6 +23,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ## 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 @@ -30,15 +31,23 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr - 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. +- 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 @@ -46,6 +55,7 @@ Example: random44@gmail is tied to your AppleID, and you are only logged in (the ## 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 @@ -54,7 +64,9 @@ Example: random44@gmail is tied to your AppleID, and you are only logged in (the - 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 @@ -65,15 +77,19 @@ Example: random44@gmail is tied to your AppleID, and you are only logged in (the ### 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". +**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) @@ -81,7 +97,9 @@ If the account connects on a new device these codes will change & you will recei - 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 @@ -89,18 +107,21 @@ If the account connects on a new device these codes will change & you will recei ## 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 @@ -108,7 +129,9 @@ If the account connects on a new device these codes will change & you will recei - 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) @@ -118,23 +141,27 @@ If the account connects on a new device these codes will change & you will recei ## 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. +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). - - \ No newline at end of file + diff --git a/docs/pages/multisig-for-protocols/planning-and-classification.mdx b/docs/pages/multisig-for-protocols/planning-and-classification.mdx index ce4e44c0..5717a955 100644 --- a/docs/pages/multisig-for-protocols/planning-and-classification.mdx +++ b/docs/pages/multisig-for-protocols/planning-and-classification.mdx @@ -26,7 +26,8 @@ import { -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 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 @@ -60,7 +61,9 @@ Determine who should be involved: ## 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. +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 @@ -86,12 +89,12 @@ What happens if this multisig is compromised or fails? #### Impact Classification -| Level | Financial Exposure | Protocol Impact | Reputational Risk | +| 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 | +| **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 @@ -117,24 +120,24 @@ How quickly and under what conditions must this multisig respond? #### Operational Classification -| Type | Response Time | Decision Context | Verification Level | +| 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 | +| **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 | +| 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 | +| 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 @@ -142,9 +145,12 @@ Record your classification decision in the [Registration template](/multisig-for ## Important Notes -⚠️ **When between classifications**: Always err toward higher security requirements. Classifications can be relaxed with proper justification, but security incidents cannot be undone. +⚠️ **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. +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 diff --git a/docs/pages/multisig-for-protocols/registration-and-documentation.mdx b/docs/pages/multisig-for-protocols/registration-and-documentation.mdx index 8330a577..307b6d7c 100644 --- a/docs/pages/multisig-for-protocols/registration-and-documentation.mdx +++ b/docs/pages/multisig-for-protocols/registration-and-documentation.mdx @@ -20,11 +20,13 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -Proper documentation is essential for multisig security and accountability. This page covers the registration process and required 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. +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 @@ -70,7 +72,7 @@ Each signer must provide a verification signature linking their identity to thei 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. +**Note**: Entity affiliations are acceptable - the goal is accountability, not doxing. ## Update Template @@ -141,7 +143,8 @@ Follow these procedures for adding, removing, or replacing signers: - Update all documentation immediately after change #### Replacing signers -Follow steps in [Signer Rotation](/wallet-security/secure-multisig-best-practices#signer-rotation) + +Follow steps in [Signer Rotation](/wallet-security/secure-multisig-best-practices#signer-rotation) ### Documentation updates @@ -160,6 +163,5 @@ Use the template in [Registration & Documentation → Update Template](/multisig - [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 - diff --git a/docs/pages/multisig-for-protocols/setup-and-configuration.mdx b/docs/pages/multisig-for-protocols/setup-and-configuration.mdx index 07a90042..7b83e774 100644 --- a/docs/pages/multisig-for-protocols/setup-and-configuration.mdx +++ b/docs/pages/multisig-for-protocols/setup-and-configuration.mdx @@ -26,20 +26,25 @@ This page covers the technical deployment and configuration of multisigs on supp ### EVM Networks (Ethereum, Base, etc.) -1. Go to https://app.safe.global +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 +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. +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) @@ -50,8 +55,9 @@ It is recommended, but not required to authorize a separate transaction proposer 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 +- **Grant allowance to**: DAO Agent - **Amount**: Max value for each token held ### Other Modules @@ -81,24 +87,32 @@ Do not install any other modules or guards without explicit governance approval 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. +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. +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. +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)). +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)). - \ No newline at end of file + diff --git a/docs/pages/multisig-for-protocols/use-case-specific-requirements.mdx b/docs/pages/multisig-for-protocols/use-case-specific-requirements.mdx index 8a0b8270..603367de 100644 --- a/docs/pages/multisig-for-protocols/use-case-specific-requirements.mdx +++ b/docs/pages/multisig-for-protocols/use-case-specific-requirements.mdx @@ -55,22 +55,31 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr ### 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) +- 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. +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. +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). +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) diff --git a/docs/pages/opsec/risk-management-overview.mdx b/docs/pages/opsec/risk-management-overview.mdx index 68cba9d6..60e49013 100644 --- a/docs/pages/opsec/risk-management-overview.mdx +++ b/docs/pages/opsec/risk-management-overview.mdx @@ -59,7 +59,7 @@ reputational factors 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 | @@ -74,7 +74,7 @@ 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 | @@ -97,7 +97,7 @@ 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 | @@ -107,7 +107,7 @@ In Web3 environments, risk management must address unique challenges: ### 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 | @@ -125,7 +125,7 @@ Building on the threat vectors identified during threat modeling, Pinnipeds Inc. #### Risk Calculation Methodology | Rating | Impact | Likelihood | -|--------|--------|------------| +| -------- | -------- | ------------ | | **1** | Minimal | Rare | | **2** | Minor | Unlikely | | **3** | Moderate | Possible | @@ -137,7 +137,7 @@ Building on the threat vectors identified during threat modeling, Pinnipeds Inc. #### 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 | @@ -145,7 +145,7 @@ Building on the threat vectors identified during threat modeling, Pinnipeds Inc. #### 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 | @@ -153,7 +153,7 @@ Building on the threat vectors identified during threat modeling, Pinnipeds Inc. #### 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 | diff --git a/docs/pages/opsec/risk-management/overview.mdx b/docs/pages/opsec/risk-management/overview.mdx index 3cc4068b..a4c7e66f 100644 --- a/docs/pages/opsec/risk-management/overview.mdx +++ b/docs/pages/opsec/risk-management/overview.mdx @@ -66,7 +66,7 @@ reputational factors 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 | @@ -81,7 +81,7 @@ 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 | @@ -104,7 +104,7 @@ 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 | @@ -114,7 +114,7 @@ In Web3 environments, risk management must address unique challenges: ### 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 | @@ -136,7 +136,7 @@ Building on the threat vectors identified during threat modeling, Pinnipeds Inc. #### Risk Calculation Methodology | Rating | Impact | Likelihood | -|--------|--------|------------| +| -------- | -------- | ------------ | | **1** | Minimal | Rare | | **2** | Minor | Unlikely | | **3** | Moderate | Possible | @@ -148,7 +148,7 @@ Building on the threat vectors identified during threat modeling, Pinnipeds Inc. #### 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 | @@ -156,7 +156,7 @@ Building on the threat vectors identified during threat modeling, Pinnipeds Inc. #### 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 | @@ -164,7 +164,7 @@ Building on the threat vectors identified during threat modeling, Pinnipeds Inc. #### 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 | diff --git a/docs/pages/opsec/threat-modeling-overview.mdx b/docs/pages/opsec/threat-modeling-overview.mdx index 74b4c2d5..700e4abd 100644 --- a/docs/pages/opsec/threat-modeling-overview.mdx +++ b/docs/pages/opsec/threat-modeling-overview.mdx @@ -99,7 +99,7 @@ For these, you can use technologies such as: 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 | @@ -126,7 +126,7 @@ Pinnipeds Inc. is a small company with 15 employees. Here's how they categorized ### 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 | @@ -151,7 +151,7 @@ Pinnipeds Inc. is a small company with 15 employees. Here's how they categorized #### 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 | @@ -160,7 +160,7 @@ Pinnipeds Inc. is a small company with 15 employees. Here's how they categorized #### 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 | @@ -169,7 +169,7 @@ Pinnipeds Inc. is a small company with 15 employees. Here's how they categorized #### 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 | @@ -180,7 +180,7 @@ Pinnipeds Inc. is a small company with 15 employees. Here's how they categorized ## 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 | @@ -206,7 +206,7 @@ The STRIDE framework, developed by Microsoft in the late 1990s, offers a systema 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 | diff --git a/docs/pages/opsec/travel/guide.mdx b/docs/pages/opsec/travel/guide.mdx index 172eeadc..48766169 100644 --- a/docs/pages/opsec/travel/guide.mdx +++ b/docs/pages/opsec/travel/guide.mdx @@ -41,6 +41,8 @@ operational security while traveling. > strong passphrases and never travel with seed phrases. Upon returning, scan devices for malware and consider resetting > high-risk devices. +{/* separator */} + > ❗ This is not, by any means, an extensive guide on this subject or expected to be followed at its core. Its intention > is to guide and provide hints as to where to apply security. This will vary depending on case to case, or, in other > words, the risks you expose yourself to, by specifically traveling. @@ -132,7 +134,8 @@ failure. **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 +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. @@ -277,7 +280,8 @@ snatched[.](https://www.cisa.gov/sites/default/files/publications/Cybersecurity% ### **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, +["**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). @@ -353,7 +357,8 @@ 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 +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. @@ -544,14 +549,17 @@ 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. +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. +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. -- diff --git a/docs/pages/opsec/travel/tldr.mdx b/docs/pages/opsec/travel/tldr.mdx index c8863769..08fe711a 100644 --- a/docs/pages/opsec/travel/tldr.mdx +++ b/docs/pages/opsec/travel/tldr.mdx @@ -62,7 +62,8 @@ anyone tracking you. - 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. +- 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 diff --git a/docs/pages/safe-harbor/overview.mdx b/docs/pages/safe-harbor/overview.mdx index 6400b97a..127de1f9 100644 --- a/docs/pages/safe-harbor/overview.mdx +++ b/docs/pages/safe-harbor/overview.mdx @@ -67,7 +67,7 @@ By adopting Safe Harbor, protocols allow: > [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? diff --git a/docs/pages/treasury-operations/classification.mdx b/docs/pages/treasury-operations/classification.mdx index 203dcbd1..b29b7610 100644 --- a/docs/pages/treasury-operations/classification.mdx +++ b/docs/pages/treasury-operations/classification.mdx @@ -27,7 +27,9 @@ import { -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. +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) @@ -100,7 +102,8 @@ Assess how transactions are executed: - 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. +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 @@ -115,21 +118,19 @@ Note: Single-approver configurations should only be used for low-value operation 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 | +| 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 diff --git a/docs/pages/treasury-operations/enhanced-controls.mdx b/docs/pages/treasury-operations/enhanced-controls.mdx index df28569e..7bd1668a 100644 --- a/docs/pages/treasury-operations/enhanced-controls.mdx +++ b/docs/pages/treasury-operations/enhanced-controls.mdx @@ -38,26 +38,33 @@ For Critical and High impact custodial accounts, implement the following control - 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. +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 + - 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 +- 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) +- 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 +- 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 +- 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 @@ -98,7 +105,8 @@ Suggested approver thresholds (treasury contexts): ## 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. +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: @@ -112,7 +120,10 @@ Core rule elements: ## 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. +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 @@ -120,7 +131,8 @@ A Zero Trust architecture involves continuous verification of user, device, and - 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) +- 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 @@ -130,13 +142,19 @@ A Zero Trust architecture involves continuous verification of user, device, and 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). +- 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. +- 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. +- 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). +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). --- @@ -147,5 +165,3 @@ For Medium and Low impact accounts, leverage custodian's native audit logs with - - diff --git a/docs/pages/treasury-operations/overview.mdx b/docs/pages/treasury-operations/overview.mdx index 61daa93f..34f512f8 100644 --- a/docs/pages/treasury-operations/overview.mdx +++ b/docs/pages/treasury-operations/overview.mdx @@ -29,25 +29,31 @@ import { ## 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. +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. +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. +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. +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. +Step-by-step protocols for receiving and sending large cryptocurrency transfers, including address verification, test +transactions, and multi-party confirmation requirements. ## Getting Started @@ -60,4 +66,3 @@ Step-by-step protocols for receiving and sending large cryptocurrency transfers, - diff --git a/docs/pages/treasury-operations/registration-documents.mdx b/docs/pages/treasury-operations/registration-documents.mdx index 8182d694..4cefc252 100644 --- a/docs/pages/treasury-operations/registration-documents.mdx +++ b/docs/pages/treasury-operations/registration-documents.mdx @@ -27,7 +27,8 @@ import { -Use these standardized templates to register custodial accounts, track access changes, document security configurations, and perform quarterly reviews. +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) @@ -411,5 +412,3 @@ Next Review Due: YYYY-MM-DD - - diff --git a/docs/pages/treasury-operations/transaction-verification.mdx b/docs/pages/treasury-operations/transaction-verification.mdx index cf82276a..1d35ecd1 100644 --- a/docs/pages/treasury-operations/transaction-verification.mdx +++ b/docs/pages/treasury-operations/transaction-verification.mdx @@ -31,7 +31,8 @@ import { ## 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. +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 @@ -46,7 +47,8 @@ The address strategy depends on your custody model: - **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 +- **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**: @@ -76,7 +78,7 @@ Have 2-3 team members independently verify the address: This should occur **24-48 hours before the main transfer**. -**Phase 1: Sender → You (Incoming Test)** +**Phase 1: Sender → You (Incoming Test): ** ``` 1. Sender sends small amount (0.001 ETH or 0.0001 BTC) to your new address @@ -87,14 +89,15 @@ This should occur **24-48 hours before the main transfer**. 3. Document transaction hash and confirmation time ``` -**Phase 2: You → Sender (Outgoing Test)** +**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. +**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 @@ -116,14 +119,22 @@ Request from sender: **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) +- **\>$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. +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. +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:** @@ -131,7 +142,8 @@ Establish code phrase during initial verified meeting. Use this phrase to authen - 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. +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 @@ -272,7 +284,8 @@ Most custody platforms support whitelisting: 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. +**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 @@ -416,7 +429,8 @@ See the Multisigs for Protocols guide. 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. +**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. diff --git a/docs/pages/wallet-security/encumbered-wallets.mdx b/docs/pages/wallet-security/encumbered-wallets.mdx index 25c823b5..723aeef3 100644 --- a/docs/pages/wallet-security/encumbered-wallets.mdx +++ b/docs/pages/wallet-security/encumbered-wallets.mdx @@ -22,96 +22,155 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -### User Profile +## 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. +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 +## 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. +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 +## 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: +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). +* 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) +## 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. +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. + +* **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. +* **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. + +* **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. +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 +## 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. + +* **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. + +* **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. +* **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. +* **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 +* **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. -* 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 +**Operational Flexibility:** -- Austgen, J., Fábrega, A., Kelkar, M., Vilardell, D., Allen, S., Babel, K., Yu, J., & Juels, A. (2024, December 3). Liquefaction: Privately liquefying blockchain assets. arXiv.org. https://arxiv.org/abs/2412.02634 -- Dai, W., Deng, J., Wang, Q., Cui, C., Zou, D., & Jin, H. (2018). SBLWT: a secure blockchain lightweight wallet based on TrustZone. IEEE Access, 6, 40638–40648. https://doi.org/10.1109/access.2018.2856864 -- Yu, J. (n.d.). PASS: A Provenanced Access Subaccount System for Blockchain Wallets [Stanford University]. https://cs191.stanford.edu/projects/Yu,%20Jay_Systems%20191W.pdf -- Aublin, P.-L., Mahhouk, M., & Kapitza, R. (n.d.). Towards TEEs with Large Secure Memory and Integrity Protection Against HW Attacks [IIJ Innovation Institute, TU Braunschweig]. https://www.ibr.cs.tu-bs.de/bib/xml/aublin2022scalableSGX.html +* **Programmable Recovery**: Implement sophisticated recovery mechanisms that work across any blockchain without relying + on smart contract support. +* **Dynamic Policy Updates**: Modify access controls and delegation structures without changing the underlying + blockchain infrastructure. +* **Multi-Asset Management**: Apply consistent policies across different cryptocurrencies and blockchain networks from a + single encumbered wallet system. + +## Security Considerations & Best Practices + +* Implement threshold or multi-party computation-based key custody rather than placing sole trust in a single TEE + enclave. Use multi-party threshold signatures or distributed key generation so that a single compromised node cannot + break the entire system, providing resilience against both hardware attacks and operational failures. +* Incorporate economic incentive mechanisms such as staking requirements for TEE operators to align security incentives + through cryptoeconomic design. Require operators to post collateral that can be slashed for malicious behavior, + attestation failures, or policy violations, creating financial disincentives for compromise attempts and encouraging + proactive security maintenance of TEE infrastructure. +* Carefully evaluate TEE technology selection based on application memory requirements and security priorities. For + encumbered wallet applications with modest memory needs (under 256MB), prefer Intel SGX v1 (Client SGX) which provides + integrity protection against hardware attacks, whereas applications requiring larger secure memory may need to accept + the trade-offs of newer implementations like Scalable SGX or SEV-SNP that offer greater memory capacity but lack + integrity protection against physical attacks. +* Establish continuous re-attestation processes that periodically re-verify enclave conformance on a regular schedule + such as hourly or per-block intervals. This helps detect drift, tampering, or compromise attempts over time and + ensures that the enclave maintains its security properties throughout its operational lifetime. +* Implement dual-attestation architectures for cloud-deployed nodes by requiring both Intel DCAP quotes and cloud + provider attestation services (such as Azure MAA or AWS Nitro Attestation). This approach provides defense-in-depth by + anchoring trust through multiple independent attestation roots with different threat models and security assumptions. +* Maintain transparent attestation policy publication by documenting and publicly sharing allowed CPU models, TCB + versions, QE/PCS builds, and upgrade paths. This enables operators and auditors to verify compliance independently + while providing clear guidance for secure deployment configurations and helping detect potentially compromised or + outdated systems. +* Collaborate with hardware vendors and ecosystem partners to push for enhanced TEE security features including replay + protection, alias detection, and memory mapping integrity. Engage in industry efforts to improve the fundamental + security properties of TEE implementations and advocate for standardized security enhancements across different TEE + platforms. + +## Relevant Papers + +* Austgen, J., Fábrega, A., Kelkar, M., Vilardell, D., Allen, S., Babel, K., Yu, J., & Juels, A. (2024, December 3). + Liquefaction: Privately liquefying blockchain assets. [arXiv.org](https://arxiv.org/abs/2412.02634) +* Dai, W., Deng, J., Wang, Q., Cui, C., Zou, D., & Jin, H. (2018). SBLWT: a secure blockchain lightweight wallet based + on TrustZone. IEEE Access, 6, 40638–40648. [https://doi.org/10.1109/access.2018.2856864](https://doi.org/10.1109/access.2018.2856864) +* Yu, J. (n.d.). PASS: A Provenanced Access Subaccount System for Blockchain Wallets [Stanford University](https://cs191.stanford.edu/projects/Yu,%20Jay_Systems%20191W.pdf) +* Aublin, P.-L., Mahhouk, M., & Kapitza, R. (n.d.). Towards TEEs with Large Secure Memory and Integrity Protection + Against HW Attacks [IIJ Innovation Institute, TU Braunschweig](https://www.ibr.cs.tu-bs.de/bib/xml/aublin2022scalableSGX.html) --- - \ No newline at end of file + diff --git a/docs/pages/wallet-security/intermediates-&-medium-funds.mdx b/docs/pages/wallet-security/intermediates-&-medium-funds.mdx index 1cd866d3..2683ea40 100644 --- a/docs/pages/wallet-security/intermediates-&-medium-funds.mdx +++ b/docs/pages/wallet-security/intermediates-&-medium-funds.mdx @@ -41,7 +41,8 @@ tamper-resistant environment, acting as a vault for the majority of the user's b 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. +* **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. @@ -61,22 +62,25 @@ already configured, as it is likely compromised. ## Initial Setup ### Purchase & Verification - - Verify tamper-resistant packaging is untouched - - Check for authenticity indicators on packaging + +* 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 + +* 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 + +* Second hardware wallet with same seed phrase +* Test both devices can create valid signatures +* Store backup securely +* Monthly verification that backup device functions correctly --- diff --git a/docs/pages/wallet-security/overview.mdx b/docs/pages/wallet-security/overview.mdx index 1bb2474c..d522f7b0 100644 --- a/docs/pages/wallet-security/overview.mdx +++ b/docs/pages/wallet-security/overview.mdx @@ -26,15 +26,23 @@ 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. +- [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. + - [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. diff --git a/docs/pages/wallet-security/secure-multisig-best-practices.mdx b/docs/pages/wallet-security/secure-multisig-best-practices.mdx index a10a51ca..8a88bcd3 100644 --- a/docs/pages/wallet-security/secure-multisig-best-practices.mdx +++ b/docs/pages/wallet-security/secure-multisig-best-practices.mdx @@ -22,7 +22,8 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -> Guidance for designing, operating, and auditing high-assurance multisigs. Use this as your single source for baseline rules, setup guidance, and daily operations. +> 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 @@ -50,12 +51,18 @@ authorize the movement of funds or execute a privileged action. - 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. +- 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. +- 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 @@ -63,7 +70,10 @@ Avoid `N-of-N` schemes, as the loss of a single key would result in a permanent #### 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: +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. @@ -71,28 +81,37 @@ The security of a multisig depends entirely on the operational security (OpSec) ### 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) +- 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. +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 +- 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. @@ -101,48 +120,52 @@ If the original key is lost: ### 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 +- 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 +- **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 +- **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 +- **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 +- **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 +- **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, +- **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, +- **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 +- **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 +- **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. +- **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 diff --git a/docs/pages/wallet-security/secure-multisig-safe-verification.mdx b/docs/pages/wallet-security/secure-multisig-safe-verification.mdx index 74486d09..853c24e3 100644 --- a/docs/pages/wallet-security/secure-multisig-safe-verification.mdx +++ b/docs/pages/wallet-security/secure-multisig-safe-verification.mdx @@ -9,7 +9,6 @@ contributors: users: [isaac, geoffrey, louis, pablo, dickson] - role: reviewed users: [pinalikefruit, engn33r] - --- import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' @@ -22,21 +21,28 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -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. +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. +- **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 +- **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 +- **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) @@ -63,6 +69,7 @@ Please see the [Tools & Resources](/wallet-security/tools-&-resources) page for ![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 @@ -72,15 +79,21 @@ Note: For complex batch transactions that include a delegateCall to multisend, m ## 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. +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. +**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 @@ -89,10 +102,12 @@ The CLI tool pulls the queued transaction from the Safe API for verification. If 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. +- 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 @@ -124,4 +139,3 @@ Signers should not all use identical tools. Cross-verify results between multipl - diff --git a/docs/pages/wallet-security/secure-multisig-signing-process.mdx b/docs/pages/wallet-security/secure-multisig-signing-process.mdx index 7aed56a7..9906a490 100644 --- a/docs/pages/wallet-security/secure-multisig-signing-process.mdx +++ b/docs/pages/wallet-security/secure-multisig-signing-process.mdx @@ -28,7 +28,8 @@ The verification process is divided into two distinct phases: signing the off-ch ## Key Definitions (EVM) -- **Domain Hash**: EIP-712 domain separator, unique to each Safe. Ensures signatures cannot be replayed on other networks or Safes. +- **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. @@ -81,22 +82,29 @@ the network. > 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. +- **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. +- **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"). +- **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. +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. --- diff --git a/docs/pages/wallet-security/secure-multisig-squads-verification.mdx b/docs/pages/wallet-security/secure-multisig-squads-verification.mdx index cccfc2a9..c6f1731c 100644 --- a/docs/pages/wallet-security/secure-multisig-squads-verification.mdx +++ b/docs/pages/wallet-security/secure-multisig-squads-verification.mdx @@ -9,7 +9,6 @@ contributors: users: [isaac, geoffrey, louis, pablo, dickson] - role: reviewed users: [pinalikefruit, engn33r] - --- import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' @@ -18,6 +17,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr # 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. @@ -40,9 +40,11 @@ Limited tooling is available for Solana verification compared to EVM. Exercise e 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. +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 ``` @@ -60,6 +62,7 @@ This shows the destination address for the SOL (H2p…Kr) and the Instruction Da 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 @@ -71,7 +74,9 @@ For the amount portion (`80 96 98 00 00 00 00 00`): 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. +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 ``` @@ -95,7 +100,8 @@ Simulation does NOT seem to work for configuration changes, but we have another 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' +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 @@ -107,8 +113,5 @@ Simulation does NOT seem to work for configuration changes, but we have another - Execute after collecting all signatures - Once all signatures are collected, execute the transaction. - - - diff --git a/docs/pages/wallet-security/seed-phrase-management.mdx b/docs/pages/wallet-security/seed-phrase-management.mdx index 451b52ca..134a1dd1 100644 --- a/docs/pages/wallet-security/seed-phrase-management.mdx +++ b/docs/pages/wallet-security/seed-phrase-management.mdx @@ -40,37 +40,46 @@ As soon as a new wallet is created, back it up using one of the following offlin 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. +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). +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. +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 @@ -82,7 +91,8 @@ Under no circumstances should you ever store your seed phrase in any of the foll - 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. +- 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 @@ -107,25 +117,30 @@ wallets. 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." + +"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. +Remember: Your seed phrase security is the foundation of multisig security. Take time to implement proper storage +procedures appropriate for your risk level. diff --git a/docs/pages/wallet-security/signing-verification.mdx b/docs/pages/wallet-security/signing-verification.mdx index 524120c3..1bbff373 100644 --- a/docs/pages/wallet-security/signing-verification.mdx +++ b/docs/pages/wallet-security/signing-verification.mdx @@ -50,11 +50,17 @@ significant level of risk. 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. +- **[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)**. diff --git a/docs/pages/wallet-security/tools-&-resources.mdx b/docs/pages/wallet-security/tools-&-resources.mdx index 6e670bc0..8f5cadf4 100644 --- a/docs/pages/wallet-security/tools-&-resources.mdx +++ b/docs/pages/wallet-security/tools-&-resources.mdx @@ -64,11 +64,14 @@ data and EIP-712 messages before signing. It is designed to protect against phis 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. +- **[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. +- **[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 diff --git a/wordlist.txt b/wordlist.txt index 702da959..3b32b084 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -4,6 +4,7 @@ Airbnbs AKAMAI ampering anonymization +Aublin authenticator Authy automod @@ -24,7 +25,6 @@ CCPA Certora CIS CISA -clippy Clippy CloudSploit CMDB @@ -32,7 +32,6 @@ CMDBs COBIT collab collateralized -comms Comms confusables Consensys @@ -51,6 +50,7 @@ Cyfrin Cypherock dapp Darknet +DCAP debevoise DeFi DeIRF @@ -62,15 +62,18 @@ DevSecOps discoverable DIY DLP +DMARC DNSSEC DocuSign DPRK Dreww DTEX Dyno +DYOR +ECDSAP EE -Efani EF's +Efani EIP emptively engn @@ -91,6 +94,8 @@ FDE fedcba Fi FIDO +Fábrega +Galxe Gapped Ghostery Gnosis @@ -101,12 +106,14 @@ Hackathon hacken Hackenproof halmos +Hetrix hevm HIDS HIPAA HSM IAPP IAST +ICANN IDOR IDPS IMEI @@ -123,15 +130,21 @@ JEA JIT Jitsi Jong +Juels +Kapitza +kdig keccak KeePassXC +Kelkar KMS Kpis kyc +LDNS levation lexpunk LLVM LUKS +Mahhouk Mailvelope MDM MEE @@ -154,9 +167,12 @@ MVNO Mythril nformation nftdreww +nicinfo +noout Nord oaicite OAuth +Octo ofac OpenSCAP OPSEC @@ -179,6 +195,7 @@ pre Predefining Pretexting programmatically +Provenanced prover pseudonymity pseudonymization @@ -187,23 +204,22 @@ Qwertycards Rabby rata RBAC +RDAP redactions reentrancy reimage renderer requestor resolvability -resolvers Resolvers responder -retainable Retainable Revolut ronin saas sambacha satisfiable -schneier +SBLWT Schneier SDLC SED @@ -225,6 +241,7 @@ SRE srldf SSL SSO +Stax ster Storj TDE @@ -238,20 +255,23 @@ TOS TOTP TPM triaging +Tuta TVL TXT unaudited uncollateralized uncompromised +unproxied Unrekt unstake +unstaking +USDS UTS VDI Vercel verifiability verifiably Vishing -vocs Vocs VPC vyper @@ -273,10 +293,4 @@ zedt Zerouali ZK Zksync -ZWJ -DCAP -Fábrega -Kelkar -Juels -SBLWT -Provenanced \ No newline at end of file +ZWJ \ No newline at end of file