Introduction to Frameworks

Welcome to the Security Frameworks by Security Alliance (SEAL), a curated resource for those seeking knowledge in the realm of blockchain security. Our organization, a collective of dedicated security specialists, is on a mission to spread awareness and educate the community about best practices and potential pitfalls in Web3 security.

Why We Created This Resource

We have noticed a growing need to address the various challenges and issues facing our field, some of which include security threats not specifically aimed at Web3 infrastructure. Recognizing that information is abundant but not always easily accessible, we've compiled and organized existing resources from around the internet and generated new content specifically with this purpose in mind.

Who Can Benefit

Regardless of your background—whether in Web2, Web3, or beyond—these guidelines are open to all who seek to learn and contribute. We aim to establish a comprehensive, high-level security framework for Web3 projects, providing best practices to development teams throughout the lifecycle of their projects. Consider this a one-stop shop for everything related to Web3 security.

How to Contribute

Read our Contribution Guide to learn how you can contribute to this project.

Who We Are

SEAL is a not-for-profit organization committed to enhancing security awareness, education, and specialized work as a public good for the Web3 ecosystem, its supporting technologies, and communities. Our efforts are driven by a shared desire to foster a safer, more informed digital landscape. We do this by designing innovative projects, engaging elite technologists, and coordinating on the social layer to ensure meaningful adoption.

How to Navigate the Website

Navigating the Security Frameworks by SEAL will be designed, in time, to be intuitive and user-friendly. We currently allow users to filter contents by role, but we're not quite there yet. Any feedback on how to improve the usage of frameworks in the future is appreciated.

Categories

The content is organized into different categories, each focusing on a specific aspect of security. Currently, we are under the introduction section, but you can explore the broader category of "Frameworks" below. Each framework is categorized to help you find relevant information quickly.

Filtering by Profile

This is currently being implemented, and we're currently looking for volunteers and collaborators for this specific task. The main objective is to allow users to filter the content by profile to focus on information relevant to their role within the organization. This feature allows them to bypass unnecessary reading and concentrate on what matters most.

Example roles:

• Developer
• Executive
• Security
• Finance
• Crypto
• Management
• Community
• Non-Technical

This targeted approach will ensure you get the most relevant information efficiently.

Overview of Each Framework

Important Disclaimer: The frameworks presented in this documentation are living documents that evolve with the Web3 security landscape. They may undergo restructuring, updates, or modifications in the future to reflect emerging threats, new best practices, and community feedback. We recommend regularly checking for updates to ensure you're working with the most current security guidelines.

This document provides an overview of the various frameworks covered in the Security Frameworks by SEAL. Each framework addresses a specific aspect of Web3 security, providing best practices and guidelines to help secure your projects.

Community Management

This framework explores best practices for securing and managing online communities associated with Web3 projects, covering platforms like Discord, Twitter, Telegram, and Google. It focuses on establishing secure communication channels and community guidelines.

Awareness

This section covers strategies for fostering security awareness among team members and users of Web3 projects, including understanding threat vectors, cultivating a security-aware mindset, and staying informed about security developments.

Operational Security (OpSec)

This comprehensive framework addresses day-to-day security practices for Web3 teams, covering fundamentals, governance, risk management, control domains, lifecycle management, monitoring, incident response, and continuous improvement.

Wallet Security

This section delves into the crucial aspect of managing cryptographic keys in Web3 projects, discussing various wallet types (cold vs hot, custodial vs non-custodial), hardware wallets, signing schemes, and software wallets.

External Security Reviews

This framework provides guidance on conducting and preparing for external security audits and reviews, including setting expectations, preparation, security policies, and vendor selection.

Vulnerability Disclosure

This section discusses best practices for handling and disclosing vulnerabilities in Web3 projects, including establishing security contacts and managing bug bounty programs.

Infrastructure

This section covers the fundamental aspects of securing the underlying infrastructure of Web3 projects, including asset inventory, cloud infrastructure, DDoS protection, DNS security, IAM, network security, and zero-trust principles.

Monitoring

This framework discusses the importance of continuous monitoring in Web3 projects, focusing on setting up effective monitoring systems and defining appropriate thresholds for alerts.

Front-End/Web Application

This section addresses security considerations specific to the user-facing components of Web3 projects, including both web and mobile application security, common vulnerabilities, and security tools.

Incident Management

This section outlines protocols for handling security incidents, including communication strategies, detection and response procedures, lessons learned, and playbooks, including specific guidelines for SEAL 911 War Room.

Threat Modeling

This framework provides guidance on creating and maintaining threat models, as well as identifying and mitigating potential threats to Web3 projects.

Governance

This section addresses risk management, regulatory compliance, and security metrics for Web3 projects, ensuring proper oversight and control.

DevSecOps

This framework focuses on integrating security practices into the development and operations processes, covering code signing, CI/CD, IDE security, repository hardening, and security testing.

Privacy

This section explores tools and practices for maintaining privacy in the Web3 ecosystem, including secure browsing, data removal, digital footprint management, encrypted communication, and privacy-focused operating systems.

Supply Chain

This framework addresses the security implications of dependencies and third-party components in Web3 projects, including dependency awareness and supply chain levels for software artifacts.

Security Automation

This section explores ways to automate security processes in Web3 projects, including threat detection and response, compliance checks, and infrastructure as code.

Identity and Access Management (IAM)

This framework covers best practices for managing user identities and access control in Web3 projects, including role-based access control and secure authentication.

Secure Software Development

This section focuses on integrating security practices throughout the software development lifecycle, including secure coding standards, code reviews, and secure design principles.

Security Testing

This framework explores various methods of testing Web3 projects for security vulnerabilities, including dynamic and static application security testing, fuzz testing, and security regression testing.

ENS

This section covers Ethereum Name Service security considerations, including data integrity, cross-chain compatibility, smart contract integration, interface compliance, and name handling.

Safe Harbor

This framework provides guidance on establishing safe harbor protocols for security researchers, including key terms, protocols, technical outlines, and whitehat guidelines.

Encryption

This comprehensive section covers various encryption methods and their applications in protecting data, including cloud data encryption, communication encryption, database encryption, and various types of storage encryption.

Community Management

Communities might be the key of many Web3 projects, but they also represent a significant security challenge. From casual users to top-level executives, everyone within an organization can be targeted by social engineering tactics across platforms like Telegram, Discord, X (formerly Twitter), Google, and more. When a community channel is compromised—whether by phishing, fraudulent links, or account takeovers—it can quickly become a vehicle for wider attacks, putting both users and organizational reputations at risk.

Here, we present essential best practices to safeguard your community. In the following sections, we will explore platform-specific recommendations in more depth.

---

Best Practices for Community Security

Strong Passwords and Two-Factor Authentication (2FA)

• Use unique, complex passwords for each service and store them securely in a reputable password manager. Refer to the Operational Security Framework and Wallet Security Framework for more information on this.
• Secure the email account linked to your community platforms with a unique password and 2FA.
• Always enable 2FA. Prefer hardware-based tokens (e.g., Yubikey) or mobile authenticator apps over SMS-based methods, which are vulnerable to SIM-swapping.
• If you use an authenticator app like Authy, 1Password, or Aegis to generate time-based one-time passwords (TOTP). Ensure that the secret keys are stored encrypted and protected with robust security measures.
• Configure your app to require a password, PIN, or biometric authentication (e.g., fingerprint or face recognition) to unlock access to the tokens. This prevents unauthorized access and ensures the tokens remain secure even if someone gains physical or remote access to your device.
• Keep password generation and 2FA codes separate; do not use your password manager to generate 2FA codes. Otherwise, if the password manager is compromised, it could render the 2FA ineffective, allowing unauthorized access to your accounts.
• Encourage community members to adopt these practices as well.

Phishing Awareness

• Educate members on recognizing and reporting phishing attempts.
• Clearly communicate to community members that your team will never send the first direct message to them. This is important because attackers often impersonate team members and initiate direct messages to trick users into believing they are legitimate, thereby gaining their trust and potentially compromising their security.
• Publicly define all official communication channels used by your organization.

Refer to the Security Awareness framework to learn more about social engineering techniques and security training best practices.

Operational Security (OpSec)

• Be mindful of the devices you use to manage community channels. Malware or compromised hardware can give attackers an entry point.
• Regularly update software, run antivirus checks, and avoid installing untrusted applications that may compromise your security.

For a comprehensive understanding of Operational Security, including additional strategies and guidelines, please refer to the dedicated Operational Security framework.

Emergency Response Plan

• Prepare a clear protocol for handling security incidents, including how to quickly remove compromised accounts and warn community members.
• Adopt a proactive mindset: it's not a matter of if but when a breach will occur. Having a plan in place helps you act decisively and contain damage.

As part of the communication team, it is crucial to know when and how to communicate effectively during an incident. This involves understanding the appropriate timing and messaging to ensure clarity and prevent misinformation. For more insights on where this role fits within an incident, refer to the Incident Management framework.

Discord Security

🔑 Key Takeaway for Discord: To secure your Discord server, focus on implementing robust access controls and enforcing two-factor authentication for all administrators. Regularly audit roles and permissions, and maintain vigilant moderation. Educate your community about security best practices to prevent unauthorized access and protect against potential threats.

Discord offers a variety of security features that are essential to use. Despite these, users should stay alert to threats like phishing, which can target server moderators. Such threats may appear as QR code scams, fake login screens, or misleading direct messages pretending to be from Discord support.

To enhance the security of your Discord server, take into account these suggestions. They cover important aspects like server settings, roles and permissions, moderation, bots, channels, invites, member screening, logging, and other security measures.

---

Essential Security Measures

Server Settings

a) Enable 2FA Requirement for Moderation

• Go to Server Settings > Safety Setup > Moderation
• Toggle on "Require 2FA for moderation"
• This ensures all moderators have an extra layer of security

b) Set Appropriate Verification Level

• Go to Server Settings > Safety Setup > Verification Level
• Choose from: None, Low, Medium, High, Highest
• Recommended: "Moderate" for public servers (requires users are registered on discord for longer then 5 min.)
• Higher levels protect against spammers and raids

c) Enable Explicit Content Filter

• Go to Server Settings > Safety Setup > Content Filter
• Set to "Scan messages from all members"
• This automatically blocks messages containing explicit images in non-age-restricted channels
• Age-restricted channels are exempt from this filter

d) Enable Raid Protection and CAPTCHA

• Go to Server Settings > Safety Setup > Raid Protection and Captcha
• Activate all relevant settings to require CAPTCHA for new user actions
• This protection uses machine learning to detect and block bot-driven join-raids
• When activated:
  • Sends alerts to a specified channel
  • Requires CAPTCHA verification for new users for one hour after detection

Roles and Permissions

a) Implement Role Hierarchy

• Go to Server Settings > Roles

• Create roles like: Cold Admin, Team, Moderator, & Verified.

• Drag to reorder; higher roles override lower roles

• Restructure the role hierarchy by dragging roles higher or lower in the roles list:

  • Cold Admin
  • Team
  • Moderator
  • Verified

b) Restrict Administrative Permissions

• For each role, carefully review the 32 available permissions
• Key permissions to restrict: Administrator, Manage Webhooks, Manage Server, Manage Roles, & Manage Channels
• Never give Admin or Kick permissions to anyone you don't fully trust
• Good permissions for moderators: Manage Channels, Manage Roles, Manage Messages, Ban Members, Delete Messages
• Good permissions for members: View Channels, View audit logs, Create Invite, Manage Messages, Read Message History, Connect, Speak & Use Voice Activity, & Ban/Kick/Timeout

c) Use Channel-Specific Permissions

• Right-click on a channel > Edit Channel > Permissions
• Set custom permissions for roles or members in specific channels

d) Use the "View Server as Role" Feature

• Go to Server Settings > Roles > Select a role > View Server as Role
• This allows you to see what members with a certain role can see and access

Advanced Security Measures

Moderation

a) Set Up Auto-Moderation Rules

• Go to Server Settings > AutoMod
• Set up rules for: Spam, Harmful Links, Mention Spam, Inappropriate Words
• Configure custom keyword filters and exempted roles
• Customize the response to spam, like blocking the message, sending an alert, or timing out the member
• Add to the existing automod rule to block keywords in a users name, and put Support, Bot, Admin, Tech, Helpdesk, etc.

b) Configure Timeout Duration

• Go to Server Settings > Safety Setup > Timeout
• Set default duration (e.g., 60 minutes)
• Educate moderators on using timeouts effectively

c) Establish Clear Server Rules

• Create a #rules channel
• Use Discord's built-in rules screening feature
• Include sections on: Behavior, Content, Moderation Actions, Appeals Process

Extra Moderation Best Practices

a) Leverage "Default Notifications to Mentions Only"

• Go to Server Settings > Overview and set Default Notifications to Mentions Only.
• Reduces potential spam notifications for members, making them more vigilant about suspicious or phishing content.

b) Stay Alert to New Features & Potential Exploits

• Keep track of newly introduced features such as Threads, Scheduled Events, or Stage Channels.
• Configure their permissions carefully (e.g., who can start or join a Thread) to prevent abuse by spammers or scammers.

c) Regularly Check Third-Party Bot Security

• Ensure bots are from reputable sources and receive frequent updates.
• Review bot permissions after each significant update to avoid newly introduced vulnerabilities.

Bots

a) Audit Bot Permissions

• Go to Server Settings > Integrations
• Review each bot's permissions
• Remove unnecessary permissions
• Remove permissions for bots that ask for Admin or other permissions that aren't needed, use least privilege with permissions at the role level and channel level.

b) Remove Unnecessary Bots

• Uninstall any bots that aren't actively used or needed

c) Implement Security/Moderation Bots

• Consider bots like:
  • Dyno for advanced moderation and logging
  • Carl-bot for reaction roles and custom commands
  • Set up security Bots

Security-Specific Bots

Various third-party Discord bots offer valuable security and protection features, facilitating automated moderation for your server. In the sections below, we'll explore different categories of security bots and highlight popular options for each category.

Anti-Impersonation Bots

Set up custom rules to prevent other users from joining using the same username and PFP (profile picture) to impersonate you or other important members of the server. A popular bot in this category is Wick Bot.

Anti-Raid Bots

to prevent spam bots from joining your server all at once, an attack known as raiding, you can also set up bots with particular rules. Beemo is a good example of a bot in this category.

Anti-Nuke Bots

This is a monitoring system to observe and note any changes (spontaneous or planned) that take place in your discord server. Some key observation markers are channel and role creation/deletions, banning or kicking members, and webhook creation/deletion.

Moderation & Link Whitelisting Bots

Only allows approved links to be used in the discord server. A popular bot in this category is Goodknight Bot.

The bots above are not all-inclusive but rather a recommended list of bots to help protect your Discord server in these categories.

Enhanced Server Configuration

Channels

a) Organize Channels Logically

• Use categories to group related channels
• Suggested categories: Information, General, Voice Channels, Topic-Specific

b) Set Slow Mode Where Needed

• Channel Settings > Overview > Slow Mode
• Set appropriate cooldown (e.g., 5-30 seconds) for busy channels

c) Use Age-Restricted Channels Appropriately

• Channel Settings > Overview > Age-Restricted Channel
• Enable for channels with mature content

Invites

a) Disable Permanent Invites

• Server Settings > Invites
• Un-check "Allow anyone with administrative permissions to create invites"

b) Set Invite Expiration and Usage Limits

• When creating an invite: Set "Expire After" and "Max Number of Uses"
• Recommended: 24 hours expiration, 50-100 uses

c) Regularly Audit Active Invites

• Server Settings > Invites
• Review and delete unnecessary or old invites

Member Screening

a) Enable Membership Screening

• Server Settings > Safety Setup > Membership Screening
• Toggle on "Enable Membership Screening"

b) Set Up Screening Questionnaire

• Add questions about server rules, age verification, etc.
• Require members to agree to rules before joining

c) Set Up Membership Requirements

• Require users to react to a message or post an introduction
• This helps filter out bots and spam accounts from joining

Logging

a) Enable Audit Logs

• Ensure admin/mod roles have "View Audit Log" permission

b) Set Up a Private Logging Channel

• Create a private channel visible only to admins/mods
• Use a logging bot like Logger or Dyno to send detailed logs

Best Practices & Administrative Security

Regular Reviews

a) Conduct Periodic Permission Audits

• Monthly: Review all role permissions
• Use a spreadsheet to track changes and justifications

b) Review and Update Server Rules

• Quarterly: Assess if rules need updating
• Announce any changes in a dedicated announcements channel

c) Check for Unused Channels/Roles

• Bi-annually: Delete or archive inactive channels
• Remove roles that are no longer needed

Cold Admin Accounts

a) Set Up a "Cold" Admin Account

• Create a new account on a separate device never used for chatting or clicking links
• This account is highly resistant to phishing and provides an extra layer of security for the server owner

b) Secure the Cold Account

• Create a new email account for the cold account
• Factory reset the device used for this account

c) Use the Cold Account for Critical Actions

• Manage bots, modify server settings, and respond to compromises
• Never use this account for regular server activities

d) Disable QR Code Login on Cold Device

• In User Settings > Privacy & Safety, deselect any quick login or QR scan options.
• Prevents attackers from using QR phishing tactics to hijack this high-privilege account.

Additional Community Features

a) Enable the Community Feature (Newer Discord Update)

• Go to Server Settings > Community to activate the Community Feature.
• Unlocks tools like membership screening, server insights, welcome screen, and discovery settings.
• Helps maintain a structured, secure environment by surfacing official rules and critical info to newcomers.

b) Review Updated Discord Moderation Resources

• Consult the official Discord Moderator Academy for ongoing best practices and new features.
• Implement recommended strategies (e.g., improved spam filters, updated role recommendations).

Platform-Specific Security Considerations

Additional Security Measures

a) Verification Systems

• Implement a verification bot like Wick
• Require users to complete an in-channel captcha before accessing the server
• Advance Settings: Have verification bot filter based on account age, PFP set, and timeout for incomplete captcha

b) Raid Protection

• Use anti-raid bots like Wick or Dyno
• Configure automatic lock-down settings for suspicious activity

c) Privacy Settings

• Server Settings > Privacy Settings
• Disable "Allow direct messages from server members"

d) Integration Whitelisting

• Server Settings > Integrations > Allow new integrations to be added by:
• Set to "Only Administrators" to prevent unauthorized bot additions

e) Server Insights

• Enable Server Insights for detailed analytics
• Use this data to inform moderation strategies and server improvements

f) Backup Systems

• Use a bot like ServerBackup to regularly backup your server configuration
• Store backups securely off-platform

g) Audit New Integration/Link Safety Settings

• Regularly review Server Settings > Integrations for newly added apps or link shorteners.
• Disable suspicious integrations or automate link scanning with a bot that checks URLs against known phishing databases.

h) Enable Safe Direct Messaging for All Users

• In User Settings > Privacy & Safety, select Keep Me Safe for direct messages.
• Encourages moderators and community members to adopt the same setting to minimize phishing DMs.

Additional Resources

• Securing Your Server - Discord
• Four Steps for a Super Safe Server - Discord
• How to setup a Discord server securely

X (Twitter) Security

🔑 Key Takeaway for Twitter (X): To secure your Twitter account, prioritize using an authenticator app or security key over SMS-based 2FA, remove your phone number, and regularly review third-party app permissions. Ensure your recovery settings are robust and frequently monitor account activity to safeguard your online presence and maintain community trust.

A compromised X account can harm not only you but also your community. Attackers often use phishing tactics—like SIM swaps or fake login screens—to seize control of your profile. A few simple steps can significantly reduce these risks.

Securing your Twitter account is not particularly hard or time consuming, so consider following the best practices below.

---

Essential Security Measures

Remove your phone number

There are no good reasons to keep a phone number attached to your account, and it's the easiest way for a hacker to get into your account after SIM swapping you. Getting verified requires you to add a phone number, but you can remove it afterward.

1. Go to: Phone Settings
2. Remove: Click Delete phone number if one is listed.

After removing your phone number, it's crucial to navigate to Settings > Security and Account Access > Security > Two-Factor Authentication > Backup Codes. Store these codes offline, just like your seed phrase. Anyone with these codes can bypass your 2FA, so it's extremely important to write them down and keep them secure. Remember, when you change your password, new backup codes are generated.

Configure 2FA

Two-factor authentication is a great way to keep hackers at bay, but it's not foolproof if you're relying on SMS 2FA and someone gets hold of your phone number. It's generally better to use an authenticator app or a security key. Also, ensure your backup codes are stored safely, ideally printed on paper rather than saved on your device.

1. Go to: Login Verification
2. Disable: Un-check Text message
3. Enable: Choose Authentication app and/or Security key
   1. If using an authentication app, store your secret (TOTP) in a reliable app (Authy, Google Authenticator), but disable syncing for added security.
   2. If using security keys, keep at least two (e.g., from Yubico) in case one fails.
4. Under Additional methods, below, select Backup codes and create a new backup code. Store this code securely, offline, ideally in a physical format like a printout, to ensure that if one device is compromised, the code remains safe.

Enable password reset protect

Twitter provides a feature that requires users to input their email or phone number linked to the account before they can initiate a password reset. This adds an extra layer of security by ensuring that hackers must know your email, rather than receiving a hint.

1. Go to: Security Settings
2. Toggle On: Check Password reset protect.

Advanced Security Measures

Revoke access from delegated accounts

It's possible to allow other accounts to access your Twitter account. If your account was previously compromised, attackers could exploit this feature to maintain access even after you've regained control.

1. Go to: Delegate Members
2. Review: Remove any unfamiliar accounts.

Revoke access from unnecessary apps

It's possible that you've linked your Twitter account to several apps, and some might have more permissions than necessary. To check and manage these permissions, follow these steps:

1. Go to: Connected Apps
2. Review: Check each app's permissions and Revoke if it's no longer needed or trusted.

Log Out of Unnecessary Sessions

It's possible you've accessed Twitter from devices you don't regularly use, like a friend's phone. Review your active sessions and log out of any that are unfamiliar or unnecessary.

Old sessions on unfamiliar devices can be risky.

1. Go to: Sessions
2. Log Out: For any device or session you don't recognize.

Verify Your Email is Current

If you've changed your email since creating your Twitter account, ensure your current email is linked to receive security alerts and updates.

1. Go to: Email Settings
2. Confirm: Update to your current email if needed.

Refresh Your Password

Using a unique password for Twitter is crucial. If you haven't set one, now is the time to do so.

1. Go to: Password Settings
2. Change: Select a long, complex password.

Best Practices & Additional Tips

• Disable Email and Phone Discoverability

  • Go to: Discoverability and Contacts
  • It is recommended to turn both email and phone discoverability off.

• Privacy & Safety Settings:

  • In Privacy & Safety, consider disabling "Allow message requests from everyone" to limit spam DMs and phishing attempts and enabling "Filter low-quality messages".

• Monitor for Suspicious Alerts:

  • X (Twitter) may notify you about unusual activity. If you suspect a breach, log out of all sessions, revoke suspicious apps, and change your password immediately.

• Use Unique Recovery Methods:

  • If you choose to use a recovery phone number, which we generally strongly advise against, make sure it isn't your main mobile number. Instead, use a separate VoIP or alternative line to minimize the risk of SIM swapping.

• If you received an email about any content moderation, login, or any email from "X"; ensure the email is from "@x.com"

Telegram Security

🔑 Key Takeaway: Stay vigilant with group chats on Telegram. Implement verification steps and secure communication practices to protect against sophisticated interception attacks.

While Telegram is widely used in the crypto community, it's crucial to understand its security limitations. Telegram does not offer end-to-end encryption (E2EE) by default, which means your messages could potentially be accessed by third parties. Additionally, Telegram's reliance on phone numbers for account creation can expose users to SIM swapping attacks, and its peer-to-peer call feature can reveal your IP address to other users. If E2EE is a priority, consider using Signal.

However, if you choose to use Telegram, the following best practices can help enhance your security.

---

Essential Security Measures

Configure 2FA

Telegram sign-ups require a phone number, but you can also enable two-factor authentication via a password—your main protection if you're ever SIM-swapped. Don't reuse this password anywhere else.

1. Go to: Settings > Privacy and Security > Two-Step Verification
2. Set: A strong password and recovery email (store both in a password manager)

Hide Your Phone Number

Making your phone number visible can expose you to unwanted contact or social engineering attacks. Restricting visibility helps safeguard your personal info.

1. Go to: Settings > Privacy and Security > Phone Number
2. Who can see my phone number?: Select Nobody
3. Who can find me by my number?: Select My contacts

Disable P2P Calling

By default, Telegram calls can connect you directly to the other user, potentially revealing your IP address.

1. Go to: Settings > Privacy and Security > Calls
2. Use peer-to-peer with: Select Nobody

Manage Inactive Sessions

Telegram supports auto-terminating inactive sessions. You can also manually review and end any suspicious active sessions.

1. Go to: Settings > Privacy and Security > Active sessions
2. Review: Delete any sessions you don't recognize
3. Auto-terminate: Set inactive sessions to end after 1 month

Implement Device-Level Security

Securing the device you use for Telegram is crucial for preventing unauthorized access to your account and messages.

1. Enable Full Device Encryption:

   • Ensure your device has full disk encryption enabled
   • For iOS: This is enabled by default with a passcode
   • For Android: Go to Settings > Security > Encryption and follow instructions

2. Set Strong Device Passcodes:

   • Use alphanumeric passwords rather than simple PINs
   • Enable biometric authentication as a secondary measure

3. Keep Your Device Updated:

   • Install OS updates promptly to patch security vulnerabilities
   • Update Telegram to the latest version regularly

4. Install Security Software:

   • Use reputable anti-malware software on your device
   • Consider privacy-focused apps that detect network anomalies

5. Secure Your Backups:

   • Ensure any device backups containing Telegram data are encrypted
   • Be cautious about cloud backups that might store Telegram messages

Advanced Security Measures

Consider Using a Different Phone Number

Even if you implement all the recommended security measures, there are still valid reasons to use a separate phone number. For instance, it can help prevent your contacts from discovering your Telegram account or reduce the risk of accidental number exposure. This is particularly important because the "Share My Phone Number" option is enabled by default whenever you add a new contact.

Using a VoIP Number

Telegram restricts many VoIP providers, but services like Google Voice or Burner might work. Purchase a burner number solely for Telegram if you prefer additional anonymity.

Using an Anonymous Number

In December 2022, Telegram introduced support for anonymous numbers purchased through its TON blockchain infrastructure. You can also check out Fragment for such options.

Turn On Auto-delete Messages

Consider the photo you shared with a friend several months ago. While it might have slipped your mind, an attacker who gains access to your account could find such information quite valuable.

1. Go to: Settings > Privacy and Security > Auto-Delete Messages
2. Set: Choose a time frame (e.g., 1 week) based on your risk tolerance

Use Secret Chats for Enhanced Privacy

For conversations that require an extra layer of security, use Telegram's Secret Chats, which offer end-to-end encryption.

1. Start a Secret Chat: Open the chat with the desired contact, tap on their name, and select Start Secret Chat
2. Benefits:
   • Messages are encrypted and can only be read by you and the recipient
   • Offers self-destruct timers for messages
   • Prevents forwarding of messages to other chats

Regularly Update the Telegram App

Ensure you are always using the latest version of Telegram to benefit from the newest security patches and features.

1. Check for Updates: Visit your device's app store regularly
2. Enable Automatic Updates: If possible, turn on automatic updates to stay current

Be Cautious with Third-Party Bots and Integrations

Third-party bots can enhance functionality but may also introduce vulnerabilities.

1. Use Trusted Bots: Only add bots from reputable sources
2. Review Permissions: Limit the permissions you grant to bots
3. Regular Audits: Periodically review and remove unnecessary bots

Manage Group and Channel Admin Permissions

If you manage Telegram groups or channels, properly configuring admin permissions is crucial for maintaining security.

1. Limit Admin Privileges:

   • Go to your group/channel, tap the group name, select Administrators
   • Only grant necessary permissions to each admin
   • Avoid giving "Add Users" permission to untrusted admins

2. Implement Admin Verification:

   • Establish a verification process before promoting members to admin
   • Use separate channels (like voice calls) to confirm admin identities
   • Document when admin changes occur and why

3. Configure Group Settings:

   • Restrict member actions such as sending media or links
   • Enable "Slow Mode" for large groups to prevent spam
   • Use discussion groups for channels to control information flow

4. Audit Admin Activities:

   • Regularly review admin actions in the group
   • Remove inactive or suspicious admins
   • Consider using admin action logs if available

5. Handle Admin Transitions Securely:

   • Have protocols for transferring ownership if needed
   • Revoke admin rights immediately when team members leave

Enhanced Privacy Settings

Passcode Lock

• Settings > Privacy and Security > Passcode Lock: This feature adds a passcode to access your Telegram app after a period of inactivity. The default setting is "away for 1 hour."
  • Recommendations:
    • Store Passcode Securely: Do not lose this passcode—store it offline if needed.
    • Unique Passcode: Ensure it is different from your phone's unlock passcode.

Privacy and Security Settings

Go to: Settings > Privacy and Security

Security

Two-Step Verification

• Overview: Telegram does not require a login by default. However, you can set up a password that acts as a "second" 2FA method when logging in from a new device.
• Security Measures:
  • SMS Codes: Telegram sends a code via SMS, which is not secure.
  • Email Recovery: Offers email recovery, which is more secure but lacks options for authenticator apps or hardware keys.
• Important:
  • Backup Password: If you lose this password, access to your account may be compromised.
  • Secure Storage: Write it down offline and ensure it is not lost.

Additional Privacy Settings

Consider adjusting the following settings based on your country, usage, and purpose for using Telegram:

• Phone Number: Set to Nobody to prevent exposure.
• Last Seen & Online: Set to Nobody to enhance privacy.
• Profile Picture: Set to Everybody to stop scammers from impersonating your profile picture.
• Bio: Set to Nobody (depending on use of Telegram).
• Date of Birth: Set to Nobody.
• Forwarded Messages: Set to Nobody.
• Calls: Set to Nobody or Contacts Only (depending on use of Telegram).
• Voice Messages: Set to Contacts Only (depending on use of Telegram).
• Messages: Set to Everybody or Contacts Only (depending on use of Telegram).
• Invites: Set to Contacts Only or Nobody to prevent being added to random groups that may impersonate legitimate groups and lead to scams.

Data Settings

Go to: Settings > Privacy and Security > Data Settings

• Sync Contacts: Disable (depending on use of Telegram) to prevent syncing your contacts.
• Suggest Frequent Contacts: Disable (depending on use of Telegram) to avoid unsolicited contact suggestions.

Best Practices & Tips for Safe Use

• Use Secret Chats: When messaging someone, create a 'secret' chat to ensure encrypted 1:1 communication, providing end-to-end encryption for sensitive transactions.
• Verify Group Invites and Authenticity: Always triple-check group invitations and confirm the legitimacy of group chats through separate channels to avoid joining impostor groups that share malicious links.
• Beware of Unsolicited DMs: Never trust direct messages from anyone sending links or posing as "support," "exchanges," or "team" members.
• Double-Check Payment Details: Verify payment information through multiple methods before transferring funds to prevent fund redirection.
• Block and Report Scammers: Use the block function to prevent further contact, and report spammers/scammers instead of just deleting chats.
• Limit Group Permissions: Restrict who can add members to groups to prevent unauthorized cloning and protect against raids.

Educate Community Members on Security Practices

If you're managing a community on Telegram, educating your members about security is vital for collective protection.

1. Regular Security Announcements:

   • Schedule periodic reminders about security best practices
   • Pin important security announcements in your group/channel
   • Create dedicated security FAQ channels or posts

2. Clear Verification Procedures:

   • Establish and communicate how official communications will occur
   • Create verification steps for new members to follow
   • Document how to verify the authenticity of admins and official messages

3. Threat Awareness Training:

   • Share examples of common scams targeting your community
   • Post screenshots of phishing attempts (with sensitive info redacted)
   • Explain the "Man-in-the-Group Attack" and how to avoid it

4. Incident Reporting Protocol:

   • Create clear guidelines for reporting suspicious activity
   • Designate security-focused admins to handle reports
   • Acknowledge reports publicly (without specifics) to encourage vigilance

5. Security Resources:

   • Develop simple, accessible security guides for members
   • Share platform-specific security updates when Telegram releases them
   • Create a security checklist for new community members

• Exercise Caution with Mini Apps: Avoid logging in or providing information to mini apps that redirect outside of Telegram. Triple-check the username of the mini app to ensure its legitimacy, as Telegram lacks a bot verification system. Never download or run any commands from Telegram on your device.
• Enhance Privacy with a VPN: Advanced tip: Set up a proxy or VPN to hide your IP address while using the Telegram app.
• Stay Vigilant Against Scam Ads: Be aware that anyone can post ads in channels, with 99% being scam ads. Exercise caution when interacting with advertisements.

Platform-Specific Risks: Man-in-the-Group Attack

Attackers can exploit Telegram's group chat features to intercept and manipulate communications between two parties. Here's a concise example of how such an attack might occur:

Scenario: Intercepting a Payment Deal

Step 1: Initial Communication

• Alice and Bob decide to finalize a cryptocurrency deal using a Telegram group chat named "Crypto Deals".

Step 2: Attackers Create Cloned Groups

• Attacker 1 creates Group A impersonating Alice.
• Attacker 2 creates Group B impersonating Bob.

Step 3: Replicating Conversations

• In Group A (Impersonating Alice):

  • The attacker, posing as Alice, relays Alice's messages from Group B to maintain the conversation.

• In Group B (Impersonating Bob):

  • The attacker, posing as Bob, mirrors Bob's messages from Group A, acting as a middleman without altering the content.

Step 4: Swapping Payment Details

• In Group A:

  • Fake Alice and Bob agree to the terms of the deal.
  • Bob shares his payment address.

• In Group B:

  • Fake Bob shares his swapped payment address.
  • The conversation continues normally, with neither Alice nor Bob aware of the swap.

Step 5: Execution of the Scam

• Alice sends the payment to what she believes are Bob's details but are actually those of Fake Bob.
• The attacker now controls both ends of the conversation, having successfully redirected the funds.

Google Security

🔑 Key Takeaway: Enhance your Google account security by implementing robust 2FA, eliminating redundant recovery options, and diligently overseeing third-party access.

Google provides a wide range of services—from email to file storage. Safeguarding your Google account is among the most critical steps you can take to protect your personal and professional data. Below are simple yet effective measures to improve your Google account security.

---

Essential Security Measures

This section does not include Google Suite or more advanced security configurations. For that, refer to the Operational Security Framework, under Google Suite Security.

Configure 2FA

Properly setting up two-factor authentication (2FA) is one of the most crucial steps you can take. Disable SMS 2FA to avoid SIM swaps, and instead use an authenticator app or a hardware security key (preferred).

1. Go to Google 2-Step Verification
2. Disable: "Voice or text message" if it's enabled
3. Enable: "Authenticator app" and/or "Passkeys and security keys". You can also can continue using Google prompts.
4. Store Backup Codes: Keep them offline in a secure place

Remove Recovery Methods

By default, Google allows account recovery using phone numbers and emails. Attackers can exploit these if they compromise your phone or email.

1. Go to: Google Recovery Phone
2. Remove: Any phone number listed
3. Optional: If you're confident you won't need standard recovery processes:
   1. Go to: Google Recovery Email
   2. Remove: Any recovery email present

Manage Active Sessions

Keeping track of active sessions helps you detect unauthorized access.

1. Go to: Google Device Activity
2. Terminate: Any session you don't recognize

Manage OAuth Applications

Some apps request extensive permissions (e.g., full inbox or file access). Regularly review these to minimize risks.

1. Go to: Google Connections
2. Review: Each connected app's permissions; remove if unnecessary or excessive

Hide Personal Information

Publicly visible personal info can aid attackers in impersonating you.

1. Go to: Google Profile
2. Check Visibility: If any info is set to "Anyone," switch it to private if unnecessary
   • Birthday: Consider making it private

Advanced Security Measures

Extended Security Settings

1. Start from: Google Security.
2. Go to:"Your connect to third-party apps & Services".
3. Revoke: all applications that should not be connected.
4. Go to: "Log out of all unknown devices"
5. Turn off: "skip password when possible" (below previous step)
6. Go to: "How you sign in with Google"
7. Setup: your 2FA or Security Key in this section
8. Ensure you do not have a recovery phone setup. No SMS 2FA or phone number on your account at all.

Once these steps are completed, please change your password. Remember to note down your backup codes.

If using Google Authenticator as a 2FA app on your phone, disconnect it from the cloud, as backup codes are then stored in the google cloud associated to email. Use it without an account and ensure backup codes are written down offline.

Advanced Protection Program

For those who are public figures or need heightened security, Google's Advanced Protection Program is worth considering. It requires the use of security keys, limits access to unverified apps, and makes the process of account recovery more challenging.

1. Go to Google Advanced Protection Program
2. Enroll: Follow the on-screen steps

Best Practices & Additional Tips

• Review Security Alerts: Pay attention to any email or phone notifications from Google regarding unusual sign-ins or account changes.
• Perform a Security Checkup: Regularly visit Google's Security Checkup to identify potential issues and resolve them.
• Consider using identity monitoring apps like Push Security.

Security Awareness

Key Takeaway Stay vigilant, your awareness is your strongest defense against cyber threats. Recognizing red flags and questioning unexpected requests can prevent costly breaches.

This framework is all about understanding the threat landscape, recognizing risk signals, and cultivating a security-aware mindset. It serves as a high-level guide to help individuals and organizations identify potential vulnerabilities and remain vigilant—without overlapping with the detailed, technical scenarios covered in other sections.

Introduction & Objectives

The modern digital landscape is filled with sophisticated attacks, including web3-specific threats like crypto drainers and rug pulls. This section lays the foundation for why a high level of security awareness is essential. It's about empowering you to notice, question, and respond appropriately when something feels off. Trust, but verify!

Objectives

• Recognize Threats: Understand common tactics used by cybercriminals, including both traditional and web3-specific attack vectors.
• Adopt a Proactive Stance: Learn how early recognition can stop an attack in its tracks.
• Foster a Security Culture: Build an organizational environment where security is everyone's responsibility.
• Implement Effective Training: Develop structured approaches to security education for all team members.
• Separate Awareness from Implementation: Focus here on "being aware" rather than the step-by-step controls, which are covered in other sections.

Contents

1. Core Awareness Principles - Foundational security concepts and mindsets that form the basis of security awareness
2. Understanding Threat Vectors - Comprehensive overview of attack methods, indicators, and preventive measures
3. Cultivating a Security-Aware Mindset - Behavioral practices and organizational strategies for building a security culture
4. Staying Informed & Continuous Learning - Training frameworks, educational approaches, and information sources
5. Resources & Further Reading - External tools, references, and resources for ongoing security education

1. Core Awareness Principles

🔑 Key Takeaway: Security awareness is built on fundamental principles like threat recognition, risk assessment, and zero trust verification. These principles form the foundation of a security-conscious culture where every individual plays a vital role in protecting organizational assets.

Key concepts

• Threat Recognition: Understand that threats come in various forms—phishing, social engineering, malware, and insider risks. For instance, a social media message urging immediate action might be a scam designed to exploit urgency.

• Risk Perception: Assessing risk means evaluating both the likelihood of an attack and the potential impact. For example, if you frequently receive messages from unknown sources on a platform like Twitter, you should view these interactions with increased skepticism.

• Zero Trust Mindset: Always verify before trusting. Even messages from familiar contacts should be confirmed if they involve unexpected requests or sensitive information.

• Filtering Credible Information: In an era of information overload, it's critical to identify and rely on reputable sources. This means following established security blogs, official alerts from cybersecurity agencies, or verified community channels.

• Organizational Responsibility: Security is a shared responsibility that requires commitment at all levels of the organization. Leadership must demonstrate strong commitment by prioritizing and investing in security initiatives, while every team member should understand their role in maintaining security.

Real-World Example: A company might receive a seemingly routine email from a "vendor" requesting updated banking details. An employee with a strong zero trust mindset will independently verify the request through known contact numbers or an established internal process, thereby avoiding a potential fraud.

2. Understanding Threat Vectors

🔑 Key Takeaway: Understanding the various ways attackers can target you and your organization is essential for effective defense. By recognizing common attack patterns like phishing, social engineering, and emerging threats in digital spaces, you can better protect yourself and your team from potential security breaches.

2.1. Traditional Attack Vectors

2.1.1. Social Engineering & Phishing

• Phishing Emails: Look for red flags like misspellings, odd URLs, and urgent language. Scenario Example: An email that claims "Your account will be locked in 24 hours" but uses a suspicious domain.

• SMS & Messaging Scams: Attackers may use text messages or direct social media messages to bypass email filters. Scenario Example: A text message that claims to be from a delivery service asking for a confirmation code.

• Voice Phishing (Vishing): Phone calls that pretend to be from a trusted organization, often using spoofed caller IDs. Scenario Example: A staff member receives a voicemail warning about a potential security breach and instructing them to call a specific number immediately.

• Pretexting: Attackers create a fabricated scenario to steal personal information or gain access. Scenario Example: Someone pretending to be a new contractor who needs urgent access to systems or information.

• Baiting: Offering something enticing to entrap the victim. Scenario Example: Leaving infected USB drives in public places or offering free downloads that contain malware.

• Tailgating: Physically following authorized personnel into restricted areas without proper credentials. Scenario Example: An unknown person following an employee through a secure door by claiming they forgot their access card.

• Shoulder Surfing: Observing someone's screen, keyboard, or device to gather information. Scenario Example: A threat actor monitoring your screen in a shared co-working space to capture sensitive information or credentials.

2.1.2. Malware & Technical Attacks

• Ransomware: Malicious software that encrypts files and demands payment for decryption. Scenario Example: An organization finds their critical files encrypted with a ransom note demanding cryptocurrency payment.

• Man-in-the-Middle Attacks: Intercepting communications between two parties. Scenario Example: An attacker on a public Wi-Fi network intercepts unencrypted traffic to steal credentials.

• Credential Stuffing: Using stolen username/password combinations to attempt access to multiple services. Scenario Example: After a data breach at one service, attackers try the same credentials on financial or email accounts.

2.2. Web3-Specific Threats

2.2.1. Crypto-Focused Attacks

• Crypto Drainers: A common attack where a threat actor suggests users can participate in an airdrop by visiting a provided link. Unsuspecting users who click the link are directed to a counterfeit website, where they are asked to authenticate their wallet and sign a transaction. Once signed, the threat actor gains access to steal funds from the wallet.

• Rug Pulls: In the context of web3 and cryptocurrencies, these scams typically involve fraudulent schemes designed to swindle individuals out of their digital assets. For example, an enticing new project may promise revolutionary technology and unprecedented returns. However, the project developers quickly vanish, leaving investors with worthless tokens and empty promises.

• Token Approval Exploits: Attackers may trick users into approving smart contracts that give unlimited access to tokens in their wallet. These "allowances" permit the approved contract to transfer any amount of a specific token without further permission. Always verify what permissions you're granting when signing transactions and set specific approval limits when possible.

2.2.2. Smart Contract Vulnerabilities

• Reentrancy Attacks: Exploiting a contract's execution flow to repeatedly withdraw funds. Scenario Example: A malicious contract calls back into the victim contract before the first execution is complete, draining funds with each call.

• Flash Loan Attacks: Using uncollateralized loans to manipulate market prices and exploit vulnerabilities. Scenario Example: An attacker borrows a large amount of cryptocurrency, manipulates a price oracle, exploits a vulnerability, and repays the loan in a single transaction.

2.3. Common Indicators & Red Flags

2.3.1. Behavioral Cues

• Inconsistencies: Look for changes in tone or style in communications from known contacts. Scenario Example: A normally formal manager sends a casual message with unexpected requests.

• Unusual Requests: Requests for urgent transfers of money, sensitive information, or changes in process should always trigger caution.

• Environmental Anomalies: Spotting unexpected logins or unfamiliar devices in account activity reports can indicate compromised accounts.

2.3.2. Technical Indicators

• Unexpected Authentication Prompts: Sudden requests to re-authenticate without clear reason. Scenario Example: Being asked to provide credentials on a site you're already logged into.

• Browser Certificate Warnings: Alerts about invalid or expired security certificates. Scenario Example: Your browser displays a warning that a connection is not secure when visiting a familiar website.

• Unusual System Behavior: Slowdowns, crashes, or unexpected pop-ups. Scenario Example: Your computer suddenly runs significantly slower or displays unfamiliar advertisements.

2.3.3. Checklist for Suspicious Communications

• Does the message contain spelling errors or unusual formatting?
• Is the sender's email or username slightly different from the norm?
• Are there requests for urgent action without proper verification channels?
• Does the message create a sense of fear, urgency, or excitement?
• Is there an unexpected attachment or link?
• Does the request bypass normal security procedures?

2.4. Preventive Measures

2.4.1. General Security Practices

• Double-Check Requests: Always verify the identity of individuals requesting sensitive information, especially if the request is unusual or urgent. Scenario Example: If you receive an email from your CEO asking for an urgent wire transfer, call them directly using a known phone number to confirm.

• Use Secure Channels: Communicate through official channels and avoid sharing sensitive information over unsecured methods. Scenario Example: Use your organization's established communication platforms rather than responding to external email links.

2.4.2. Web3-Specific Protections

• Check & Remove Token Approvals: Regularly check which smart contracts have approvals to handle funds in your wallet and revoke unnecessary approvals to improve your security posture. Useful Tools:

  • Unrekt
  • Etherscan Token Approval Checker

• Scrutinize Transaction Requests: Never sign a transaction unless you are completely sure exactly what you are signing. Be especially skeptical of offers that seem too good to be true.

• Hardware Wallets for Critical Assets: Use hardware wallets for storing significant cryptocurrency holdings. Scenario Example: Keeping your long-term investments on a hardware wallet while only maintaining small amounts in hot wallets for daily transactions.

3. Cultivating a Security-Aware Mindset

🔑 Key Takeaway: Developing a security-aware mindset is about building habits that prioritize caution and verification. By questioning unusual requests, pausing before acting, and leveraging peer support, you transform security from a set of rules into an intuitive approach to daily interactions.

3.1. Behavioral Best Practices

Practical Tips

• Question Unusual Requests: Always verify any request for sensitive information or financial transactions through a separate communication channel.

• Pause Before Reacting: Take a moment to think before clicking a link or downloading an attachment. Example: If you get an unexpected file from a colleague, call them directly to confirm they sent it.

• Peer Verification: Leverage your team by asking a colleague's opinion if something seems off.

Scenario Example A community manager receives a direct message on Discord that looks like it comes from a well-known project partner, asking for private credentials. Instead of immediately responding, they cross-check the message in a team meeting or via a known contact method.

3.2 Awareness in Community Settings

Unique Challenges on Social Platforms

• Platform-Specific Red Flags: Each community platform—Discord, Twitter, Telegram—has its own quirks. Example: On Telegram, unsolicited group invites with suspicious usernames could be phishing attempts.

• Community Role Awareness: Moderators and administrators should be extra cautious since they have higher privileges. Example: A moderator on a crypto project Discord might notice a sudden spike in login attempts from an unfamiliar IP range.

• Culture of Reporting: Foster an environment where suspicious behavior is immediately reported and discussed, not brushed aside.

Scenario Example During a routine community chat, several members report receiving odd messages that urge them to click on a link. The community manager organizes a quick session to remind members of red flags and the correct reporting channels, reinforcing collective vigilance.

3.3 Organizational Strategies for Security Culture

• Leadership Commitment: Ensure that leadership demonstrates a strong commitment to security by prioritizing and investing in security initiatives. Leaders should model security-conscious behavior and allocate appropriate resources to security efforts.

• Regular Communication: Communicate the importance of security regularly through team meetings, newsletters, and other channels. Keep security topics visible and relevant to all team members.

• Security Policies and Procedures: Develop and enforce clear security policies and procedures that outline expectations and responsibilities for all team members.

• Encourage Reporting: Create an environment where team members feel comfortable reporting security incidents, suspicious activities, and potential vulnerabilities without fear of retribution.

• Recognition and Rewards: Recognize and reward team members who demonstrate exemplary security practices and contribute to the organization's security efforts.

• Continuous Improvement: Continuously assess and improve the project's security culture through feedback, assessments, and audits.

• Shared Responsibility: Instill a sense of responsibility for security at all levels of the project, emphasizing that security is everyone's job.

• Collaboration: Promote collaboration and information sharing among team members to enhance overall security awareness and response capabilities.

Scenario Example A project implements a monthly "Security Spotlight" where different aspects of security are highlighted, and team members can share their experiences or ask questions. This regular touchpoint keeps security top-of-mind and encourages ongoing dialogue about best practices.

3.4 Essential Security Practices

3.4.1. Password Management

• Strong, Unique Passwords: Use complex, unique passwords for each account to prevent credential stuffing attacks. Example: A passphrase like "correct-horse-battery-staple" (with four random words) is both strong and memorable, while being more secure than shorter passwords with special characters like "P@ssw0rd!".

• Password Managers: Utilize a reputable password manager to securely store and generate complex passwords. Example: Tools like Bitwarden, 1Password, or KeePassXC can generate and store unique passwords for all your accounts.

3.4.2. Multi-Factor Authentication (MFA)

• Enable MFA Everywhere Possible: Add an extra layer of security beyond just passwords. Example: Even if someone obtains your password, they still can't access your account without the second factor.

• Choose Secure MFA Methods: Hardware tokens and authenticator apps are more secure than SMS-based verification. Example: Use YubiKeys or authenticator apps like Authy instead of SMS, which can be vulnerable to SIM swapping attacks.

3.4.3. Secure Communication

• End-to-End Encryption: Use messaging platforms with end-to-end encryption for sensitive communications. Example: Signal provides strong encryption for messages, ensuring only the intended recipient can read them.

• Verify Communication Channels: Be cautious of unexpected platform changes for important communications. Example: If a colleague suddenly asks to switch from your company's official channel to a personal messaging app for work discussions, verify this request directly.

3.4.4. Device Security

• Keep Systems Updated: Regularly update your operating system and applications to patch security vulnerabilities. Example: Schedule automatic updates or set a weekly reminder to check for and install updates.

• Secure Your Workspace: Be mindful of physical security in shared or public spaces. Example: Use privacy screens when working in public and lock your device when stepping away.

3.5. Incident Response Awareness

3.5.1. Recognizing Security Incidents

• Know the Warning Signs: Understand what constitutes a potential security incident. Example: Unexpected account lockouts, strange system behavior, or unusual access requests could indicate a breach.

• Immediate Actions: Know what steps to take when you suspect a security incident. Example: Disconnect from networks, document what happened, and report to your security team immediately.

3.5.2. Reporting Procedures

• Clear Reporting Channels: Ensure everyone knows how and where to report security concerns. Example: Have a dedicated email address or communication channel specifically for security reports.

• No-Blame Culture: Encourage prompt reporting by focusing on solutions rather than blame. Example: Acknowledge and thank team members who report potential issues, even if they turn out to be false alarms.

Scenario Example A team member notices unusual login attempts to their account. Instead of ignoring it or feeling embarrassed, they immediately report it to the security team, who can then investigate whether this is part of a larger attack pattern affecting other users.

4. Staying Informed & Continuous Learning

🔑 Key Takeaway: Security is not a one-time achievement but an ongoing journey of learning and adaptation. By establishing regular training routines, staying current with emerging threats, and fostering a culture of continuous improvement, you ensure your security awareness remains effective against evolving challenges.

4.1. Comprehensive Security Training Framework

4.1.1. Training Approaches

• Bite-Sized Learning: Security training doesn't need to be lengthy or overwhelming. Short, focused sessions of relevant information can be more effective than infrequent, lengthy presentations. Example: Weekly 5-minute security tips delivered via team chat or email.

• Role-Based Training: Tailor security training to specific roles and access levels within your organization. Example: Developers might need more in-depth training on secure coding practices, while community managers might focus more on social engineering awareness.

• Recurring Schedule: Make security training a regular, ongoing activity rather than a one-time event. Example: Monthly security topics with quarterly refreshers on critical subjects.

• Practical Application: Include hands-on exercises that allow people to apply what they've learned. Example: Conduct simulated phishing tests followed by immediate feedback and learning opportunities.

• Interactive Training Methods: Use interactive training methods, such as SEAL Wargames or workshops to engage team members and enhance learning.

• Real-World Scenarios: Incorporate real-world scenarios and case studies to illustrate the impact of security breaches and the importance of preventive measures.

• Assessments and Quizzes: Use assessments and quizzes to evaluate the effectiveness of training and identify areas where additional training may be needed.

4.1.2. Training Delivery

• Regular Awareness Sessions: Schedule quarterly webinars or short training refreshers focusing on the latest trends and emerging threats.

• Interactive Simulations: Participate in phishing simulations or scenario-based exercises that allow you to practice identifying and responding to threats in a risk-free environment.

• Security Awareness Campaigns: Implement periodic campaigns that focus on specific security themes to reinforce key messages. Example: A "Phishing Awareness Month" with targeted activities and resources.

4.1.3. Measuring Training Effectiveness

• Baseline Assessments: Conduct assessments before and after training to measure improvement.

• Behavioral Metrics: Track security-related behaviors such as reporting rates for suspicious emails or incidents.

• Feedback Collection: Gather participant feedback to continuously improve training content and delivery methods.

4.2. Essential Training Topics

• Phishing and Social Engineering: Educate team members on recognizing and responding to phishing attacks and social engineering tactics, with special focus on web3-specific threats.

• Password Management: Provide best practices for creating and managing strong passwords and using password managers.

• Data Protection: Teach methods for protecting sensitive data, including encryption, access controls, and secure data handling practices.

• Incident Reporting: Instruct team members on how to report security incidents and suspicious activities promptly.

• Secure Coding Practices: For developers, provide training on secure coding practices and common vulnerabilities in web3 environments.

• Device and Account Security: Cover best practices for securing devices and accounts, including updates, encryption, and access controls.

• Emerging Threats: Keep team members informed about new and evolving security threats relevant to your organization.

4.3. Trusted Information Sources

4.3.1. Security Newsletters

• Industry News: Subscribe to newsletters from sources such as FIRST.org for broader cybersecurity trends. Example: The SANS NewsBites provides twice-weekly summaries of the most important security news.

• Vendor Updates: Follow security updates from the software and hardware vendors in your project stack. Example: Subscribe to security bulletins from cloud providers, operating system vendors, and key software dependencies.

4.3.2. Security Communities

• Online Forums and Groups: Join online communities dedicated to security topics. Example: The SEAL Discord provides a space to discuss security challenges specific to web3 projects.

• Local and Virtual Meetups: Attend security-focused events to network and learn. Example: Conferences like DeFi Security Summit offer insights into emerging threats and defenses.

4.3.3. Security Blogs and Podcasts

• Technical Blogs: Follow security researchers and organizations that regularly publish detailed analyses. Example: Trail of Bits blog provides in-depth technical security content.

• Security Podcasts: Listen to podcasts that cover current security topics. Example: The Daily Stormcast from FIRST.org offers brief daily updates, while Darknet Diaries provides longer-form stories about notable security incidents.

4.4. Implementing a Learning Culture

• Share Knowledge: Create channels for team members to share security articles, news, and insights. Example: A dedicated Slack channel for security-related content.

• Recognize Vigilance: Acknowledge and reward security-conscious behavior. Example: Highlight team members who identify and report potential security issues.

• Learn from Incidents: Use security incidents (both internal and external) as learning opportunities. Example: After major industry breaches, conduct brief sessions to discuss what happened and how similar issues could be prevented in your organization.

5. Resources & Further Reading

🔑 Key Takeaway: Expanding your security knowledge requires reliable resources and continuous engagement with the security community. By leveraging curated learning materials, self-assessment tools, and professional networks, you can deepen your expertise and stay ahead of emerging threats.

5.1. Additional Learning Materials

• Security Awareness Blogs: Subscribe to blogs like "Security Week" or "Dark Reading" for the latest on cyber threat trends.

• Self-Assessment Tools: Use downloadable checklists and online quizzes to periodically test your awareness.

• Community Forums & Discussion Groups: Engage with professional security communities on platforms such as Reddit's r/cybersecurity or specialized Discord groups.

• Case Studies and Whitepapers: Read detailed incident reports and analysis (available from sources like Verizon's Data Breach Investigations Report) to learn from past events.

Example Resources:

• Personal security checklist: Digital Defense (we are currently developing a version of this based on frameworks, will be available at https://check.frameworks.securityalliance.dev).
• Interactive phishing simulation: Phishing Dojo.
• SEAL's blog on frameworks.

5.2. Recommended Security Newsletters

• SANS NewsBites - Twice-weekly summaries of the most important security news
• FIRST.org - Forum of Incident Response and Security Teams newsletters and resources
• The Hacker News - Cybersecurity news and analysis
• Krebs on Security - In-depth security news and investigation

5.3. Security Podcasts and Media

• Daily Stormcast - Daily 5-10 minute updates from SANS Internet Storm Center
• Darknet Diaries - Stories from the dark side of the internet
• Security Now - Weekly deep dives into security topics
• Risky Business - Weekly information security podcast

5.4. Security Training Resources

• OWASP - Open Web Application Security Project resources and guides
• Cybrary - Free and premium cybersecurity training
• SANS - Professional information security training
• Phishing.org - Anti-phishing training and awareness resources

5.5. Web3-Specific Security Resources

• DeFi Security Summit - Conference focused on DeFi security
• SEAL news & SEAL Discord - Security Alliance's initiatives related to news and events
• Immunefi - Educational resources about web3 security
• Consensys Diligence - Smart contract security blog
• Blockthreat - Web3 security news and analysis
• The Red Guild - Web3 security awareness and education

5.6. Web3 Security Tools

• Token Approval Management:

  • Unrekt - Check and revoke token approvals
  • Etherscan Token Approval Checker - Monitor smart contract approvals

• Wallet Security:

  • wise-signer - Game to learn how to verify transaction information on your wallets
  • Qualified Signer Certification - Certification for verifying transaction information
  • Software and Hardware Wallets comparison - Compare security features of different crypto wallets
  • Hardware Wallets comparison - Compare security features of different hardware wallets
  • Wallet Scrutiny - Analyze wallet security and features
  • Hardware Wallet Resources - Educational content about hardware wallet security

5.7. Security Tools and Services

• Password Managers:

  • Bitwarden - Open-source password management
  • 1Password - Premium password management solution
  • KeePassXC - Free, open-source, cross-platform password manager

• Two-Factor Authentication:

  • Authy - Multi-device 2FA application
  • YubiKey - Hardware authentication device

• Secure Communication:

  • Signal - End-to-end encrypted messaging
  • ProtonMail - Encrypted email service

Operational Security

Operational Security (OpSec) is a systematic approach to identifying critical information, determining threats to that information, analyzing vulnerabilities, assessing risks, and implementing countermeasures to protect sensitive data and operations. This framework provides comprehensive guidance for implementing effective operational security practices in Web2 and Web3 environments.

Core Components

This framework is organized into several interconnected components:

1. Overview: Core principles and concepts of operational security
2. Threat Modeling Overview: Identifying and analyzing potential security threats
3. Risk Management Overview: Identifying, assessing, and mitigating security risks
4. Monitoring & Detection Overview: Continuous monitoring of security events and anomalies
5. Incident Response & Recovery Overview: Handling security incidents when they occur
6. Governance & Program Management Overview: Establishing security leadership and organizational structures
7. Control Domains Overview: Key areas requiring specific security controls and practices
8. Lifecycle Overview: The continuous process of implementing and maintaining security measures
9. Continuous Improvement Overview: Learning from incidents and evolving security practices

Additional contents

• While Traveling
  • TL;DR
  • Guide

Using This Framework

Organizations should adapt this framework to their specific needs, considering their size, resources, and risk profile. Start with the fundamentals and gradually implement more advanced controls as your security program matures.

The guidance provided here is designed to be practical and actionable, with specific recommendations that can be implemented by Web3 teams of all sizes.

Overview

Operational Security (OpSec) is a practical approach that helps organizations protect sensitive information and critical assets through both foundational security concepts and actionable implementation processes. In simple terms, it means identifying what information is valuable, understanding who might try to steal or misuse it, figuring out how it could be accessed, and then putting the right protections in place to prevent that from happening. This section covers the essential frameworks that form the basis of an effective operational security program.

What is Operational Security?

Operational Security is a systematic process that:

1. Maps and secures critical information and assets
2. Identifies and analyzes relevant threats
3. Discovers and addresses exploitable vulnerabilities
4. Evaluates risks in a business context
5. Deploys targeted controls to mitigate identified risks

The goal is to prevent unauthorized access to systems and information that, if compromised, could lead to operational, financial, or reputational harm. To achieve this, modern Operational Security frameworks should adopt zero trust security model, which assumes no user, or device is inherently trustworthy. Instead, every access request must be explicitly verified, regardless of origin or credentials.

Security Fundamentals

The following fundamentals form the foundation of effective operational security:

• Layered Protection: Implementing multiple overlapping security controls so that if one mechanism fails, others will continue to protect your assets.
• Minimal Access Scopes: Granting users, systems, and processes only the specific permissions they need to perform their required functions and nothing more.
• Information Flow Control: Ensuring sensitive information is only accessible to those with a legitimate need to know, with restrictions on how that information can be shared and used.
• System Isolation: Segmenting systems and networks into isolated zones to contain security breaches and limit lateral movement.
• Continuous Visibility: Maintaining ongoing awareness of your security posture through active monitoring, testing, and continuous improvement.

Check the Security Fundamentals for practical application guidance.

Operational Implementation Process

1. Critical Asset Identification: Map and document the assets that would cause significant harm to your organization if compromised.
2. Practical Threat Analysis: Identify specific, relevant threat actors and their tactics based on your organization's profile.
3. Actionable Vulnerability Assessment: Systematically identify and validate weaknesses in your environment through practical testing.
4. Contextual Risk Evaluation: Analyze identified risks in the context of your business to drive informed decision-making.
5. Targeted Control Deployment: Implement security controls that address prioritized risks while minimizing operational friction.

Check out the Operational Implementation Process for detailed implementation actions.

Web3-Specific Considerations

In Web3 environments, operational security must address unique challenges:

• Transparency vs. Privacy: Balancing blockchain transparency with the need for operational secrecy
• Decentralized Operations: Securing operations across distributed teams and systems
• Cryptocurrency Security: Protecting digital assets and private keys
• Smart Contract Vulnerabilities: Addressing the immutable nature of deployed code
• Community Dynamics: Managing security in open, community-driven projects

Check out Web3 considerations for more details on these topics.

Security Fundamentals

🔑 Key Takeaway: Effective security operations are built on five practical fundamentals: layered protective measures, minimized access scopes, controlled information flows, system isolation, and continuous visibility — working together to secure critical assets in dynamic environments.

Relationship to Implementation Process

This document outlines the foundational security approaches that should be embedded throughout your organization's operations. They complement the practical Operational Implementation Process, which defines specific action steps:

• These fundamentals establish enduring approaches that shape your security architecture
• The implementation process provides a sequential workflow for security teams to follow

While these fundamentals provide the security principles that should be consistently applied across your environment, the implementation process offers a structured methodology for putting security into practice. Both elements must work in concert - these fundamentals guide your overall approach, while the implementation process provides the tactical roadmap.

For organizations just beginning their security journey, start with the Operational Implementation Process for concrete steps.

The ultimate goal is to prevent unauthorized access to systems and information that could cause operational, financial, or reputational harm if compromised.

Practical Example: Web3 Organization

Consider a Web3 project managing a DeFi protocol with a treasury of $10M in assets. Practical security fundamentals in action include:

• Layered protection: Hardware security modules for key storage, multi-signature requirements (3-of-5) for transactions, automated monitoring for unusual patterns, and regular third-party security audits
• Minimal access scopes: Deployment keys accessible only to specific DevOps team members, with different permission levels strictly enforced between development, staging, and production environments
• Information flow control: Private keys for multi-signature wallets distributed among trusted team members based on role, with sensitive incident response procedures restricted to the security team
• System isolation: Clear separation between development environments and production systems, with treasury management isolated from day-to-day operations
• Continuous visibility: Real-time monitoring systems tracking transaction patterns, weekly security reviews, and quarterly penetration tests with findings addressed in prioritized sprints

1. Layered Protection

Implement multiple overlapping security controls so that if one mechanism fails, others will continue to protect your assets.

🔗 Related Framework: This approach is reinforced in frameworks like Infrastructure with Zero-Trust Principles and Network Security.

Practical Application

1. Implement multiple defensive mechanisms that protect against the same risks using different methods
   • Example: Protect admin interfaces using network ACLs, MFA, time-limited access windows, and anomaly detection
2. Deploy protection at each layer of your technology stack
   • Network layer: Firewalls, network segmentation, DDoS protection
   • Host layer: Endpoint protection, host-based IDS, secure configuration
   • Application layer: Input validation, output encoding, API security
   • Data layer: Encryption, access controls, data loss prevention
3. Identify and eliminate single points of failure in your security architecture
   • Map defense coverage to ensure overlapping protections
   • Document security dependencies and create contingency plans
4. Test defensive layers regularly through realistic scenarios
   • Conduct tabletop exercises focused on specific defensive failures
   • Use red team exercises to validate defense-in-depth effectiveness
5. Maintain a continuous improvement cycle for each defensive layer
   • Review and update security controls after incidents or near-misses
   • Track industry developments to identify emerging defensive tactics

2. Minimal Access Scopes

Grant users, systems, and processes only the specific permissions they need to perform their required functions and nothing more.

🔗 Related Framework: For detailed implementation, see Identity and Access Management and Role-Based Access Control.

Practical Application

1. Implement a structured permission model that starts with zero access
   • Default deny: Require explicit permission grants for all access
   • Document justification for each permission granted
   • Create standardized role templates for common job functions
2. Establish automated processes for access lifecycle management
   • Onboarding: Provision minimal initial access based on role
   • Role changes: Adjust permissions when responsibilities change
   • Offboarding: Remove all access immediately upon departure
3. Apply time-based restrictions to elevated privileges
   • Use just-in-time access for administrative functions
   • Implement automatic session termination after periods of inactivity
   • Require re-authentication for sensitive operations
4. Conduct regular access reviews with verification
   • Quarterly: Review all privileged accounts and service accounts
   • Semi-annually: Audit all standard user accounts and group memberships
   • Use automated tools to identify inactive or excessive permissions
5. Implement technical controls to enforce minimal access
   • Application permissions: API scopes, feature flags, entitlement checks
   • Infrastructure permissions: IAM policies, network ACLs, resource policies
   • Database permissions: Row-level security, column-level controls

3. Information Flow Control

Ensure sensitive information is only accessible to those with a legitimate need to know, with restrictions on how that information can be shared and used.

🔗 Related Framework: This approach is supported by practices in Data Protection and aspects of Privacy.

Practical Application

1. Implement a practical data classification system with clear handling requirements
   • Public: Information approved for general distribution
   • Internal: Business information for employee use only
   • Confidential: Sensitive information requiring specific protections
   • Restricted: Critical information with strictly controlled access
2. Define and enforce data handling procedures for each classification level
   • Storage requirements: Where information can be stored
   • Transmission rules: How information can be sent/shared
   • Processing restrictions: How information can be used
   • Retention limits: How long information should be kept
3. Deploy technical controls to enforce information flow policies
   • Data loss prevention tools to monitor and block unauthorized sharing
   • Encryption for data at rest and in transit based on sensitivity
   • Information rights management for persistent protection
4. Establish secure channels for different types of communication
   • High-sensitivity: End-to-end encrypted messaging with disappearing messages
   • Medium-sensitivity: Encrypted collaboration platforms with access controls
   • Low-sensitivity: Standard business communication tools
5. Train users on practical information handling procedures
   • Provide clear guidelines with concrete examples
   • Use realistic scenarios in training materials
   • Conduct periodic verification checks

4. System Isolation

Segment systems and networks into isolated zones to contain security breaches and limit lateral movement.

Practical Application

1. Implement network segmentation based on security requirements
   • Create security zones with consistent trust levels
   • Implement strict traffic control between zones
   • Document and regularly review allowed communication paths
2. Establish environment separation with controlled boundaries
   • Maintain distinct development, testing, staging, and production environments
   • Implement one-way data flows from higher to lower environments
   • Control code promotion processes between environments
3. Isolate high-value systems with enhanced protection
   • Place critical infrastructure on dedicated hardware
   • Example: Run blockchain nodes on dedicated hardware isolated from general workstations
   • Implement jump servers or privileged access workstations for administrative access
4. Apply micro-segmentation where appropriate
   • Container isolation: Enforce pod security policies and network policies
   • Application segmentation: Implement service meshes with mutual TLS
   • Process isolation: Use containerization, virtualization, or sandboxing
5. Monitor and enforce boundary controls
   • Implement egress filtering to control outbound connections
   • Deploy internal firewalls between segments
   • Use network monitoring to detect unauthorized communication attempts

5. Continuous Visibility

Maintain ongoing awareness of your security posture through active monitoring, testing, and continuous improvement.

🔗 Related Framework: For implementation details, see the Monitoring framework, including Guidelines and Thresholds. Also relevant is Incident Management for response to detected issues.

Practical Application

1. Implement a multi-layered monitoring strategy
   • System monitoring: Performance, availability, and system integrity
   • Security monitoring: Threat detection, anomaly identification, and correlation
   • Compliance monitoring: Policy enforcement and regulatory requirements
   • Establish clear ownership for each monitoring domain
2. Define actionable metrics tied to security objectives
   • Leading indicators: Metrics that help predict future issues
   • Example: Percentage of systems with current patches
   • Lagging indicators: Metrics that measure past performance
   • Example: Mean time to detect and respond to incidents
3. Establish a regular testing cadence to validate security controls
   • Vulnerability scanning: Weekly automated scans
   • Penetration testing: Quarterly focused tests on critical systems
   • Red team exercises: Annual comprehensive assessments
4. Implement a structured incident management process
   • Define clear incident response procedures with specific roles
   • Conduct regular tabletop exercises to practice response
   • Perform thorough post-incident reviews focused on improvement
   • Create feedback loops to security controls based on incidents
5. Maintain an active threat intelligence program
   • Collect intelligence relevant to your specific environment
   • Analyze and contextualize threats for your organization
   • Disseminate actionable intelligence to appropriate teams
   • Use threat intelligence to drive security improvements

Operational Implementation Process

🔑 Key Takeaway: Operational security is implemented through a practical five-phase process: critical asset identification, practical threat analysis, actionable vulnerability assessment, contextual risk evaluation, and targeted control deployment.

Relationship to Security Fundamentals

This document outlines a practical implementation process for operational security that organizations can follow in sequence. This process complements the Security Fundamentals document, which defines the guiding principles:

• This process provides a sequential workflow for security teams to follow
• The fundamentals establish enduring principles that shape security architecture

While this process offers a concrete methodology for implementation, the fundamentals establish the ongoing security approaches that must be maintained throughout your systems. Both elements must work together: the fundamentals guide your overall approach, while this process provides the tactical roadmap.

For organizations just beginning their security journey, start here with these concrete implementation steps.

1. Critical Asset Identification

Map and document the assets that would cause significant harm to your organization if compromised.

🔗 Related Framework: This phase integrates with Asset Inventory practices and drives Data Protection strategies.

Implementation Actions

1. Conduct asset discovery across your environment using both automated tools and manual inventorying
   • Digital assets: Use network scanning, CMDB tools, and cloud resource inventories
   • Physical assets: Document hardware, systems and access points
2. Apply a practical classification system with clear, actionable categories
   • High-value assets: Direct financial impact if compromised (e.g., private keys, treasury wallets)
   • Operational assets: Required for continued business operations
   • Sensitive data: Includes Customer information, intellectual property, strategic plans
3. Map information flows to understand how data moves between systems
4. Assign specific owners responsible for each asset category
5. Establish a sustainable review cadence based on your environment
   • High-volatility environments: Monthly reviews
   • Stable environments: Quarterly reviews
   • Document trigger events that require immediate reassessment (e.g., acquisitions, new product, etc.)

2. Practical Threat Analysis

Identify specific, relevant threat actors and their tactics based on your organization's profile.

🔗 Related Framework: For hands-on approaches, see Understanding Threat Vectors and Threat Modeling frameworks.

Implementation Actions

1. Create a focused threat profile based on:
   • Your industry's recent attack history (consult threat intelligence reports)
   • Your organization's specific attack surface
   • The value of your assets to different adversaries
2. Document concrete adversary personas with specific capabilities:
   • External attackers: Targeted vs. opportunistic
   • Insider risks: Privileged users, contractors, disgruntled employees
   • Supply chain actors: Vendors with access to your systems
3. Map threat actors to their likely tactics using MITRE ATT&CK or similar frameworks
4. Establish threat intelligence feeds relevant to your environment
5. Create a lightweight process for updating threat models when new intelligence emerges

3. Actionable Vulnerability Assessment

Systematically identify and validate weaknesses in your environment through practical testing.

🔗 Related Framework: This aligns with the Security Testing framework and includes practices like Static Application Security Testing and Dynamic Application Security Testing.

Implementation Actions

1. Implement a layered vulnerability discovery program:
   • Automated scanning: Deploy tools appropriate for your environment (infrastructure, applications, cloud)
   • Manual testing: Conduct regular penetration tests focusing on critical systems
   • Red team exercises: Simulate real-world attacks against your defenses
2. Examine security processes for operational gaps:
   • Incident response procedures: Test through tabletop exercises
   • Access management: Audit privilege escalation paths
   • Change management: Review for security bypass opportunities
3. Evaluate security awareness through:
   • Targeted phishing simulations
   • Knowledge assessments
   • Procedural compliance checks
4. Document findings in a centralized vulnerability management system with clear ownership
5. Implement a consistent vulnerability scoring system to enable prioritization

4. Contextual Risk Evaluation

Analyze identified risks in the context of your business to drive informed decision-making.

🔗 Related Framework: For practical approaches, see Governance and Risk Management frameworks.

Implementation Actions

1. Establish a practical risk calculation methodology that considers:
   • Business impact (financial, operational, reputational)
   • Exploitation likelihood based on real-world attack patterns
   • Existing control effectiveness
2. Create a prioritized risk register with clear owners and timelines
3. Define risk acceptance criteria based on your organization's risk tolerance
4. Develop risk narratives that translate technical findings into business impacts
5. Implement a streamlined risk review process that:
   • Enables timely decisions
   • Involves appropriate stakeholders
   • Documents rationale for future reference
   • Triggers reassessment when conditions change

5. Targeted Control Deployment

Implement security controls that address prioritized risks while minimizing operational friction.

🔗 Related Framework: Implementation integrates with Security Automation and control frameworks like Infrastructure and Identity and Access Management.

Implementation Actions

1. Design a defense-in-depth strategy with layered controls:
   • Preventive: Stop attacks before they succeed
   • Detective: Identify attacks in progress
   • Responsive: Limit damage from successful attacks
   • Recovery: Restore normal operations
2. Select controls using a balanced approach:
   • Technical feasibility in your environment
   • Implementation and maintenance costs
   • Potential operational impact
   • Coverage of multiple risks where possible
3. Implement controls using a phased approach:
   • Quick wins: Deploy high-impact, low-effort controls first
   • Foundational controls: Build core security capabilities
   • Advanced measures: Address sophisticated threats
4. Validate control effectiveness through:
   • Technical testing
   • Process verification
   • Metrics collection
5. Document clear procedures for:
   • Control operation
   • Maintenance requirements
   • Monitoring and alerting
   • Incident response when controls fail

Web3-Specific OpSec Considerations

🔑 Key Takeaway: Web3 environments require specialized security approaches that balance blockchain transparency with privacy, address immutability risks, manage self-custody responsibilities, secure decentralized operations, mitigate smart contract vulnerabilities, and navigate community-driven security challenges.

In addition to traditional OpSec principles, Web3 environments require consideration of unique challenges. Many organizations claim to be backed only by decentralized technologies, but they later realize that part of their process is dependant on technologies that are not.

Transparency vs. Privacy

Balancing the transparent nature of blockchain with the need for operational privacy.

Suggested steps

1. Understand what information is publicly visible on-chain
   • Transaction amounts, addresses, contract interactions, and timestamps
   • Use block explorers and analysis tools to understand your on-chain footprint
2. Develop strategies to maintain operational privacy while utilizing public blockchains
   • Use different addresses for different transaction types or business functions
   • Consider privacy-focused layer 2 solutions for sensitive operations
3. Use privacy-enhancing technologies where appropriate
   • ZK (Zero-Knowledge) protocols for privacy-preserving computations
   • Privacy pools or similar technologies (when legally permissible)
   • Privacy-focused blockchains for specific operations (e.g., Monero, Zcash)

Immutability and Finality

Recognizing that blockchain transactions are generally irreversible, requiring heightened security before execution.

Suggested steps

1. Implement robust verification procedures before executing transactions
   • Mandatory multi-person review for transactions above defined thresholds
   • Automated checks for anomalous transaction patterns
   • Hash verification of destination addresses
2. Use multi-signature requirements for high-value transactions
   • 3-of-5 or 2-of-3 signature schemes for treasury operations
   • Hardware wallets for each signer with physical separation
   • Time-locks for large transfers (24-48 hour delay before execution)
3. Deploy transaction simulation tools to verify outcomes before execution
   • Use Tenderly or similar platforms to simulate transactions in a fork of the chain
   • Verify gas estimates and test with small amounts first when using new contracts\
   • Use auxiliary tools such as Safe Multi-sig Transaction Hashes
4. Establish secure deployment practices for smart contracts
   • Use formal verification tools before mainnet deployment
   • Implement deployment scripts with dry-run functionality
   • Require multiple approvals in your deployment pipeline
   • Consider gradual deployments with circuit breakers for critical contracts

Self-Custody Responsibility

Managing private keys and digital assets with appropriate security controls.

🔗 Related Framework: For detailed guidance on wallet security practices, see the Wallet Security framework.

Suggested steps

1. Develop clear procedures for wallet security
   • Air-gapped hardware wallet setups for cold storage
   • Specific seed phrase backup procedures (e.g., metal backups, split storage)
   • Clear rules for when hot vs. cold wallets should be used
2. Implement separation of duties for transaction approval
   • Different roles for transaction initiation, verification, and execution
   • Rotation of responsibilities to prevent single points of compromise
   • Hardware security modules (HSMs) for institutional-grade key management
3. Balance security with operational efficiency
   • Define thresholds for different security requirements (e.g., <$10K, $10K-$100K, >$100K)
   • Implement tiered wallet architecture (hot wallets for operations, cold storage for reserves)
   • Establish secure methods for replenishing hot wallets from cold storage
4. Stay up-to-date with best practices in wallet security and custody solutions
   • Subscribe to security advisory services for cryptocurrencies
   • Follow developments in MPC (Multi-Party Computation) wallet technologies
   • Regularly review and test recovery procedures

Decentralized Operations

Securing operations across distributed teams and systems.

Suggested steps

1. Establish clear security protocols for remote team members
   • Device security requirements (disk encryption, endpoint protection, auto-updates)
   • Secure home network guidelines (dedicated VLANs, strong WPA3 passwords)
   • Clear policies for public WiFi usage (always-on VPN requirement)
2. Use secure communication channels for sensitive discussions
   • End-to-end encrypted messaging (Signal, Matrix/Element with verified devices)
   • Ephemeral messaging for highly sensitive topics (disappearing messages)
   • Encrypted video conferencing with waiting rooms and passwords (Jitsi, Signal)
   • PGP-encrypted emails for sensitive communications that need to be preserved
3. Implement strong authentication for all team members
   • Hardware security keys (Yubikeys, Passkeys) as primary 2FA method
   • TOTP apps as backup authentication method (not SMS)
   • Passwordless authentication where possible (WebAuthn/FIDO2)
   • Regular access review and prompt offboarding procedures
4. Create guidelines for secure collaboration in a distributed environment
   • Encrypted file storage and sharing (Cryptomator, end-to-end encrypted cloud storage)
   • Private repositories with signed commits for code collaboration
   • Secure DevOps practices for CI/CD pipelines
   • Role-based access to administrative systems with just-in-time privilege elevation

Smart Contract Vulnerabilities

Addressing the immutable nature of deployed code.

Suggested steps

1. Conduct thorough code reviews and security audits before deployment
   • Multiple independent security audits for critical contracts
   • Comprehensive test coverage (>95%) for all contract functions
   • Symbolic execution and static analysis tools (Slither, Mythril)
2. Implement upgradability patterns where appropriate
   • Proxy patterns with clear governance mechanisms
   • Immutable core logic with upgradeable periphery
   • Emergency pause functionality with decentralized controls
3. Use formal verification where possible
   • Mathematical proofs of contract correctness for critical functions
   • Verification of business logic and security properties
   • Property-based testing frameworks (Echidna, Scribble)
4. Maintain comprehensive testing environments
   • Local development environments with mainnet forking
   • Testnet deployments with real-world simulation
   • Adversarial testing and red team exercises
5. Consider timelocks and circuit breakers for critical functions
   • Time-delayed administration actions (48-72 hours)
   • Value-limit circuit breakers for suspicious transaction volumes
   • Decentralized monitoring and alerting systems

Community Dynamics

Managing security in open, community-driven projects.

Suggested steps

1. Develop clear security guidelines for community contributors
   • Documented security policies in repositories
   • Security templates for pull requests
   • Required security reviews for changes to sensitive components
2. Establish review processes for community-submitted code
   • Multi-level review requirements based on code criticality
   • Automated security scanning integrated into CI/CD pipelines
   • Bounty programs for vulnerability identification
3. Create security awareness programs for the community
   • Educational resources on common vulnerabilities
   • Regular security-focused community calls or workshops
   • Recognition for security-conscious contributions
4. Balance transparency with operational security needs
   • Clear guidelines on what information should remain private
   • Secure channels for reporting vulnerabilities
   • Responsible disclosure policies and timelines
   • Public security incident post-mortems (with appropriate redactions)

Threat Modeling Overview

🔑 Key takeaway: Think of threat modeling as your security roadmap. It's how you understand what you need to protect, who might try to steal it, and how they might do it. From random hackers to state actors, knowing your potential attackers helps you build defenses that actually matter. It's about being smart with your security resources and focusing on what really needs protection.

Effective security requires understanding what you're protecting and who you're protecting it from. Without a structured threat model, security efforts become unfocused and inefficient. Different entities face different threats based on their assets, visibility, and technological footprint.

Why is it important

Failure to implement threat modeling has led to catastrophic security breaches:

• How Threat Modeling Could Have Prevented the 1.5B ByBit Hack
• North Korea's Lazarus Group stole $620 million from Axie Infinity's Ronin bridge (2022) through a sophisticated attack targeting blockchain infrastructure
• The Nomad bridge lost $190 million (2022) through a critical vulnerability that allowed attackers to bypass transaction validation
• The 2020 Twitter compromise resulted in hijacked high-profile accounts being used for cryptocurrency scams

Common pitfalls & examples

• Tunnel vision: The Colonial Pipeline attack (2021) succeeded through a legacy VPN account without MFA, while the company focused security resources on operational technology
• Unrealistic scenarios: Many organizations over-invested in zero-day defense while leaving basic phishing vulnerabilities open
• Static models: Equifax's 2017 breach occurred partly because threat models weren't updated to reflect new attack patterns
• Insider blindness: The 2020 Twitter compromise of high-profile accounts happened when internal admin tools weren't included in threat modeling

Organizations that implement threat modeling can focus limited security resources on their most significant risks, avoiding both over-protection of low-value assets and under-protection of critical systems. A DeFi protocol that fails to properly identify potential attack vectors, might focus extensively on their website and marketing infrastructure while overlooking smart contract security.

Effective threat modeling ensures security teams can identify and document all potential attack paths - enabling risk management teams to later assess and prioritize these threats effectively. Without threat modeling, organizations often distribute security resources evenly across all assets regardless of risk levels.

Practical guidance

🔗 Related Framework: For detailed approaches, see Understanding Threat Vectors and Threat Modeling frameworks.

Asset inventory

1. Digital value stores: Document cryptocurrencies, tokens, NFTs, and any assets directly convertible to monetary value
2. Credentials & access information: Catalog passwords, API keys, recovery seeds/phrases, private keys, and other non-physical authentication data
3. Identify all Hardware & physical devices:
   • Computing devices: Computers, phones, tablets, servers
   • Security hardware: Hardware wallets, YubiKeys, MFA devices, HSMs
   • Physical security: Office equipment, security systems, physical access controls
4. Infrastructure & systems: Map cloud resources, development environments, network equipment, and third-party services
5. Sensitive information & intellectual property: Track code repositories, proprietary algorithms, customer data, business documents, email archives, and backup files
6. Legal & compliance assets: Identify digital certificates, identity documents, contracts, and regulatory compliance documentation

For these, you can use technologies such as:

• Configuration Management Databases (CMDBs)
• Specialized asset tracking software
• GRC (Governance, Risk, and Compliance) platforms with asset inventory modules

⬇️ Collapsible Example: Pinnipeds Inc. asset inventory

Pinnipeds Inc. Asset Inventory

Pinnipeds Inc. is a small company with 15 employees. Here's how they categorized their assets:

Asset Category	Items
Digital value stores	• Company treasury holding 5 BTC and 50 ETH for operations • Client tokens held in custody during project development • Test tokens on various testnets for development purposes
Credentials & access information	• Multi-signature wallet configuration (3-of-5 signers) • Password manager company accounts for all employees • Recovery seed phrases (stored separately from devices) • SSH keys for server access • API keys for third-party services
Hardware & physical devices	Computing devices: • 15 developer laptops with encrypted drives • 5 company mobile phones for executives • 2 physical servers for internal development Security hardware: • Hardware wallets for each founding member (3) • YubiKeys for all developers for GitHub access • Biometric access readers Physical security: • Office security system with cameras • Card readers for building access • Secure storage for sensitive documents
Infrastructure & systems	• AWS cloud infrastructure for production environments • GitHub organization with private repositories • CI/CD pipeline tools (Jenkins, GitHub Actions) • Company VPN for remote work • Slack and Discord for internal and client communications
Sensitive information & IP	• Custom smart contract code for clients • Internal research on blockchain optimization • Client database with contact and project information • Financial records and business strategy documents • Employee personal information
Legal & compliance assets	• Company incorporation documents • Client contracts and NDAs • Regulatory compliance documentation for different jurisdictions • SSL certificates for company websites • Code audit reports and security assessments

Adversary analysis

1. Classify potential attackers by tiers:
   • Tier 1 (Opportunistic): Random cybercriminals, script kiddies, automated scanners
   • Tier 2 (Targeted): Organized crime groups, corporate competitors, angry ex-employees
   • Tier 3 (Advanced): Nation-state actors, APT groups, sophisticated criminal syndicates
2. Document adversary capabilities and motivations:
   • Technical capabilities and resources
   • Financial motivations or strategic goals
   • Persistence level (hit-and-run vs. long-term compromise)

⬇️ Collapsible Example: Analysis of adversaries targeting Pinnipeds Inc.

Pinnipeds Inc. Adversary Analysis

Adversary Tier	Characteristics	Examples & Techniques
Tier 1 (Opportunistic)	Who: Individual hackers, script kiddies, automated scanners/bots Motivations: Quick financial gain, building reputation, opportunistic theft Capabilities: Using public exploits, basic phishing, automated scanning tools Targets: Public-facing infrastructure, employee email accounts, known vulnerabilities	• Crypto wallet draining scams • Generic phishing campaigns • Website defacement • Automated vulnerability scanning
Tier 2 (Targeted)	Who: Organized criminal groups, competitors, disgruntled former employees Motivations: Financial theft, competitive advantage, sabotage, revenge Capabilities: Custom malware, spear phishing, social engineering, persistent attacks Targets: Company treasury wallets, intellectual property, client data, employee credentials	• Targeted social engineering of specific developers • Custom exploits for Pinnipeds' systems • Extended reconnaissance operations • Sophisticated phishing campaigns
Tier 3 (Advanced)	Who: Nation-state actors, sophisticated criminal syndicates, APT groups Motivations: Strategic intelligence, large-scale financial theft, disruption Capabilities: Zero-day exploits, supply chain attacks, long-term persistence, stealth techniques Targets: Crypto treasury, proprietary algorithms, strategic business information, infrastructure access	• Lazarus Group's systematic targeting of cryptocurrency organizations • Supply chain compromises • Advanced persistent threats with long dwell times • Multi-stage attack campaigns

Attack vector mapping

1. Map potential attack vectors:
   • Technical: Zero-day exploits, vulnerability exploitation, network attacks
   • Social: Phishing, social engineering, insider threats
   • Physical: Device theft, office intrusion, hardware tampering
   • Operational: SIM swapping, supply chain compromise, third-party breaches
2. Document potential attack scenarios for each critical asset
3. Link attack vectors to adversary capabilities identified in your adversary analysis

⬇️ Collapsible Example: Attack Vector Mapping for Pinnipeds Inc.

Pinnipeds Inc. Attack Vector Analysis

Critical Asset: Treasury Wallet (Financial)

Attack Vector	Description	Relevant Adversary
Phishing	Targeted emails to obtain wallet credentials	Tier 1-2 attackers
Social engineering	Manipulating employees to gain access	Tier 2 attackers
Supply chain compromise	Compromised wallet software	Tier 3 attackers
Insider threat	Disgruntled employee with access	Tier 2 attackers

Critical Asset: Source Code (Intellectual Property)

Attack Vector	Description	Relevant Adversary
GitHub account compromise	Targeting developer credentials	Tier 1-3 attackers
CI/CD pipeline injection	Injecting malicious code during build	Tier 3 attackers
Code repository breach	Direct attack on GitHub infrastructure	Tier 3 attackers
Developer machine compromise	Targeting local development environment	Tier 2-3 attackers

Critical Asset: Client Data (Customer Information)

Attack Vector	Description	Relevant Adversary
Database exploitation	SQL injection or other DB vulnerabilities	Tier 1-2 attackers
AWS credential theft	Stolen cloud access credentials	Tier 2 attackers
API vulnerabilities	Insecure API endpoints	Tier 1-2 attackers
Data in transit interception	Man-in-the-middle attacks	Tier 2-3 attackers

Implementation details

Role-specific considerations:

• Security specialists: Lead the threat modeling process, provide intelligence on current threats
• Operations: Contribute infrastructure knowledge and implement technical controls
• Developers: Identify code-level vulnerabilities and secure development practices
• HR/Management: Address insider threat risks and security awareness training
• Community/Marketing: Consider reputation risks and public-facing attack surfaces

Practical Frameworks and Tools

After completing the asset inventory, adversary analysis, and attack vector mapping, organizations can leverage established frameworks and visualization techniques to systematize their threat modeling approach. These tools help translate the theoretical understanding of threats into practical, actionable security measures.

STRIDE Threat Categorization Framework

The STRIDE framework, developed by Microsoft in the late 1990s, offers a systematic approach to identifying and categorizing threats. It maps directly to key security properties that must be protected in any system:

Organizations can apply STRIDE systematically to each component identified in their asset inventory to ensure comprehensive threat coverage.

Attack Trees: Visualizing Attack Paths

Attack trees provide a structured method to visualize potential attack scenarios against critical assets. They help security teams understand the relationship between different attack vectors and identify the most critical paths requiring mitigation:

Goal: Steal crypto assets
├── Compromise user wallet
│   ├── Phishing attack
│   │   └── Mitigate: Security awareness training
│   └── Malware infection
│       └── Mitigate: Endpoint protection
├── Attack exchange
│   ├── API key theft
│   │   └── Mitigate: IP restrictions, 2FA
│   └── Credential stuffing
│       └── Mitigate: Unique passwords, MFA
└── SIM swapping
    └── Mitigate: Hardware keys, non-SMS 2FA

Further Reading & Tools

Frameworks & References

• NIST SP 800-154: Guide to Data-Centric System Threat Modeling
• OWASP Threat Modeling Cheat Sheet
• Microsoft STRIDE Model
• MITRE ATT&CK Framework

Visualization & Modeling Tools

• Microsoft Threat Modeling Tool,
• OWASP Threat Dragon

Risk Management

🔑 Key takeaway: Risk management transforms threat information into actionable priorities. It helps you determine which threats matter most, where to allocate resources, and how to make security trade-offs that align with business goals.

Effective risk management builds upon threat modeling to assess, prioritize, and mitigate identified security risks. While threat modeling identifies what needs protection and potential attack vectors, risk management determines which threats warrant immediate attention and resources.

Risk Assessment Process

🔗 Related Framework: This process builds directly on outputs from Threat Modeling.

Key Components

1. Impact Analysis: Estimating the potential consequences of a security incident
2. Likelihood Determination: Assessing the probability of a threat exploiting a vulnerability
3. Risk Calculation: Combining impact and likelihood to determine risk levels
4. Risk Prioritization: Determining which risks to address first

Implementation Steps

1. For each threat scenario identified in threat modeling, assign impact ratings based on financial, operational, and reputational factors
2. Determine likelihood based on threat intelligence and historical data
3. Calculate risk scores (typically Risk = Impact × Likelihood)
4. Prioritize risks based on scores and organizational context

Prioritization Methodology

Not all risks require the same level of attention. Prioritize based on:

Trade-off Analysis

Security decisions often involve trade-offs between security, usability, cost, and other factors. Trade-off analysis helps make informed decisions.

Key Considerations

Decision-Making Framework

1. Define: Clearly articulate the security challenge and objectives
2. Identify: Enumerate all viable options
3. Analyze: Evaluate each option against established criteria
4. Select: Choose the option that best balances competing priorities
5. Implement: Execute the chosen option
6. Review: Assess the effectiveness of the decision and adjust as needed

Web3-Specific Considerations

In Web3 environments, risk management must address unique challenges:

Unique Risk Factors

Best Practices for Web3 Organizations

⬇️ Collapsable Example: Risk Assessment for Pinnipeds Inc.

Pinnipeds Inc. Risk Assessment

Building on the threat vectors identified during threat modeling, Pinnipeds Inc. conducted a risk assessment:

Risk Calculation Methodology

Rating	Impact	Likelihood
1	Minimal	Rare
2	Minor	Unlikely
3	Moderate	Possible
4	Major	Likely
5	Severe	Almost Certain

Formula: Risk Score = Impact × Likelihood

High Risk Threats (Score 15-25)

Threat Scenario	Likelihood	Impact	Risk Score	Reasoning
Treasury wallet compromise	4	5	20	High impact due to direct financial loss; relatively high likelihood given frequency of attacks on crypto companies
Source code theft	3	5	15	High impact due to IP loss and potential backdoor insertion; medium likelihood based on industry intelligence
Phishing of employees	5	3	15	Medium impact as most employees have limited access; very high likelihood based on attack trends

Medium Risk Threats (Score 8-14)

Threat Scenario	Likelihood	Impact	Risk Score	Reasoning
Client data breach	3	4	12	Major impact to reputation; moderate likelihood based on API exposure
DDoS on infrastructure	4	3	12	Moderate impact on operations; likely to occur given industry trends
AWS credentials leaked	2	5	10	Severe impact if exploited; unlikely due to current controls

Mitigation Decision Process

Factor	Approach
Resource allocation	60% of security budget allocated to high-risk threats
Implementation timeline	High-risk mitigations scheduled for completion within 30 days
Control selection criteria	Controls evaluated based on cost, operational impact, effectiveness, and implementation time

This risk-based approach allowed Pinnipeds Inc. to make informed decisions about which security controls to implement first, focusing resources where they would have the greatest risk-reduction impact.

Further Reading & Tools

• NIST Risk Management Framework
• ISO 31000:2018 Risk Management Guidelines
• FAIR (Factor Analysis of Information Risk) Framework
• OWASP Risk Rating Methodology
• Tools: Eramba (open source GRC)

Operational Security while traveling

🔑 Key Takeaway: Travel introduces unique security risks to your digital assets and sensitive information. Proper preparation before, vigilance during, and careful review after travel creates a comprehensive defense strategy that balances security with practical usability.

When we travel, our normal security routines are disrupted, and we face elevated risks from physical theft, digital surveillance, border inspections, and social engineering. Web3 professionals face additional challenges when traveling with crypto assets or access to treasury funds.

The resources in this section provide practical guidance for maintaining operational security while traveling:

• OpSec Travel Guide - A comprehensive resource covering all aspects of travel security with in-depth explanations and implementation details
• Too Long; Did not Read version - A condensed checklist format for quick security planning before and during travel

Three-phase Security Approach

Our travel security framework is organized into three critical phases:

1. Pre-travel preparation: Risk assessment, device hardening, backup creation, and contingency planning
2. On-trip vigilance: Network security, physical device protection, social engineering awareness, and maintaining operational security
3. Post-travel review: Device inspection, account security verification, and lessons learned documentation

Additional considerations are provided for high-risk travelers who may face targeted threats due to their role or access to valuable assets.

Personal security travel guide — full

🔑 Key Takeaway: Minimize data exposure by carrying only essential devices with full-disk encryption and updated software. Secure accounts with backup 2FA methods, avoid biometrics at borders, use trusted networks with VPNs, and never leave devices unattended. Guard against USB attacks, shoulder surfing, and hidden cameras. For crypto, use strong passphrases and never travel with seed phrases. Upon returning, scan devices for malware and consider resetting high-risk devices.

❗ This is not, by any means, an extensive guide on this subject or expected to be followed at its core. Its intention is to guide and provide hints as to where to apply security. This will vary depending on case to case, or, in other words, the risks you expose yourself to, by specifically traveling.

This guide is categorized into four sections:

1. Before traveling: All the things you could do before you depart, such as hardening some devices or making sure you have a backup of the data you’ll be traveling with, even letting know someone you’ll be calling in case of an emergency and how to identify you. This does not necessarily mean that if you’re reading this while traveling you cannot do anything from that list, only that it might be more challenging to execute depending on your context.
2. While traveling: All the things you have to pay attention to or take care of while on the move. Is it necessary to connect to that conference’s WiFi? Have you checked if there is a camera that might be recording your keystrokes? Leaving your computer unattended or just running whatever software your hackathon teammate asks you to download in order for your promising project to win.
3. Returning home: Not in the literal sense of it, but directed toward all the things you have to do after your travels. From updating your processes based on experience to wiping exposed devices before rejoining them to your networks.
4. Additional information for high-profile targets: If you are a high-profile target, you’ll evidently realize that some of these initial suggestions fall short within your threat model. This section provides a hint toward profiles like yours.

Before traveling

💡Remove or securely store any data, devices, printed files, and documents you don’t absolutely need on the trip. The less sensitive information and fewer critical assets you carry, the lower the risk and impact if loss, theft, or inspection occurs. Minimize your digital and physical footprint by leaving backups and originals securely at home or in trusted locations, and encrypt what must travel with you. This principle applies to laptops, phones, hardware wallets, paper backups, and any portable storage media.

Perform a quick threat model

Even if you are already traveling, take 5 minutes to map out your risks. Identify what assets you're carrying (laptops, phones, hardware wallets, seed phrases, account access), who might target them (thieves, cybercriminals, border agents, etc.), and how attacks might happen (device theft, tampering, malware, coercion). For each threat, plan a mitigation. For example, if you're carrying a hardware wallet, a threat is pickpocketing – mitigation could be keeping it attached to yourself (just don't use ledger's necklace) and securing it with a secure PIN/passphrase (no patterns, not repeated across devices).

This exercise keeps security measures proportionate to your situation.

Secure devices with encryption & updates

Enable full-disk encryption on all devices (laptops, phones, tablets) to protect data if lost or stolen. Most modern OSes have this by default (e.g. BitLocker for Windows, FileVault for MacOS, LUKS for Linux,or Android/iOS encryption – just ensure a strong password/PIN is set).

Use popular devices like iPhones and Pixels. Install the latest OS and app updates since these patch security vulnerabilities, you can install any of the mobile security applications there are, which adds a layer of security and also reminds you of important security updates.

If you must bring high-risk confidential data, consider encrypting those files individually using tools like VeraCrypt.

Back up and prepare for loss

Back up your devices before travel (and ensure cloud backups like iCloud/Google are up to date). This way, if a device is lost or confiscated, you won’t lose important information. Record device details (make, model, serial numbers, IMEI for phones) and keep that list separate – it will help in filing reports or remote-wipe commands.

If your company uses Mobile Device Management (MDM) on phones or laptops, verify the device is enrolled and you know how to trigger a remote wipe or “lost mode.” Test “Find My” or equivalent device-finding services so you can use them if needed. Pack chargers and cables so you won’t need to borrow unknown ones (which could be malicious).

Protect Accounts with 2FA redundancy

Plan for how you’ll access accounts that use two-factor authentication if your main device is unavailable. For authenticator apps (TOTP codes), print out backup codes for your important accounts and keep them securely in services like 1Password or NordPass. Alternatively, consider storing them elsewhere physically (not on your phone). If your 2FA is tied to a phone number (SMS or voice), disable SMS for 2FA. For technologies that are unfortunately dependent on phone numbers, use a separate line (not your personal one) from services like Google Voice, Burner App or SLYFONE. Transfer your number to an eSIM since they are harder to physically steal or swap than a physical SIM. You can also register a backup 2FA method (e.g. add a secondary phone or a backup hardware key to your accounts) in case of emergency.

Ensure your password manager is accessible – many like 1Password have a Travel Mode that removes sensitive vaults from your device while you travel (you can restore them later). This limits exposure if your device is searched or seized.

Secure your wallets and keys

Hardware wallets (e.g. Ledger, Trezor): Update the firmware and test the device before you leave, don’t do this while traveling. Do NOT bring any written seed phrases under any circumstance – seed backups are unencrypted keys that are far easier to steal or copy than a hardware device. Leave seed backups in a secure place and travel only with your hardware wallet. Enable all security features on the device (set a strong PIN, and use a BIP39 passphrase for example, if supported) so that even if the device is stolen, the amount of required information to access your crypto, is high. Carry hardware wallets and security keys in your carry-on or under your sight, not in checked luggage, to avoid loss or tampering.

Yubikeys and 2FA tokens: Bring them to protect logins (they’re the best MFA) and make sure they’re enabled on your critical accounts. Keep them on your person or in a separate bag from your laptop/phone so that a thief or snoop can’t easily steal both at once. If you have a spare hardware wallet or Yubikey, you might leave one at home as a backup in case the one you carry is lost. Add, when possible, an extra layer of security to the token, such as a PIN code.

Lock down phones

On your smartphone, take advantage of security settings before you travel. Set a strong passcode (not just a 4-digit PIN or pattern). Consider disabling Touch ID/Face ID if you might face situations where someone could force-unlock your device using your biometrics – in many jurisdictions, authorities can compel a fingerprint or face scan more easily than a memorized password. At a minimum, know how to quickly and temporarily disable biometrics; for example, on an iPhone, holding the side button and a volume button will trigger an emergency mode that requires the passcode to unlock. On Android, use Lockdown mode if available (which only temporarily disables biometrics and is different from iOS Lockdown Mode).

If you have an iPhone, enable Lockdown Mode (extreme protection on iOS) even if you are not at high risk or traveling to a high-threat region – but be aware it restricts many features, though totally worth it.

Disabling or restricting USB debugging on Android and using iOS USB restricted mode helps prevent unauthorized physical USB access and reduces risks from malicious cables or compromised charging stations.

If your phone is managed by work (MDM), inform your IT team of your travel so they can assist with any location-based security policies and ensure you have the latest security profile. Finally, consider using a dedicated eSIM/local SIM for travel data. This can protect your primary phone number (you can keep your main line on eSIM and turn it off, while using a local data eSIM for mobile internet) and avoids physical SIM issues.

Configure additional phone protections: On iOS devices, disable Control Center and Notification Center access from the lock screen (Settings > Face ID & Passcode) to prevent thieves from seeing notifications or enabling Airplane Mode without unlocking. Disable USB accessory connections when locked to prevent unauthorized connections. For device recovery, ensure Find My iPhone is enabled with "Send Last Location" and "Find Network" options activated so tracking continues even if the device is powered off.

On Android, similar protections can be configured: disable notifications on lock screen (Settings > Notifications > On lock screen > Don't show notifications), and enable "Find My Device" with all location services.

Pay special attention apps security: many financial apps default to PIN verification instead of biometrics, which means a thief who has your phone and knows your PIN could potentially access your financial accounts even if they can't bypass Face ID/Touch ID. Use unique PINs for banking apps that differ from your device PIN, or where possible, configure these apps to require biometric verification for every login.

Minimize digital footprint & social visibility

It's not just cyber threats – operational security matters. Avoid announcing your travel plans publicly on social media and be careful with real-time updates. Posts about being away from home can signal to criminals that you (and possibly valuable devices or even your house) are vulnerable. Consider sharing trip photos and crypto conference highlights after you return or only with trusted contacts. Ensure your social media privacy settings are tightened so strangers can't see your travel posts.

When registering for events, use privacy-focused tools like iOS's Hide My Email or create burner emails through providers like ProtonMail. Avoid giving out personal details unnecessarily during registration—use minimal, generic info to reduce your digital footprint.

Discretion is key: if possible, don't advertise that you work in crypto or carry cryptocurrency. For example, remove or cover any crypto stickers on laptops or bags, and avoid wearing company swag or Bitcoin/Ethereum logos while in transit. These can be neon signs attracting thieves or unwanted attention ("I have valuable data or wallets!"). If asked about your work or luggage by curious strangers, have a cover story (e.g. "I work in finance/IT") rather than "I manage a crypto fund". High-profile team members might travel under pseudonyms or at least not list their company on luggage tags to stay low-profile. Also, be wary that you might be traveling with someone with these characteristics, so don't give them away.

Plan emergency and incident responses

Before departure, know what you'll do if something goes wrong. Have a fallback plan in case of device loss: who will you notify & how (have safe words and beware of deepfakes or impersonations); how will you revoke access to sensitive accounts; and how will you continue working (e.g., a backup laptop or a colleague who can step in).

If traveling to countries with strict tech or encryption laws (e.g., China, Russia, UAE), devices like VPNs, encrypted messaging apps (Signal, or Telegram with Secret Chats only), hardware wallets (Ledger, Trezor), Yubikeys, or encryption software (VeraCrypt, BitLocker) may be flagged by border authorities. Research local laws beforehand. Consider carrying a travel letter from your organization explaining the professional need for these tools, or use sanitized loaner devices to avoid issues at border controls.

Share your itinerary and contact information with a trusted peer so they can assist or monitor for any issues.

Finally, schedule critical work (especially high-value transactions) for before or after your trip if possible, so you’re not forced to do ultra-sensitive actions on the road. Criminals usually play with the “time-sensitive factor,” trying to trick you into doing something quick and urgent, by committing something reckless.

While traveling

Network safety – avoid untrusted Wi-Fi & Bluetooth

Treat every network as potentially hostile. Whenever possible, use a cellular connection or a personal hotspot instead of public Wi-Fi – your mobile data is encrypted and safer than an open café or hotel network. If you must use public Wi-Fi (hotel, airport, conference), verify the network name with staff and disable auto-connect features so your devices don't join networks without prompting you.

Turn off Wi-Fi and Bluetooth on your phone and laptop when you're not using them; this reduces the risk of unsolicited connections or Bluetooth-based attacks. Also, disable any device-to-device sharing like AirDrop or Nearby Share to prevent strangers from sending you files.

Use a trustworthy VPN for an extra layer of encryption for your internet traffic, although in most cases by using an updated device, safe hardcoded DNS records, and ensuring SSL while browsing (enforce HTTPS-only-modes or adding “http://*” to your uBlock list, might be enough. A reputable, non-logging VPN (or your company’s VPN) helps protect against snooping on public networks, especially if you’re handling highly sensitive work and using several communication channels.

Using a personal portable router combined with a trusted VPN adds a strong layer of security when connecting to public Wi-Fi networks. This setup creates a private, encrypted tunnel between your devices and the internet, minimizing exposure to malicious actors on shared networks. Whenever possible, prefer mobile data over Wi-Fi, as cellular networks provide better encryption and isolation by default. If you must use Wi-Fi, disable automatic connections and ensure you connect only to verified, trusted networks to reduce risk.

Device handling – keep them close and protected

Never leave your devices (laptops, phones, hardware wallets) unattended or unsecured in public. Keep them on your person or within sight whenever possible. In a conference or cafe, use a cable lock for your laptop if you must step away briefly, take it with you or get someone you trust to watch it over for you.

In hotels/Airbnbs, use the room safe for small devices when you're out, or consider a portable travel safe/bag you can lock to a fixed object. A portable door lock or door jammer for your room can add an extra barrier against intruders (useful in rentals without chain locks). This simple gadget prevents anyone (even with a key) from opening your door while you're inside, giving you peace of mind at night. When out and about, be mindful of pickpockets – use bags that zip and consider a subtle anti-theft backpack for expensive gadgets or important assets.

For hardware wallets or Yubikeys, a good practice is to separate them from the device they authenticate: e.g. don't carry your Yubikey on the same keychain as your laptop bag key; keep it hidden on you. And, of course, keep devices powered off or locked when not in use – enable short auto-lock timeouts on your phone/laptop so they aren't unlocked if snatched.

Beware of public USB charging

Avoid plug-and-play charging stations at airports or malls. The risk of “juice jacking” is that a malicious charging kiosk or cable can inject malware or siphon data when you connect via USB. Stick to using your own charger plugged into a power outlet, or use a USB data blocker (a little adapter that only passes power, not data). Similarly, do not plug unknown USB drives into your laptop – if someone hands you a free USB stick at an event, assume it could be a trap. USBGuard software (for Linux) or equivalent can be used to restrict USB device access on your computer, allowing only whitelisted devices. This tool can prevent an unknown USB from automatically tampering with your system by requiring authorization for new devices. At a minimum, disable any “USB autorun” features and consider locking down ports if your OS allows.

Screen privacy and social engineering

Practice situational awareness when working in public spaces. Shoulder surfing is a real threat – someone nearby could be watching you enter passwords or PIN codes. Use a privacy screen filter on your laptop or phone to narrow the viewing angle. This makes it much harder for anyone not directly in front of your screen to read it. Sit with your back to a wall when possible, and shield the keypad with your body or hand when typing sensitive info.

In crowded conferences or airports, be cautious if someone you don't know strikes up conversation — might be trying to distract you or talk about crypto; scammers might engage you to glean info or even attempt to get you to unlock your device. Don't log in to critical accounts in front of others – you never know who's looking.

Also be mindful of phishing attempts: traveling users are prime targets for fake "urgent" emails or messages. Double-check any unusual prompts before entering credentials, especially if you're on untrusted Wi-Fi (use your VPN and look for HTTPS).

Maintain OpSec in public

While traveling, blend in and stay discreet. Refrain from discussing sensitive matters in public areas where eavesdropping is possible, or directly sharing things like where you are staying to people you don't know. Even hotel lobbies or rideshares might not be secure for private discussions.

When meeting people, don't give your phone to others to type down their socials, and remember to disable default options like Telegram's sharing phone number when adding a contact.

Remember that hidden cameras or microphones could exist in unfamiliar environments. It's rare but not unheard of, especially in Airbnbs or rented spaces – malicious hosts have hidden cameras in items like smoke detectors, clock radios, or USB chargers. Give your accommodations a scan: look for odd or extra devices plugged in (especially facing beds or desks) and cover or unplug them if suspicious. You can also play ambient noise (or use a noise generator app) during confidential conversations to thwart any listening devices.

Keep a low profile: as mentioned, don't flaunt crypto wealth or gear. For example, if attending a blockchain conference, consider using an alias on your name badge that doesn't explicitly say your company or title, and don't display that badge outside the venue. When moving around, secure your laptop in a nondescript sleeve or bag (instead of one with a well-known conference brand). The goal is to avoid drawing the attention of both petty thieves and more organized attackers by limiting the signals that you're a high-value crypto target.

Don't fall into security by obscurity. Don't assume that by going "stealth", you cannot be the victim of an attack. These section's suggestions don't replace the rest.

Traveling with high-value crypto or duties

If you must make crypto transactions or access sensitive systems while on the road, do so with caution. Use trusted hardware and networks: e.g. if you need to send a transaction, use your hardware wallet on your own laptop (never a shared computer), on a secured connection.

Be aware of surveillance at events – attackers have been known to watch for people handling sensitive info. If you need to access a seed or enter a recovery phrase, do it in a private, secure setting (never over public Wi-Fi or in view of anyone, including cameras). Consider that everyone knows you own crypto at a crypto event, so your threat profile is elevated. 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-sig – 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.

While presenting or doing public appearances

One often overlooked risk is the exposure caused by presenting or hosting technical workshops in public. Without properly hardening or isolating your computer before setting up, you may unintentionally expose network services to hostile environments or reveal sensitive information on-screen. Always prepare a clean, minimal environment and verify no confidential data or open ports are accessible before connecting to unfamiliar networks or projecting your screen.

Physical safety and common sense

Operational security also has a physical aspect. Trust your instincts and normal travel safety rules: stick to well-lit and populated areas if carrying devices at night, don’t let strangers “shoulder surf” your ATM or credit card PIN (check for skimmers, fake interfaces), and keep your travel documents secure since identity theft can be as damaging as device theft.

Use hotel lockers at conferences if provided (for example, some events offer secure charging lockers – use them rather than leaving devices out only).

Beware of the classic “evil maid” scenario in hotels (where someone might tamper with your laptop in your room): using tamper-evident tape or seals on your laptop case can help detect this, though it’s mostly a concern for high-risk targets. If you have tamper-evident stickers or tamper-evident bags, you can seal your device in them overnight – any attempt to open or remove the device will leave a visible trace. While not foolproof against a determined adversary, it raises the bar and can deter casual snooping.

Petty thieves may look beyond obvious valuables. Simply locking items in a dorm safe or hiding them at home might deter casual theft, but savvy criminals often search inside books, behind electrical outlets, or within patterns on walls or furniture to find hidden stashes. Consider unconventional hiding spots and avoid predictable storage methods. Layer your physical security measures with tamper-evident seals or discreet decoy containers to raise the effort required for unauthorized access.

Above all, maintain an alert posture: be aware of who’s around when you’re working, and if something feels off (like someone persistently hovering or a device acting strangely), don’t ignore it. You can always relocate, power down your device, or otherwise cut off exposure at the first sign of trouble.

Returning home

Secure your accounts and passwords

Once you're back, if you suspect that any account credentials you used while abroad might have been exposed (especially if you had to log in over a hotel or conference Wi-Fi), address the issue. Change the passwords for any accounts you accessed unsafely during the trip – but if you don't feel is necessary, sometimes you pose a greater risk at doing so.

Do this from a trusted device/network (ideally wait till you're on your home or office network, not the airport Wi-Fi). Use this opportunity to upgrade weak passwords and ensure 2FA is still working on those accounts. Check your email filters and crypto account settings for any unauthorized changes (attackers sometimes add forwarding rules or new withdrawal addresses if they did get access).

Essentially, rotate secrets that may have been used under less-secure conditions.

Inspect and clean your devices

After traveling, give your devices a thorough once-over. Run a reputable anti-malware scan on laptops and phones. Look for any unusual apps, processes, or device behavior (for example, unusual battery drain could indicate malware).

If you were in a high-risk environment or your device was out of your control at any point, consider wiping the device and restoring it from your pre-trip backup (or factory-resetting a phone) to ensure it's clean. This is especially recommended for "burner" devices used on the trip – you can safely restore your data onto your main device and decommission the travel device.

For hardware wallets, verify they weren't tampered with: check the device seals if any, and when you connect, confirm the firmware is still legitimate (if the manufacturer provides verification software). If you have any suspicion that a device (or hardware wallet) was compromised, do not continue using it for sensitive transactions. Transfer crypto assets to new wallets (using your seed backups in a new device if necessary) once you're on a secure network and device. It's also a good idea to disable or remove any travel-specific eSIMs or accounts you used on the trip – for example, remove that foreign cellular plan from your phone if you no longer need it, and uninstall any travel or conference apps that are no longer required.

Post-travel review

Now that you're home, reflect on the trip and note any security incidents or close calls. If any device was lost, stolen, or even taken out of your sight and potentially tampered (like held by airport security for a long inspection), inform your organization's IT or security team immediately. They may assist with forensic checks or account monitoring. Also inform colleagues if any work data might have been exposed so they can be vigilant. This is not about blame – it's about mitigating any damage early.

Re-enable any data or accounts you put in "travel mode." For instance, if you used 1Password Travel Mode to hide vaults, log in and turn those vaults back on. If you created throwaway emails or burner chat accounts for the trip, decide if you'll deactivate them now.

Update your threat model based on your experience: did any new threats emerge, or did some precautions prove unnecessary? Use that to improve future travel prep. Finally, share key lessons with your team. Sharing what you've learned from each trip and tweaking your security practices contributes to a stronger security culture for everyone!

Additional precautions for high-risk travelers

This section is for Web3 professionals who have elevated privileges or profiles – for example, access to multisig treasury keys, leadership roles, or possession of sensitive organizational secrets. These users may be targeted more deliberately by criminals or even nation-states. In addition to all the precautions above, high-risk travelers should take further steps:

For high-profile or recognizable individuals, keeping a low profile is essential. Beyond avoiding branded merchandise, a simple yet effective tactic is wearing a COVID N95 mask or similar face covering. It's socially accepted, draws no attention, and helps protect your identity — making it harder for adversaries to target or track you during public events.

Use loaner or "burner" devices

If feasible, travel with clean devices that don't contain sensitive data. Leave your primary laptop/phone at a protected location (assuming you also have security in place as well), and bring a wiped, minimal laptop or a cheap travel phone with only the basics. Log into what you absolutely need (through secure channels) and nothing more. Treat these devices as expendable – assume they will be compromised and plan to wipe them afterward. For example, a senior developer might bring a laptop with no source code on it and use a VPN or VDI (virtual desktop) to access company systems when necessary, leaving no data on the local disk. A hardware wallet keyholder might carry a secondary hardware wallet with lower privileges (or a single key to a multisig instead of full access). Keep your primary keys secured in a location that is not accompanying you. Remember, a nearly empty device can raise suspicion at some borders, so don't make it obvious – load some innocuous data (music, generic files) so it looks used, but nothing that would be harmful if inspected.

Plan for customs and border checks

High-risk individuals may face increased scrutiny or device searches at borders due to the sensitive nature of their data or their roles (e.g., journalists). Before crossing borders, purge or secure sensitive information. Turn off devices before landing (some experts even recommend encrypting and then powering down devices – a powered-off device with strong encryption is extremely hard to access).

Disable cloud auto-sync of sensitive data; you don’t want customs inadvertently accessing company cloud drives if they inspect your laptop. If asked to unlock devices, having them powered off gives you an opportunity to state that it’s encrypted and requires a passphrase (which you should have memorized, not written down). It’s wise for high-risk travelers to disable biometrics entirely before travel – use PIN/password only, as mentioned – so you cannot be compelled or tricked via fingerprint/face. Know your legal rights in the countries you transit; in some places you can refuse to unlock (though it may mean the device is held or you are denied entry), while in others you might face penalties. This is a personal risk decision – but the best case is to carry nothing truly incriminating or irreplaceable across a checkpoint. For ultra-sensitive data, use secure communication channels to retrieve it at destination rather than carrying it. For instance, an executive could store confidential files in a secure cloud drive they access over VPN once abroad, rather than carrying them on a laptop.

Enhanced device protections

High-risk users should layer additional defenses. Lockdown Mode (on iOS) or Android’s equivalent secure modes should be enabled if there’s any chance of targeted spyware (these modes disable exploit-prone services and attachments). Use messaging apps with end-to-end encryption and disappearing messages (NOT Telegram, Signal is a good example) for any sensitive communications – assume that standard SMS or emails could be monitored.

Consider using a Faraday bag for phones when not in use, if you suspect active tracking or exploitation (this prevents any signals in or out, though use sparingly as it also blocks your calls). If you leave a device in your hotel, you can put it in a tamper-evident bag and seal it, or at least take measures like noting the exact placement or taking a photo, so you can detect if it was disturbed. Some high-risk individuals even weigh their devices before and after travel to detect the addition of hardware implants (a change in weight could indicate something like a chip added) – this is an extreme step, but shows the level of caution possible. At the very least, physically inspect your devices for new scratches, screws that look tampered with, or unexpected behavior.

Protect crypto keys with multi-party controls

If you have access to significant crypto funds (exchanges, DAO treasury, etc.), implement policies that prevent a single point of failure while you’re traveling. For example, if you’re one of N-of-M multisig signers, consider temporarily requiring an extra signer for transactions while you’re away (so if normally 2-of-3 can move funds, bump it to 3-of-3 or add a 4th backup signer) so that a compromised key or coerced action cannot alone execute a transfer.

If you hold hardware keys, keep them geographically split – e.g. bring one key device with you, leave the backup key in a safe place at home, and perhaps give a third key to a colleague, so that even a forced disclosure cannot result in an immediate loss of funds without collaboration. Use duress codes if your hardware supports it (some wallets allow a secondary PIN that opens a decoy account with minimal funds, the same can also be made with encryption volumes).

In general, assume a determined adversary could target you specifically for your role: use confidential communication to stay in touch with your team (so they know you’re safe daily), and establish a code word or protocol for emergencies. High-risk travelers might also arrange a “check-in” schedule with their security team or colleagues – if you don’t check in by a certain time, they can take pre-agreed actions (like disabling your accounts or alerting authorities). This kind of planning is an extra safety net when the stakes are especially high.

Post-trip device rebuilding

For highly targeted individuals, the safest course after returning is to treat every device as compromised and rebuild it, especially before reaching your safe zone (home, work office). This involves wiping devices to factory settings, flashing firmware if necessary, and restoring data from known-good backups made before the trip.

Consider using read-only operating systems or booting from trusted live media during travel to reduce risk exposure. Before your trip, you can create a cloned disk image of a clean system state, so after traveling you can restore your device to that exact low-level copy — starting fresh with a known secure baseline. This approach helps eliminate stealthy malware or spyware that may have been implanted.

Additionally, review system logs if available (security apps or MDM solutions often report unusual access or configuration changes during your absence). As always, report any suspicious incidents promptly. High-risk roles may require a debrief with your security officer — be transparent about any odd encounters or possible security lapses to mitigate threats that could have followed you home.

--

Part of the contents were inspired and based on some of the following articles.

• CISA Cybersecurity While Traveling – official tips on device updates, Wi-Fi safety, and physical device security | cisa.govcisa.gov.
• Cornell University IT Security – international travel security checklist (device encryption, using loaner devices, minimizing data) | it.cornell.edu | it.cornell.edu.
• Cypherock Blog – "Safe Vacation Tips while Traveling with Crypto" (advice on MFA keys, avoiding public Wi-Fi and chargers, not carrying seed phrases) | cypherock.com | cypherock.com.
• Schneier on Security (comments) – community OPSEC suggestions for border crossings (burner phones, no biometrics, 1Password Travel Mode) | schneier.com.
• The MacGuys – Apple device travel tips (Lockdown Mode, separate eSIM for travel, disabling Face ID in emergencies) | themacguys.com | themacguys.com.
• Unchained Capital – "7 Tips for Traveling with Bitcoin Keys" (don't advertise crypto holdings, leave seed backups at home, use passphrases/multisig for travel) | unchained.com | unchained.com.
• BlackCloak – Dangers of oversharing travel on social media (real-time posts can invite burglaries or attacks) | blackcloak.io.
• Trio Security Blog – Shoulder surfing and visual hacking (use privacy screens and be mindful of surroundings) | trio.so.
• Washington Post – Portable door locks for travelers (added security in accommodations) | travelandleisure.com and finding hidden cameras in rentals | washingtonpost.com.
• GitHub USBGuard – tool to enforce USB device policies on laptops (helps block malicious USB devices) | github.com.

Personal security travel guide — concise version

🔑 Key Takeaway: Protect your digital assets while traveling through minimizing sensitive data, using encrypted devices, avoiding public networks, securing hardware wallets, maintaining physical control of devices, being cautious with USB connections, practicing social discretion, and sanitizing devices upon return.

Before traveling

• Remove or securely store any data, devices, or documents not essential for the trip. Less sensitive material reduces risk if lost or stolen.
• Perform a quick threat model: list what you carry, who may target you, and how. Plan mitigations accordingly.
• Enable full-disk encryption on all devices; update OS, firmware, and apps before departure.
• Back up devices, record serial numbers and IMEI, and verify Mobile Device Management (MDM) enrollment and "Find My" functionality.
• Print or securely store backup 2FA codes; disable SMS-based 2FA if possible. Use eSIM or secondary numbers for authentication.
• Use password manager travel modes to hide sensitive vaults while away.
• Update and test hardware wallets; never travel with written seed phrases.
• Carry hardware wallets and 2FA tokens on your person; keep spares securely at home.
• Use strong phone passcodes; disable biometrics in risky scenarios; enable Lockdown Mode if available.
• Minimize your digital footprint: avoid public travel announcements and crypto branding.
• Prepare an emergency plan: who to notify if devices are lost or compromised, and how to revoke access quickly.
• Research local laws on encryption and tech; carry travel letters or sanitized devices if needed for border crossings.

While traveling

• Prefer cellular data or personal hotspots over public Wi-Fi; disable automatic Wi-Fi connections.
• Use a trusted VPN and consider a portable router to encrypt traffic on public networks.
• Turn off Wi-Fi, Bluetooth, AirDrop, and Nearby Share when not in use to reduce attack surface.
• Keep devices on you or locked; use cable locks and hotel safes.
• Be cognizant of what you are posting on Social Media in real time. Delay posting a location by 1-2 days to avoid anyone tracking you.
• Avoid public USB charging stations ("juice jacking"); use your own charger or a USB data blocker.
• Use privacy screens on laptops and phones; be mindful of shoulder surfing and phishing attempts.
• Don't discuss sensitive information publicly; be alert for hidden cameras or microphones in accommodations.
• Use passphrases on wallets and multisig setups for large crypto holdings.
• Separate hardware wallets and keys from the devices they authenticate.
• Consider portable door locks and tamper-evident bags to secure your room and devices overnight.

Returning home

• Change passwords and verify 2FA on accounts accessed during travel, preferably from trusted devices and networks.
• Scan devices for malware and unusual behavior; factory reset if you suspect compromise.
• Inspect hardware wallets for tampering; transfer funds if compromised or suspicious.
• Remove travel-specific SIMs, accounts, or apps no longer needed.
• Report incidents to your security or IT team; share lessons learned to improve future security.

High-risk traveler extras

• Use burner or loaner devices with minimal data; assume they may be compromised and plan to wipe them post-trip.
• Power down and encrypt devices before border crossings to limit data exposure.
• Disable biometrics completely pre-travel to avoid compelled unlocks.
• Enable Lockdown Mode and use end-to-end encrypted messaging apps (e.g., Signal).
• Use Faraday bags and tamper-evident seals to prevent tracking and unauthorized device access.
• Physically inspect devices before and after travel for signs of tampering or implants.
• Increase multisig signer requirements while traveling; geographically split key custody.
• Use duress codes if supported by hardware wallets.
• Establish secure emergency check-ins and code words with your team for rapid response.

Wallet Security

In cryptocurrency, the security of digital assets is directly tied to how control over the funds is protected. This section provides a technical deep-dive into wallet security, covering the range from fundamental concepts to advanced practices for safeguarding assets against theft, loss, and unauthorized access.

The goal is to move beyond introductory concepts and provide actionable, technical knowledge for securely managing crypto assets.

Table of Contents

• Custodial vs Non-Custodial - Comparing custodial and non-custodial wallet solutions.
• Cold vs Hot Wallet - Understanding the security trade-offs of online and offline wallets.
• Wallets For Beginners & Small Balances - Recommended setups for users with non-critical funds.
• Wallets For Intermediates & Medium Funds - Security upgrades for users with significant assets.
• Multisig Wallets For Advanced Users & High Funds - Best practices for setting up and managing multisig wallets.
• Account Abstraction Wallets - Exploring the security features of smart contract wallets.
• Signing & Verification - An overview of secure transaction signing and verification.
  • Verifying Standard Transactions (EOA) - How to safely verify transactions from standard wallets.
  • Multisig Signing Process - Detailed guide for secure multisig transaction signing.
  • Using EIP-7702 - Enabling smart contract features for EOAs and mitigating new risks.
• Private Key & Seed Phrase Management - Best practices for securing your seed phrase.
• Tools & Resources - A curated list of security tools and resources.

In this section you can learn:

• Explore wallet fundamentals, analyzing the security trade-offs of hot vs. cold wallets and the ownership implications of custodial vs. non-custodial models.
• Receive guidance on choosing the right wallet for your threat model, from basic setups to advanced configurations like Multisignature (Multisig) and Account Abstraction wallets.
• Master transaction verification techniques, from basic smart contract interactions to the advanced verification.
• Implement security best practices for private key and seed phrase management.

Mastering wallet security is a critical skill for any developer, user, or organization operating in the web3 ecosystem.

xkcd

Custodial vs. Non-Custodial Wallets

The distinction between custodial and non-custodial wallets centers on who controls the private keys. This control directly impacts ownership, security responsibility, and the ability to interact with the web3 ecosystem.

Custodial Wallets

What Are They?

Custodial wallets are managed by a third party, such as a centralized exchange (CEX) or a dedicated wallet service provider. In this model, the third party holds and manages the private keys on behalf of the user.

Characteristics

• Managed Private Keys: The third party has full control over the private keys. You do not possess them.
• Recovery Options: It is often easier to recover account access if login credentials are lost, as the custodian can assist.
• Security Dependence: The security of your assets is entirely dependent on the custodian's security practices, infrastructure, and operational integrity.
• Ease of Use: Provides a simpler user experience, abstracting away the complexities of private key management.

Use Cases

• New Users/Beginners: Suitable for users who are new to cryptocurrency and prefer a simpler, managed solution.
• Convenience Over Control: Ideal for users who prioritize convenience and ease of use over full control.

Non-Custodial Wallets

What Are They?

Non-custodial (or self-custody) wallets are managed directly by the user, who has sole and complete control over their private keys. The user is entirely responsible for the security, backup, and management of these keys.

Characteristics

• User-Controlled Private Keys: The user has exclusive control and possession of their private keys.
• Eliminates Counterparty Risk: Assets are not exposed to the risk of a third-party custodian being hacked, becoming insolvent, or freezing funds. Security becomes dependent on the user's own practices.
• Full Responsibility: The user is solely responsible for backing up their seed phrase and securing their private keys. Loss of these keys means irreversible loss of funds.
• Web3 Interaction: Enable seamless interaction with dApps.

Use Cases

• Experienced Users & Developers: Preferred by users who understand blockchain and wallet security best practices.
• Security & Control Prioritization: Ideal for users who prioritize full control over their assets and are willing to undertake the responsibility of self-custody.

Comparison

Cold vs. Hot Wallets

The primary distinction between wallet types is their connectivity to the internet. This factor dictates their security threat model, risk profile, and ideal use cases.

Cold Wallets

What Are They?

Cold wallets are cryptocurrency wallets that store private keys in an offline environment. By being disconnected from the internet, or "air-gapped," by default, they provide the highest level of security against online attacks like malware and phishing.

Transactions are signed offline and then broadcast to the network using a connected device, ensuring the private keys are stored on device with minimal connectivity.

❓ Did you know?

Most cold wallets come with some way to connect to the internet, such as via a USB connection. This technically makes them "hot" when connected. However, the key distinction is that they are not continuously online and are designed to minimize exposure to online threats.

Types of Cold Wallets

• Hardware Wallets: Dedicated physical devices that store private keys offline and sign transactions without exposing the keys to a connected internet device.
• Paper Wallets: Physical printouts or handwritten notes of private keys and QR codes.
• Software Wallets on Air-Gapped Devices: Standard wallet software installed on a device that is permanently disconnected from the internet, used for offline transaction signing.
• Brain Wallets: Private keys that are memorized.
• Account Abstraction Wallets: Using smart contracts to manage keys and transactions without exposing private keys.
• Multisig Wallets: Require multiple signatures to authorize a transaction, enhancing security.

Use Cases

• Long-Term Storage: Ideal for storing large amounts of cryptocurrency for extended periods.
• High-Security Needs: Essential for individuals securing significant value and operating with a low risk tolerance.

Hot Wallets

What Are They?

Hot wallets are actively and consistently connected to the internet. This connectivity makes them highly convenient for daily use but also inherently more vulnerable to online attacks.

Types of Hot Wallets

• Browser Wallets (Extensions): Software that integrates directly into a web browser, allowing seamless interaction with dApps.
• Mobile Wallets: Apps installed on smartphones.

Use Cases

• Daily Transactions & dApp Interaction: Perfect for users who need quick and frequent access to their funds for interacting with applications.
• Small Balances: Suitable for storing smaller, non-critical amounts of cryptocurrency that are used regularly.

Comparison

Key Security Considerations

Regardless of the type, non-custodial wallets place the full burden of security on the user:

• Online Vulnerabilities: If the device they are on (computer or phone) is compromised, your assets can be stolen.
• Supply Chain Attacks: Be cautious of both software and hardware integrity. Always download wallet software from official sources and purchase hardware wallets directly from the manufacturer to avoid receiving a tampered device.

For Beginners & Small Balances

User Profile

A user with foundational web3 knowledge who is actively learning and interacting with dApps. The asset value is typically non-critical, where a potential loss would not be financially significant. This profile prioritizes ease of use and learning over protections against online threats.

Primary Goal

The primary objective is a low-friction setup for convenience and dApp interaction. This includes frequent transactions, exploring DeFi protocols, and engaging with NFTs.

Recommended Setup

The standard setup for this profile is a hot wallet, which provides the necessary internet connectivity for active use. The most common types are:

• Browser Extension Wallets: Integrate directly into a web browser for seamless dApp interaction.
• Mobile Wallets: Applications installed on a smartphone, offering convenience and on-the-go access.
• Desktop Wallets: Software applications installed on a computer, which can sometimes offer more advanced features than mobile or browser counterparts.

Key Considerations & Trade-offs

While convenient, this setup carries inherent risks that the user must understand and accept.

• Online Threat Vector: As hot wallets are internet-connected, they are inherently vulnerable to malware and exploits targeting the browser or operating system.
• Supply Chain Risk: It is critical to download wallet software only from official, verified sources.

How to Select a Wallet

When selecting a wallet, prioritize those whose code is open-source, as this allows for public scrutiny and independent verification by the security community. For users who are not developers, several platforms provide independent analysis to help evaluate a wallet's security.

For example, Wallet Scrutiny focuses on verifying if a wallet's code is verifiably open-source. Others, like Wallet Security Ranking, provide a security score based on specific criteria such as transaction clarity, protection against known threats, and how it handles dApp permissions.

Using these tools can provide valuable data points to help you assess a wallet's security posture and make an informed decision.

For Intermediates & Medium Balances

User Profile

An intermediate user who is comfortable with web3 interactions and is now managing a significant, but not life-altering, amount of assets. This user understands the inherent risks of hot wallets and is actively seeking to upgrade their security posture to protect their capital.

Primary Goal

The main objective is to secure balances against online threats while still retaining the ability to interact with dApps when necessary. This involves separating the bulk of assets from daily operational balances.

Recommended Setup

A hardware wallet is the core of this setup. This dedicated physical device stores private keys offline in a secure, tamper-resistant environment, acting as a vault for the majority of the user's balances.

Key Considerations & Trade-offs

Adopting a hardware wallet introduces a new set of security considerations focused on physical and supply chain vectors.

• Physical Security: A hardware wallet is a physical asset that must be protected from theft, damage, or coercion.
• Supply Chain Integrity: Hardware wallets must only be purchased directly from the manufacturer or an authorized reseller to avoid receiving a tampered device.
• Convenience vs. Security: Using a hardware wallet introduces friction into the transaction process, as it requires physical access and approval on the device for every signature.

How to Select a Hardware Wallet

• Open Source: Evaluate if the wallet's firmware and software are open-source, which allows for public auditing and verification by the security community.
• Secure Element (SE) Look for devices with a SE certified, tamper-resistant chip that protects against physical attacks. Check for high assurance ratings like EAL6+ and features like attestation, which verifies the device is genuine.
• Reputation & Incident: Investigate the manufacturer's security track record, including their response to past vulnerabilities, data breaches, and overall transparency.
• Verify Device Integrity: A legitimate hardware wallet will arrive uninitialized, requiring you to perform the initial setup. Reject any device that comes with a pre-set PIN, a pre-generated recovery phrase, or appears to be already configured, as it is likely compromised.

Multisig Wallets For Advanced Users & High Funds

User Profile

Advanced technical users, developers, Decentralized Autonomous Organizations (DAOs), and organizations responsible for managing protocol treasuries, smart contract ownership, or significant personal/collective assets.

Primary Goal

The primary objective is to eliminate single points of failure and establish robust, distributed control over high-value assets and critical smart contract functions.

Core Concept: M-of-N Scheme

A multisignature (multisig) wallet is a smart contract that requires a predefined minimum number of approvals M from a total set of authorized signers N to execute a transaction. This is known as an M-of-N scheme (e.g., 2-of-3, 3-of-5).

By distributing signing authority, a multisig ensures that the compromise of a single private key is insufficient to authorize the movement of funds or execute a privileged action.

Setup Best Practices

• Threshold Selection: The M-of-N threshold should be chosen to balance security and operational resilience. Avoid N-of-N schemes, as the loss of a single key would result in a permanent loss of access to all funds.

• Strategic Signer Distribution: The security of a multisig depends entirely on the operational security (OpSec) of its individual signer keys. Storing multiple signer keys on the same device or in the same physical location negates the security benefits. Effective distribution strategies include:

  • Using different hardware wallet models and manufacturers.
  • Maintaining geographical separation for devices holding signer keys.
  • Assigning signer keys to different trusted individuals within an organization.
  • Using diverse client software to interact with the multisig to mitigate single-point-of-failure risks from a software vulnerability.

• Practice on Testnet: Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and owner management on a test network.

• Timelocks: Enforce a mandatory delay between the approval of a transaction and its execution. This provides a critical window for the community or team to detect and react to malicious proposals.

• Role-Based Access Control (RBAC): Implement modules that grant specific, limited permissions to certain addresses (e.g., a "pauser" or "executor" role) without making them full owners, adhering to the principle of least privilege.

• Disaster Recovery Plan: Establish a clear, documented process for what to do when a signer is compromised, the multi-signature UI is down, or other emergencies arise. These should be done at regular intervals.

Operational Best Practices

• Signer Key Revocation and Replacement: A feature of multisigs is the ability to add, remove, or replace signer keys. If a signer's key is compromised or lost, it can be revoked and replaced with a new, secure key through a transaction approved by the remaining owners, preserving the integrity of the wallet's assets without needing to migrate funds.

• Secure Signing Environment: For maximum security, all signing activities should be performed on a dedicated, air-gapped, or hardened device running a secure OS. Using a primary work laptop significantly increases the risk of malware interference.

• Independent Transaction Verification: Before signing, always verify the raw transaction data (target address, function call, parameters) to ensure it matches the intended operation.

• Out-of-Band Verification for Admin Changes: Any critical administrative action, such as adding or replacing a signer, must be verified through multiple, independent communication channels (e.g., a video call and a signed message) to prevent social engineering attacks.

• Active Monitoring: Implement monitoring and alerting systems to be immediately notified of any on-chain activity related to the multisig, including proposed transactions, new signatures, and owner changes (e.g., using tools like Safe Watcher ).

• Documented Procedures: Maintain clear, secure, and accessible documentation for all multisig procedures, including transaction creation, signing, and emergency recovery plans.

Acknowledgements

Some ideas were borrowed from the EF's multisig SOP notes and Manifold Finance multisig best practices.

Account Abstraction Wallets

User Profile

Advanced users, developers, and organizations interested in programmable security, customizable transaction rules, and moving beyond the limitations of standard Externally Owned Accounts (EOAs) to eliminate single points of failure like seed phrase loss.

Primary Goal

To leverage the power of smart contracts at the account level, enabling features like social recovery, gas sponsorship, batch transactions, and flexible security policies that are not possible with an EOA.

Core Concept: ERC-4337

Account Abstraction (AA) turns a user's account into a smart contract, making it programmable. Instead of being controlled directly by a single private key, the account's logic is defined by its code. This is achieved through ERC-4337, a standard that enables AA without requiring changes to the core Ethereum protocol. It introduces a higher-level pseudo-transaction system with several key components:

• Smart Contract Account: The user's wallet itself is a smart contract, containing custom logic for validating transactions.
• UserOperation: A data structure that bundles the user's intent, calldata, and signature. This object is sent to a dedicated, alternative mempool.
• Bundlers: Specialized nodes that package multiple UserOperation objects from the mempool into a single transaction and submit it to the EntryPoint contract.
• EntryPoint: A singleton smart contract that acts as the central orchestrator. It verifies and executes the bundled UserOperations, ensuring that accounts and paymasters have sufficient funds to pay for gas.
• Paymasters: Optional smart contracts that can sponsor gas fees on behalf of the user, enabling gasless transactions for the end-user or allowing fees to be paid in ERC-20 tokens.

Key Benefits & Features

• Enhanced Security:

  • Social Recovery: Mitigate the risk of losing a primary key by designating trusted "guardians" (other accounts or devices) who can collectively approve an account recovery.
  • Customizable Policies: Implement robust security rules directly into the wallet, such as daily spending limits, whitelisting trusted contracts, or requiring multisig confirmation for transactions over a certain value.

• Improved User Experience:

  • Gasless Transactions: Enjoy a smoother experience where dApps can sponsor gas fees, or pay for transactions using ERC-20 tokens instead of needing the chain's native asset (e.g., ETH).
  • Simplified Interactions: Perform complex, multi-step actions (like approve and swap) in a single, atomic transaction, reducing clicks and potential points of failure.

Security Considerations & Best Practices

• Smart Contract Risk: The security of an AA wallet is entirely dependent on the quality and security of its underlying smart contract code. Bugs or vulnerabilities in the account's implementation can lead to a total loss of funds. Thorough audits of the account logic are non-negotiable.
• Guardian Selection and Security: The strength of the social recovery model depends on the security and independence of the guardians. They should be diverse and not susceptible to a single common threat.
• EntryPoint Centralization: The EntryPoint contract is a central trust point for the entire ERC-4337 ecosystem. A vulnerability in the official EntryPoint could have widespread consequences. Use only the canonical, heavily audited EntryPoint contract.
• Paymaster and Factory Security: Malicious or poorly coded Paymasters and Factories can introduce DoS vectors or other risks. The ERC-4337 standard includes a reputation system and staking mechanisms to throttle or ban misbehaving entities, but users should only interact with trusted and audited Paymasters.
• Gas Overhead: The added logic in a smart contract account means that transactions can be more expensive than those from a standard EOA. This trade-off between features and cost should be considered, though it can be offset by gas sponsorship.
• Key Revocation: If the primary signing key is compromised, the recovery process allows you to swap it out for a new one without having to move all assets to a new wallet address.
• Advanced Guardian Setups: For enhanced security, guardian roles can be implemented using Multi-Party Computation (MPC). In an MPC-based recovery, guardians hold cryptographic shares that are used collectively to authorize a recovery action. This method allows guardians to produce a valid signature through a distributed computation using their individual shares, without ever reconstructing a single master key on any device.

Signing & Verification

This section provides a guide to transaction verification, from basic EOA interactions to advanced multisig operations.

The rule is to never sign blindly. Always take the time to verify what your wallet is asking you to approve. A compromised dApp front-end or a misunderstanding of a transaction's parameters can lead to a complete loss of funds, even with a wallet that is not compromised.

Core Principles of Secure Signing

Before diving into specific use cases, it's critical to adopt a security-first mindset built on these foundational principles:

• Verify, Don't Trust: Never trust a user interface blindly. The raw transaction data is the ground truth of what you are authorizing. Always use independent tools to confirm that what you see is what you sign.
• Simulate Before Signing: Before approving any non-trivial transaction, use a simulation tool. These tools act as a "sandbox," showing you the human-readable outcome before you commit, protecting you from unexpected results and malicious contracts.
• The Hardware Wallet is the Source of Truth: Your hardware wallet's trusted display is your last line of defense against UI spoofing. If the information on your computer screen does not perfectly match what is on your hardware device, reject the transaction immediately.
• Demand Clear Signing: Prioritize hardware and software that can decode and display a transaction's intent in a human-readable format. If a wallet requires "blind signing" (approving a raw, unreadable hash), you are accepting a significant level of risk.

In This Section

This chapter breaks down transaction verification into key areas:

• Standard Transaction Verification: An overview of the foundational security principles that apply to all types of transactions.
• Verifying Multisig Transactions: A detailed guide to the two-phase process of securely signing and executing multisig transactions, including how to verify EIP-712 hashes and execTransaction calldata.
• Verifying EIP-7702 Transactions: 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.

Verifying Standard Transactions (EOA)

When interacting with a dApp using a standard Externally Owned Account (EOA) via a wallet, you must verify several key components of the transaction request before signing.

1. Verify the Origin

• What to check: The URL of the website initiating the transaction request.
• Why it's critical: A malicious site can perfectly clone a legitimate dApp's interface to trick you into signing a malicious transaction. Always ensure you are on the correct, official domain.

2. Verify the Smart Contract Address

• What to check: The contract address listed under a field like "Interacting With" in your wallet's transaction prompt.
• Why it's critical: This is the actual on-chain address your transaction is being sent to. A malicious dApp will substitute a fraudulent contract address here.
• Verification Methods:
  • Official Documentation: The most reliable source. Find the "Contract Addresses" or "Deployments" section in the protocol's official documentation and confirm the address matches.
  • Block Explorer (Etherscan, Blockscout, etc.): Paste the address into a block explorer. Look for verification checkmarks, official labels, and a healthy transaction history.

3. Verify the Function and Parameters

• What to check: The function name (e.g., depositETH) and the parameters in the "Data" tab of your wallet.
• Why it's critical: This is the exact action you are authorizing the smart contract to perform. A malicious transaction might look legitimate on the surface but contain a harmful function call.
• Verification Methods:
  • Cross-reference with Documentation: The protocol's developer documentation will define the function and what each parameter represents.
  • Scrutinize Recipient Addresses: For any function that directs assets (e.g., onBehalfOf, recipient, to), ensure the address is your own or the intended recipient.
  • Understand Amounts: Verify token amounts, paying attention to the number of decimals.

4. Sanity-Check the Network Fee (Gas)

• What to check: The estimated gas fee for the transaction.
• Why it's critical: An unusually high gas fee for a simple operation can be a red flag, potentially indicating an inefficient or malicious contract designed to waste user funds.

Verifying Multisig Transactions

The security of a multisig wallet relies on each signer independently verifying what they are signing. A compromised web interface could present a legitimate-looking transaction while tricking a hardware wallet into signing a malicious one.

The verification process is divided into two distinct phases: signing the off-chain message and executing the on-chain transaction.

Phase 1: Signing the Off-Chain Message

When you are the first signer or are adding your signature to a transaction that has not yet met its threshold, you are not sending an on-chain transaction. Instead, you are signing a structured, off-chain message that conforms to the EIP-712 standard.

Goal: To confirm that the cryptographic hash displayed on your hardware wallet exactly matches the hash of the transaction you intend to approve.

Process

1. Initiate Signing: Start the signing process in the multisig wallet's web interface.
2. Verify on Hardware Wallet: Your hardware wallet will display an EIP-712 hash for you to sign.
3. Independently Compute Hash: Use an independent, local tool like safe-hash to re-calculate the expected hash. The tool will ask for the transaction's parameters (nonce, to, value, data, etc.) to generate the hash locally on your machine.

   For less technical users, a web-based tool like Safe Utils can perform this calculation, but a local command-line tool offers superior security against browser-based attacks.

4. Compare Hashes: Compare the SafeTxHash generated by the local tool with the hash displayed on your hardware wallet's screen. They must match perfectly.
5. Sign: If the hashes match, you can confidently sign the message on your hardware wallet. This confirms you are approving the correct transaction, even if the web UI has been compromised.

Phase 2: Executing the On-Chain Transaction

Once a transaction has the required M-of-N signatures, it can be executed. This involves submitting a final on-chain transaction that calls the execTransaction function on the multisig contract, passing in all the previously signed data.

Goal: To confirm that the on-chain transaction being sent correctly encapsulates the multisig transaction you and other signers approved.

Process

1. Initiate Execution: In the multisig interface, start the execution of the fully signed transaction.
2. Verify Calldata: Your hardware wallet will prompt you to sign a new on-chain transaction. It will display the raw transaction data (calldata), which should show a call to the execTransaction function.
3. Decode and Compare: Use a calldata decoder (e.g.,calldata.swiss-knife.xyz) to parse the data shown on your hardware wallet.
4. Confirm Parameters: Carefully check the decoded parameters within the execTransaction call, especially the internal destination address (to), value, and data payload. Ensure they match the original, intended transaction.
5. Sign and Broadcast: If the calldata is correct, sign the transaction on your hardware wallet to broadcast it to the network.

Operational Best Practices

⚠️ Beware of DELEGATECALL: In a smart contract multisig transaction, an operation: 1 (DELEGATECALL) is dangerous if the target contract is not explicitly known and trusted. This opcode gives another contract full control over your wallet's context and storage.

• Transaction Simulation: Before signing, use a simulator like Tenderly or Alchemy 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.
• Alternative Frontends: To further reduce reliance on a single public UI, consider using an alternative or self-hosted multisig interface.

Using EIP-7702

The Pectra network upgrade introduces EIP-7702, which allows a standard Externally Owned Account (EOA) to temporarily function like a smart contract wallet. This is achieved via a new transaction type (0x04) that lets an EOA delegate its authority to a smart contract's code for the duration of a transaction or until it's changed.

Benefits of EIP-7702

This EIP unlocks several key user experience improvements:

• Transaction Batching: Users can combine multiple operations (e.g., an ERC-20 approve and a swap) into a single, atomic transaction, saving on gas fees and reducing confirmation fatigue.
• Gas Sponsorship: It enables third parties to pay for a user's transaction fees, which can simplify onboarding and abstract away gas management for the user.
• Privilege De-escalation: Users can delegate to contracts that enforce specific permissions, such as daily spending limits or interactions with only certain dApps.

Risks of EIP-7702

While powerful, this feature introduces a new attack vector. If an attacker tricks a user into signing a message that sets the wallet's code to a malicious contract, the attacker can gain full control and drain all assets.

• Phishing Attacks: The primary threat is phishing sites or scams that trick users into signing a SetCode delegation to a malicious contract under the guise of a wallet "upgrade."
• Multi-Chain Replay Attacks: A signature authorizing a delegation with chain ID 0 can be replayed on other EVM chains. An attacker could deploy a malicious contract at the same address on a different chain and use the replayed signature to take control there.

Guidance for Users

• Trust Your Wallet's Implementation: Major wallets mitigate phishing risks by hardcoding the only valid delegation contract. This prevents malicious websites from tricking you into delegating to an unsafe contract. Only approve delegations to contracts vetted and integrated by your wallet provider.
• Verify Delegation Targets: Only delegate your account to contracts that are well-known and audited.
• Understand Revocation: You can revoke a delegation and return your account to a standard EOA by authorizing a new transaction that sets the delegation address to the zero address (0x0000000000000000000000000000000000000000).
• Protect Your Private Key: Delegation does not eliminate the fundamental risk of a private key compromise. If your key is stolen, an attacker can still authorize delegations.
• Beware of Phishing: Be skeptical of any request to "upgrade" or "enable" smart account features, especially if it comes from an external link or pop-up.

⚠️ Wallets will only prompt you to switch to a smart account within the wallet's native. Any request to do so via email, a website, or a direct message is a phishing scam.

Private Key & Seed Phrase Management

The seed phrase (or mnemonic phrase) is the master key to a non-custodial wallet, granting complete control over all its derived private keys and assets. The management of this phrase is the single most important aspect of self-custody security.

⚠️ If you suspect for even a moment that your private key or seed phrase has been lost, viewed by another person, or exposed digitally (e.g., shown on-screen, copied to a clipboard on a connected device), you must consider it compromised. Immediately create a new, secure wallet and transfer all assets to it.

Secure Storage Practices

The goal is to protect the seed phrase from both physical threats (theft, fire, water damage) and digital threats (hacking, malware). The foundational principle is to keep your seed phrase offline at all times.

As soon as a new wallet is created, back it up using one of the following offline methods. Wallet providers do not have access to your seed phrase and cannot help you recover it.

• Physical Written Copies: Writing the phrase on paper or a notebook is a common starting point. To mitigate risks of loss or damage from fire or water, store multiple copies in secure, geographically separate locations (e.g., a personal safe, a trusted family member's home, a bank deposit box).

• Durable Metal Storage: For superior protection against physical damage, etch or stamp your seed phrase onto a metal plate (e.g., steel, titanium). Commercial products are available for this purpose. These should also be stored in secure, separate locations.

Prohibited Practices

Under no circumstances should you ever store your seed phrase in any of the following ways:

• Taking a digital photograph of it.
• Uploading it to cloud storage (iCloud, Google Drive, Dropbox).
• Sending it via text message or any messaging app.
• Sending it in an email, even to yourself.
• Storing it in a plain text file on a computer or phone.
• Sharing it with anyone. Wallet providers will never ask for your seed phrase.
• Never use a device obtained from an untrusted source, such as a conference, hackathon, or third-party online marketplace, as it may be tampered with.

Ongoing Security Hygiene

1. Periodic Security Audits

On a recurring basis (e.g., every 6 months), conduct a security review by asking:

• Do I know the physical location of all my seed phrase backups?
• Are my storage methods still secure and uncompromised?
• If my primary device were destroyed, do I have a clear plan to recover my assets?

2. Key Rotation

While you can use the same keys for years, it is a best practice to periodically rotate them by moving assets to new wallets.

3. Succession Planning

Establish a clear, secure protocol for a trusted next-of-kin to access your assets in case of incapacitation or death. This may involve sealed instructions stored with a lawyer or in a safe deposit box.

Tools & Resources

This section provides a curated list of tools and resources to help users select wallets, practice safe signing habits, and verify transactions. Using these tools is a critical part of a robust security strategy.

Wallet Selection

Before choosing a wallet, it is essential to consult independent, community-trusted resources.

• ethereum.org/wallets: The official, community-maintained list of wallets, filterable by features. A reliable starting point for discovering wallets.
• Wallet Scrutiny: An in-depth review site that focuses on transparency, verifiability, and reproducibility. It flags wallets that are closed-source or have other potential security concerns.
• Wallet Security Ranking: Evaluates wallets by permissions, intent clarity, device security, and threat prevention to help users choose safer, more trustworthy options.
• Wallet Beat: Aims to provide a comprehensive list of wallets, their functionality, practices, and support for certain standards.

Transaction Simulation

Transaction simulators allow you to preview the exact outcome of a transaction before signing it, preventing errors and security risks.

• Tenderly: A platform that allows you to simulate transactions and preview, helping to prevent transaction failures, security risks, and unnecessary gas costs.
• Alchemy Simulation APIs: An API suite that predicts the precise impact of a transaction before it reaches the blockchain.

Transaction Verification

These tools are designed to help you independently verify the integrity of transaction data, especially for multisig operations.

• safe-hash: A command-line tool for locally verifying Safe transaction data and EIP-712 messages before signing. It is designed to protect against phishing by allowing you to independently generate the hash your wallet will ask you to sign.
• Safe Utils: A user-friendly web interface for calculating and verifying Safe transaction hashes. While convenient, remember the security advantages of using a local, offline tool like safe-hash for high-value transactions.
• calldata.swiss-knife.xyz: Web-based tool for quick decoding of transaction data.
• Foundry cast: A powerful command-line tool for local, offline decoding.

Security Training

These tools allow you to practice identifying threats in a safe, simulated environment.

• Wise Signer: An interactive platform that challenges users to identify safe and dangerous transactions before signing them. It is an excellent tool for learning to recognize common phishing attacks and deceptive transaction patterns without risking real assets.
• Web3 Wallet Security Courses: Offers a structured curriculum for hands-on security training, guiding users from foundational concepts in "Web3 Wallet Security Basics" to advanced techniques. The advanced course covers critical topics like Safe multisig configuration, EIP-712 signature verification, and real-world hack analysis.
• How to Multisig: A dedicated resource with best practices on how to implement secure standard operating procedures for multisig wallets.

External Security Reviews

An external security review is a time-boxed, security-based assessment of software systems, applications, and infrastructure to enhance security and identify vulnerabilities. External security reviews are essential for organizations to protect against threats and build trust with users and stakeholders.

Why Are External Security Reviews Important?

According to research, significant value and data have been compromised due to security vulnerabilities in software systems. Modern applications face complex threats from malicious actors, and security issues can lead to data breaches, financial losses, and reputation damage.

Beyond preventing security incidents, external security reviews provide several key benefits:

• Enhanced Security: Find and fix vulnerabilities before they can be exploited
• Team Education: Level up your engineering team's knowledge through security best practices
• Trust Building: Demonstrate maturity and safety to users and stakeholders
• Risk Mitigation: Identify business logic issues and implementation flaws
• Compliance: Meet regulatory and industry security requirements

Scope of External Security Reviews

Security reviews can encompass multiple layers of an organization's technology stack:

• Applications: Web applications, mobile apps, APIs, and microservices
• Infrastructure: Cloud configurations, network security, access controls, and deployment pipelines
• Data Systems: Databases, data processing pipelines, and storage security
• Third-party Integrations: External APIs, libraries, and vendor services
• Documentation: Technical specifications, security policies, and incident response procedures

External security reviews are not foolproof and cannot guarantee absolute security. They represent an ongoing commitment to safety rather than a one-time event.

Contents

There are many different kinds of external security reviews, and we have some context on many of them here.

1. Smart Contract Audits
2. Security Policies and Procedures

Smart Contract Security Reviews

Smart contract security reviews are specialized assessments focused on identifying vulnerabilities in blockchain-based smart contracts and protocols. These reviews are critical for web3 projects due to the immutable nature of blockchain deployments and the high-value targets that smart contracts often represent.

Why Smart Contract Security Reviews Are Critical

Smart contracts operate in a unique environment that makes security paramount:

• Immutability: Once deployed, smart contracts cannot be easily changed
• Financial Risk: Smart contracts often handle significant value in cryptocurrencies
• Public Accessibility: All code and transactions are visible on the blockchain
• Adversarial Environment: Attackers are incentivized by potential financial gains
• Complex Interactions: DeFi protocols involve intricate interactions between multiple contracts

According to industry data, billions of dollars have been lost due to smart contract vulnerabilities, making security reviews essential for protecting user funds and maintaining protocol integrity.

Smart Contract Security Review Process

A security review engagement is typically divided into four phases:

• Scoping Phase: The project team prepares the codebase and defines specific scope for security researchers
• Initial Assessment Phase: Researchers conduct preliminary analysis to identify potential security issues
• Mitigation Phase: The team works on fixing identified issues with ongoing auditor support
• Final Report Phase: Auditors review implemented fixes and provide a comprehensive final report

Audit Methodologies

• Static Analysis: Automated code scanning for known vulnerability patterns
• Dynamic Analysis: Runtime testing and fuzzing
• Manual Review: Expert analysis of business logic and complex vulnerabilities
• Formal Verification: Mathematical proofs of contract correctness (where applicable)

Types of Smart Contract Audits

Private Audits

• Dedicated security researchers assigned to your project
• Confidential and personalized attention
• Higher cost but comprehensive coverage
• Direct communication with audit team

Public/Competitive Audits

• Multiple researchers competing for prizes
• Diverse perspectives and approaches
• More cost-effective option
• Broader coverage through competition

Contents

This section contains detailed guidance on different aspects of smart contract security reviews:

1. Audit Expectations - What to expect during the audit process
2. Preparation Guide - How to prepare for a successful audit
3. Vendor Selection - Choosing the right security auditor

Expectations

Scoping Phase

The team looking for a security review will agree with the auditors/security researchers the exact parameters of the review. What exact contracts should they review? What should they not review? This is incredibly important so the can clearly estimate timelines on how long a review may take. This is also where compensation is discussed, usually the more aspects a team wants to review, the more expensive the audit will be.

Initial Assessment Phase

• Automated Testing: Auditors will run various automated security tools including static analysis, fuzz testing, formal verification, and unit testing to identify basic vulnerabilities
• Manual Code Review: Security researchers will manually analyze the code to understand context, complexity, and identify deeper vulnerabilities that automated tools might miss
• Documentation Review: Auditors will review project specifications and documentation to understand intended functionality

Deliverables

A comprehensive security review will generate the following:

Initial Report

• Vulnerability Identification: Security vulnerabilities classified by severity (High, Medium, Low)
• Proof of Concept: Demonstration of potential exploit scenarios where applicable
• Gas Optimizations: Recommendations for improving contract efficiency
• Informational Findings: Code quality improvements and best practice recommendations
• Mitigation Strategies: Specific recommendations for addressing each identified issue

Mitigation Phase

• Fix Review Period: Time allocated for your team to address identified vulnerabilities
• Collaborative Support: Ongoing communication with auditors during the fix implementation
• Code Re-review: Assessment of implemented fixes to ensure issues are properly resolved

Final Report

• Updated Assessment: Review of all implemented fixes and their effectiveness
• Residual Risk Analysis: Documentation of any remaining risks or limitations
• Public Publication: In web3, audit reports are commonly published publicly to build community trust

Timeline and Cost Expectations

The following are incredibly rough estimates for timelines/costs based on Solidity smart contract audits from around the industry. Actual timelines and costs will vary significantly based on the complexity of the codebase, the number of contracts, and the specific requirements of the project.

Duration

• Small Projects (< 1000 lines): 1-2 weeks
• Medium Projects (1000-4000 lines): 2-5 weeks
• Large Projects (> 4000 lines): 5+ weeks

Cost Range

• Per Week: $1,000 - $60,000 depending on complexity and auditor expertise
• Factors Affecting Cost: Codebase size, complexity, timeline requirements, auditor reputation

Important Limitations

• No Guarantee: Audits do not guarantee bug-free code or complete security. However, the engagement with the team should still provide value (teaching better security practices, improving code quality, etc.)
• Snapshot in Time: Audits assess code at a specific commit hash - any changes create unaudited code
• Ongoing Process: Security should be viewed as a continuous journey, not a one-time event
• Emergency Preparedness: Even audited protocols should have incident response plans and emergency communication channels

Preparation

A common misconception is that when doing a security review, you can just hand off the written code and let reviewers do their work. This approach is inefficient and costly, as auditors will spend time on issues you could have resolved beforehand. Proper preparation maximizes the value of your security review investment and helps auditors focus on complex vulnerabilities rather than basic issues.

How to Get the Most Out of Your Security Review

Set a Goal for the Review

This is the most important step of a security review and often the most overlooked. By setting a scope that is not too large or undefined, you are more likely to have a successful audit. If the project is very large, you may want to focus on the most critical aspects of the project.

Internal Due Diligence

Conduct internal testing before engaging an external security provider. You can do this by creating and running test vectors for your code, and leverage automated tools to identify low-hanging fruit. Here’s a list of free/open-source tools your project could use:

• Solidity: slither, mythril, semgrep-smart-contracts
• Golang: golangci-lint, go-critic, gosec
• Rust: cargo audit, cargo outdated, clippy, cargo geiger, cargo tarpaulin

Write Clear Documentation

Providing comprehensive documentation is essential for auditors to understand your protocol's intended functionality. Since 80% of all bugs are due to business logic issues, auditors need to understand what your protocol should do, not just what the code does.

Documentation should include:

• Project Overview: Describe your protocol in plain English—what it does and its components.
• Flow Diagrams: Outline all possible interaction paths within your system.
• Design Choices: Document design decisions and any known potential issues.
• Known Restrictions / Limitations: Document centralization risks and known limitations (e.g., limited TVL, token support).
• Dependencies: List all external dependencies.
• Access Control / Privileged Roles: Record all roles and their privileges.

Provide a Robust Test Suite

Maintaining a comprehensive test suite that covers significant portions of your codebase allows auditors to focus on finding vulnerabilities rather than understanding basic functionality. Before an audit, ensure you have:

• Unit Tests: Test individual functions and components
• Integration Tests: Test interactions between different parts of your system
• Fuzz Testing: Automated testing with random inputs to find edge cases
• High Code Coverage: Aim for substantial coverage of your critical code paths
• Formal Verification: If applicable, use formal methods to prove correctness of critical components

Conduct an Initial Code Walkthrough

The first step in a security audit should be a high-level video walkthrough where you:

• Explain your codebase architecture and key components
• Describe how the code is intended to function
• Highlight critical areas that need special attention
• Provide context for design decisions and trade-offs
• Guide auditors on where to find answers to common questions

This walkthrough helps auditors understand your system quickly and focus their time on security analysis rather than code comprehension.

Vendor Selection

Choosing the right security vendor is crucial for getting maximum value from your security review. There are numerous security vendors in both the web3 and web2 ecosystems, each with different specializations and approaches.

Types of Security Audits

Understanding the different types of security audits available helps you choose the right approach for your project:

Private Security Audits

Private smart contract security audits are performed by security companies or solo auditors, typically involving one or multiple security researchers specifically chosen by your team or assigned by the security firm.

Characteristics:

• Confidential engagement with limited access to code
• Dedicated focus from chosen security researchers
• Personalized attention and direct communication
• Typically higher cost but more thorough coverage

Public/Competitive Security Audits

Public or competitive audits involve tens or hundreds of security researchers competing to find the highest number of issues to win a share of a prize pool.

Characteristics:

• Open participation from multiple researchers
• Competitive environment drives thorough analysis
• Often more cost-effective than private audits, but less personalized
• Can identify a broader range of issues through diverse perspectives

Vendor Selection Criteria

1. Track Record and Reputation

• Evaluate potential vendors based on their track record, reputation, and experience in your specific technology stack
• Look for vendors with a proven history of addressing security challenges similar to your project's needs
• Check for published audit reports and client testimonials

2. Domain Expertise

• Web3 Focus: For smart contracts, DeFi protocols, or blockchain infrastructure, choose vendors with deep web3 security expertise
• Web2 Focus: For traditional infrastructure, APIs, or backend systems, consider vendors with strong web2 security backgrounds
• Specialized Knowledge: If building an L2, DEX, or other specialized system, prioritize vendors with relevant experience

3. Technical Capabilities

• Ensure the vendor has experience with your specific:
  • Programming languages (Solidity, Rust, Go, etc.)
  • Blockchain platforms (Ethereum, Polygon, Arbitrum, etc.)
  • Protocol types (DeFi, NFTs, DAOs, etc.)
  • Architecture patterns (proxy contracts, multisig, etc.)

4. Security Methodology

• Tool Usage: Verify they use appropriate automated security tools
• Manual Review: Ensure they conduct thorough manual code reviews
• Testing Approach: If applicable, look for comprehensive testing methodologies including fuzz testing or formal verification

Due Diligence Process

1. Request References: Ask for previous client references and audit examples
2. Evaluate Methodology: Understand their specific audit process and deliverables
3. Assess Communication: Ensure clear communication channels and responsive support
4. Review Pricing: Compare costs against scope and expected value
5. Timeline Alignment: Confirm availability matches your project timeline

Red Flags to Avoid

• Vendors who guarantee finding all vulnerabilities
• Extremely low pricing without clear scope limitations
• Lack of relevant experience in your technology stack
• Poor communication or unresponsive during initial discussions
• No clear methodology or standardized reporting process

Audit the Auditors

As of today, the best review of the security reviewers that we have is the historical performance of security reviewers. One of the best ways to evaluate this is to review the historical performance of the security team.

If you see codebases that they reviewed were hacked, this doesn't mean that the team is bad. There are two types of security teams out there:

• Those who have had codebases they have reviewed hacked
• Those who have not reviewed enough codebases

Additionally, comparing sequential audits of the same codebase can be misleading. If auditor A reviews codebase X, and then auditor B reviews the same codebase and finds more bugs, some insight from auditor A could have been used to find those extra bugs. However, if two auditors review the same codebase at the same time, this can be a much better comparison of the two auditors.

Security Policies and Procedures

As part of the external security review, it could be beneficial to also review the internal security policies and procedures as well. Some of the things that could be relevant to review are:

1. Ensure there is a developed and maintained plan for responding to security incidents.
2. Ensure there are defined roles and responsibilities, and enforce the principle of least privilege.
3. Ensure there are processes implemented for managing changes to the codebase and infrastructure.
4. Ensure there are regular training sessions conducted for all team members on security best practices.
5. Ensure adherence to any potentially relevant regulatory and industry standards for your project.

Security Testing

The objective of Security testing, while most likely impossible, is to ensure that applications and systems are resilient to attacks and free from vulnerabilities. This section covers various security testing methodologies, including dynamic and static application security testing, fuzz testing, and security regression testing.

There are several types of testing:

• Unit Testing: Tests individual components or functions of the codebase.
• Integration Testing: Tests the interaction between different components or systems.
• Fuzz Testing: Tests the application by providing random or unexpected inputs to identify vulnerabilities.
• Static Analysis: Analyzes the code without executing it to find potential vulnerabilities.
• Formal Verification: Uses mathematical methods to prove the correctness of algorithms and protocols.

Some types of testing overlap, for example, a unit test could also be a fuzz test. We will focus on testing and how it applies to smart contracts, and use solidity as an example.

Goal

The goal of security testing is to identify vulnerabilities and weaknesses in the codebase, while also making sure that the code behaves the same way even after changes. Different types of testing can help achieve this goal in different ways. There is no "one size fits all" solution, and the choice of testing methodology depends on the specific requirements and constraints of the project.

Smart Contracts

For smart contracts in particular, here is when to use each type of testing:

• Unit Testing: Always. And aim for high "code coverage" (i.e. unit test as many paths as possible)
• Integration Testing: Always. This can also be combined with fork testing.
• Fuzz Testing: Always. Most unit tests can be fuzz tests.
• Static Analysis: Always. Use tools like Slither and Aderyn to analyze the code for vulnerabilities.
• Formal Verification: Dependent. Anywhere functions are math heavy, stateless, or functionality matches another system, this should be used.

Dynamic Application Security Testing

Fuzz Testing

Fuzz testing (or fuzzing) is when you supply random data to your system in an attempt to break it. Most of the time, hacks come from scenarios you didn't think about and write a test for. What if I told you that you could write one test that would check for almost every possible scenario?

What is Fuzz Testing?

For example, if a balloon was our system/code, it would involve doing random stuff to the balloon to break it.

• Punch it
• Squeeze it
• Throw it
• etc

Why would we want to do all that? Let's look at an example.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract MyContract {
    uint256 public shouldAlwaysBeZero = 0;
    uint256 private hiddenValue = 0;

    function doStuff(uint256 data) public {
        if (data == 2) {
            shouldAlwaysBeZero = 1;
        }
        if (hiddenValue == 7) {
            shouldAlwaysBeZero = 1;
        }
        hiddenValue = data;
    }
}

Let's say we have this function named doStuff, which takes an integer as input. We additionally have a variable named shouldAlwaysBeZero that we want always to be zero.

The fact that this variable should always be zero is known as our invariant, or "property of the system that should always hold."

Invariant: The property of the system that should always hold.

Our invariant in this contract is that: Invariant: shouldAlwaysBeZero MUST always be 0

Why Normal Unit Tests Aren't Enough

Let's look at a normal unit test:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import {MyContract} from "../src/MyContract.sol";
import {Test} from "forge-std/Test.sol";

contract MyContractTest is Test {
    MyContract exampleContract;

    function setUp() public {
        exampleContract = new MyContract();
    }

    function testIsAlwaysZeroUnit() public {
        uint256 data = 0;
        exampleContract.doStuff(data);
        assert(exampleContract.shouldAlwaysBeZero() == 0);
    }
}

With this single unit test testIsAlwaysZeroUnit, we might think our code has enough coverage, but if we look at the doStuff function again, we can see that if our input is 2, our variable will not be zero.

function doStuff(uint256 data) public {
    // WHAT IS THIS IF STATEMENT???
    // 👇👇👇👇👇👇
    if (data == 2) {
        shouldAlwaysBeZero = 1;
    }
    // 👆👆👆👆👆👆

    // Ignore this one for now
    if (hiddenValue == 7) {
        shouldAlwaysBeZero = 1;
    }
    hiddenValue = data;
}

This seems obvious with our example function, but more often than not, you'll have a function that's much more complex with numerous edge cases that are impossible to manually test.

Stateless Fuzz Tests

In Foundry, you'd write a fuzz test like so:

function testIsAlwaysZeroFuzz(uint256 randomData) public {
    exampleContract.doStuff(randomData);
    assert(exampleContract.shouldAlwaysBeZero() == 0);
}

Foundry will automatically input semi-random values to randomData and over many runs, input them to the doStuff function and check that the assertion holds.

This would be equivalent to writing many tests where randomData had different values, all in one test!

Now I say "semi-random" because the way your fuzzer (in our case, Foundry) picks the random data isn't truly random, and should be somewhat intelligent with the random numbers it picks. Foundry is smart enough to see the if data == 2 conditional, and pick 2 as an input.

If we run our fuzz test, it tells us exactly what input fails our test:

$ forge test -m testIsAlwaysZeroFuzz

Failing tests:
Encountered 1 failing test in test/MyContractTest.t.sol:MyContractTest
[FAIL. Reason: Assertion violated Counterexample: calldata=0x47fb53d00000000000000000000000000000000000000000000000000000000000000002, args=[2]] testIsAlwaysZeroFuzz(uint256) (runs: 6, μ: 27070, ~: 30387)

We can see that it found out if it passed args=[2] to the test, it was able to break our assert(exampleContract.shouldAlwaysBeZero() == 0). So now, we can go back into our code, and realize we need to fix the edge case where data == 2, and now we are safe from the exploit!

Stateful vs Stateless Fuzzing

The Hidden Bug

Now you may notice that there is another scenario where our code could have an issue, and that's when hiddenValue == 7. In order for this revert to happen, you have to:

1. First call doStuff with the value 7 (which sets hiddenValue to 7)
2. Then call this function again with any other number

It takes 2 calls for our invariant to be broken:

1. Call doStuff with 7
2. Call doStuff with any other number

Our fuzz test written above will never be able to find this example because as it's currently written, our test is what's known as a "stateless fuzz test."

Stateless Fuzzing: Fuzzing where the state of a previous run is discarded for the next run.

Stateful Fuzz Tests (Invariant Tests)

So, in smart contract testing, we can do "stateful fuzzing" instead.

Stateful Fuzzing: The state of our previous fuzz run is the starting state of our next fuzz run.

To write a stateful fuzz test in Foundry, you'd use the invariant keyword, and it requires a little more setup:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import {MyContract} from "../src/MyContract.sol";
import {Test} from "forge-std/Test.sol";
import {StdInvariant} from "forge-std/StdInvariant.sol";

contract MyContractTest is StdInvariant, Test {
    MyContract exampleContract;

    function setUp() public {
        exampleContract = new MyContract();
        targetContract(address(exampleContract));
    }

    function invariant_testAlwaysReturnsZero() public {
        assert(exampleContract.shouldAlwaysBeZero() == 0);
    }
}

Instead of just passing random data to function calls, a stateful fuzz test (invariant test) will automatically call random functions with random data.

We use the targetContract function to tell Foundry that it can use any of the functions in exampleContract. There is just one function for this example, so it will just call doStuff with different values across multiple calls.

If we run this test, we can see it finds out that if you call doStuff twice (once with the value 7), it will break our invariant!

$ forge test -m invariant_testAlwaysReturnsZero

Failing tests:
Encountered 1 failing test in test/MyContractTest.t.sol:MyContractTest
[FAIL. Reason: Assertion violated]
        [Sequence]
                sender=0x000000000000000000000000000000000000018f addr=[src/MyContract.sol:MyContract]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=doStuff(uint256), args=[7]
                sender=0x0000000008ba49893f3f5ba10c99ef3a4209b646 addr=[src/MyContract.sol:MyContract]0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f calldata=doStuff(uint256), args=[2390]

Perfect! It shows us the exact sequence of calls that broke our invariant.

Real-World Smart Contract Invariants

In an actual smart contract, your invariants won't be that a balloon shouldn't pop or some function should always be zero; they'll be something like:

• New tokens minted < inflation rate
• There should only be 1 winner of a random lottery
• Someone shouldn't be able to take more money out of the protocol than they put in
• The protocol must always be over-collateralized
• Total supply should equal sum of all balances

Fuzz Testing Tools

• Foundry
• Echidna
• Medusa

Best Practices

1. Start with Unit Tests: Build your foundation with comprehensive unit tests first
2. Identify Invariants: Clearly define what properties must always hold
3. Use Stateful Fuzzing: Most real bugs require multiple function calls to trigger
4. Bound Your Inputs: Use realistic parameter ranges in handlers
5. Document Invariants: Make your invariants clear in comments and documentation

References

Much of this document was inspired by the Cyfrin Updraft fuzzing curriculum.

Security Regression Testing

Static Application Security Testing

ENS Best Practices

🔑 Key Takeaway: To securely implement ENS in your applications, prioritize direct L1 data verification, enforce proper name normalization, and validate bidirectional resolution. Always verify interface support before interaction, respect chain-specific cointype parameters, and implement CCIP-Read functionality correctly. These practices prevent address spoofing, ensure cross-chain compatibility, and maintain data integrity throughout the ENS ecosystem.

The Ethereum Name Service (ENS) is a distributed, open, and extensible naming system based on the Ethereum blockchain.

ENS maps human-readable names like 'alice.eth' to machine-readable identifiers such as Ethereum addresses, other cryptocurrency addresses, content hashes, metadata, and more. ENS also supports 'reverse resolution', making it possible to associate metadata such as primary names or interface descriptions with Ethereum addresses.

What This Framework Covers

This best practices framework includes guidance on:

• Data Integrity & Verification - Ensuring reliable and secure name resolution
• Cross-Chain Compatibility - Supporting ENS across multiple blockchain networks
• Smart Contract Integration - Leveraging ENS in smart contract systems
• Interface Compliance - Correctly implementing and verifying ENS interfaces
• Name Handling & Normalization - Properly processing and displaying ENS names

These recommendations are designed for developers integrating ENS into applications, wallets, smart contracts, or other blockchain systems. Following these practices will help create more secure, reliable, and user-friendly ENS implementations.

Data Integrity & Verification

Use On-chain Resolution for Financial Transactions

• Always resolve fresh data directly from Ethereum mainnet whenever conducting financial transactions
• Do not rely on indexer or API data when moving or managing funds
• Preferably run an Ethereum node for high-value transactions, or if not feasible, use reputable L1 RPC providers while still verifying the integrity and audit status of all software involved in the resolution process

Rationale: Indexers and third-party APIs may have delayed updates or inconsistencies that could lead to payments being sent to outdated or incorrect addresses. By querying L1 directly, applications work with the most current and authoritative ENS data, dramatically reducing the risk of misdirected funds. This is particularly crucial for high-value transactions where the consequences of using stale data could be severe.

Verify Forward Resolution on Reverse Records

• Always perform forward resolution on reverse records to verify address matches
• Check that name → address → name completes a valid loop
• Clearly indicate to users when there's a mismatch

Rationale: ENS supports both forward resolution (name → address) and reverse resolution (address → name). However, reverse records can be set independently, creating the possibility for spoofing or impersonation if not properly verified. By performing forward resolution on the result of a reverse lookup and comparing it to the original address, applications can ensure the bidirectional integrity of the ENS data, preventing potential phishing or impersonation attacks.

Cross-Chain Compatibility

Respect Cointype for Chain-Specific Resolution

• Always use the correct cointype parameter when resolving addresses on specific chains
• For EVM-compatible chains, derive cointypes from chain IDs according to ENSIP-11

Rationale: An ENS name can resolve to a different address for each different blockchain network, which ENS supports through the cointype field in address records (following SLIP-44 standards). With the rise of smart contract wallets and account abstraction, users may have different addresses across different chains. Failing to respect the cointype when resolving addresses can lead to funds being sent to addresses that don't exist on the target chain or that belong to different entities altogether.

Implement CCIP-Read Support

• Properly support and handle CCIP-Read functionality EIP-3668
• Set reasonable timeouts and fallbacks for CCIP-Read operations

Rationale: CCIP-Read (EIP-3668) enables off-chain data retrieval for ENS resolution, allowing for more complex resolution patterns and greater flexibility for name owners. This protocol allows resolvers to redirect resolution requests to off-chain services that can implement custom logic beyond what's practical on-chain. Applications that ignore CCIP-Read requests limit the functionality available to ENS users and may provide incorrect resolution results. Supporting this standard ensures compatibility with advanced ENS use cases.

Test Multi-Chain Implementations

• Test ENS resolution across all chains your application supports
• Implement proper error handling for unsupported chains
• Document which chains are supported by your implementation

Rationale: As blockchain ecosystems expand, users expect applications to work across multiple networks. Testing ENS resolution across different chains ensures consistent behavior regardless of which network a user is connected to. Clear documentation about chain support also helps users understand the limitations of your application.

Handle Reverse Records Per Chain

• Query reverse records on the chain where the address exists, not just mainnet
• Consider user context when displaying names, prioritize the reverse record from the chain the user is currently interacting with
• Validate reverse record ownership by checking if the returned name actually resolves back to the queried address on that chain

Rationale: With ENSIP-19, reverse records (address-to-name lookups) can now be set and queried on any chain, not just Ethereum mainnet. This allows users to set different reverse records for the same address across different networks, enabling more contextual and chain-specific identity resolution. Applications that only check mainnet reverse records will miss valid reverse resolutions on other chains where users are actually active, leading to incomplete or incorrect identity displays.

Smart Contract Integration

Name Your Smart Contracts

• Register ENS names for core contracts in your project's ecosystem
• Set appropriate reverse records for your contracts
• Document contract ENS names in project documentation
• Consider naming contracts at deployment time to ensure immediate resolvability
• Use a standard pattern for contract naming to improve discoverability

Rationale: Smart contracts typically have complex hexadecimal addresses that are error-prone when shared or referenced. By assigning ENS names to smart contracts, developers can significantly improve user experience, make documentation more approachable, and reduce the risk of address errors. This practice is especially important for contracts that interact directly with users or serve as key infrastructure components. Human-readable names also aid in contract verification, as users can more easily confirm they're interacting with official protocol contracts rather than potential phishing imitations.

Leverage ENS as an Infrastructure Component

• Use ENS for service discovery between contract components
• Build upgradeability mechanisms that leverage ENS for implementation pointers
• Consider ENS as a registry for official protocol extensions and integrations
• Use ENS records to store protocol metadata in a human-readable format

Rationale: ENS can serve as more than just a human-readable address layer, it can function as critical infrastructure for contract systems. Using ENS for implementation pointers enables flexible and upgradeable architectures, as contract dependencies can be redirected without requiring contract redeployment. This pattern supports robust governance models while maintaining a consistent user interface. Additionally, using ENS to register official extensions creates a trust layer that helps users identify legitimate protocol integrations, while storing protocol metadata in ENS records improves discoverability and system documentation.

Interface Compliance

Verify Resolver Interface Support

• Always check if a resolver supports your target interface using EIP-165
• Call supportsInterface() before attempting to use specific resolver methods
• Implement graceful fallbacks when interfaces aren't supported
• Cache interface support results to minimize redundant on-chain calls

Rationale: ENS resolvers can implement various interfaces, each providing different functionality (addresses, text records, content hashes, etc.). Not all resolvers implement all interfaces, so checking interface support before calling specific methods prevents failed transactions and improves reliability. This verification step is especially important as the ENS ecosystem evolves and new resolver interfaces are introduced. Without proper interface verification, applications may fail when encountering resolvers with limited functionality or custom implementations.

Signal Supported Interfaces in Custom Resolvers

• When writing custom resolvers, properly implement EIP-165
• Signal all supported interfaces via supportsInterface()
• Document which interfaces your resolver supports
• Consider incremental implementation of interfaces based on user needs

Rationale: Implementing EIP-165 interface detection allows other contracts and applications to programmatically discover what functionality your resolver supports. This promotes interoperability and ensures your custom resolver can seamlessly integrate with the broader ENS ecosystem. Proper interface signaling is not just a technical requirement but a key element of good blockchain protocol citizenship. Without it, other contracts and applications can't reliably determine the capabilities your resolver offers, leading to poor user experiences and potential security risks.

Stay Updated with ENS Improvement Proposals (ENSIPs)

• Regularly monitor the ENS GitHub repository for new ENSIPs
• Participate in ENSIP discussions to provide implementer feedback
• Implement support for new ENSIPs after they reach "Final" status
• Plan for deprecation of older interfaces as specified by ENSIPs
• Test implementations against the reference implementations provided in ENSIPs

Rationale: The ENS protocol evolves through the ENSIP process, which introduces new interfaces, standards, and recommended practices. Staying current with these proposals ensures your implementation remains compatible with the broader ecosystem and can leverage new functionality as it becomes available. ENSIPs often address security vulnerabilities, improve user experience, or add valuable new features that users will come to expect. Implementers who track and promptly adopt new ENSIPs gain competitive advantages while contributing to the overall health and advancement of the ENS ecosystem.

Name Handling & Normalization

Normalize Names per ENSIP-15

• Always normalize ENS names before creating namehash, labelhash, or DNS-encoding
• Use established libraries that correctly implement ENSIP-15 normalization (like @adraffy/ens-normalize)
• Apply normalization at the earliest possible point in your ENS handling logic
• Include normalization checks in validation procedures for user-entered names

Rationale: ENS uses a specific normalization algorithm defined in ENSIP-15 to ensure consistent handling of Unicode characters and emoji sequences. Failing to normalize names correctly can result in different hash values for what users perceive as the same name, leading to resolution failures, security vulnerabilities, and poor user experience. Proper normalization is fundamental to the correct operation of any ENS integration and must be performed before any cryptographic operations (namehash, labelhash) or encoding. Using established libraries ensures compliance with the complex requirements of ENSIP-15.

Implement Security Measures for Homograph Attacks

• Detect and warn users about visually confusable characters in ENS names
• Display names using fonts that clearly differentiate similar-looking characters
• Consider displaying the script/language of characters in multi-script names
• Implement visual indicators for mixed-script names or potentially deceptive names
• When displaying ENS names, highlight or annotate unexpected character sets

Rationale: Homograph attacks use visually similar characters from different Unicode scripts to create deceptive names (e.g., using Cyrillic 'о' instead of Latin 'o'). While ENSIP-15 addresses some confusables, it cannot eliminate all visual ambiguities. Implementing additional security measures helps users identify potentially deceptive names before interacting with them. These protections are particularly important in financial applications or any context where users might send assets to an ENS name, as homograph attacks can lead to irreversible asset loss.

Properly Handle Emoji in ENS Names

• Ensure your UI correctly displays emoji in ENS names at appropriate sizes
• Be aware that emoji rendering varies across platforms and fonts
• Handle emoji sequences correctly, including skin tone modifiers and ZWJ sequences
• Test thoroughly with emoji-containing names on multiple platforms and browsers
• Use libraries that correctly implement UTS-51 (Unicode Emoji) for handling emoji

Rationale: Emoji are increasingly common in ENS names but introduce technical challenges. Emoji can be composed of multiple code points, including zero-width joiners (ZWJ) and variation selectors, making proper handling critical. Incorrect emoji implementation can cause names to appear differently across platforms or fail to resolve correctly. Emoji rendering also varies significantly between operating systems and browsers, requiring thorough cross-platform testing to ensure consistent user experience.

SEAL Whitehat Safe Harbor

💡 An industry-standard framework, letting your protocol pre-authorize whitehats to rescue funds during active exploits

What is Safe Harbor?

When your protocol is under attack, every second counts. Safe Harbor gives you a way to fight back.

Safe Harbor is a legal and technical framework that lets your protocol pre-authorize whitehats to step in during active exploits, rescue funds, and return them - fast, safely, and with clear legal protection for everyone involved.

By adopting Safe Harbor, protocols allow:

• Empower whitehats to act immediately during an exploit
• Remove legal ambiguity and delays
• Boost the odds of recovering user funds

Why we started Safe Harbor

💡 We started Safe Harbor after the Nomad hack, where over $190M was drained over the course of hours while whitehats stood by, willing to help, but unable to act without legal protection. With Safe Harbor, our goal is to make sure that never happens again and to empower whitehats to rescue funds.

Vetted by industry leaders and top Web3 lawyers

Safe Harbor was developed over two years with direct input and rigorous legal review from experts at a16z Crypto, Cooley, Debevoise & Plimpton, Filecoin Foundation, MetaLeX, Paradigm, Piper Alderman, Powerhouse, and more.

Who's Adopted Safe Harbor

Safe Harbor is already protecting $16B+ in assets across leading DeFi protocols. Current adopters include Uniswap, Pendle, PancakeSwap, Balancer, Silo Finance, Zksync, and more. See the full up-to-date list.

How Does Safe Harbor Work?

• Protocols pre-authorize rescues: You clearly define when and how whitehats are allowed to step in - covering what assets are protected, where to return funds, and what bounty terms apply, etc
• Whitehats act only during active exploits: Safe Harbor only applies when an exploit is already in progress or imminent - e.g., in the mempool, or after initial funds have been drained. It's not for bug bounty reports, and it does not protect blackhats. Only whitehats who rescue funds without initiating the exploit are covered.
• Funds are returned, bounty is automatic: Whitehats must send rescued funds to your official recovery addresses within 72 hours. Bounties are enforceable and pre-defined - no negotiation, no chaos.

Other key protections:

• You can choose to allow anonymous whitehats or require KYC.
• Whitehats must follow established guidelines for responsible intervention
• You define exactly which contracts, and chains are protected.
• The agreement is only valid if funds are returned and the protocol's rules are followed

How to adopt?

Adopting Safe Harbor is fast, simple, and works whether you're a DAO or a centralized team. You can complete the whole process in under an hour.

Here are a few options:

1. Get Help from SEAL

For protocols that want white-glove support, SEAL offers guided onboarding at no cost. We'll walk you through scoping, governance language, on-chain registration, etc.

→ Apply for the SEAL Onboarding Waitlist

Space is limited - we prioritize high-impact protocols and critical infrastructure

2. Self-Adopt Using Our Guide

For teams that want to do it themselves, we provide a clear step-by-step guide, including templates for scope definitions, template DAO proposals, and on-chain registration instructions.

→ View the Self-Adoption Guide

3. Adopt Through a Third-Party Provider

Safe Harbor is also supported by select ecosystem partners who offer adoption workflows as part of their existing services.

→ Adopt via Immunefi

Safe Harbor doesn't require a legal entity, legal counsel, or new infrastructure. Just define your terms, publish your scope, and your protocol is protected.

Whether you're a DAO or not, adopting Safe Harbor is a low-lift way to enable real-time defense and recover funds during live exploits.

Whitehats Work

💡 SEAL911 and the broader whitehat community have already helped protocols recover over $150M from live attacks - proving that fast, responsible intervention is possible.

FAQ

What counts as an active exploit?

An active exploit is one that’s already in progress or imminent - for example, a malicious transaction sitting in the mempool or a vulnerability that's already being exploited. Safe Harbor only applies when immediate action is required to prevent or stop fund loss. It does not apply to situations where there is no imminent threat and where responsible disclosure can prevent fund loss.

How is it different than a Bug Bounty?

Bug bounties reward whitehats for responsibly disclosing vulnerabilities before they’re exploited. Safe Harbor kicks in after an exploit is underway - when there’s no time for disclosure, and whitehats need legal cover to intervene and recover funds in real time.

What are the risks?

There is little to no risk. The status quo is the protocol is hacked and the hacker gets 100% of funds. But with Safe Harbor, we unlock the upside of whitehats stepping in and rescuing funds. So the worst case scenario is the status quo, while the best case scenario is all funds are rescued by the protocol.

Whitehats only receive protection if they follow every requirement. If no exploit happens, nothing changes. If they do not follow Safe Harbor, they’re a blackhat

Can DAOs adopt it?

Yes. Safe Harbor was built with DAOs in mind. No legal entity is required - just a governance vote and public on-chain registration. Many protocols who have adopted are DAOs (ex: Uniswap, Balancer, Zksync)

Can Non-DAOs adopt it?

Yes. Centralized teams and foundations can also adopt Safe Harbor by publishing their scope and adoption terms. No DAO is required. Many protocols who have adopted are centralized teams (Pendle, Polymarket)

Who is the agreement with?

The Safe Harbor agreement is structured as a public unilateral offer - a legally binding offer made by your protocol to any whitehat who acts under the published terms. There’s no need to know or pre-approve the individual. If a whitehat follows your rules (e.g. intervenes during an active exploit, returns funds to the recovery address, meets any KYC requirements), the agreement becomes binding. No signatures or formal negotiation required.

Do we need to sign a legal contract (like DocuSign)?

Nope. Safe Harbor uses on-chain registration and public adoption details - no signatures or lawyers required. If you’re a DAO, a governance vote is enough.

What if a blackhat initiates a hack with one account, then “whitehats” it with another account to get the bounty?

They’re not covered. Safe Harbor protections only apply to whitehats who are fully independent from the original exploit. If someone initiates a hack and then tries to “rescue” the funds with another address, they’re still considered a blackhat - no bounty, no legal protection, and fully liable.

To reduce this risk even further, we recommend protocols set their Safe Harbor bounty cap at or below their existing bug bounty. This way, there’s no financial incentive to attempt an exploit - it's easier, safer, and more profitable to report the bug through your standard disclosure process than to fake a whitehat rescue under legal risk.

Can we modify the Safe Harbor legal contract?

We strongly discourage protocols from modifying the legal language of the Safe Harbor agreement. The framework is designed as a standard across the industry, so whitehats can understand the rules quickly and act confidently during emergencies.

That said, the agreement is built with flexibility where it matters: you define your scope - such as which contracts are covered, Asset Recovery Addresses, bounty terms, and KYC requirements. These parameters are designed to give you control without breaking the shared standard that makes Safe Harbor effective.

Should our legal team review the Safe Harbor agreement?

It’s optional. The agreement has already been vetted by leading law firms (Cooley, Debevoise & Plimpton, Piper Alderman) and adopted by top-tier protocols like Uniswap, Balancer, and Pendle.

That said, if your legal team wants to review it for extra peace of mind, they absolutely can. Just keep in mind: the agreement is a community standard designed for consistency, so major edits aren’t recommended (and usually unnecessary).

Safe Harbor Eligibility Checklist

Use this checklist to evaluate whether adopting the SEAL Whitehat Safe Harbor Agreement makes sense for your protocol.

Can Safe Harbor Help Your Protocol?

• Do you hold user funds in smart contracts? Without Safe Harbor, whitehats who could save your users' funds might hesitate to act due to legal uncertainty around unauthorized access.
• Do you want whitehats to help during active attacks? Safe Harbor gives ethical hackers legal protection to intervene immediately, before attackers can drain your protocol.
• Do you already have a bug bounty or security disclosure program? Safe Harbor fills the critical gap your bug bounty can't cover - live attacks happening right now when disclosure timelines don't matter.
• Do you want to increase the odds of recovering funds? Safe Harbor encourages rescue attempts by trusted whitehats.

If you checked any of the above - you can benefit from adopting our Safe Harbor.

What Does Adoption Involve?

1. Define your scope (what's covered, where funds go, bounty %, etc.)
2. (If DAO) Pass a governance proposal
3. Register on-chain
4. Update your Terms of Service and documentation
5. Make a public announcement to inform users and whitehats

It's fast, flexible (DAO or non-DAO), and aligns with industry standards.

Ready to Get Started?

You have 3 ways to adopt:

1. Self-adopt using our guide:

   → Self-Adoption Guide

2. Get help from SEAL (free):

   → Apply for onboarding

3. Adopt via a third-party:

   → Immunefi: Immunefi Integration Form

Find out more about Safe Harbor here

---

If you ever need help or have any questions, don’t hesitate to reach out!

Contact us at: [email protected]

Self-Adoption Guide

This guide walks you through the full process of self-adopting the SEAL Safe Harbor Agreement for your protocol. The goal is to provide whitehats with legal clarity and confidence to rescue funds when it matters most.

To do this effectively, protocols should cover all public and legal bases: defining a clear scope, obtaining DAO approval (if applicable), registering on-chain, updating their terms of service, and making a public announcement.

1. Scope Definition

The first step is defining the scope. This information informs whitehats about how and when they can intervene. It includes which assets are covered, where to send rescued funds, how to contact your team, what bounties apply, and any identity requirements.

• Refer to the scope walkthrough: Scope Definitions & Tips
• DAO Template: DAO Scope Template
• Non-DAO Template: Non-DAO Scope Template

2. DAO Proposal (If applicable)

If you are a DAO, this is a critical step. It formalizes permission from the community and provides legitimacy to the adoption.

• DAOs do not need a legal entity. Safe Harbor was designed to allow on-chain communities to adopt the agreement natively.
• Use the DAO Proposal draft from Step 1 where you defined the scope. Feel free to edit the proposal to reflect your DAO’s tone and format.
• Push your proposal through governance, temp check → formal proposal → Snapshot/Tally/etc.
• (Optional) Include the on-chain adoption call in the proposal itself for a full end-to-end flow.

3. On-Chain Adoption

Whether you're a DAO or a centralized team, you'll need to publish your adoption on-chain. This ensures your terms are publicly visible and enforceable.

If you are NOT doing on-chain via DAO proposal:

• Follow the guide: SEAL Safe Harbor On-Chain Adoption

If you ARE doing this in your DAO proposal:

• On-chain adoption involves two parts:
  1. Creating the AgreementV2 contract (the "terms" container)
  2. Registering it in the Safe Harbor Registry (this is what matters for whitehats)
• The DAO proposal should handle step 2, while step 1 can be done beforehand by following the guide: SEAL Safe Harbor On-Chain Adoption (IMPORTANT: Be sure to set the owner of the agreement to your DAO address)

4. Update Terms of Service & Docs

To ensure all users are informed and legally covered, update your Terms of Service and documentation.

Terms of Service (TOS)

Add the following language to your TOS:

User Agreement to be Bound By Agreement, Consent to Attempted Eligible Funds Rescues and Payment of Bounties

The User hereby acknowledges and agrees to, and consents to be bound by the terms and conditions of, that certain Safe Harbor Agreement for Whitehats, adopted by the Protocol Community on [INSERT DATE HERE] (the ”Whitehat Agreement”), available here https://bafybeigvd7z4iemq7vrdcczgyu2afm7egxwrggftiplydc3vdrdmgccwvu.ipfs.w3s.link, as a "User" and member of the "Protocol Community" thereunder. Without limiting the generality of the foregoing:

• the User hereby consents to Whitehats attempting Eligible Funds Rescues of any and all Tokens deposited into the Protocol by the User and the deduction of Bounties out of User’s deposited Tokens to compensate Eligible Whitehats for successful Eligible Funds Rescues;
• the User acknowledges and agrees that Tokens may be lost, stolen, suffer diminished value, or become disabled or frozen in connection with attempts at Eligible Funds Rescues, and assumes all the risk of the foregoing;
• the User acknowledges and agrees that payment of the Bounty as a deduction from User’s Tokens to an Eligible Whitehat may constitute a taxable disposition by the User of the deducted Tokens, and agrees to assume to all risk of such adverse tax treatment; and
• the User agrees to hold the other Protocol Community Members harmless from any loss, liability or other damages suffered by the User in connection with attempted Eligible Funds Exploits under the Whitehat Agreement.

This is also found in Exhibit D in the legal agreement

Documentation

Under your documentation's "Security" or "Bug Bounty" section, include:

"This protocol has adopted the SEAL Safe Harbor Agreement for Whitehats, which empowers approved security researchers to intervene during active exploits to rescue funds. Full adoption details, scope, and bounty terms are publicly available [here]."

Replace [here] with your actual registry listing or agreement address.

5. Announcement

Once everything is live, it's time to communicate publicly. This signals to whitehats, users, and the broader ecosystem that your protocol is protected.

• Use Twitter, Discord, forums, and governance portals.

• Highlight your on-chain registration, bounty terms, and any DAO vote.

• Example announcement:

  Today, we’re proud to announce that [Protocol Name] has officially adopted the @_seal_org Safe Harbor Agreement - a legal and technical framework that empowers whitehats to rescue funds during active exploits.

  This move brings us into alignment with some of the most security-forward protocols in the space - Uniswap, Pendle, Balancer - as we take real steps to defend our community and user funds.

• Feel free to coordinate with SEAL - we're happy to co-announce and amplify it.

---

If your protocol ever needs help with adoption, SEAL is happy to help answer any questions, walk you through adoption, amplify announcements, etc

📬 Contact us at: [email protected]

Safe Harbor Scope Terms

When adopting Safe Harbor, you'll define specific parameters that control what's covered and how whitehat rescues work. Below is an explanation of each term with tips and best practices.

1. Asset Recovery Address

The address where whitehats must return rescued funds after an exploit.

Tips:

• Use a highly secure smart contract wallet (e.g., Gnosis Safe or governance-controlled address).
• Ensure it can handle large inflows, potentially a significant portion of your TVL.
• Please refer to this framework on Wallet Multisig Security

2. Security Contact

The person or team whitehats must notify after completing a rescue.

Tips:

• Provide multiple points of contact (email, Signal, Telegram) for redundancy.
• Make sure these methods of notification are checked in case of an active exploit. Whitehats should reach out within 6 hours of a rescue

3. Assets Under Scope

The on-chain contracts or accounts that whitehats can legally interact with under Safe Harbor.

Scope Options:

• All: Covers the listed address and all child contracts, both existing and future.
• ExistingOnly: Covers the address and child contracts deployed before adoption.
• FutureOnly: Covers the address and child contracts deployed after adoption.
• None: Covers only the listed address.

Examples:

• All: Use for factories or deployer addresses that create vaults, pools, or markets. Covers all current and future instances.
• None: Use for single vault contracts where funds are concentrated and no child contracts exist.
• ExistingOnly / FutureOnly: Very rarely used; typically for protocols with legal or operational constraints on future contracts.

Tips:

• If your protocol deploys many contracts, include your deployer address EOA/Multisig/Governance Addresses with All. This avoids the need for updates.
• Keep this list current - if you launch new deployments and they aren't covered, whitehats can't legally intervene.

4. Bounty Terms

Defines how whitehats are rewarded for successful intervention.

4.1 Bounty Calculation

As a FYI, the formula to determine the bounty payout to the whitehats is:

bounty = min(bountyPercentage × recoveredAmount, bountyCapUSD)

Predefining this ensures no post-hack negotiation and prevents delays.

4.2 Bounty Percentage

The percentage of recovered funds that a whitehat receives.

Recommendation:

• 10% is standard in the industry.
• Set equal to your bug bounty program's critical exploit payout percentage

4.3 Bounty Cap (USD)

The maximum bounty amount for a single whitehat, in USD.

Recommendation:

• Match or set equal to your bug bounty program’s max payout to avoid incentives for malicious behavior.

4.4 Aggregate Bounty Cap (USD)

The maximum total bounty payout across all whitehats for a single incident. Bounties will be distributed pro-rata.

Rule:

• If you set an Aggregate Bounty Cap, you must set retainable to false so all funds return to the protocol first, then bounties are distributed.

4.5 Retainable

Whether whitehats keep their bounty directly or return everything first.

• True: Whitehat deducts bounty before returning funds.
• False: Whitehat returns all funds; protocol pays bounty afterward.

Rule:

• Cannot set retainable to true if Aggregate Bounty Cap is enabled.

5. Identity Verification

Determines whether whitehats must verify their identity.

Options:

• Anonymous: No KYC (most crypto-native option).
• Pseudonymous: Requires a pseudonym.
• Named: Legal name verification (KYC required).

Tips:

• Most protocols choose Named (KYC) for compliance.
• Some opt for crypto-native option of protecting the whitehat's anonymity.

6. Diligence Requirements

Additional compliance checks for whitehats before bounty payout (applies only if identity = Named).

Generic Template:

<PROTOCOL_NAME> requires all eligible whitehats to undergo Know Your Customer (KYC) verification and be screened against global sanctions lists, including US, UK, and EU regulations. This process ensures that all bounty recipients are compliant with legal and regulatory standards before qualifying for payment.

---

If you ever need help or have any questions, don’t hesitate to reach out!

📬 Contact us at: [email protected]

On-Chain Adoption Guide

This guide explains how protocols can register their Safe Harbor adoption on-chain. Registering ensures your adoption is public, verifiable, and enforceable.

Why On-Chain Adoption Matters

On-chain registration:

• Makes your Safe Harbor adoption public and transparent.
• Signals to whitehats that your protocol is officially covered under the agreement.
• Publishes your terms (scope, bounty, contacts) on-chain in a way that's traceable and verifiable, even if updated later.

How On-Chain Adoption Works

The process involves two steps:

1. Deploy your AgreementV2 contract (containing your scope details)
2. Register the agreement with the Safe Harbor Registry

Three Ways to Deploy and Register

Important Note:

• The address that registers represents your protocol on-chain.
• Most protocols use multisigs or DAOs for the registration step - Be sure to set the owner of the agreement to your multisig or DAO address if you are registering with them.
• The simpliest workflow is to use the SEAL Self-Adoption Tool to deploy your agreement and register it with your multisig/DAO.

1. SEAL Self-Adoption Website + Script/Multisig Registration

1. Navigate to the SEAL Self-Adoption Tool.
2. Fill in your scope details (Asset Recovery Address, Assets Under Scope, Bounty Terms, etc.).
   • WARNING: Be sure to set the owner of the agreement to your multisig or DAO address if you're registering with them.
3. Choose one of the following:
   • Generate an Agreement to deploy your AgreementV2 contract via the SEAL tool
   • Export JSON for use in Foundry scripts
4. Deploy your agreement using the generated parameters
5. Register separately using either:
   • Foundry script (see method 3 below)
   • Multisig registration (see method 2 below)

2. Multisig Registration (Gnosis Safe)

If your protocol uses a multisig, you can register on-chain securely after deploying your agreement.

Steps:

1. First, deploy your AgreementV2 contract:

   • Use the SEAL Self-Adoption Tool to generate the deployment parameters
   • Deploy via the AgreementFactoryV2 using your preferred method
   • WARNING: Be sure to set the owner of the agreement to your multisig address

2. Register with your multisig:

   • Open your Gnosis Safe and go to the Transaction Builder app
   • Enter the Safe Harbor Registry address:
     • Default for most EVM chains: 0x1eaCD100B0546E433fbf4d773109cAD482c34686
     • Full address list: Registry Addresses
   • Select the method: adoptSafeHarbor(address agreementAddress) and input your deployed AgreementV2 contract address
   • Add the transaction and simulate it:
     • You should see a SafeHarborAdoption event with your multisig as the entity
   • Collect signatures and execute

3. Foundry Script / Custom Code

If you prefer deploying and registering via code or need custom integrations, you can use SEAL's Foundry script or write your own.

Using SEAL's Foundry Script:

• Repository: security-alliance/safe-harbor
• Script: registry-contracts/script/v2/AdoptSafeHarborV2.s.sol

Steps:

1. Generate your scope JSON via the SEAL tool or manually prepare it using registry-contracts/agreementDetailsV2.json as a template
2. Paste the JSON into: registry-contracts/agreementDetailsV2.json
3. Run the script:
   • By default, the script will set the deployer as the owner of the agreement
   • You can change this by setting AGREEMENT_OWNER in your .env file to your desired owner address
   • By default, the script will not register the agreement - you can change this by setting DEPLOY_REGISTRY to true in your .env file
   • The script can handle both deployment and registration

Manual Method:

1. Deploy your agreement: AgreementFactoryV2.create(AgreementDetailsV2 memory details, address registry, address owner)
2. Register it: SafeHarborRegistryV2.adoptSafeHarbor(address agreementAddress)
3. Use the deployed Registry & Factory Addresses

Key Contracts

• Agreement Factory: Deploys AgreementV2 contracts
• Safe Harbor Registry: Registers adoption and makes it official
• Deployed Addresses: View Registry & Factory Addresses

---

If you ever need help or have any questions, don't hesitate to reach out! 📬 Contact us at: [email protected]

Safe Harbor for Whitehats

Why You Should Care

Safe Harbor lets whitehats intervene during active exploits to help secure protocol funds. It does so by providing a legal framework that outlines what whitehats can and can't do, how they ought to operate, and protects abiding whitehats in the event of legal action taken by the protocol.

In addition to the legal protections, Safe Harbor also helps whitehats by giving them the following information:

1. What assets are owned by a protocol
2. What is the protocol's (asset recovery address)
3. Who the security contact
4. What KYC requirements (if any) protocols impose onto whitehats
5. What bounty terms whitehats will be awarded under Safe Harbor

This information is all neatly cataloged in the Safe Harbor Registry - an on-chain registry cataloging all protocol adoptions and their adoption details. For more details, review the Safe Harbor for Protocols document. It has also been compiled by Skylock at the Safe Harbor Database.

Whitehat Adoption

If a whitehat reads and understands the entire legal framework, they may later be eligible to participate in a whitehat rescue. These rescues should only be taken in very specific circumstances, and it is important to reiterate the following:

• The framework only applies to active exploits, and it is a violation of the agreement if the whitehat initiates an exploit themselves.
• The protocol is not responsible for ensuring the whitehat follows the law, and the whitehat can not be protected from criminal charges outside the agreement's scope.
• There are nuances that can affect the agreement's enforceability, and whitehats will assume many legal risks by becoming involved.
• If the whitehat decides to proceed with a whitehat rescue, they must follow the process specified in the agreement. This includes transferring rescued funds to the protocol's "Asset Recovery Address" and promptly notifying the protocol of the fund recovery. The whitehat may keep (or later receive) a reward, based on the terms of the agreement.

Safe Harbor may also apply to generalized frontrunner / arbitrage bots. The rules of conduct enforced by Safe Harbor for Prospective and Retrospective whitehats differs in a few key areas.

In the Event of a Hack

Pre-Intervention

In the event of a hack targeting a protocol that has adopted Safe Harbor, whitehats are permitted to take broad actions to secure the protocol's funds. Before taking action, review the following checklist (also present in the Safe Harbor Technical Summary):

• Is this an active, urgent exploit?
• Are you unable to responsibly disclose the exploit (e.g. via a bug bounty program) due to time constraints or other reasons?
• Can you reasonably expect your intervention to be net beneficial, reducing total losses to the protocol and associated entities?
• Are you experienced and confident in your ability to manage execution risk, avoiding unintentional loss of funds?
• Will you avoid intentionally profiting from the exploit in any way other than through the reward granted by the protocol?
• Are you and anyone with whom you directly cooperate during the funds rescue, as well as all funds and addresses used in said rescue, free from OFAC sanctions and/or other connections to sanctioned parties?
• Have you confirmed the agreement has been duly adopted by the protocol community?
• Are you fully aware of the risks associated with your actions, including but not limited to accidental loss of funds, claims and liabilities outside this agreement's scope, and the unclear extent of this agreement's enforceability?

In the event that all the above applies, you may chose to take action to protect the protocol's assets. How you do this depends on the situation - perhaps offensively white-hat hacking a protocol with a proven exploit, or returning funds recovered by your MEV bot from an incident it frontran.

Post-Intervention

After the funds have been recovered, it is your responsibility to ensure their safe return to the owner protocol. We strongly recommend contacting SEAL911 immediately to advise on the fund recovery process and to assist with KYC, protocol communications, and bounty collection. You must also contact the protocol's posted security contact and return all recovered funds to the protocol's asset recovery address within 6 hours of the event, or 48 hours if reason is provided and the protocol has been made aware.

Vulnerability Disclosure

Vulnerability disclosure is the task that is done after a vulnerability has been identified and fixed, and means to make the vulnerability known to the larger public. Often, a vulnerability disclosure will come after a bug bounty report has been filed and the vulnerability has been corrected, or from a team member that noticed a vulnerability which was then fixed. In the event that responsible disclosure of the vulnerability is not possible because the vulnerable code is actively or will imminently be exploited, Safe Harbor may be applicable.

Security Contact

Having a security contact provides a designated point of contact for security researchers to report vulnerabilities to.

SECURE.md File

Importance

A SECURE.md file in your GitHub repository provides clear instructions on how to report security vulnerabilities.

Example Content

# Security Policy

We take the security of our project seriously. If you discover any security vulnerabilities, please report them responsibly.

## Reporting a Vulnerability

Please email us at [email protected] with the details of the vulnerability. We will respond as soon as possible.

We appreciate your help in improving the security of our project.

Security Email Address

Importance

Having a dedicated security email address (e.g., [email protected]) ensures that vulnerability reports are directed to the appropriate team members.

Setup

• Dedicated Team: Ensure that the security email is monitored by a team with the expertise to handle vulnerability reports.
• Prompt Responses: Aim to acknowledge receipt of vulnerability reports within 24 hours.

.well-known/security.txt

Importance

The .well-known/security.txt file is a standardized way to provide security contact information on your website.

Example Content

Contact: mailto:[email protected]
Encryption: https://projectname.TLD/pgp-key.txt
Acknowledgements: https://projectname.TLD/hall-of-fame.html
Policy: https://projectname.TLD/security-policy.html
Preferred-Languages: en

Implementation

• Standard Location: Place the security.txt file in the .well-known directory of your website (e.g., https://projectname.TLD/.well-known/security.txt).
• Regular Updates: Keep the security.txt file updated with current contact information and policies.

Managing Security Contacts

Responsibilities

• Triage: Assess and prioritize vulnerability reports based on severity and impact.
• Communication: Maintain clear and respectful communication with reporters. Provide regular updates on the status of their reports.
• Resolution: Work promptly to resolve reported vulnerabilities and update the reporter on the actions taken.

Best Practices

• Confidentiality: Treat all vulnerability reports as confidential until a fix is implemented.
• Acknowledgement: Consider publicly acknowledging researchers who report vulnerabilities, with their permission.
• Transparency: Be transparent about your vulnerability disclosure process and timelines.

Bug Bounties

Bug bounty programs incentivize security researchers to identify and report vulnerabilities in your project. They augments a security team and audits by allowing external security researchers to disclose vulnerabilities in your project in a way that should be a good experience for the security researcher. Depending what the scope of the bug bounty program is, you may have a higher success rate having certain parts at different types of bug bounty as a service providers, as they generally have security researchers with different skill sets using their platforms.

Bug Bounty as a Service

Web3

• Immunefi
  • Pros: One of the largest bug bounty as a service platforms for web3
• Hackenproof
  • Pros: Provides end-to-end encryption for reports, ensuring only a project's security team can decrypt it using their own private keys.

Web2

• HackerOne
• Bugcrowd

Pros and Cons of Running Your Own Bug Bounty Program

Pros

1. Full control over the scope, rewards, and rules of the program.
2. Potentially lower cost.
3. Direct interaction with security researchers could build strong relationships.

Cons

1. Requires significant time and resources to manage.
2. Need for skilled triage abilities to handle and prioritize reports.
3. Risk of being overwhelmed by reports, including false positives.

Key Elements of a Successful Bug Bounty Program

Scope

1. Clearly define the scope of the program, including in-scope and out-of-scope assets.
2. Regularly update the scope to include new features and exclude deprecated ones.

Rewards

1. Offer competitive rewards based on the severity and impact of the vulnerabilities.
2. Be transparent about the reward structure and criteria for evaluating reports.

Triage and Response

1. Have skilled personnel to triage incoming reports, assess severity, and prioritize responses.
2. Respond to reports promptly, acknowledging receipt and providing regular updates.

Communication

1. Treat all reporters with respect and professionalism.
2. Provide feedback to researchers on the status of their reports and any actions taken.

Legal and Ethical Considerations

1. Clearly state safe harbor provisions to protect researchers from legal action when acting in good faith.
2. Define your policy on public disclosure of vulnerabilities, including timelines and conditions.

Infrastructure

Infrastructure can often be overlooked in web3, but it's often a very important area given that most front-end web applications are running on centralized infrastructure. This section focuses on Infrastructure Security, encompassing critical aspects such as cloud infrastructure, DNS providers, domain registrars, and DDoS (Distributed Denial of Service) protection.

When designing your architecture, it may be worth considering how many different providers you rely on. Are you going to use different providers for infrastructure, DDoS protection, domain registration, and DNS, or will you choose a provider that provides all of these? On one hand, putting all eggs in one basket means a failure on said service would cause downtime, however by using a single service and ensuring it’s following all best practices with regards to security measures means a lower risk surface.

Contents

1. Asset Inventory
2. Cloud Infrastructure
3. DDoS Protection
4. DNS and Domain Registration
5. Network Security
6. Operating System Security
7. Zero-Trust Principles

Asset Inventory

An asset inventory means having information about everything related to your project, meaning for example contracts, hardware, software, cloud providers, dependencies and network components. This is important, as if you don't have awareness of your assets then how are you going to be able to protect them?

You should at the very least document as much as you can with regards to your assets, and update this on a regular basis. It is highly recommended to also assign ownership of each asset, so that someone ensures the safety of this asset. Classifying them based on their criticality and sensitivity also helps you prioritize them with regards to security measures.

Cloud Infrastructure

Securing your cloud infrastructure could be considered as important as securing your decentralized application, as a lot of users will be interacting with your dapp through the cloud provider. Some best practices to consider are:

1. Implement strict access controls and identity management to ensure that only authorized individuals can interact with cloud resources. Use role-based access control (RBAC) and multi-factor authentication (MFA).
2. Encrypt data both in transit and at rest. Use managed encryption keys or bring your own keys (BYOK) for enhanced security.
3. Configure virtual private clouds (VPCs), implement firewalls, and monitor network traffic to protect against unauthorized access and threats.
4. Set up comprehensive logging, monitoring, and threat detection systems to identify and respond to security incidents in real-time. Use services like AWS CloudTrail, Azure Monitor, and Google Cloud Logging.
5. Implement high availability, data backup, and disaster recovery plans to protect against service disruptions. Use automated fail-over and replication strategies.
6. Ensure compliance with regulatory requirements (e.g., GDPR, MiCA).

Cloud Provider Hardening Guides

All cloud providers have hardening guides that provide step-by-step instructions and best practices for securing cloud infrastructure:

• AWS: Security, Identity, and Compliance
• Azure: Best Practices and Patterns
• GCP: Security Best Practices

Open Source Tools

To aid with vulnerability detection and compliance, you could consider using the following open-source tools:

• CloudSploit: CloudSploit
• Prowler: Prowler
• S3Scanner (AWS): S3Scanner
• Zeus (AWS): Zeus

DDoS Protection

Distributed Denial of Service (DDoS) attacks are a pervasive threat that can disrupt your services by overwhelming them with excessive traffic.

Best Practices

• Use Cloud Provider Solutions: Utilize DDoS protection services offered by your cloud provider:

AWS

• AWS Shield Standard and Advanced:
  • Shield Standard: Basic DDoS protection at no extra cost.
  • Shield Advanced: Enhanced protection with real-time visibility and access to AWS DDoS Response Team (DRT).
• Amazon CloudFront and AWS WAF:
  • CloudFront: Distributes traffic globally to mitigate DDoS attacks.
  • AWS WAF: Protects against application layer attacks.

Azure

• Azure DDoS Protection Basic and Standard:
  • DDoS Protection Basic: Automatic protection against common attacks.
  • DDoS Protection Standard: Advanced protection with real-time monitoring.
• Azure Front Door and Azure Application Gateway with WAF:
  • Front Door: Global application delivery with DDoS mitigation.
  • Application Gateway with WAF: Protects against various attacks.

GCP

• Google Cloud Armor: Provides DDoS protection and WAF capabilities.
• Load Balancing: Distributes traffic to mitigate DDoS attacks.
• VPC Flow Logs and Stackdriver Logging: Monitors and logs traffic patterns for effective response.

External DDoS Protection Providers

In addition to cloud provider solutions, consider external DDoS protection services:

• Cloudflare: Offers comprehensive DDoS protection and mitigation services.
• Akamai: Provides scalable DDoS protection solutions.
• Imperva: Specializes in DDoS protection and mitigation.

DNS and Domain Registration

DNS (Domain Name System) is the backbone of the internet, translating domain names into IP addresses. Choosing a secure and trusted Domain Registrar is important, as if someone is able to obtain access to your domain registrar they could change DNS servers and more.

DNS Security

1. Implement DNSSEC to digitally sign DNS records, ensuring data integrity and authenticity.
2. Evaluate and choose DNS hosting providers based on their performance, security, and reliability.

Domain Registrar Security

1. Select a registrar with a strong security posture and a history of reliability.
2. Follow best practices for securing your domain registrar account, including strong authentication methods.
3. Enable domain transfer locks and two-factor authentication to prevent unauthorized domain transfers.
4. Use WHOIS privacy services to protect your domain registration information from public exposure.
5. Implement processes to ensure your domains do not inadvertently expire, potentially causing disruptions.

DNS Monitoring and Incident Response

1. Create alerts to be notified of DNS route changes and ensure those changes are expected and authorized.
2. Develop an incident response plan specific to DNS and Domain Registrar security breaches, including steps for investigation and mitigation.

Identity and Access Management

Right now, this subsection has an entire category of its own. Please refer to Incident and Access Management (IAM)

Network Security

Network security is a very wide subject, and the steps you take are significantly dependent on if you're managing your own network, if you're utilizing a cloud provider, or if you're using a service provider. With that said, there are some general best practices to consider:

Best Practices

1. Infrastructure should deny all incoming traffic by default. When opening ports, consideration should be made as to which ports and incoming IPs are needed. SSH, RDP, and Database ports should not be open to the entire Internet.
2. Divide your network into segments to limit the impact of a potential breach.
3. Implement firewalls to control and monitor incoming and outgoing network traffic based on predetermined security rules.
4. Use IDPS to detect and prevent potential security breaches.
5. Use VPNs to provide secure remote access to your network.
6. Encrypt sensitive data in transit using secure protocols.
7. Use ACLs to define and control which systems or users can access network resources.
8. Conduct regular network security audits to identify and address vulnerabilities.
9. Keep any potential network devices and software updated with the latest security patches.

Operating System Security

This document outlines some general best practices one should follow with regards to operating system security, however if you're interested in a much more comprehensive guide you could look at NIST 800-123.

Best Practices

1. Keep your operating systems updated with the latest security patches and updates.
2. Block the remote shell port from all but required IPs.
3. Block all ports except absolutely required ones from public.
4. Use tools such as fail2ban to protect against attacks.
5. Enforce personal account and SSH key login
6. Enable multi factor authentication.
7. Implement strict access controls to limit administrative privileges and use role-based access control (RBAC).
8. Use antivirus and anti-malware software to detect and prevent malicious activities on systems where relevant
9. Configure host-based firewalls to control incoming and outgoing network traffic.
10. Implement host-based intrusion detection and prevention systems (HIDS/HIPS).
11. Follow secure configuration guides, such as the NIST 800-123 guidelines, to harden your operating systems.

Zero-Trust Principles

The Zero-Trust security model assumes that threats can exist both inside and outside the network. It requires strict verification for every user and device attempting to access resources, regardless of their location.

Key Principles

1. Always authenticate and authorize based on all available data points, including user identity, location, device health, and service or workload.
2. Limit user access with just-in-time and just-enough-access (JIT/JEA), risk-based adaptive policies, and data protection.
3. Segment networks and use encryption to limit the potential impact of a breach.

Implementation Strategies

1. Implement strong IAM practices, including multi-factor authentication (MFA) and conditional access policies.
2. Use micro-segmentation to create secure zones in data centers and cloud environments.
3. Ensure all endpoints (e.g., devices, servers) comply with security policies before granting access.
4. Implement continuous monitoring and analytics to detect and respond to anomalies in real-time.
5. Use automation to enforce security policies consistently across the network.

Monitoring

Monitoring is a crucial aspect of maintaining the security and integrity of a blockchain project. Effective monitoring allows you to detect anomalies and potential security breaches in real-time, enabling prompt response and mitigation. This section focuses on monitoring the on-chain security of a project, including guidelines for setting up monitoring systems, defining thresholds for alerts, and utilizing existing on-chain monitoring tools.

Guidelines for On-Chain Monitoring

Effective on-chain monitoring is complex, and involves setting up systems and processes to continuously observe blockchain activities and detect any anomalies.

Best Practices

Define Monitoring Objectives

1. Determine the critical metrics to monitor, such as large fund transfers, token minting events, and changes in contract ownership.

Implement Monitoring Tools

1. Use automated monitoring tools that can continuously track blockchain activities and generate alerts for anomalies.
2. Supplement automated tools with periodic manual reviews.

Establish Alerting Mechanisms

1. Set up real-time alerts to notify relevant project members of any suspicious activities or threshold breaches.
2. Use multiple channels for alerts, such as email, SMS, and messaging apps where available, to ensure timely response.

Regular Reviews and Updates

1. Conduct regular reviews of your monitoring systems to ensure they are functioning correctly and covering all necessary metrics.
2. Regularly update thresholds and alert configurations to reflect your current needs.

Incident Response

1. Develop and maintain an incident response plan to handle alerts and anomalies as soon as possible.

Defining Thresholds for On-Chain Monitoring

Setting appropriate thresholds for on-chain monitoring is hard when taking into account you want to detect unusual activities, without generating excessive false positives. Here are some guidelines for defining and configuring thresholds.

Generic Guidelines

Understand Normal Activity Patterns

1. Establish baseline metrics for normal activities, such as average transaction volumes and typical token minting rates (if any).
2. Use historical data to understand activity patterns and identify deviations from the norm.

Set Thresholds for Alerts

1. Define thresholds for large fund transfers from project wallets, considering both absolute amounts and relative percentages.
2. Set thresholds for token minting events, including the number of tokens minted and the frequency of minting.
3. Establish thresholds for changes in contract ownership or significant modifications to contract code.

Adjust Thresholds Over Time

1. Implement adaptive thresholds that can adjust based on changing activity patterns and emerging threats.
2. Periodically review and update thresholds to ensure they remain relevant and effective.

Multi-Layered Thresholds

1. Use primary thresholds for critical alerts and secondary thresholds for less urgent notifications.
2. Define thresholds based on a combination of metrics to reduce false positives and improve accuracy.

Anomaly Detection

It is hard, if not impossible, to predict every type of alert one should setup for their project. As such, implementing an anomaly detection system can be of great value as it will monitor the project and its transactions in real time, and compare it to its previous behavior. If for example it is common that 4% of tokens change owner each day and there's a day with 20% of tokens changing owner in the past 10 minutes, then that could be detected as an anomaly cause for investigation.

Front-End Web Application Security Best Practices

Often an overlooked area, but ensuring the security of your front-end web and potential mobile applications is crucial for protecting your users. If the front-end web application is compromised, it could have severe effects on your users as they for example could start interacting with a malicious contract instead of your official contract.

Contents

1. Web Application Security
2. Mobile Application Security
3. Common Vulnerabilities
4. Security Tools and Resources

Web Application Security

Providing a secure front-end (web application) for users to interact with your web3 protocol is often essential. Web application vulnerabilities have however been exploited in the past to steal user funds, and as such it's important to take web application security into consideration for your project.

Best Practices

1. Utilize popular and well-maintained web application frameworks when developing your application.
2. Familiarize yourself with common web application vulnerabilities that may affect your decentralized application such as Cross-Site Scripting (XSS). Refer to the OWASP Top 10 for a comprehensive list.
3. Minimize the introduction of custom components in your framework. Ensure that any custom code undergoes thorough internal and external security testing.
4. Refer to the Infrastructure/DDoS Protection section for insights on ensuring high availability of your protocol’s front-end.
5. Lock down access to associated back-end services, such as S3 buckets, to prevent unauthorized access.
6. Consider deploying additional versions of your front-end on IPFS to ensure availability and resilience.

Mobile Application Security

Mobile applications are increasingly used as front-ends for web3 protocols. As more projects are using mobile applications, it also becomes an increasing target for threat actors. Below, you can find some suggestions to help protect your mobile application:

Best Practices

1. Follow secure coding practices to prevent common vulnerabilities such as:

   • Insecure Data Storage
   • Insufficient Transport Layer Protection
   • Insecure Authentication
   • Insecure Authorization

2. Use the trusted execution environment available in the device for secret management.

3. Ensure that APIs used by the mobile application are secure and follow best practices for authentication and authorization by implementing certificate pinning to help prevent man-in-the-middle attacks.

4. Encrypt sensitive data stored on the device and during transmission.

5. Keep the mobile application and its dependencies updated to protect against known vulnerabilities.

6. Leverage security libraries and frameworks designed for mobile application security, such as OWASP Mobile Security Project.

Common Vulnerabilities

Understanding and mitigating common vulnerabilities is crucial for securing your web and mobile applications. Here are some frequently encountered vulnerabilities:

General Vulnerabilities

• Account Takeovers: Having the administrator accounts for your services (DNS, Cloud, Domain Registrar, Email, Github, etc.) is likely to be devastating to your project, as a threat actor can then make malicious changes. To protect against this, it is recommended to follow best practices with regards to account security and use hardware 2FA solutions to secure the accounts.

Web Application Vulnerabilities

• Cross-Site Scripting (XSS): Malicious scripts injected into trusted websites, leading to data theft or session hijacking.
• Cross-Site Request Forgery (CSRF): Unauthorized commands transmitted from a user trusted by the web application.
• Insecure Direct Object Reference (IDOR): Unauthorized access to data by manipulating input parameters.

Mobile Application Vulnerabilities

• Insecure Data Storage: Sensitive data stored in an insecure manner on the device.
• Insufficient Transport Layer Protection: Lack of encryption for data transmitted over the network.
• Insecure Authentication and Authorization: Weak authentication mechanisms and improper authorization checks.
• Code Tampering: Modifications to the application code by attackers.

Refer to the OWASP Top 10 and OWASP Mobile Security Project for more details on common vulnerabilities and mitigation strategies.

Security Tools and Resources

There is a very large amount of security tools and resources available, and sometimes it can feel overwhelming.

There is a wide range of security tools to test your web & mobile applications, such as OWASP ZAP or Burp Suite to scan your application for vulnerabilities, Snyk to check your dependencies, or MobSF for security analysis on Android/iOS applications.

For web3, there is also a wide range of tools. Rather than listing specific tools, we are providing links to repositories listing many of these tools:

• https://github.com/safful/Web3-Security-Tools
• https://github.com/OffcierCia/On-Chain-Investigations-Tools-List
• https://github.com/shanzson/Smart-Contract-Auditor-Tools-and-Techniques
• https://github.com/Anugrahsr/Awesome-web3-Security

Incident Management

Incident management involves preparing for, detecting, responding to, and recovering from security incidents. By thinking about incident management prior to actually experiencing an incident, you can help increase the likelihood of a timely recovery.

Contents

1. Communication Strategies
2. Incident Detection and Response
3. Lessons Learned
4. Playbooks
5. SEAL 911 War Room Guidelines

Communication Strategies

Communication during an incident can be very hard, as people are often scrambling to fix the issue at hand. Nonetheless, from aa team member, outsider or observer's point of view, communication is very important to be able to understand what's happening, and it also provide some time to reflect and think about what is going on. With that said, providing information before confirming that it's accurate, can often be very negative and cause uncertainty. It is recommended to have a person designated for communication during an incident, and that updates are sent out on a fixed schedule, and it can often be that the update is that there is currently no new information available.

Best Practices

1. Define and establish secure communication channels for incident response teams. Use encrypted messaging apps
2. Appoint primary and backup spokespersons to handle internal and external communications during an incident.
3. Develop pre-approved templates for incident notifications, updates, and press releases to ensure consistency and speed.
4. Provide regular updates to all stakeholders, including employees, customers, partners, and regulatory authorities, to keep them informed of the situation and response efforts.
5. Maintain clear communication within the incident response team to ensure that everyone is aware of their roles and responsibilities.
6. Be transparent with external stakeholders about the incident, the impact, and the steps being taken to address it. Avoid speculation and provide factual information.

Incident Detection and Response

You don't want to be that project which has funds stolen, and then don't notice it for multiple days. Early detection and effective response to security incidents will help minimize damage.

Key Components of Incident Detection

• Monitoring and Logging: Implement continuous monitoring and logging of on-chain activity for your project to understand when something is behaving out of the ordinary. Also implement monitoring of system events, and user behavior to detect anomalies and potential security incidents in non-on-chain systems such as web applications or cloud environments.

Key Components of Incident Response

• Incident Response Team (IRT): Establish a dedicated IRT with clearly defined roles and responsibilities.
• Incident Response Plan (IRP): Develop and maintain an IRP that outlines the procedures for detecting, responding to, and recovering from security incidents.
• Containment: Implement strategies to contain the incident.
• Recovery and Remediation: Ensure that everything is restored to normal operation and take steps to prevent future incidents.
• Post-Incident Review: Conduct a thorough review of the incident to identify lessons learned and improve future response efforts.

Lessons Learned

Conducting a post-incident review and identifying lessons learned will improve your project's incident response capabilities. By analyzing what went well and what could be improved, you can enhance your readiness for future incidents.

Best Practices

1. Review the incident together with everybody involved in handling it shortly after the incident is resolved.
2. Record details about the incident, including the timeline, root cause, impact, and response efforts.
3. Assess the effectiveness of the incident response, highlighting areas where the team performed well and areas needing improvement.
4. Create action plans to address identified weaknesses and enhance strengths. Assign responsibilities and deadlines for implementing improvements.
5. Share the lessons learned with the ecosystem to promote awareness and improve overall security practices.
6. Revise incident response policies and procedures based on the lessons learned to ensure continuous improvement.

Playbooks

Generally speaking, incident response playbooks aim to provide detailed, step-by-step procedures for handling specific types of security incidents. Obviously, it's not possible to have thought about every possible scenario ahead of time, but one could create documentation for the most likely or devastating scenarios.

Best Practices

1. Define the type of incident the playbook addresses (e.g., stolen funds, data breach, DDoS attack).
2. Outline the steps for detecting and analyzing the incident, including key indicators of compromise (IOCs) and tools to use.
3. Describe immediate actions to contain the incident and prevent further damage.
4. Provide detailed steps for eradicating the root cause of the incident.
5. Outline procedures for restoring everything affected to normal operation.
6. Detail the steps for conducting a lessons learned review.

SEAL 911

SEAL 911 is a project designed to give users, developers, and even other security researchers an accessible method to contact a small group of highly trusted security researchers. The group can be reached via the Telegram bot.

Members of SEAL 911 follow a strict CODE OF CONDUCT.

When interacting with SEAL 911, ensure that you give as much information as possible in order to avoid double work by the security researchers.

---

Crisis Handbook - Smart Contract Hack | Google Doc

Actions Checklist

Perform Immediately

• Notify SEAL 911 Bot of the incident. Use this message template to get started.
• Create a War Room with audio and share the invite link with trusted individuals.
• Duplicate this document to allow collaboration and share the link in the War Room.
• Review the Advice to Keep in Mind section.

Perform in Parallel by Role

1. Assign Key Roles to War Room Members:

   • Assign members to specific roles.

2. Analysis:

   • Scope the impact of the attack.
   • Gather Transactions Involved.
   • Gather Affected Addresses.
   • Record Funds Movement.
   • Gather Attacker Information.
   • Investigate the issue and update the Issue Description.
   • Propose workable solutions.

3. Protocol actions:

   • Take immediate corrective/preventative actions to prevent further loss of funds.
   • Pause contracts if possible.
   • Execute pre-made defensive scripts.
   • Prioritize proposed solutions.
   • Validate and execute the solution.
   • Prepare monitoring alerts for situations that require future actions.

4. Web actions:

   • Disable deposits and/or withdrawals as needed in the web UI.
   • Enable front-end IP or Address blacklisting.
   • Create front-end for any user actions necessary (approval revoking, fund migrating, etc.).

5. Communications:

   • Identify social platforms that communications on the incident must be sent to.
   • Prepare messages for incident communication internally and externally.
   • Gather security contacts for any potentially affected downstream protocols (bridges, lending protocols).
   • Notify block explorers (like Etherscan) for attacker address labeling.
   • Continuously monitor social media for users providing additional information that aids whitehat efforts.
   • Monitor War Room efforts and maintain the Event Timeline.

After all of the above is complete, consider Post Incident Actions

Information Gathering

Information will primarily be shared and acted upon in the War Room. As time allows, consolidate intel in the below section to achieve the following:

• Accurately scope the incident impact.
• Inform new War Room members and third parties efficiently.
• Aid external communication.

This is the chief duty of the Scribe.

Issue Description

The issue involves an unauthorized transfer of funds from the protocol's treasury contract due to a vulnerability in the contract's access control mechanism. The attacker exploited this vulnerability to initiate multiple transfers, siphoning funds to an external wallet.

Events Timeline

Record events to construct an overall timeline of the incident. Events worth recording:

• First notice of the incident
• War room creation
• External communications
• Attack transactions
• Transactions performed by the team

Record times in UTC. Use a UTC Time Converter.

Transactions Involved

Record all transactions related to the incident.

Affected Addresses

Record affected addresses related to the incident (protocol contracts, bridges, users, etc.).

Funds Movement

Record funds movement to gather the impact of the incident and organize recovery efforts.

• Original address that held the funds
• Transaction that moved the funds
• Assets and amounts the funds are comprised of
• Destination the funds moved to (Contract, CEX, Bridge, Mixer)
• Recovery Status of the funds

Use Phalcon Tx Explorer to aid in recording funds movement.

Attacker Information

Gather attacker information to aid legal efforts and fund recovery.

Post Incident Actions

1. Confirm the incident has been resolved.
2. Create monitoring alerts for situations requiring future actions.
3. Prepare scripts to perform any actions related to monitoring events in the future.
4. Consider creating additional defensive scripts (pause/upgrade) to use for future situations.
5. Schedule a Post Mortem write-up.
6. Post the write-up to relevant social media.

Appendix

Advice to Keep in Mind

• Limit the War Room occupancy. Be careful not to invite too many people during the early stages. Sensitive information is being shared; be wary.
• Make it clear to War Room members not to publicize information without the protocol’s consent.
• Do not speak to the press/news/publications.

Key Roles

• Operations: Initiates War Room, assigns roles, distributes tasks, herds multisig participants.
  • Person Responsible
• Scribe: Consolidates gathered information for efficiency in knowledge-sharing.
  • Person Responsible
• Strategy Lead: Prioritizes actions, considers trade-offs of decisions.
  • Person Responsible
• Protocol Lead: Responsible for smart-contract actions (pausing, upgrading, etc.).
  • Person Responsible
• Web/Infrastructure Lead: Responsible for updating the front-end, managing servers.
  • Person Responsible
• External Communicator: Social media and user communications.
  • Person Responsible

Suggested Tools and Platforms

SEAL Message Template

Fill out with relevant information and send to SEAL 911 Bot.

Protocol: [Protocol Name]
Attack Tx(s): [Transaction Hash(es)]
Funds at Risk: [Estimated Amount in USD or Token]

[Brief Description of the incident]

Decentralized Incident Response Framework (DeIRF)

A lightweight, end-to-end scaffold for security teams that work without a single authority.
Use it as a menu, not a mandate.

1. Guiding Principles

---

2. Roles and Identities

Tip: Publish a public mapping of handles to real names and keep it in a tamper evident repo.

---

3. Preparation Checklist

---

4. Detection and Triage Flow

1. Alert fires or user reports an issue.
2. First Reporter opens a ticket in the transparent issue tracker (GitHub security advisory or private GitLab issue).
3. Triage Lead checks severity matrix.
4. If P1, spin up a temporary incident channel with a predefined template.
5. Assign Leads and set T-minus deadlines.

---

5. Containment Options

Keep a one-liner command ready for each action and store it in the runbook.

---

6. Eradication and Recovery

1. Patch or replace vulnerable code.
2. Peer review with at least two signers.
3. Deploy to staging with replay of attack scenario.
4. Roll forward to production by multisig or automated pipeline.
5. Verify by monitoring metrics and logs for stability.

---

7. Post-Incident Actions

---

8. Quick-Start Templates

---

9. Pros and Cons of Decentralized IR

---

10. Keep It Alive

• Run quarterly red team drills.
• Rotate secrets on a fixed cadence.
• Review identity proofs every six months.
• Measure mean time to detect and contain.
• Iterate on this framework during each retrospective.

Remember: Simplicity plus strong fundamentals beat heavy processes every time.

Threat Modeling

Threat modeling is a structured approach to identifying and mitigating security threats to a system. It involves understanding potential threats, vulnerabilities, and attack vectors, and developing strategies to mitigate them.

Create and Maintain Threat Models

Creating and maintaining threat models help identify potential security risks and develop mitigation strategies to protect the project.

Steps to Create a Threat Model

1. Define the Scope

   • Identify the contract, system, application, or component to be analyzed.
   • Determine the boundaries and interfaces of the it.

2. Identify Assets

   • List all critical assets that need protection, such as funds, data, credentials, and infrastructure components.
   • Prioritize assets based on their importance and sensitivity.

3. Identify Threats

   • Use frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to identify potential threats.
   • Consider various attack vectors and threat actors that could target the system.

4. Identify Vulnerabilities

   • Analyze the system for potential vulnerabilities that could be exploited by threats.
   • Use vulnerability databases, past incident reports, and security assessments to identify common weaknesses.

5. Create Attack Scenarios

   • Develop detailed attack scenarios that describe how threats could exploit vulnerabilities to compromise assets.
   • Use diagrams and flowcharts to visualize the attack paths.

6. Evaluate and Prioritize Risks

   • Assess the likelihood and impact of each identified threat.
   • Prioritize risks based on their potential impact on the system and organization.

7. Develop Mitigation Strategies

   • Identify and implement controls to mitigate the identified risks.
   • Consider technical, administrative, and physical controls to reduce the risk.

8. Document the Threat Model

   • Create detailed documentation of the threat model, including all identified threats, vulnerabilities, attack scenarios, and mitigation strategies.
   • Use templates and standardized formats to ensure consistency.

Maintaining Threat Models

1. Regular Updates

   • Update the threat model regularly to reflect changes in the system, new threats, and emerging vulnerabilities.
   • Schedule periodic reviews to ensure the model remains current.

2. Continuous Monitoring

   • Implement continuous monitoring to detect changes in the threat landscape and system environment.
   • Use automated tools to monitor for new vulnerabilities and threats.

3. Collaboration

   • Foster collaboration between development, security, and operations teams to keep the threat model up to date.
   • Encourage feedback and contributions from all stakeholders.

4. Training and Awareness

   • Provide training for team members on threat modeling concepts and techniques.
   • Raise awareness about the importance of threat modeling in maintaining security.

Tools for Threat Modeling

1. Microsoft Threat Modeling Tool

   • A free tool that helps create threat models using the STRIDE framework.
   • Pros: Easy to use, integrates with Microsoft technologies.
   • Cons: Limited to Windows platforms.

2. OWASP Threat Dragon

   • An open-source threat modeling tool for creating diagrams and identifying threats.
   • Pros: Free, web-based, supports multiple platforms.
   • Cons: Limited features compared to commercial tools.

Standard Operating Environment

Identifying and mitigating threats is a crucial part of the threat modeling process. By understanding potential threats and developing strategies to address them, projects can help protect their systems and data from security incidents.

Identifying Threats

1. Threat Enumeration

   • Use frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to systematically identify potential threats.
   • Consider various threat actors, including insiders, external attackers, and automated threats.

2. Attack Surface Analysis

   • Analyze the attack surface to identify all potential entry points for attackers.
   • Include smart contracts, wallets, external interfaces, APIs, third-party integrations, and user inputs in the analysis.

3. Adversary Modeling

   • Develop profiles of potential adversaries, including their capabilities, goals, and motivations.
   • Consider different threat actors, such as black hats and nation-state actors.

4. Historical Data

   • Review past security incidents and vulnerabilities to identify common attack patterns and weaknesses.
   • Use vulnerability databases and threat intelligence feeds to stay informed about emerging threats.

Mitigating Threats

1. Security Controls

   • Implement security controls to mitigate identified threats. These can include technical controls, administrative controls (e.g., policies, procedures), and physical controls.

2. Defense in Depth

   • Apply the principle of defense in depth by implementing multiple layers of security controls.
   • Ensure that if one control fails, additional controls are in place to provide protection.

3. Least Privilege

   • Follow the principle of least privilege by granting users and systems the minimum level of access necessary to perform their functions.
   • Regularly review and adjust access permissions to reduce the risk of privilege escalation.

4. Security by Design

   • Incorporate security into the design and development processes from the outset.
   • Use secure coding practices, perform regular code reviews, and conduct security testing throughout the development lifecycle.

5. Monitoring and Detection

   • Implement continuous monitoring to detect and respond to security incidents in real time.

6. Incident Response

   • Develop and maintain an incident response plan to quickly and effectively address security incidents.
   • Train team members on incident response procedures and conduct regular drills to ensure readiness.

Insider Threats (DPRK)

This framework serves as an entry point to understanding the organizational and personal risks related to "Insider Threats," most commonly (though not exclusively) associated with "DPRK IT Workers" - the North Korean hacker-freelancers. This framework is targeted at projects affected by insider threat actors as well as projects wanting to harden their posture against these actors.

Throughout this module, we will discuss:

• Who insider threat actors are and what they do
• How to recognize insider threat actors
• How to interact with a potential threat actor
• How to mitigate the risks and impact of insider threat actors
• How to harden your defenses against insider threat actors
• Potential consequences of insider threats for you and your organization

Table of Contents

• General Information
  • What is an insider threat? Who are DPRK IT Workers?
  • Operational structure and short history of DPRK IT Workers
  • What are the goals of DPRK IT Workers?
  • How many DPRK IT Workers are there?
  • Average DPRK IT Worker Profile
• Techniques, Tactics, and Procedures
  • How can DPRK IT Workers find a job in your company?
  • Am I Interviewing a DPRK IT Worker?
  • Did I hire a DPRK IT Worker?
  • After a DPRK IT Worker is hired by your company
• Mitigating DPRK IT Workers
  • Hardening your hiring processes
  • Hardening your organization
  • I hired a DPRK IT Worker. What now?
  • Data collection
  • Overview of risks to your organization
• Case Studies
  • Story 1
  • Story 2
  • Story 3
• Summary

Overview of risks to your organization

1. Defrauding the company: The company is paying someone whose identity they do not know.
2. Subpar operational security: DPRK IT workers share credentials among themselves in open channels, have a poor command of Git, and unintentionally or intentionally leak the access they are granted to third parties.
3. Extortion: They may try to extort more money after a job is finished.
4. Future hacking activities: They may use the knowledge gained for future hacking activities.
5. Sanctions violations: The DPRK is a sanctioned entity. No company can legally transfer funds to DPRK-related operations.
6. Contribution to the North Korean Military: DPRK IT worker salaries directly contribute to the Military Ministry of North Korea. The workers do not keep the salaries for themselves.
7. Supply-chain compromise: DPRK IT Workers may intentionally introduce vulnerabilities that impact down-stream projects that depend on your software / services (e.g. SafeWallet UI in the ByBit hack).
8. Reputational damage: To your brand and loss of trust of your users and customers.
9. Asset freeze / loss of access to financial services: your assets may be frozen or seized, and financial institutions (e.g. banks, exchanges) may terminate your access if you are suspected of funding sanctioned entities.
10. Criminal investigations: Law enforcement may investigate your involvement and impose fines or press criminal charges against your organization.

General Information

What is an insider threat? Who are DPRK IT Workers?

1. An insider threat refers to the risk posed by individuals within an organization who misuse their authorized access to compromise the organization's security. This misuse can involve malicious actions like data theft or sabotage, but also unintentional actions like negligence (e.g. ignoring security updates) or accidents (e.g. sending sensitive document to the wrong email address) leading to security breaches and/or data leaks.
2. DPRK IT workers are individuals from North Korea (the Democratic People's Republic of Korea) who engage in remote IT work for foreign companies, often using false identities. Their work, while often appearing legitimate, is a source of revenue for the North Korean regime, may be involved in malicious activities, and constitutes a serious violation of international sanctions to send payments to North Korea. "DPRK IT Workers" are synonymous with an "insider threat."
3. Read: OFAC's North Korea Information Technology Workers Advisory
4. Read: Google's advisory on DPRK IT Workers

Operational structure and short history of DPRK IT Workers

1. North Korean IT workers, operating both within the DPRK and abroad, are a significant source of revenue for the country's regime, particularly for its weapons programs. They engage in various IT roles (but are not limited to these roles!), often disguising their identity and location to secure freelance contracts and generate income that is remitted back to North Korea. These workers are primarily based in China and Russia, with some in other parts of Asia, Africa, and Latin America. North Koreans are also observed to run a network of 'facilitators' (or local accomplices) to help them cover their identities and facilitate remote employment. The facilitator lends his or hers digital and physical identity in exchange for compensation from the DPRK IT Workers.
2. Reports of North Korean IT workers operating internationally began to surface around the mid-2010s, with a growing awareness of their role in generating revenue for the regime. The number of DPRK IT workers increased, with a wider geographical spread and a diversification of their activities from the late-2010s to the present.
3. Read: Google's North Korean Cyber Structure and Alignment
4. Read: Google's advisory on DPRK IT Workers expanding scope and scale

What are the goals of DPRK IT Workers?

1. Generating stable revenue for the North Korean regime through remote IT work.
2. Building support networks for North Korean IT-related operations (mules and money laundering).
3. Gaining access to Western companies technology, infrastructure, and identities (both personal and company, digital and physical).
4. Exfiltrating company secrets (intentionally and unintentionally).
5. Extortion (ransomware and blackmail).
6. Avoiding sanctions (North Korean entities are barred from receiving any form of payment from Western countries).
7. Hacking (establishing permanent access to infrastructure in which they can gain a foothold or infiltrate).
8. Malware (infecting high-value targets for future theft).
9. Read: DPRK IT Workers pushing malicious code and stealing 1.3M
10. Read: Highlights from the UN Security Council on DPRK IT Workers

How many DPRK IT Workers are there?

The exact number is hard to estimate. DPRK IT Workers operate in separate 'cells' (different teams distributed over different locations, often without any direct contact with one another), and their organizational structure is flexible (even chaotic). Some workers focus exclusively on the blockchain space, while others are never seen applying outside of Fortune 500 companies. Estimates by different companies and government agencies vary between 2,000 and 15,000 in total. However, it's worth noting that this number includes multiple identities being re-used by the same actor or inactive accounts. We estimate that about 3-5% of all Web3 developers are North Korean, and at any given time, there are at least 200-300 DPRK-related accounts actively seeking employment in Web3 companies.

Average DPRK IT Worker Profile

In the following sections of this framework, we will discuss more advanced methods for detecting deeply nested DPRK IT Workers who may avoid the usual heuristics. However, it is still important to review the most common indicators of North Korean insider threats. If you suspect any of your contributors or have received a report regarding one, this set of questions can help you evaluate if you are dealing with a typical North Korean operative.

1. Did you meet your contributor in real life?
   1. Yes - Significantly lowers the chance that the contributor is North Korean.
   2. No - Red flag.
2. Is your contributor an Asian man in his 20s or 30s?
   1. Yes - Red flag.
   2. No - Lowers the chance that the contributor is North Korean, but they could still be a 'facilitator'.
3. Does your contributor avoid real-life meetings?
   1. Yes - Red flag.
   2. No - Even if they agree to a meeting, North Koreans will often try to postpone it indefinitely.
4. How often do you sync with your contributor, and is their video on during calls?
   1. Often, with video on - Lowers the chance that the contributor is North Korean.
   2. Rarely, or with video off - Red flag. North Koreans will try to appear 'independent' and focus only on technical output.
5. Does your contributor consistently try to recommend someone else for the job? Are those recommendations also for Asian men in their 20s or 30s?
   1. Yes - North Koreans will try to place other North Koreans in your organization.
   2. No - Lowers the chance that the contributor is North Korean.
6. Is your Asian contributor's name 'westernized' (e.g., Victor Lee, James Kano) or extremely generic/popular (e.g., Scott Brown, James Smith)?
   1. Yes - North Koreans have a tendency to use generic, pre-generated fake names.
   2. No - Lowers the chance that the contributor is North Korean.
7. Does the KYC documentation provided by your Asian contributor show an unorthodox combination of nationality and physical appearance (e.g., an Asian man living in Indonesia with a Latin American passport)?
   1. Yes - North Koreans often repurpose stolen identities to fit their fabricated backstory.
   2. No - Lowers the chance that the contributor is North Korean.
8. Does your contributor have poor English communication skills, despite claiming to live in the US?
   1. Yes - It is atypical for someone with a US passport to have poor English skills in an IT job.
   2. No - Lowers the chance that the contributor is North Korean.

We cover more detailed indicators in the section Techniques, Tactics, and Procedures

Techniques, Tactics, and Procedures

This section focuses on avoiding, discovering, and confirming the threat of DPRK IT Workers to your organization. The sections dedicated to answering the questions "Am I interviewing a DPRK IT Worker?" and "Did I hire a DPRK IT Worker?" are interchangeable and both provide strategy outlines for avoiding, discovering, and confirming DPRK-related insider threats. Your organization can use tips from these sections to identify a DPRK IT Worker before you hire them, as well as to identify them after you have made the mistake of hiring one.

This section focuses on dealing with emergent situations to identify potential DPRK IT workers who are attempting to or already have infiltrated your organization. In the next section, (Mitigating DPRK IT Workers), we will discuss strategies to harden your organization to minimize both the impact and the chances of infiltration and how to deal with the fallout of hiring a DPRK IT Worker.

How can DPRK IT Workers find a job in your company?

1. There is no single established channel through which a DPRK IT Worker can approach your company. Applying with an impressive CV and GitHub portfolio through a public channel (LinkedIn/Job Portal) is common; however, we have often observed alternative routes, such as:
   1. Direct outreach to CEO/CTO. They are persistent until clearly denied the opportunity, and even then, the actor may change their identity and try again.
   2. Initiating contact through open-source contributions. An actor will submit valid Pull Requests to your repositories and use this as a way to request a job interview.
   3. Recommendation. A worker will come recommended by another DPRK IT Worker or by a company they previously infiltrated (where the company may or may not be aware the employee is a DPRK IT Worker).
   4. Tech recruiters. Recruiters often prioritize evaluating skillsets over performing background checks. DPRK IT Workers can appear on their radar and be unwittingly pushed by a legitimate tech recruiter to your company.
   5. Bounty/Hackathon participation. DPRK IT Workers look for ANY source of revenue, no matter how small or large. If your company runs free-for-all bounty systems, it's extremely likely that some of the contributors are DPRK IT Workers.
   6. Hired through a "dev shop." If you recruit your employees through an outsourcing agency, you need to ensure their vetting process is appropriate. The outsourcing agency itself can be a victim of DPRK IT Worker infiltration.
2. The bottom line is that there is no single "safe" remote recruitment channel. You should vet your potential employees independently and look beyond their skillset, which can often be impressive. We have observed DPRK IT Workers joining companies by utilizing all the channels mentioned above. Establish a high-quality hiring process to avoid recruiting DPRK IT Workers; do not blindly rely on outsourced solutions.

Am I Interviewing a DPRK IT Worker?

1. The list below can serve as a guide for avoiding hiring a DPRK IT Worker and as an exit-interview guide for verifying if an employee is a DPRK IT Worker.
2. Before discussing the heuristics: Don't over-focus on stereotypical DPRK IT worker characteristics, such as being an Asian male in their 20s or 30s, using specific headphones, or obscuring their background. What you are looking for is evidence of misrepresentation and fraud. Job fraud is not exclusive to North Koreans - approach it as such.
3. Below is a list of 'red flags' that can help you evaluate with higher confidence if you are dealing with a DPRK IT Worker. However, always keep the above point in mind! For every 'obvious' DPRK IT Worker, there will be some who are able to evade most, if not all, of the following flags:
   1. Is their video on? If not, insist they enable their camera.
      1. Some DPRK IT Workers have no problem presenting as themselves (without a facilitator, AI, or disabled video). See if you recognize anyone from this Collection of DPRK IT Workers photos.
   2. Is the background visible or obscured? An obscured background isn't always a red flag, but it can be helpful for the final assessment.
      1. DPRK IT Workers love "stock" backgrounds. You'll often find them using the Golden Gate Bridge as a backdrop. Other times, you may notice them sitting in low-quality housing where the workspace is only divided by temporary walls or rugs.
   3. Read: Detect if it's an AI-generated face or deepfake.
   4. Start with small talk relevant to their claimed nationality and location. This is especially important if you're dealing with someone presenting as an Asian man but providing, for example, Latin American documents/names while claiming to live in Southeast Asia (an identity mismatch). Note: While a smaller number of female DPRK IT workers have been identified, they do exist. In other cases, you might encounter hired female facilitators. If the candidate claims to be in your country, offer an on-site interview. Beware, DPRK IT workers may send a stand-in. Verify that the person attending is the same one from the call.
   5. Keep an open mind about gender, nationality, and experience. DPRK IT workers are known to use facilitators from all over the world. This means you might encounter a non-Korean individual on the call who is, in fact, a DPRK IT worker. Similarly, a DPRK IT worker's portfolio can sometimes be impressive and not far off from their claimed experience. In previous instances, we've found profiles showing 2-3 years of work for reputable organizations.
   6. Go through the candidate's background. Verify the timelines of their claimed experience (e.g., "You worked at Company X from when to when?"). While the candidate answers, observe if they seem to be reading from a script. Try to mix up details from their claimed experience and note their reaction (e.g., "I see you worked at XYZ," when you know from their CV that they didn't). This is good general advice. If the candidate appears to be relying on ChatGPT for answers (reading from the screen), it's a red flag.
   7. Conduct a language comprehension test. If the candidate claims to be Japanese, ask them questions in Japanese. Beware, some DPRK IT workers can speak Japanese or Chinese, though their proficiency is often similar to their English skills (A1/A2 level). See: North Korean failing to answer questions in Japanese despite claiming to be Japanese
   8. Ask if the candidate is at home or a co-working space.
      1. Look for movement in the background.
      2. If they claim to be at home, you can try a quick KYC check: ask them to show their ID card next to their face.
   9. Carefully observe the candidate's screen presentation if they share their screen. Often, you might notice different GitHub, Gmail, or other social network profiles active on their screen than those claimed in their CV. It's best not to give the candidate a chance to prepare for this. Casually ask, "Could you walk us through your best code on GitHub by sharing your screen?"
   10. Evaluating a potential DPRK IT Worker's GitHub profile:
       1. The account creation date is later than the commits in its hosted repositories (an artificially aged account). This is especially suspicious if many repositories follow this pattern and the user claims experience aligning with the age of these manipulated commits. This can be a false positive but is usually easy to clear up. Some users re-upload their old code, pre-dating the GitHub account creation date. A false positive for this particular flag can be deduced from the overall quality of the account.
       2. A high number of followers and accounts followed (e.g., over 200). If the user is a popular developer with a significant online presence, this isn't a red flag. False positives can occur for accounts that automatically follow back or for Developer Relations (DevRel) and recruitment professionals.
       3. A high number of contributors to the user's repositories. If the user is not a popular developer, this is a red flag. Regular developers typically won't have 100+ contributors to their repositories without a significant online presence. This flag has a tendency to be polluted with high numbers of contributors on "copied" repositories, where a DPRK IT Worker has "injected" themselves as an author but has also kept the original contributors' usernames.
       4. Quality of opened Pull Requests and Issues. It's useful to retrieve the full history of Pull Requests and Issues opened by the user and review them for quality. For advanced DPRK IT workers, these may not differ significantly from those of regular developers. Additionally, if a suspicious user was @pinged in a PR or Issue, it might help uncover a previous nickname. Look for automated or spam-like text/code. DPRK IT Workers will often go for "quantity" over "quality." At the same time, some DPRK IT Workers will be authors of perfectly valid Pull Requests and Issues - an artifact of their previous employment or a better credibility-building effort.
       5. Overly informative (full of images and stats) GitHub profile README/About page.
          1. This can be a false positive. Regular developers have been observed to overuse this section.
       6. Avatars.
          1. DPRK IT workers often use AI-generated images (not necessarily faces) as their avatars. They typically use freely accessible models like Stable Diffusion or Midjourney.
          2. "Cartoonish" avatars are also popular: CGI-style images of fictional characters, Minion avatars, and NFT-related avatars (especially Pengu and Doodles).
          3. Having no avatar at all is also common.
          4. Reference: Identifying Suspicious Github Accountsl
       7. Social media links.
          1. In many cases, there will be a Twitter link. It's always worth visiting.
             1. Check the "Media" page for images uploaded by the account owner. Can you find any pictures from conferences or showing their physical appearance? DPRK IT workers usually will not post pictures from physical locations. The exception to this rule would be "facilitator" or "purchased/stolen" accounts.
             2. Look for job-begging tweets.
             3. References:
                1. Nick Franklin Case - A well developed IT Worker persona
                2. Nick Franklin Case - Acivity across different platforms
       8. Suspicious interactions.
          1. Contributions to low-quality external repositories and/or organizations. DPRK IT workers are known to set up "fake" organizations on GitHub, often populated by other IT workers. Similarly, DPRK IT workers will cross-commit to each other's repositories. It's worth checking the profiles of contributors to the potential threat actor's repositories: are these contributors legitimate themselves? A full data dump of the GitHub account may be useful, but cherry-picking a few repositories from the profile is often effective enough for a first pass.
             1. Reference: A counter example - Good looking IT Worker Github Profiles
       9. Repositories.
          1. "Copied repositories." DPRK IT workers will try to boost their credibility by pushing a clone of a legitimate repository to their own account (Google: "How to fake Github history"). They will often edit the .git config and insert their own account data. Usually, they won't remove all original contributors but will insert themselves among them. Use GitHub's search feature to find the original repository by name, commit SHA, or a unique string extracted from within the repository. Compare the actual account creation date with the profile's UI-displayed history: is it consistent, or is the account's creation date more recent than the years of activity displayed? A simple API query to get the account creation date from GitHub may be necessary here.
          2. GitHub's Activity Badge for contributing to an organization. Verify if it's an actual contribution like a PR or commit or just a spam Issue/Comment/PR. This is an often-utilized method for highly popular repositories (e.g., OpenZeppelin, Paradigm) where core developers are reluctant to merge spam PRs.
             1. Reference: DPRK IT Workers faking Github Activity Badges
   11. Evaluating other immediately available data points:
       1. Full Name.
          1. Even if a full name is "fake," it can still be a useful data point. DPRK IT workers rotate their identities, but they need to maintain them for at least some time. Another challenge they face is managing multiple personas; you may catch an "identity confusion" where a DPRK IT worker uses different names in different places, for example, a different name used/mentioned on GitHub than on a call or on other social profiles. It's also possible to notice different names used with the same (or different) GitHub owner's email addresses.
             1. Take extra care with Asian names, especially Chinese names. Chinese citizens often westernize or shorten their full names in various ways. This doesn't necessarily mean they are malicious.
          2. In most cases, DPRK IT workers prefer to use Asian (Japanese, Chinese, Korean) names. However, they are also known to use fake names from all around the world, corresponding to where their "facilitators" are based. This includes American names ("James" being an extremely popular choice) and even European names (e.g., Polish, Ukrainian, Hungarian).
             1. DPRK IT workers may have access to KYC documents issued for their claimed nationality. You should be alarmed by highly unorthodox combinations, such as an Asian man living in Indonesia with Argentinian KYC documents.
       2. Location.
          1. Japan and the USA are extremely popular choices for claimed locations. Additionally, Southeast Asian countries like Thailand, Malaysia, Singapore, or Taiwan are also common. The actual physical location is commonly the DPRK (Pyongyang, border regions), China (border regions), Eastern Russia (Vladivostok), Laos (Vientiane), Indonesia, Vietnam, and parts of Africa. It's possible to obtain the IP address of a potential DPRK IT worker through a DocuSign document that collects HTTP headers. DPRK IT workers are known to utilize "laptop farms," meaning they can hide their IP behind an actual fixed/landline IP address in their claimed country of residence.
       3. OSINT analysis.
          1. We recommend checking each suspicious email address with a service like https://epieos.com. It can provide additional data points, such as a LinkedIn profile, which can uncover further identity mismatches.
             1. On LinkedIn, examine the strength of the actor's connection network.

Did I hire a DPRK IT Worker?

1. The list below serves as a guide for confirming your suspicions if one of your employees is a potential DPRK IT Worker. We're focusing on using non-enterprise flags accessible to even the smallest of projects. The assumption is that your project has limited EDR/SIEM logging infrastructure (you should, however, consider implementing some monitoring infrastructure in the future).
   1. If your organization has EDR/SIEM capability, Read: DTEX advisory on DPRK Insider Threat Kill Chain
   2. Consider using GitHub Enterprise for your organization to have access to more detailed logs.
2. Before discussing the heuristics: Don't focus on negating your suspicion; focus on clearing it up. It doesn't matter if you're checking a long-time employee who provides good technical output, is not Korean/Asian, logs into the workspace using a US-based IP, or came recommended. DPRK IT Workers have been known to successfully evade detection for YEARS. Focus on creating a full profile of your employee and judge it based on the complete picture and any inconsistencies you find.
3. Below is a list of 'red flags' that should prompt immediate action from your side (e.g. a deep background check):
   1. Avoiding real-life meetings. Even if they initially agree to meet, they might come up with explanations as to why they can't. They often cite 'family reasons' or 'travel abroad.' The situation can repeat itself for every single meeting proposal, regardless of the location. You can propose to meet at their location as a final test.
   2. Inconsistencies in work and communication. It's often the case that a single DPRK IT Worker account is operated by a few individuals, especially if your company communication is sparse. One week you may observe good quality and high output; the next week, a significant drop. Similarly, for communication, you may observe the worker being overly 'mute' on all company sync calls or clueless as to what was discussed in previous meetings. They will also often have issues communicating about their code but not with the code development itself (a sign of more than one worker on a single account).
   3. Timezone. If your worker claims to be in Texas (GMT-5) but is located in Pyongyang (GMT+9), you may observe work patterns closer to North Korean time than to Texan time. Note that DPRK IT Workers work around the clock and can circumvent this flag easily.
   4. Bogus work history. Verify if the job history claimed on their CV is real. You can always reach out to the previous company for background information. In most cases, the history will be made up, but there are exceptions. DPRK IT Workers may list legitimate companies for which they did previous work but were let go (without that company's knowledge of their true nature). Sometimes, DPRK IT Workers will list organizations they control, so exercise caution when contacting anyone for background information.
   5. Identity switch. Be on guard if an employee's profile suddenly changes its nickname/identity. DPRK IT Workers do this often, usually when discovered in one of their previous jobs and for fear that someone will notify your company. They may suddenly start using a different GitHub handle (this includes suddenly pushing a Pull Request using a different account than usual), delete their social media accounts, or get banned from LinkedIn. Additionally, they may occasionally 'confuse' their fake identities and log in to your company workspace or a meeting using a completely different account.
   6. Identity mismatch. It should raise questions if your employee is Asian but provides non-Asian KYC documentation along with poor language skills. Run a background check on all the data. Can you find a person with the same name whose identity was potentially stolen or borrowed? Is the address provided legitimate, or does it seem 'random' (e.g., an empty house, a business venue)? Google "(Full Name of your worker) + sentenced" to see if the DPRK IT Worker bought a criminal's identity (an often-seen case with claimed US-based personas). Perform a reverse image search on your worker's profile pictures/avatars. Are there more similar accounts using the exact same image? Beware that DPRK IT Workers have no issues providing credible-looking KYC documentation; some of these documents even pass authentication checks on specialized services.
   7. Recommending other suspicious accounts for work. DPRK IT Workers will leverage their initial foothold in your organization to propose other DPRK IT Workers for a job. Their recommendations will usually follow the same patterns. Many organizations fall for it and hire multiple workers (sometimes, as much as 50-70% of the entire company is composed of DPRK IT Workers if such tactics succeed). Additionally, check if the potential DPRK IT Worker hasn't already added some of their 'friends' to your organization without your knowledge.
   8. Proximity to other suspicious/spam accounts. Don't be fooled by GitHub or Twitter accounts that are over 10 years old. DPRK IT Workers can easily source these. However, check if your worker has any meaningful history of interaction with their followers/following. Or, do all accounts in proximity to your worker appear spam-like or like bots?
   9. Poor social skills. It's usually (but not always) the case that a DPRK IT Worker will have trouble with 'small talk.' This isn't necessarily because of cultural differences (DPRK IT Workers are educated on Western culture and language as part of their job). It's often because of the sheer volume of remote gigs they handle and how confusing it can be. A DPRK IT Worker will prefer to always steer the conversation toward technical details.
   10. Review Workspace logs (IP addresses). Check if the IP addresses used to log in to your infrastructure are coming from the same location as claimed by the worker. VPNs, proxies, or Russian ISPs are red flags, as are highly inconsistent IP ranges (a mix of the sources mentioned). Beware that DPRK IT Workers are known to utilize "Laptop Farms." Read: North Korea Infiltrates U.S. Remote Jobs - With the Help of Everyday Americans
   11. Payments. North Koreans can organize a 'drop' bank account to receive wire transfers; however, their preferred method of receiving a salary will be through cryptocurrency, usually at a flat rate that they will not try to negotiate. In most cases, DPRK IT Workers will work at a discount to industry standards without complaining (25-50% discount). It may be the case that the worker's CEX account gets frozen, and they will come back to your organization for help unfreezing it (by providing proof of employment).

After a DPRK IT Worker is hired by your company:

1. The main goal of a DPRK IT Worker is to keep their job and salary coming for as long as possible. It's worth understanding that DPRK IT Workers themselves vary in quality. For more 'senior' workers, keeping the job will be easy as their output and technical skills are high. For 'junior' ones, the engagement may end on the basis of poor performance.
   1. We have observed cases where DPRK IT Workers are fine with taking a salary cut to help a project stay afloat, as long as they continue to be paid.
2. The highest risk to your organization, which occurs immediately after you on-board the DPRK IT Worker, is a data and secrets leak. DPRK IT Workers do not care about your organization's and their operational security. When you assign access to a single DPRK IT Worker, you can be sure more individuals are using the same access. Unbeknownst to you, everything that's private to this single worker is now accessible over a (usually) poorly secured internal DPRK IT Worker network.
3. We have observed DPRK IT Workers passing access or sensitive information to DPRK Hacking teams. This is not often the case, as the goal of the DPRK IT Worker is to keep their job and salary as opposed to a one-time hack. However, if the target is high-value, they won't hesitate or may not even have a say in whether or not their employer is targeted for a hack.
4. Some DPRK IT Workers also perform tasks adjacent to malicious campaigns like the "Contagious Interview." Read: North Korean Threat Actors lure tech job seekers as fake recruiters and Two Campaigns by North Korea Bad Actors target job hunters. Your North Korean employee may leverage the credibility granted by being employed at your company to conduct malware-related campaigns in the present and future. This could significantly affect your brand.
5. A DPRK IT Worker will try to escalate their access if possible, whether by adding new members (who will also be getting paid) or by getting permissions to release builds and packages. Additionally, we have encountered situations where DPRK IT Workers were added as signers to the multisig wallets of the entire project as part of the dev team!
6. DPRK IT Workers won't report code vulnerabilities to you and may leave them for future exploitation. First, they generally do not care about and are not invested in the success of your project to protect it from being hacked. Second, they may intentionally leave the backdoor with the intent to use it in the future. Lastly, they may simply miss the vulnerability because they are overworked across numerous remote gigs they're performing at once.

In the next section Mitigating DPRK IT Workers we will be discussing ways to harden your organization and employees against the DPRK IT Worker threat.

Mitigating DPRK IT Workers

This section discusses ways you can harden your organization against DPRK IT Workers, both before and after a potential hiring. All of the strategies covered in the prior section, Techniques, Tactics, and Procedures, still apply but serve a more 'active' role to identify DPRK IT Workers during recruiting or within your organization. Here, we will discuss mitigation strategies that limit the effects of a DPRK IT Worker infiltration and what you should do after identifying a successful infiltration.

Hardening your hiring processes

1. Apply all the steps from the sections Am I Interviewing a DPRK IT Worker? and Did I hire a DPRK IT Worker?. It's important to educate all of your non-DPRK employees on these points, especially people responsible for hiring, developer relations, talent hunting, and community management.
2. Introduce a culture of background checks. Do not take a prospective developer's claims at face value. Even the most basic OSINT check can often discover deep inconsistencies. Check GitHub commit history, check Twitter history, and Google the full name of the developer.
   1. Is the work experience claimed in the CV reflected on GitHub?
   2. Does the potential employee indicate any physical presence anywhere?
   3. Is the potential employee writing non-AI-generated posts and replying to anything other than job offers on Twitter?
   4. Did you find any name collisions after searching for the potential employee's name in Google?
   5. Did you check the potential employee's nickname in Google? Maybe they have already appeared as a threat actor in a past report?
   6. Remember the best discovery rule: You're looking for misrepresentations, mismatches, and obfuscation, not for North Koreans specifically. Tick your boxes on the first three and only then proceed to decide if you're potentially dealing with a North Korean.
3. Do not try to undercut developer market salaries. DPRK IT Workers will always accept low-ball offers without much hesitation. If you're looking for a cheap hire, you are at a higher chance of hiring a DPRK IT Worker.
4. ALWAYS perform your own due diligence on new remote employees. Do not settle for recommendations from third parties; they could be victims themselves.
5. You could ask about North Korea on call and observe the reaction. There's a so-called "F**k Kim Jong Un" test, where interviewer is asking to repeat the phrase and North Koreans are banned from saying it and they drop the call immediately. Obviously, it won't be effective for 'facilitators' but it will most likely be effective for North Koreans themselves. Do not rely on it as a panacea.
6. Regardless of our tips of not focusing on "Asian man in his 20-30s" that particular appearance is still the most common (If not cloaked under the generative AI). Similarly, Korean-English accents.

Hardening your organization

1. Define and implement tight access control rules for all of your employees, especially remote ones. Avoid giving privileged access to workers who did not pass 100% of the tests and filtering criteria for DPRK IT Workers (all the points already discussed). Specific examples of privileged access include:
   1. Do not give admin permissions to your GitHub organization and repositories, including for build releases, adding members, and repository settings.
   2. Do not give publishing permissions on any package managers. The publishers of your packages are a critical supply chain risk; they need to be 100% vetted.
   3. Do not add your remote employees as multisignature wallet signers. The signer role should be reserved only for high-trust individuals, not based on the dedication of the developer you are working with.
   4. Do not give unlimited access to cloud instances. Scope permissions to the minimal access required for each individual or team, including setting minimal expiration times for access tokens (e.g. access tokens should expire within hours, not weeks).
2. Define a lead developer - a highly trusted individual you've met in real life and are sure of their background - as the code reviewer, publisher, signer, and image builder. This individual's role should be to double-check all of the remote workers' work and actions within your organization at all times. Make sure the lead developer is not a DPRK IT Worker.
3. Silo your remote workers from the most critical infrastructure. If you choose to provision access to such infrastructure, always create a threat model to understand the 'worst-case' scenario and potential mitigation approaches.
4. Monitor your logs for IP addresses, user sessions, and timestamped access. Monitor your remote contributors' actions for any sudden changes (identity changes) and potential secrets leaks through their private accounts. You can obtain such information from Google, Slack or Github Workspaces, depending on your organization setup and tiers.
5. DO NOT allow hired contributors to use throwaway Github accounts for the work at your company! It's part of the DPRK IT Worker tactics to save their main accounts from being discovered.
6. If your project allows, it may be beneficial to establish a public codebase on GitHub and have your remote workers make at least some public contributions related to your project. If all of your codebase is supposed to stay private, at least list all of the contributors (CODEOWNERS) in a special repository created only for such purpose. Security researchers like SEAL911 scan such public codebases and will notify you privately if they suspect DPRK IT Workers are contributing to your project.

I hired a DPRK IT Worker. What now?

1. Contact security professionals if you're unable to handle the situation alone. You can reach out to SEAL911 (@seal_911_bot on Telegram).
2. You do not need to end the engagement abruptly. It's important to maintain a facade while you deal with access revocation and mitigate any immediate risks to your organization. Act normally, but start preparing an actionable plan immediately and aim to remove the DPRK IT Worker within the next few days at most. If your organization is properly siloed from insider threats, you shouldn't have much of an issue firing the worker almost immediately after conducting a post-mortem review.
3. Check if you did not hire more than one DPRK IT Worker. In the majority of cases, we find more DPRK IT Workers within the same organization. They do not always come as a recommendation from an already-discovered DPRK IT Worker; they simply already know how to abuse your hiring process.
4. At the same time, you should immediately cease any further payments to the DPRK IT Worker. It's illegal. You can cite temporary financial issues as the reason for the delay if confronted by the worker and you still need a bit of time to deal with the situation.
5. List all infrastructure endpoints the DPRK IT Worker had access to, both sensitive and not. Useful, for the next steps.
6. Review the current and past work of the accounts in question. The code does not necessarily need to be malicious, but it can be of overall poor quality. Pay extra attention to added dependencies or edited CI/CD files.
7. Review the permissions that these actors have or had in your organization. Revoke them.
8. Review all of the files and links previously provided by the DPRK IT Worker and who opened them. The issue may extend beyond your technical workers. Look back to see if you did not potentially run malware-infested code or give them remote desktop access to your or your developers' machines.
9. Set up a final confirmation call after all access is revoked and you are certain your organization is safe from any insider threats. Attempt to perform KYC under some pretense. Do not settle for document scans, as these are easily obtainable. Insist on a "video call" KYC, where the actor must show the physical document they previously provided next to their face.
10. Attempt to geolocate them. Send a document that tracks the IP address used to open it. Look for VPN usage or IP addresses in the DPRK/Eastern Russian range.
11. Collect all on-chain/payroll data on funds transferred to the actor. If an actor is confirmed as DPRK-related, you will be required to file a Suspicious Activity Report (SAR). We would appreciate you sharing this data with SEAL911 later for public security reasons and future investigations. The data will remain private.
12. You do not need to inform the DPRK IT Worker about the actual reasons for termination. You can cite downsizing, poor performance, lack of cultural fit, or any other reason.
13. In the post-mortem phase, you will need to halt all development on the affected infrastructure. For companies that hired a DPRK IT Worker as a "Core Engineer," this may sometimes mean several weeks of re-auditing all code and infrastructure. You should stop and do it. At the same time, build a threat model to prevent the situation from recurring and to limit its effects if it does happen again. You can remove the DPRK IT Worker's code from your codebase. DPRK IT Workers will claim this code as part of their work experience in their future job searches. The decision is ultimately yours. While not removing the code helps security researchers like those at SEAL911 track these workers, our recommendation is to remove it to protect your project and deny adding credibility to DPRK IT Worker.

Data collection

1. You should collect the following data before firing the DPRK IT Worker. This data will help organizations like SEAL with future mitigation and the discovery of other actors.
   1. Full Legal Name
   2. Phone
   3. Email(s)
   4. Location (City/State)
   5. LinkedIn
   6. Telegram/Discord
   7. GitHub
   8. Copy of Resume
   9. Date Hired
   10. Sourcing (Where were they hired from? Telegram, Staffing, Recruiter, etc.)
   11. Company Email (Yes/No)
   12. IP addresses (from email or any other sources at your disposal)
   13. Managed Laptop (Yes/No)
       1. Shipment address (for the laptop or other items)
   14. KYC data (ID/Passport/Bills document scans)
   15. Photos/Screenshots (physical appearance, potentially from a video call)
   16. Payment data (Extremely important!)
       1. On-chain addresses provided for payment
       2. Bank data
   17. Did they refer anyone else?
   18. Were they referred by someone else?

Overview of risks to your organization

1. Defrauding the company: The company is paying someone whose identity they do not know.
2. Subpar operational security: DPRK IT workers share credentials among themselves in open channels, have a poor command of Git, and unintentionally or intentionally leak the access they are granted to third parties.
3. Extortion: They may try to extort more money after a job is finished.
4. Future hacking activities: They may use the knowledge gained for future hacking activities.
5. Sanctions violations: The DPRK is a sanctioned entity. No company can legally transfer funds to DPRK-related operations.
6. Contribution to the North Korean Military: DPRK IT worker salaries directly contribute to the Military Ministry of North Korea. The workers do not keep the salaries for themselves.

Case Studies

Here are a few deviations from the usual DPRK IT Worker patterns. As mentioned a few times already, the goal is to always be open-minded about threat actor tactics. They are known to evolve and adapt while also pushing their methods further. The examples below are anonymized, but they are real cases we have encountered in the past:

Story 1

Background: A GitHub profile created in 2013, with no flagged "copied repositories" (indicating original code), an active and verified Twitter account from 2012, and no history of nickname changes on any platform. The user claimed to be Japanese, which was reflected in his posts and 10+ years of digital activity. The nicknames were "relevant" to Web3/Blockchain (e.g., using a "0x" prefix or "sol" in the name). A Rust developer with experience in Solana was looking to get hired by a Solana project.

Conclusion: This was a DPRK IT Worker, confirmed by independent sources who had also been "spammed" by the same actor. The most likely reason for avoiding most software flags was a "stolen" account. DPRK operatives managed to get their hands on the GitHub and Twitter handles of a Japanese citizen, which had been lying dormant without ANY activity for 10+ years. They then proceeded to build a history on these accounts for almost two years before starting to apply for jobs and messaging other developers. It's worth noting that no event history was present for this GitHub account, as the original owner had never used it after signing up. This allowed them to build a "perfect" dummy history with no event data present in the GitHub Archive. This absence of data, along with a significant gap in Twitter activity between 2013 and 2022, contributed to flagging this particular actor.

Story 2

Background: An actor who had worked for three years at a popular security company. (An example of a perfect backstory for future employment.) The actor was usually delegated auxiliary tasks, which he completed diligently and on time. He was reluctant to accept promotions or on-site invitations, citing his own business as the reason. The company was fine with this, as he was an auxiliary worker. His GitHub profile was created in 2021 and had a single, yet consistent, name change. The actor used his GitHub account only for work at that company and did not maintain any social media profiles. There was no overly informative README/About page, no avatar, and he consistently used a single Gmail address.

Conclusion: This was a DPRK IT Worker. By cross-referencing our existing database and performing an extremely deep analysis of commits from actors we suspected were connected to him, we finally found his old nickname associated with two commits to an already known -but old and inactive - account of a known DPRK IT Worker. Confirmation was only possible through a video call with the company's participation. (On-call KYC and a few other tactics were used; the threat actor decided to abandon the call and delete his profiles.)

Story 3

Background: An actor with a consistent identity across all relevant platforms (GitHub, Twitter, LinkedIn). He was referred by a legitimate company and had already been working with the affected company for a year. He claimed to be based in Canada (using an IP from a Laptop Farm), spoke good English, performed his tasks diligently and on time (the company claimed he was selected as a top candidate), had no issues with video calls, and used his own physical appearance (no Gen-AI).

Conclusion: This was a DPRK IT Worker. We scanned contributors to a few of his repositories and found that all of them were high-confidence DPRK IT Workers. From their profiles, we managed to pinpoint a history of identity rotations (changes in legal names). The final confirmation was only possible with the company's participation. The actor was "cut off" from access to company infrastructure and given the pretext of a potential breach the company suspected. This gave them a reason to perform additional KYC - "to make sure the (suspected) dev account is not compromised." The actor was asked to go outside his claimed location and take a "selfie" in front of the house where he supposedly lived. He refused and resigned immediately, blocking all accounts.

Summary

• Who are DPRK IT Workers? They are North Korean individuals, often operating from abroad (primarily China and Russia), who use fraudulent identities to secure remote IT jobs. Their primary goal is to generate revenue for the North Korean regime, which may involve legitimate work but also opens the door to espionage, data theft, extortion, and future hacking activities.
• How to Spot DPRK IT Workers During Hiring:
  • Focus on detecting fraud and misrepresentation, not stereotypes. Look for inconsistencies across their CV, digital profiles, and interview answers.
  • During video interviews, insist the camera is on. Watch for AI-generated faces, obscured or generic backgrounds, and an inability to answer small-talk questions related to their claimed location or nationality.
  • Scrutinize their GitHub profile for red flags like a recent account creation date with years of "faked" commit history, "copied" repositories from legitimate projects, spam-like contributions, or interactions with other suspicious accounts.
  • Check their social media (LinkedIn, Twitter) for a lack of personal photos, a history of job-begging posts, and no evidence of a physical presence at conferences or events.
  • Be wary of highly unorthodox identity combinations, such as an Asian individual living in one country while providing KYC documents from a completely different continent.
• How to Verify an Existing Employee:
  • Watch for behavioral patterns like consistently avoiding in-person meetings with repeated excuses or work patterns that don't match their claimed time zone.
  • Audit workspace logs for suspicious IP addresses (VPNs, proxies, known sanctioned regions).
  • Be on high alert if an employee suddenly changes their name or GitHub handle, or deletes social media accounts, as this often happens after being discovered elsewhere.
  • Verify their claimed work history independently. Be cautious if they recommend other candidates, as they often leverage their position to bring in more DPRK operatives.
• How to Harden Your Organization:
  • Implement a "least privilege" principle for access control. New and remote employees should not have admin rights, permission to publish packages, or be signers on multisig wallets.
  • Appoint a trusted, fully-vetted individual to review all code and actions from remote contributors before they are merged or deployed.
  • Perform your own due diligence on all remote hires. Do not rely solely on third-party recruiters or recommendations, as they can also be victims.
  • Avoid the temptation to hire based on the lowest salary offer, as DPRK IT workers often work at a significant discount.
• What to Do After Discovering a DPRK IT Worker:
  • Do not fire them immediately. Maintain a normal appearance to avoid tipping them off while you secure your organization.
  • Immediately stop all payments, as funding them is a sanctions violation. If confronted, use a pretext like "financial issues" to buy time.
  • Systematically revoke all access to code repositories, cloud infrastructure, and internal systems. At the same time, collect all available data (KYC docs, crypto addresses, emails, resumes) for reporting.
  • Conduct a full security audit of all their code contributions, paying close attention to dependencies, build files (CI/CD), and potential backdoors.
  • Once your systems are secure, terminate their contract using a business-related reason (e.g., downsizing, change in direction) and report the incident to law enforcement.

Governance

Good governance practices involve setting clear policies, establishing accountability, and continuously monitoring and improving security measures. This section provides some best practices and guidelines for how you could implement governance in your project.

Contents

1. Compliance with Regulatory Requirements
2. Risk Management
3. Security Metrics and KPIs

Compliance with Regulatory Requirements

Compliance with regulatory requirements may be essential for your project. Understanding the needs and ensuring the necessary compliance helps protect your project from potential legal penalties.

Key Regulatory Frameworks

Some examples of regulatory frameworks or standards for web3 are:

• GDPR (General Data Protection Regulation): Applies to organizations handling the personal data of EU citizens. It mandates strict data protection measures and grants individuals significant rights over their data, as soon on https://gdpr.eu/.
• MiCA: Companies seeking to offer crypto services or assets within the EU are in scope. While this may seem daunting, there are different levels of compliance needed depending on the project, as can be seen on https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica

Best Practices for Compliance

Best Practices for Regulatory Compliance in Terms of Security

1. Understand Applicable Regulations

• Identify Relevant Regulations: Clearly identify all regulatory frameworks that apply to your organization, such as GDPR, HIPAA, CCPA, or PCI DSS.
• Regularly Review Legal Requirements: Stay updated on changes in regulations that impact your industry, ensuring compliance measures evolve accordingly.
• Engage Legal Counsel: Work with legal experts to interpret regulations accurately and implement appropriate security controls.

2. Develop a Robust Security Policy Framework

• Comprehensive Security Policies: Develop detailed security policies that align with regulatory requirements, covering areas like data protection, access control, and incident response.
• Policy Documentation: Maintain thorough documentation of all security policies, procedures, and controls, ensuring they are easily accessible for audits and reviews.
• Regular Policy Updates: Review and update security policies regularly to reflect changes in regulations and emerging threats.

3. Data Protection and Privacy

• Data Classification: Classify data based on sensitivity and regulatory requirements, ensuring appropriate protection levels for each category.
• Data Minimization: Collect and retain only the minimum amount of data necessary for business operations, reducing exposure to potential breaches.
• Anonymization and Pseudonymization: Where possible, apply anonymization or pseudonymization techniques to protect personal data.

4. Access Management and Control

• Role-Based Access Control (RBAC): Implement RBAC to ensure that employees have access only to the data and systems necessary for their roles.
• Multi-Factor Authentication (MFA): Require MFA for access to sensitive systems and data, adding an extra layer of security.
• Regular Access Audits: Conduct regular audits of user access rights to ensure compliance with the principle of least privilege.

5. Incident Response Planning

• Comprehensive Incident Response Plan: Develop an incident response plan that aligns with regulatory requirements, detailing steps for identifying, responding to, and reporting security incidents.
• Regulatory Reporting: Ensure the incident response plan includes protocols for reporting breaches to regulatory authorities within the required timeframes.
• Regular Testing: Conduct regular simulations and tabletop exercises to test the effectiveness of the incident response plan.

6. Continuous Monitoring and Auditing

• Automated Monitoring Tools: Implement automated tools to continuously monitor compliance with security regulations and detect potential vulnerabilities or breaches.
• Internal Audits: Conduct regular internal audits to assess compliance with security policies and regulatory requirements.
• External Audits: Engage third-party auditors to provide independent assessments of your security posture and compliance status.

7. Employee Training and Awareness

• Regular Training Programs: Provide regular training on regulatory requirements, data protection, and security best practices for all employees.
• Phishing and Social Engineering Awareness: Educate employees about phishing, social engineering, and other common attack vectors that could lead to compliance breaches.
• Role-Specific Training: Tailor training programs to address the specific regulatory and security responsibilities of different roles within the organization.

8. Third-Party Risk Management

• Vendor Due Diligence: Conduct thorough due diligence on third-party vendors to ensure they comply with relevant security regulations.
• Contractual Obligations: Include specific security and compliance requirements in contracts with third-party vendors.
• Continuous Monitoring: Monitor third-party vendors’ compliance with security requirements throughout the relationship.

9. Data Encryption and Secure Communication

• Encryption Standards: Use strong encryption standards for protecting data both at rest and in transit, in line with regulatory requirements.
• Secure Communication Channels: Ensure that all communication involving sensitive data is conducted over secure channels (e.g., TLS, VPN).
• Key Management: Implement robust key management practices to protect encryption keys from unauthorized access.

10. Documentation and Record-Keeping

• Compliance Documentation: Maintain detailed records of compliance efforts, including audit results, incident reports, and training logs.
• Retention Policies: Establish data retention policies that comply with regulatory requirements, ensuring that records are kept for the required duration.
• Audit Trails: Ensure that all access to sensitive data is logged, creating a clear audit trail for compliance verification.

Useful Resources

Here are some useful resources where you can follow and learn more about the best practices mentioned:

1. National Institute of Standards and Technology (NIST)

   • NIST Cybersecurity Framework: A comprehensive resource for implementing cybersecurity best practices and complying with regulatory requirements.
   • URL: https://www.nist.gov/cyberframework

2. International Organization for Standardization (ISO)

   • ISO/IEC 27001 Information Security Management: The leading international standard for information security management, providing guidelines for establishing, implementing, and maintaining an effective security program.
   • URL: https://www.iso.org/isoiec-27001-information-security.html

3. Center for Internet Security (CIS)

   • CIS Controls: A prioritized set of actions that help organizations comply with regulatory requirements and improve their cybersecurity posture.
   • URL: https://www.cisecurity.org/controls/

4. General Data Protection Regulation (GDPR)

   • Official GDPR Portal: Provides detailed information on GDPR requirements, including guidelines, tools, and resources for compliance.
   • URL: https://gdpr.eu/

5. Health Insurance Portability and Accountability Act (HIPAA)

   • HIPAA Journal: Offers news, resources, and guidelines for ensuring compliance with HIPAA regulations, particularly in the healthcare sector.
   • URL: https://www.hipaajournal.com/

6. Payment Card Industry Data Security Standard (PCI DSS)

   • Official PCI Security Standards Council: Provides comprehensive resources, including guidelines and tools for complying with PCI DSS requirements.
   • URL: https://www.pcisecuritystandards.org/

7. Cybersecurity & Infrastructure Security Agency (CISA)

   • CISA Best Practices: Offers guidelines and resources for improving cybersecurity, including incident response planning and third-party risk management.
   • URL: https://www.cisa.gov/publication/best-practices

8. Cloud Security Alliance (CSA)

   • CSA Security Guidance for Cloud Computing: Provides best practices and guidance for ensuring compliance and security in cloud environments.
   • URL: https://cloudsecurityalliance.org/artifacts/security-guidance-v4/

9. International Association of Privacy Professionals (IAPP)

   • IAPP Resource Center: Offers a wealth of resources, including whitepapers, research, and tools, to help organizations comply with data protection regulations.
   • URL: https://iapp.org/resources/

10. SANS Institute

• SANS Security Resources: Provides extensive resources, including guides, whitepapers, and training courses, for improving security and regulatory compliance.
• URL: https://www.sans.org/security-resources/

Risk Management

If a project has effective risk management, it is also likely to be successful at identifying, assessing, and mitigating potential threats to the project. By utilizing risk management, you're likely to be able to prioritize security efforts and see where resources are needed. Risk management provides the capabilities to develop and implement strategies to mitigate identified risks by continuously monitoring the security landscape for new threats and vulnerabilities and then communicating risk findings and mitigation strategies to relevant people.

Best Practices for Risk Management

1. Use established frameworks such as NIST, ISO 27001, or COBIT to help start your risk management efforts.
2. Focus on the most critical risks first, using a risk matrix to prioritize based on likelihood and impact.
3. Conduct regular risk assessments and reviews to keep up with the so very evolving threat landscape.
4. Use lessons learned from past incidents and risk assessments to continuously improve your risk management practices.

Security Metrics and KPIs

Measuring security performance through metrics and Key Performance Indicators (KPIs) can be very useful for assessing the effectiveness of your security program, and can allow you to make informed decisions on what actions to take with regards to security.

Some examples of what could be worth recording are:

Key Security Metrics

1. Measure the time taken to detect, respond to, and resolve security incidents.
2. Track the total number of security incidents over a specified period.
3. Measure the time taken to fix identified vulnerabilities.
4. Monitor the rate of false positives generated by security tools to assess their accuracy and efficiency.

Key Performance Indicators (KPIs)

• Mean Time to Detect (MTTD): The average time taken to detect a security incident.
• Mean Time to Respond (MTTR): The average time taken to respond to a security incident.
• Patch Management Effectiveness: Percentage of code/systems patched within a defined timeframe.
• User Training Completion Rate: Percentage of project team members who have completed required security training.
• Security Audit Findings: Number of findings from security audits and the percentage of findings resolved within a specified period.

DevSecOps

Traditionally, rapid development and deployment is often prioritized at the expense of security considerations. This is generally speaking no different in web3, but it is important to take integrity, confidentiality, and availability into consideration too. To effectively address this without compromising on rapid development and deployment, it is essential to integrate security into the process, which is where devsecops comes into play. By implementing devsecops, projects can not only deploy faster, but also be more secure.

When operating in a devsecops mindset, projects prioritizes automation and collaboration between the development, operations and security teams.

Some of the key areas to consider are:

1. Integrate security measures early in the development process, such as by utilizing security tools such as fuzzing, static and dynamic analysis tools in your CI/CD process, to identify and mitigate vulnerabilities before they turn into critical issues.
2. Implement automated security testing and monitoring.
3. Development, Operations and Security teams should be aligned and work closely together.

Code Signing

Code signing ensures that the code has not been tampered with, and verifies the identity of the developer. Here are some best practices that could be followed:

1. Ensure all Pull Requests (PRs) are signed with the user’s GPG key.
2. Every PR must be reviewed by another core team member before being merged into the stable/main/master branch, with github settings set to reflect this.
3. Require Multi-Factor Authentication (MFA) for all users where applicable and available. Encourage the use of hardware MFA such as Yubikeys.
4. Rotate GPG keys regularly to mitigate the risk of key compromise.
5. Maintain clear documentation on the code signing procedures for your team members.

Continuous Integration and Continuous Deployment (CI/CD)

Continuous Integration and Continuous Deployment are there to ensure good code quality and create rapid and secure deployments. Some best practices are:

1. Ensure every PR undergoes CI testing (e.g., GitHub Actions) that must pass before merging. CI tests should at least include unit tests, integration tests, and checks for known vulnerabilities in dependencies.
2. The CI/CD pipeline should check for misconfigurations and leaked credentials.
3. Produce deterministic builds with a strict set of dependencies and/or a build container that can reliably produce the same results on different machines.
4. Integrate security scanning tools to detect vulnerabilities in code and dependencies during the CI process.
5. Use isolated environments for building and testing to prevent contamination between different stages of the pipeline.
6. Implement strict access controls for CI/CD pipelines to limit who can modify the pipeline configurations.

Integrated Development Environments (IDEs)

Integrated Development Environments (IDEs) are essential tools for developers, but they also need to be secured. Consider implementing the following best practices:

1. Ensure IDEs are configured securely, with plugins and extensions only installed from trusted sources. Some IDEs have features that allow for automated execution of files in folders. Use restricted mode if you don't fully trust a project.
2. Keep IDEs and their plugins/extensions up-to-date to protect against vulnerabilities.
3. Integrate static code analysis tools within the IDE to catch security issues early in the development process.
4. Configure IDEs to follow the principle of least privilege, limiting access to sensitive information and systems.
5. Ensure that potential development environments are isolated from production environments.

Repository Hardening

If a threat actor obtains access to your repository, it could have very severe consequences. In order to help avoid this, you could consider implementing the following best practices:

1. Require Multi-Factor Authentication (MFA) for all repository members.
2. Enable protected branches to prevent unauthorized changes to critical branches. Learn more about protected branches.
3. Follow the Security hardening for GitHub Actions to avoid token stealing and other vulnerabilities.
4. Implement strict access controls to limit who can push to critical branches and repositories.
5. Conduct regular security audits of the repository to identify and mitigate potential vulnerabilities.
6. Require all commits to be signed to verify the identity of contributors and ensure the integrity of the code.
7. Regularly update dependencies and use tools to check for and manage vulnerabilities in dependencies.

Security Testing

Security testing is a crucial part of the DevSecOps process, as it helps identify vulnerabilities early on so that they can be taken care of before they become an issue in production.

1. Integrate SAST tools into the CI/CD pipeline to analyze source code for vulnerabilities.
2. Use DAST tools to test running applications for security issues.
3. Combine SAST and DAST approaches with IAST tools for comprehensive security testing.
4. Implement fuzz testing to discover security vulnerabilities by inputting random data.

Privacy

Privacy is a fundamental aspect of security. Protecting your personal and team's information from unauthorized access and exposure is crucial. This section provides guidelines and resources for maintaining privacy, managing your digital footprint, and utilizing privacy-focused tools and services.

Secure Browsing

Secure browsing is essential to protect your privacy and personal information while using the internet.

Best Practices for Secure Browsing

1. Use HTTPS

   • Always use HTTPS to ensure that your connection to websites is encrypted. Look for the padlock icon in the browser address bar.
   • Most browser now enforce HTTPS by default, otherwise use browser extensions like HTTPS Everywhere to enforce HTTPS connections.

2. Avoid Public Wi-Fi

   • Avoid using public Wi-Fi for sensitive activities. If you must use it, ensure you connect through a VPN to encrypt your internet traffic.

3. Disable Third-Party Cookies

   • Disable third-party cookies in your browser settings to prevent tracking by advertisers and other third parties.

4. Use Private Browsing Mode

   • Use private browsing mode to prevent your browser from storing your browsing history, cookies, and temporary files.

5. Keep Your Browser Updated

   • Regularly update your browser to ensure you have the latest security patches and features.

Tools for Secure Browsing

1. Tor Browser

   • A browser designed for anonymous browsing using the Tor network.
   • Pros: Strong anonymity, easy to use.
   • Cons: Slower browsing speeds, some websites block Tor traffic.

2. Brave Browser

   • A privacy-focused browser that blocks ads and trackers by default.
   • Pros: Fast, blocks ads and trackers, built-in Tor support.
   • Cons: Limited extensions compared to other browsers.

3. uBlock Origin

   • A browser extension that blocks ads, trackers, and malware.
   • Pros: Highly configurable, efficient.
   • Cons: Requires setup for optimal use.

4. Privacy Badger

   • A browser extension that blocks tracking cookies and ads.
   • Pros: Easy to use, protects privacy.
   • Cons: May block some legitimate content.

Secure Search Engines

1. DuckDuckGo

   • A search engine that does not track your searches or store your personal information.
   • Pros: Strong privacy, no tracking.
   • Cons: Less personalized search results.

2. Start-page

   • A search engine that uses Google’s search results but protects your privacy.
   • Pros: Google search results, strong privacy.
   • Cons: Slower than Google.

Best Practices

1. Regularly clear your browsing history, cookies, and cache to remove any stored data.
2. Only install trusted browser extensions and regularly review their permissions.
3. Use a password manager to create and store strong, unique passwords for each website.

Data Removal Services

Removing your personal data from online platforms can help protect your privacy and reduce the risk of identity theft. Here are some steps and services to help you remove your data from the internet.

Steps to Remove Your Data

1. Identify Where Your Data Is

   • Conduct a search of your name and information on search engines to identify where your data is located.
   • Review your social media accounts, online forums, and public records for any personal information.

2. Request Data Removal

   • Contact websites directly to request the removal of your data. Most sites have a contact form or email for privacy concerns.
   • Use online tools and forms provided by search engines like Google to remove specific results.

3. Opt-Out of Data Brokers

   • Data brokers collect and sell personal information. Opt-out of their databases using their online forms.
   • Some common data brokers include Spokeo, Whitepages, and PeopleFinder.

Data Removal Services

1. DeleteMe

   • A subscription service that removes your data from data brokers and online databases.
   • Pros: Comprehensive removal, regular monitoring.
   • Cons: Costly subscription model.

2. PrivacyDuck

   • Offers manual removal services from various websites and databases.
   • Pros: Thorough and personalized service.
   • Cons: Expensive, manual process.

3. OneRep

   • Automated removal service that targets over 100 data broker sites.
   • Pros: Automated process, extensive reach.
   • Cons: Subscription fee required.

4. JustDeleteMe

   • A directory of direct links to delete your account from web services.
   • Pros: Free, easy to use.
   • Cons: Requires manual effort.

Best Practices

1. Regularly check and update the privacy settings on your online accounts.
2. Be mindful of the information you share online and with whom.
3. Use pseudonyms for accounts that don't require your real name.

Digital Footprint

Your digital footprint is the trail of data you leave behind while using the internet.

Understanding Your Digital Footprint

1. Active Footprint

   • Information you intentionally share online, such as social media posts, blog comments, and online profiles.

2. Passive Footprint

   • Information collected without your explicit consent, such as tracking cookies, IP addresses, and browsing history.

Managing Your Digital Footprint

1. Audit Your Online Presence

   • Regularly search your name and personal information on search engines.
   • Review your social media profiles and privacy settings.

2. Limit Information Sharing

   • Be cautious about the personal information you share online.
   • Avoid sharing sensitive information such as your home address, phone number, and financial details.

3. Use Privacy Settings

   • Adjust privacy settings on social media platforms to control who can see your information.
   • Enable two-factor authentication for added security.

4. Delete Unused Accounts

   • Remove accounts you no longer use to minimize the amount of personal information available online.

5. Opt-Out of Data Collection

   • Use tools and browser extensions to block tracking cookies and ads.
   • Opt-out of data collection by data brokers and online advertisers.

Tools for Managing Your Digital Footprint

1. Privacy Badger

   • A browser extension that blocks tracking cookies and ads.
   • Pros: Free, easy to use.
   • Cons: May block some legitimate content.

2. Ghostery

   • A browser extension that blocks trackers and enhances privacy.
   • Pros: Detailed tracker information, customizable.
   • Cons: Some features require a subscription.

3. Deseat.me

   • A tool to find and delete your old accounts.
   • Pros: Simple interface, effective.
   • Cons: Requires access to your email.

Best Practices

1. Conduct regular audits of your online presence to identify and remove unwanted information.
2. Protect your accounts with strong, unique passwords.
3. Keep up-to-date with privacy news and updates to stay informed about new threats and tools.

Encrypted Communication Tools

Encrypted communication tools are essential for maintaining privacy and security in digital communications. These tools ensure that your messages and calls are protected from eavesdropping and unauthorized access.

Popular Encrypted Communication Tools

1. Signal

   • An encrypted messaging app that provides end-to-end encryption for messages, calls, and video chats.
   • Pros: Strong encryption, open source, user-friendly.
   • Cons: Requires a phone number for registration.

2. WhatsApp

   • A widely-used messaging app that offers end-to-end encryption for messages, calls, and media.
   • Pros: Easy to use, large user base, supports various media types.
   • Cons: Owned by Facebook, requires a phone number.

3. Telegram

   • A messaging app that offers optional end-to-end encryption through its "Secret Chats" feature.
   • Pros: Cloud-based, supports large groups and channels, feature-rich.
   • Cons: End-to-end encryption is not enabled by default, requires a phone number.

4. Wire

   • A secure messaging app that provides end-to-end encryption for messages, calls, and file sharing.
   • Pros: Strong encryption, open source, supports multiple devices.
   • Cons: Requires an email or phone number for registration.

5. Threema

   • A privacy-focused messaging app that offers end-to-end encryption for messages, calls, and media.
   • Pros: No phone number or email required, strong encryption, anonymous usage.
   • Cons: Paid app, smaller user base.

Best Practices for Encrypted Communication

1. Verify Contacts

   • Always verify the identity of your contacts through security codes or other verification methods to ensure you are communicating with the intended person.

2. Keep Apps Updated

   • Regularly update your encrypted communication apps to ensure you have the latest security patches and features.

3. Use Strong Passwords

   • Protect your accounts with strong, unique passwords and enable two-factor authentication where possible.

4. Be Cautious with Metadata

   • Be aware that while the content of your messages may be encrypted, metadata such as timestamps and contact information may still be accessible.

5. Educate Yourself and Others

   • Stay informed about the latest security practices and educate your contacts on the importance of using encrypted communication tools.

Additional Resources

1. Electronic Frontier Foundation (EFF)

   • Provides guides and resources on secure communication and privacy tools.

2. PrivacyTools.io

   • Offers recommendations and reviews of privacy-focused tools and services.

3. ProtonMail Blog

   • Features articles on privacy, security, and encrypted communication.

By using encrypted communication tools and following best practices, you can significantly enhance the privacy and security of your digital communications.

Financial Privacy Services

Maintaining financial privacy is often seen by an important thing for people inside the web3 ecosystem, and it can help prevent personal and financial information from unauthorized access and fraud.

Tools for Financial Privacy

1. Cash

   • Using cash for transactions can help maintain privacy by avoiding digital records.
   • Pros: Anonymous, widely accepted.
   • Cons: Not practical for online transactions, physical security risks.

2. Prepaid Cards

   • Use prepaid debit cards for purchases to avoid linking transactions to your bank account.
   • Pros: Anonymity, control over spending.
   • Cons: Fees, limited acceptance.

3. Privacy.com

   • A service that allows you to create virtual credit cards for online purchases.
   • Pros: Protects your real credit card information, easy to use.
   • Cons: Limited to US users.

Strategies for Financial Privacy

1. Limit Data Sharing

   • Be cautious about sharing financial information online.
   • Use secure methods for sharing sensitive information, such as encrypted emails.

2. Monitor Your Accounts

   • Regularly review your cryptocurrency wallets, bank and credit card statements for unauthorized transactions.
   • Set up alerts for suspicious activity.

3. Use Secure Connections

   • Ensure that your internet connection is secure when conducting financial transactions.
   • Use a VPN to encrypt your internet traffic.

4. Shred Financial Documents

   • Shred any physical documents containing financial information before disposing of them.
   • Store important documents in a secure location.

Privacy-Focused Operating Systems and Tools

Using privacy-focused operating systems and tools can significantly enhance your digital privacy. These systems and tools are designed to protect your data and minimize your digital footprint.

Privacy-Focused Operating Systems

1. Tails

   • A live operating system that you can start on any computer from a USB stick or DVD.
   • Pros: Leaves no trace on the computer, comes with built-in privacy tools.
   • Cons: Requires a USB stick or DVD, limited software availability.

2. Qubes OS

   • An open-source operating system designed for security through isolation.
   • Pros: Strong isolation, supports running multiple virtual machines.
   • Cons: Requires fairly powerful hardware, steep learning curve.

3. Whonix

   • A security-focused operating system that runs in a virtual machine and uses Tor to anonymize internet traffic.
   • Pros: Strong anonymity, easy to use.
   • Cons: Slower internet speeds due to Tor, requires a virtual machine.

Privacy-Focused Tools

1. Tor Browser

   • A web browser designed for anonymous browsing using the Tor network.
   • Pros: Strong anonymity, easy to use.
   • Cons: Slower browsing speeds, some websites block Tor traffic.

2. Signal

   • An encrypted messaging app for secure communication.
   • Pros: End-to-end encryption, open source.
   • Cons: Requires a phone number for registration.

3. KeePass

   • An open-source password manager for securely storing and managing passwords.
   • Pros: Strong encryption, no cloud storage.
   • Cons: Requires manual setup, less user-friendly than some alternatives.

4. VeraCrypt

   • A disk encryption software for creating secure, encrypted volumes.
   • Pros: Strong encryption, supports hidden volumes.

VPN Services

Virtual Private Networks (VPNs) can help increase online privacy. They encrypt your internet traffic and hide your IP address, increases the protection of your data from eavesdroppers and provide you additional anonymity online.

Choosing a VPN Service

When selecting a VPN service, consider the following factors:

1. Privacy Policy

   • Ensure the VPN provider has a strict no-logs policy, meaning they do not store any information about your online activities.

2. Encryption Standards

   • Look for VPNs that use strong encryption standards, such as AES-256, to protect your data.

3. Server Locations

   • A wide range of server locations allows you to access content from different regions and improves connection speeds.

4. Speed and Performance

   • Choose a VPN that offers high-speed connections and minimal impact on your browsing and streaming experience.

5. Security Features

   • Look for additional security features such as kill switch, DNS leak protection, and multi-hop connections.

Recommended VPN Services

1. MullvadVPN

   • Pros: Strong privacy policy, fast speeds, wide range of server locations, robust security features.
   • Cons: More expensive than some competitors.

2. ProtonVPN

   • Pros: Strong focus on privacy, no-logs policy, free tier available, high security standards.
   • Cons: Fewer servers compared to competitors, can be slower on free tier.

3. NordVPN

   • Pros: No-logs policy, strong encryption, numerous servers, additional security features (e.g., Double VPN, CyberSec).
   • Cons: Some servers can be slow, interface can be cluttered.

4. Surfshark

   • Pros: Affordable, no-logs policy, unlimited simultaneous connections, strong security features.
   • Cons: Relatively new, smaller network of servers.

5. ExpressVPN

   • Pros: Strong privacy policy, fast speeds, wide range of server locations, robust security features.
   • Cons: More expensive than some competitors.

Best Practices for Using a VPN

1. Always Connect to a VPN on Public Wi-Fi

   • Public Wi-Fi networks are often unsecured, making them prime targets for attackers. Always use a VPN when connected to public Wi-Fi.

2. Enable the Kill Switch

   • A kill switch ensures that your internet connection is cut off if the VPN connection drops, preventing your data from being exposed.

3. Regularly Update Your VPN Software

   • Ensure that you are using the latest version of your VPN software to benefit from the latest security updates and features.

4. Use Multi-Hop Connections for Extra Security

   • Some VPNs offer multi-hop connections, which route your traffic through multiple servers for additional security.

5. Avoid Free VPNs

   • Free VPNs often come with limitations, such as data caps and slower speeds, and may not offer the same level of privacy and security as paid services.

Supply Chain Security

Supply chain security involves managing and securing all the components, dependencies, and processes involved in the development, deployment, and maintenance of software. In the context of blockchain and web3 projects, supply chain security could for example be parts of the web application stack, or external libraries used by the smart contract.

Dependency Awareness

Dependency awareness is the practice of understanding and managing all the external libraries, frameworks, and components that a software project relies on. Dependencies can introduce vulnerabilities and risks, which means it's important to keep track of them and ensure they are secure.

Importance of Dependency Awareness

1. Security Risks

   • Dependencies can contain vulnerabilities that may be exploited by threat actors.

2. Compliance

   • Ensuring that dependencies comply with licensing and regulatory requirements is essential to avoid legal issues.

3. Maintainability

   • Understanding dependencies and their impact on the project will help understand if it's possible to update a dependency used by your application.

Best Practices for Dependency Awareness

1. Use Dependency Management Tools

   • Leverage tools that can automatically track and manage dependencies. Examples include:
     • Web2:
       • Snyk: Monitors and fixes vulnerabilities in dependencies.
       • Dependabot: Automatically updates dependencies in GitHub projects.
     • Solidity:
       • Ethlint: Analyzes and lints Solidity code, including dependencies.
       • MythX: Scans for vulnerabilities in smart contract dependencies.

2. Regularly Update Dependencies

   • Regularly update dependencies to the latest secure versions after verifying them.

3. Monitor for Vulnerabilities

   • Continuously monitor dependencies for known vulnerabilities using tools like Snyk, npm audit, and GitHub Security Alerts.

4. Audit Dependencies

   • Perform regular audits of dependencies to ensure they are necessary and secure. Remove unused or outdated dependencies.

5. Use Trusted Sources

   • Only use dependencies from trusted and reputable sources. Avoid using unverified or poorly maintained libraries.

Supply Chain Levels for Software Artifacts

Supply chain levels for software artifacts provide a framework for categorizing and securing software components based on their risk levels. This approach helps projects prioritize their security efforts towards software components with the highest risk levels.

Framework for Supply Chain Levels

1. Level 1: Critical Artifacts

   • These artifacts are essential to the core functionality of the software and pose a high risk if compromised.
   • Examples: Core libraries.

2. Level 2: High-Risk Artifacts

   • Artifacts that are important but not critical. Their compromise could lead to significant security issues.
   • Examples: Middleware, database connectors, oracles, authentication modules.

3. Level 3: Moderate-Risk Artifacts

   • Artifacts that are used frequently but have a lower risk profile. Their compromise could cause inconvenience but not catastrophic failure.
   • Examples: User interface libraries, utility functions, data processing modules.

4. Level 4: Low-Risk Artifacts

   • Artifacts that have minimal impact on security if compromised.
   • Examples: Logging libraries, test utilities.

Best Practices for Securing Supply Chain Levels

1. Critical Artifacts

   • Implement strict access controls and require code reviews for all changes.
   • Use robust security testing, including static and dynamic analysis.
   • Monitor continuously for vulnerabilities and apply patches promptly.

2. High-Risk Artifacts

   • Enforce strong access controls and conduct regular security assessments.
   • Perform regular updates and vulnerability scans.
   • Implement automated security testing in CI/CD pipelines.

3. Moderate-Risk Artifacts

   • Apply standard security practices, including access controls and regular updates.
   • Use automated tools to scan for vulnerabilities periodically.
   • Ensure that dependencies are from trusted sources.

4. Low-Risk Artifacts

   • Follow basic security hygiene, such as using trusted sources and applying updates.
   • Perform occasional security reviews and audits.

Security Automation

Security automation involves using technology to perform security tasks with minimal human intervention. By automating repetitive and complex security processes, teams can improve efficiency, reduce the risk of human error, and respond to threats more quickly. This section covers best practices and tools for automating various aspects of security, including compliance checks, infrastructure as code, and threat detection and response.

Threat Detection and Response

Threat detection and response is a critical aspect of maintaining the security of your project. It involves identifying potential threats, monitoring for signs of malicious activity, and responding effectively to mitigate any identified risks. By implementing robust threat detection and response strategies, you can protect your project from security breaches and minimize the impact of any incidents that do occur.

Guidelines for Threat Detection and Response

1. Implement Continuous Monitoring: Use automated tools to continuously monitor your systems for signs of suspicious activity. This can help you detect threats early and respond quickly.
2. Establish Clear Response Protocols: Develop and document clear protocols for responding to different types of security incidents. Ensure that all team members are familiar with these protocols and know their roles in the response process.
3. Conduct Regular Threat Assessments: Regularly assess your systems for potential vulnerabilities and update your threat detection and response strategies accordingly.
4. Use Threat Intelligence: Leverage threat intelligence sources to stay informed about the latest threats and trends in the security landscape. This can help you anticipate and prepare for new types of attacks.
5. Train Your Team: Provide regular training for your team on threat detection and response best practices. This can help ensure that everyone is prepared to act quickly and effectively in the event of a security incident.

Example Best Practice

One effective approach to threat detection and response is to use a Security Information and Event Management (SIEM) system. A SIEM system collects and analyzes data from various sources within your network, helping you to identify and respond to potential threats in real-time. By integrating a SIEM system into your security strategy, you can improve your ability to detect and respond to threats, ultimately enhancing the overall security of your project.

Incident Example

Imagine that your SIEM system detects unusual login activity from an IP address located in a different country than your usual operations. This could be an indication of a potential security breach.

Sample Process

1. Detection: The SIEM system flags the unusual login activity and generates an alert.
2. Analysis: A security analyst reviews the alert and examines the login activity to determine if it is indeed suspicious.
3. Containment: If the activity is confirmed to be malicious, the analyst takes steps to contain the threat, such as blocking the IP address and disabling the compromised account.
4. Eradication: The analyst investigates the extent of the breach and removes any malicious software or unauthorized access points.
5. Recovery: The affected systems are restored to normal operation, and any necessary security patches or updates are applied.
6. Lessons Learned: A post-incident review is conducted to identify any gaps in the threat detection and response process and to implement improvements for future incidents.

Compliance Checks

Automating compliance checks helps projects ensure that they adhere to security policies, standards, and potential regulatory requirements consistently. Automated compliance tools can continuously monitor, assess, and report on the compliance status of systems and applications.

Benefits of Automated Compliance Checks

1. Continuous Monitoring

   • Automated tools provide continuous monitoring of systems to ensure ongoing compliance.
   • Reduces the risk of non-compliance due to configuration drift or changes.

2. Efficiency

   • Automates repetitive compliance tasks, freeing up security teams to focus on more strategic activities.
   • Speeds up the compliance assessment process.

3. Accuracy

   • Reduces human error in compliance assessments.
   • Provides consistent and repeatable compliance checks.

Tools for Automated Compliance Checks

1. AWS Config

   • A service that continuously monitors and records AWS resource configurations and allows automated compliance checks based on predefined rules.
   • Pros: Deep integration with AWS services, customizable rules.
   • Cons: Limited to AWS environments.

2. Azure Policy

   • A service that enables the creation, assignment, and management of policies to enforce organizational standards and assess compliance at-scale.
   • Pros: Integrated with Azure services, supports custom policies.
   • Cons: Limited to Azure environments.

3. HashiCorp Sentinel

   • A policy-as-code framework for defining and enforcing policies across infrastructure as code and cloud environments.
   • Pros: Flexible and extensible, integrates with Terraform and other HashiCorp tools.
   • Cons: Requires knowledge of policy language.

4. OpenSCAP

   • An open-source tool for implementing and enforcing security policies and compliance checks.
   • Pros: Supports various compliance frameworks (e.g., NIST, CIS), open-source.
   • Cons: Requires configuration and management.

Best Practices

1. Integrate compliance checks into the CI/CD pipeline to ensure that code changes and deployments comply with security policies.

Infrastructure as Code

Infrastructure as Code (IaC) is the managing and provisioning computing infrastructure through machine-readable definition files, rather than manual configuration or interactive configuration tools. Automating security within IaC helps ensure that infrastructure is configured securely and consistently.

Benefits of Automating Security in IaC

1. Consistency

   • Ensures that infrastructure is provisioned and configured consistently across environments.
   • Reduces the risk of configuration drift and security misconfigurations.

2. Scalability

   • Enables scalable deployment of secure infrastructure.
   • Simplifies management of large-scale environments.

3. Version Control

   • Treats infrastructure configurations as code, allowing version control and change tracking.
   • Facilitates rollback to previous configurations if issues arise.

Best Practices for Secure IaC

1. Use Trusted Modules

   • Use trusted and verified modules or templates for infrastructure provisioning.
   • Avoid using unverified or outdated modules that may contain vulnerabilities.

2. Implement Least Privilege

   • Ensure that infrastructure components have the minimum necessary permissions.
   • Use role-based access control (RBAC) to manage permissions.

3. Automate Security Scans

   • Integrate security scanning tools into the IaC pipeline to automatically detect and remediate vulnerabilities.
   • Use tools like Checkov, tfsec, and Terrascan to scan Terraform configurations for security issues.

4. Encrypt Sensitive Data

   • Encrypt sensitive data at rest and in transit within the infrastructure.
   • Use managed encryption services provided by cloud providers.

5. Regularly Update IaC Templates

   • Keep IaC templates and modules up to date with the latest security patches and best practices.
   • Regularly review and update configurations to address new security threats.

Tools for Automating Security in IaC

1. Terraform

   • A widely used IaC tool that allows for the automated provisioning of infrastructure across various cloud providers.
   • Supports integration with security scanning tools like tfsec and Checkov.

2. AWS CloudFormation

   • An IaC service provided by AWS for modeling and setting up AWS resources.
   • Supports AWS Config rules for automated compliance checks.

3. Azure Resource Manager (ARM) Templates

   • IaC templates for deploying and managing Azure resources.
   • Integrates with Azure Policy for enforcing security policies.

4. Ansible

   • An open-source automation tool for configuration management and application deployment.
   • Supports security roles and playbooks for automating security configurations.

Identity and Access Management (IAM)

Identity and Access Management (IAM) is defined as managing who has access to your systems and data, and ensuring that access is secure and appropriate. Effective IAM practices help prevent unauthorized access, reduce the risk of insider threats, and ensure that users have the necessary access to perform their roles efficiently.

Contents

1. Role-Based Access Control (RBAC)
2. Secure Authentication
3. Access Management Best Practices

Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) is a method of regulating access to systems and data based on the roles assigned to individual users within an project. RBAC ensures that users have the minimum access necessary to perform their job functions, reducing the risk of unauthorized access.

Key Principles of RBAC

• Role Definition: Clearly define roles within the project based on the team member's job responsibility. Each role should have a specific set of permissions, for example a community manager could potentially not require administrative permissions to the project's github repository.
• Role Assignment: Assign roles to team members based on their job responsibilities. Ensure that users only have access to the resources they need.
• Permission Management: Regularly review and update role permissions to ensure they are aligned with current team functions and security requirements.
• Separation of Duties: Implement separation of duties to prevent conflicts of interest and reduce the risk of threats.

Secure Authentication

Secure authentication is essential for verifying the identity of team members and ensuring that only authorized individuals have access. By implementing strong authentication mechanisms you can protect your project against unauthorized access and lower the risk for potential security breaches.

Key Authentication Methods

• Multi-Factor Authentication (MFA): Require multiple forms of verification (e.g., something you know, something you have, something you are) to enhance security. It is strongly suggested that one does not use SMS as a form of multi-factor authentication, but instead utilizes hardware tokens such as Yubikeys.
• Single Sign-On (SSO): Enable SSO in services you use to allow team members to authenticate once and gain access to multiple systems without re-entering credentials, but make sure that the account connected to SSO is secured by strong Multi-Factor Authentication.
• Password Management: Enforce strong password policies and encourage the use of password managers to generate and store complex passwords.

Best Practices for Secure Authentication

1. Require MFA for all team members, especially for accessing sensitive systems and data. Encourage the use of hardware tokens (e.g., Yubikeys) over SMS-based MFA.
2. Implement monitoring and alerting for suspicious authentication attempts, such as repeated failed logins or logins from unusual locations.
3. Provide training on secure authentication practices and the importance of protecting authentication credentials.

Access Management Best Practices

Effective access management involves ensuring that users have the right access, at the right time, and that access is promptly revoked when no longer needed. Implementing access management practices helps prevent unauthorized access, and reduces the risk of insider threats.

Practices for Access Management

• Just-In-Time Access: Implement just-in-time (JIT) access to provide users with temporary access when needed. This minimizes the risk of long-term access being misused.
• Timely Access Revocation: Ensure that access is revoked in a timely manner for users who are no longer part of the organization or whose roles within the project have changed.
• Access Reviews: Conduct regular access reviews to ensure that team members have appropriate access based on their current functions.
• On-boarding and Off-boarding Processes: Establish clear processes for on-boarding new team members and off-boarding departing team members to ensure that access is granted and revoked as appropriate.
• Access Logging and Monitoring: Implement logging and monitoring of access to critical services to detect and respond to unauthorized access attempts.

Best Practices for Access Management

1. Grant users the minimum access necessary to perform their job functions.
2. Ensure that critical tasks require multiple users to perform, reducing the risk of misuse.
3. When possible, use automated tools to manage access provisioning and revocation based on user lifecycle events.

Secure Software Development

Secure software development is the practice of integrating security measures throughout the entire software development lifecycle (SDLC). This approach ensures that software is designed, developed, and maintained with security in mind, protecting against vulnerabilities and threats. This section provides guidelines and best practices for secure software development, including code reviews, secure coding standards, version control, and threat modeling.

Secure Coding Standards and Guidelines

Using secure coding standards and guidelines increases the likelihood of you being resilient to security threats. Having these type of standards can help developers avoid common vulnerabilities, and help ensure that security is considered at every stage of development.

Secure Coding Standards

1. Input Validation

   • Validate all inputs to ensure they conform to expected formats and ranges.
   • Use whitelisting (allowing only known good inputs) rather than blacklisting.

2. Output Encoding

   • Encode output data.
   • Use libraries and frameworks that provide built-in encoding functions.

3. Authentication and Authorization

   • Implement strong authentication mechanisms to verify user identities.
   • Ensure proper authorization checks are in place to control access to resources based on user roles.

4. Error Handling

   • Handle errors gracefully without revealing sensitive information.
   • Log errors securely and provide generic error messages to users.

Guidelines for Secure Coding

1. Use Secure Libraries and Frameworks

   • Use libraries and frameworks that have been vetted for security and are regularly updated.
   • Avoid using deprecated or unmaintained libraries.

2. Follow Principle of Least Privilege

   • Grant the minimum level of access necessary for code to function.
   • Avoid running code high privileges.

3. Secure Data Storage

   • Encrypt sensitive data both at rest and in transit.
   • Use secure storage mechanisms for credentials and secrets.

4. Regular Code Reviews

   • Conduct regular code reviews to identify and fix security vulnerabilities.
   • Use automated tools to complement manual code reviews.

5. Continuous Security Training

   • Provide ongoing security training for developers to keep them informed about the latest threats and best practices.
   • Encourage participation in security communities and events.

Code Reviews and Peer Audits

Code reviews and peer audits help identifying and mitigating security vulnerabilities in software. They involve systematically examining code to ensure it adheres to the security standards and best practices of the project.

Best Practices for Code Reviews

1. Regular Reviews

   • Conduct code reviews regularly to identify and fix security vulnerabilities early in the development process.
   • Integrate code reviews into the development workflow to make them a routine part of the process.

2. Review Checklists

   • Use review checklists to ensure that all security aspects are covered during the review.
   • Checklists should include common security issues such as input validation, error handling, and authentication.

3. Automated Tools

   • Use automated code analysis tools to assist in identifying potential security vulnerabilities.
   • Tools like SonarQube, Checkmarx, and Snyk can help in detecting issues that might be missed during manual reviews.

4. Peer Audits

   • Encourage peer audits where team members review each other's code.
   • Peer audits provide a fresh perspective and can help identify issues that the original developer might overlook.

Conducting Effective Code Reviews

1. Focus on Security

   • Prioritize security issues during code reviews.
   • Ensure that code follows secure coding standards and guidelines.

2. Collaborative Approach

   • Foster a collaborative environment where reviewers and developers work together to improve code quality.
   • Provide constructive feedback and encourage open communication.

3. Document Findings

   • Document all findings from code reviews and track their resolution.
   • Use issue tracking systems to manage identified vulnerabilities and ensure they are addressed.

4. Continuous Improvement

   • Continuously improve the code review process based on feedback and lessons learned.
   • Regularly update review checklists and practices to keep up with evolving security threats.

Secure Code Repositories and Version Control

Managing secure code repositories and having version control practices helps protect your project from unauthorized access and ensuring the integrity of your project.

Best Practices for Secure Code Repositories

1. Access Control

   • Implement strict access controls to limit who can view, modify, and commit code.
   • Use role-based access control (RBAC) to grant permissions based on the user's role within the organization.

2. Multi-Factor Authentication (MFA)

   • Require MFA for all users accessing the code repository to add an extra layer of security.
   • Use hardware tokens or authentication apps for stronger security.

3. Branch Protection

   • Enable branch protection rules to prevent unauthorized changes to critical branches such as main/master.
   • Require code reviews and approvals by another person before changes can be merged into the main/master branch.

4. Audit Logs

   • Enable audit logging to track all activities within the repository.
   • Regularly review logs to detect any suspicious activities or unauthorized access attempts.

Secure Version Control Practices

1. Commit Signing

   • Require developers to sign their commits with GPG keys to verify the authenticity of the code changes.
   • Enforce commit signing policies in the version control system.

2. Regular Backups

   • Regularly back up the code repository to prevent data loss.
   • Store backups in a secure, offsite location.

3. Continuous Integration/Continuous Deployment (CI/CD)

   • Integrate security checks into the CI/CD pipeline to automatically scan code for vulnerabilities.
   • Ensure that only tested and approved code is deployed to production.

Threat Modeling and Secure Design Principles

Threat modeling and secure design principles help identify and mitigating potential security threats during the design phase of software development. T

Threat Modeling

1. Identify Assets

   • Determine the valuable assets that need protection, such as user funds, sensitive data, user credentials, and intellectual property.

2. Identify Threats

   • Identify potential threats to the assets using models like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).

3. Assess Risks

   • Evaluate the risks associated with each identified threat based on its likelihood and potential impact.

4. Develop Mitigations

   • Design and implement security controls to mitigate the identified threats. Prioritize mitigations based on the assessed risks.

5. Validate and Iterate

   • Regularly validate the threat model and update it as the application evolves. Continuously assess and improve security measures.

Secure Design Principles

1. Principle of Least Privilege

   • Grant users and systems the minimum level of access necessary to perform their functions. Reduce the attack surface by limiting permissions.

2. Defense in Depth

   • Implement multiple layers of security controls to protect against different types of threats. Ensure that security is not reliant on a single control.

3. Fail Securely

   • Design systems to fail in a secure manner. Ensure that errors and failures do not expose sensitive information or create security vulnerabilities.

4. Secure Defaults

   • Configure systems with secure default settings. Require users to opt into less secure configurations rather than opting into secure ones.

5. Separation of Duties

   • Separate critical functions to prevent a single individual or system from having excessive control. Implement checks and balances.

6. Secure by Design

   • Integrate security into the design and architecture of the application. Consider security implications during every stage of the design process.

Encryption

Encryption is a fundamental aspect of securing data, ensuring that sensitive information remains confidential and protected from unauthorized access. This section covers various types of encryption and best practices for implementing them effectively.

Contents

1. Cloud Data Encryption
2. Communication Encryption
3. Encryption in Transit
4. Database Encryption
5. Email Encryption
6. File Encryption
7. Full Disk Encryption
8. Hardware Encryption

Cloud Data Encryption

You should consider using the best practices below, in order to ensure that data stored in the cloud is protected from unauthorized access:

Best Practices

1. Use strong encryption algorithms.

   • Example: Use AES-256 for data at rest and TLS 1.2 or higher for data in transit.
   • Ensure that encryption libraries and tools are up-to-date to avoid vulnerabilities.

2. Ensure data is encrypted in transit and at rest.

   • Example: In AWS, enable S3 bucket encryption and use AWS KMS for key management.
   • Example: In Azure, use Azure Storage Service Encryption and Azure Key Vault for key management.
   • Example: In Google Cloud, enable encryption for Cloud Storage and use Cloud KMS for key management.

3. Use cloud provider-managed keys or even better bring your own keys (BYOK) for enhanced control over encryption keys.

   • Example: In Google Cloud, use Cloud KMS for managing encryption keys and consider using Customer-Supplied Encryption Keys (CSEK) for BYOK.
   • Regularly rotate encryption keys to minimize the risk of key compromise.

4. Implement strict access controls and monitoring to prevent unauthorized access to encrypted data.

   • Example: Use IAM roles and policies in AWS to restrict access to sensitive data.
   • Example: Enable Azure Security Center to monitor and alert on unauthorized access attempts.
   • Example: In Google Cloud, use IAM policies and Cloud Audit Logs to monitor access.

5. Continually review that the encryption best practices are being followed everywhere it's relevant.

   • Example: Regularly audit your encryption settings and access controls using tools like AWS Config or Azure Policy.
   • Example: Use automated compliance checks in Google Cloud Security Command Center.

6. Enable logging and monitoring for encryption activities.

   • Example: In AWS, enable CloudTrail to log all API calls related to encryption.
   • Example: In Azure, use Azure Monitor to track encryption-related activities.
   • Example: In Google Cloud, use Cloud Logging to monitor encryption key usage.

7. Implement automated backups and ensure they are encrypted.

   • Example: In AWS, use AWS Backup to automate backups and ensure they are encrypted.
   • Example: In Azure, use Azure Backup to automate and encrypt backups.
   • Example: In Google Cloud, use Cloud Storage for backup and ensure encryption is enabled.

8. Educate and train your team on encryption best practices.

   • Conduct regular training sessions on the importance of encryption and how to implement it correctly.
   • Provide documentation and resources for team members to reference.

9. Use multi-factor authentication (MFA) for accessing encryption keys and management consoles.

   • Example: In AWS, enable MFA for IAM users and roles.
   • Example: In Azure, enable MFA for Azure AD users.
   • Example: In Google Cloud, enable MFA for Google Cloud accounts.

10. Regularly update and patch your encryption tools and libraries.

    • Ensure that all encryption-related software is kept up-to-date with the latest security patches.
    • Monitor for vulnerabilities in encryption libraries and apply patches promptly.

By following these best practices and utilizing the recommended tools, you can significantly enhance the security of your data stored in the cloud.

Secure Messaging Systems

Using secure messaging systems is crucial for protecting the privacy and integrity of your communications. Here are some popular messaging systems that offer end-to-end encryption and those that do not by default.

End-to-End Encrypted Messaging Systems

1. Signal

   • Offers strong end-to-end encryption for messages, voice calls, and video calls.
   • Open source and highly recommended for secure communication.
   • Signal

2. Matrix/Element

   • An open standard for decentralized communication with end-to-end encryption.
   • Element is a popular client for the Matrix protocol.
   • Matrix / Element

3. WhatsApp

   • Provides end-to-end encryption for messages, voice calls, and video calls by default.
   • Owned by Meta (Facebook).
   • WhatsApp

4. Wire

   • End-to-end encryption for messages and calls
   • Open source with a strong focus on privacy.
   • Wire

Messaging Systems Without Default End-to-End Encryption

These messaging systems supposedly provides encryption for data in transit and at rest, but not end-to-end encryption for messages.

1. Telegram

   • Offers end-to-end encryption only for "Secret Chats".
   • Telegram

2. Discord

   • Does not offer end-to-end encryption for messages.
   • Discord

3. Zoom

   • End-to-end encryption for calls, but must be manually enabled.
   • Zoom

4. Slack

   • Does not offer end-to-end encryption for messages.
   • Slack

5. Microsoft Teams

   • Does not offer end-to-end encryption for messages.
   • Microsoft Teams

For secure communication, it is recommended to use messaging systems that offer end-to-end encryption by default.

Database Encryption

Often, databases contains information that should not be publicly available. In order to protect your database, you may consider implementing the following best practices:

Best Practices

1. Use strong encryption algorithms to encrypt database files and backups.
2. Encrypt sensitive columns within the database, such as those containing personally identifiable information (PII).
3. Use Transparent Data Encryption (TDE) to automatically encrypt and decrypt data stored in the database.
4. Implement robust key management practices, including the use of HSMs and regular key rotation depending on your use case.
5. Enforce strict access controls to prevent unauthorized access to encrypted data.

Email Encryption

Email is insecure and un-encrypted by default, but can become more secure by following best practices:

Best Practices

1. Implement S/MIME or PGP:

   • S/MIME: Secure/Multipurpose Internet Mail Extensions (S/MIME) is a widely accepted protocol for sending digitally signed and encrypted messages. It requires a certificate from a trusted Certificate Authority (CA). Popular email clients like Microsoft Outlook and Apple Mail support S/MIME.
     • Example:
       1. Obtain an S/MIME certificate from a trusted CA (e.g., Comodo, Symantec).
       2. Install the certificate in your email client:
          • Outlook: Go to File > Options > Trust Center > Trust Center Settings > Email Security > Import/Export to import your certificate.
          • Apple Mail: Open Mail > Preferences > Accounts > Advanced > Certificates to add your certificate.
       3. Compose a new email and select the option to sign/encrypt the email.
   • PGP: Pretty Good Privacy (PGP) is another method for encrypting emails. It uses a decentralized trust model and is supported by tools like GnuPG (GPG), which is an open-source implementation. Extensions like Enigmail for Thunderbird or FlowCrypt for Gmail can simplify the process.
     • Example:
       1. Install GnuPG (GPG) on your system.
       2. Generate a key pair using the command: gpg --gen-key.
       3. Share your public key with your contacts.
       4. Install an email client extension:
          • Thunderbird: Install Enigmail from the Thunderbird add-on store.
          • Gmail: Install FlowCrypt from the Chrome Web Store.
       5. Configure the extension with your GPG key.
       6. Compose a new email and use the extension to encrypt/sign the email.

2. Train Project Members: Conduct regular training sessions to ensure all team members understand how to use email encryption tools effectively. Provide step-by-step guides and resources for troubleshooting common issues.

3. Use Trusted Email Gateways: Ensure that your email service provider uses secure and trusted gateways to protect both incoming and outgoing communications. Verify that the provider complies with industry standards and regulations.

4. Transmit Emails Over TLS: Ensure that all emails are transmitted over TLS-encrypted connections. This can be configured in your email server settings. TLS (Transport Layer Security) helps protect the data in transit from eavesdropping and tampering.

5. Open Source Alternatives:

   • GnuPG (GPG): An open-source implementation of PGP, widely used for encrypting and signing data and communications.
   • Mailvelope: A browser extension that integrates PGP encryption into web-mail services like Gmail, Outlook, and Yahoo Mail.
   • ProtonMail: A secure email service that offers end-to-end encryption and is open-source. It provides an easy-to-use interface and strong privacy protections.

By following these best practices and utilizing the recommended tools, you can significantly enhance the security of your email communications.

Encryption in Transit

Encryption in transit means how data is being encrypted while it flows across networks. This is important as you don't want anyone eavesdropping on your traffic, and by following best practices such as the ones below, you can reduce the risk of that:

Best Practices

1. Ensure that all data transmitted over the internet is encrypted using TLS/SSL.
2. Use secure VPNs to encrypt data transmitted over public networks such as public WiFi.
3. Use SSH for secure remote access to servers and other infrastructure.
4. Use encryption protocols such as S/MIME or PGP for email communications.

File Encryption

File encryption protects sensitive information stored in files.

Use strong encryption algorithms to encrypt sensitive files stored on local and network drives. There are multiple tools available for file encryption, use one that is regarded as trusted.

Full Disk Encryption

Full disk encryption protects all data stored on a device in the event that it's stolen or lost. Today, all major Operating Systems for workstations, servers and mobile phones have full disk encryption capabilities built in, and sometimes enabled by default. Check which full disk encryption is built into your operating system, and enable it if not enabled by default.

Best Practices

1. Ensure that full disk encryption uses strong industry-standard algorithms.
2. Enable full disk encryption by default on all devices, including laptops, desktops, and mobile devices.
3. Implement secure boot to ensure that only trusted software can be loaded during the boot process.

Hardware Encryption

Hardware encryption, such as HSM, uses dedicated hardware to encrypt data, providing robust security. Utilizing a HSM is a fairly specialized thing, but consumers are for example often using TPM.

Best Practices

1. Enable TPM when available on your computer to enhance the security of hardware-based encryption.
2. Consider using self-encrypting drives (SEDs) for storage to ensure data is encrypted at the hardware level.
3. If relevant for your use case, use HSMs to securely generate, store, and manage encryption keys.

Partition Encryption

What is Partition Encryption?

Partition encryption is the process of encrypting specific partitions on a storage device. This allows for selective encryption of data, providing flexibility in managing encrypted and un-encrypted data on the same device. Unlike full disk encryption, which encrypts the entire disk, partition encryption targets specific areas, making it ideal for protecting sensitive data without impacting the entire storage system.

Importance of Partition Encryption

Partition encryption is crucial for protecting sensitive information from unauthorized access, especially in environments where different types of data coexist on the same device. It helps prevent data breaches in case of unauthorized access to specific partitions and ensures compliance with data protection regulations.

Uses of Partition Encryption

• Protecting Sensitive Data: Ensures that sensitive information stored on specific partitions is secure.
• Compliance: Helps organizations meet regulatory requirements for data protection.
• Data Breach Prevention: Reduces the risk of data breaches in case of unauthorized access to specific partitions.
• Secure Decommissioning: Ensures that data on encrypted partitions is not recoverable when storage devices are decommissioned or repurposed.

Examples of Partition Encryption

• BitLocker: A partition encryption feature included with Microsoft Windows that provides encryption for specific partitions. Learn how to use BitLocker
• LUKS (Linux Unified Key Setup): A disk encryption specification for Linux that provides a standard for partition encryption. Learn how to use LUKS
• VeraCrypt: An open-source disk encryption software that can encrypt specific partitions. Learn how to use VeraCrypt

Best Practices for Partition Encryption

1. Use Strong Encryption Algorithms: Ensure that the encryption algorithms used are strong and up-to-date, such as AES-256.
2. Enable Encryption on Sensitive Partitions: Apply partition encryption to all partitions that store sensitive information.
3. Regularly Update Encryption Software: Keep encryption software and tools updated to protect against vulnerabilities.
4. Implement Access Controls: Use strong authentication methods, such as multi-factor authentication (MFA), to control access to encrypted partitions.
5. Backup Encryption Keys: Securely backup encryption keys to prevent data loss in case of key corruption or loss.
6. Monitor and Audit: Regularly monitor and audit encryption settings and access logs to ensure compliance and detect any unauthorized access attempts.

By following these best practices and using reliable partition encryption technologies, organizations can significantly enhance the security of their data and protect against unauthorized access and data breaches.

Volume Encryption

What is Volume Encryption?

Volume encryption is the process of encrypting a specific storage volume or partition to protect the data it contains. Unlike full disk encryption, which encrypts the entire disk, volume encryption allows for selective encryption of specific volumes, providing flexibility in managing encrypted and un-encrypted data on the same device.

Importance of Volume Encryption

Volume encryption is essential for protecting sensitive information from unauthorized access, especially in environments where different types of data coexist on the same device. It helps prevent data breaches in case of unauthorized access to specific volumes and ensures compliance with data protection regulations.

Uses of Volume Encryption

• Protecting Sensitive Data: Ensures that sensitive information stored on specific volumes is secure.
• Compliance: Helps organizations meet regulatory requirements for data protection.
• Data Breach Prevention: Reduces the risk of data breaches in case of unauthorized access to specific volumes.
• Secure Decommissioning: Ensures that data on encrypted volumes is not recoverable when storage devices are decommissioned or repurposed.

Examples of Volume Encryption

• Partition Encryption: Encrypts specific partitions or volumes on a disk, allowing for selective encryption of sensitive data.
• Virtual Encrypted Disks: Creates virtual encrypted disks within files, providing an additional layer of security for sensitive data.

Known Technologies for Volume Encryption

• BitLocker: A volume encryption feature included with Microsoft Windows that provides encryption for specific volumes.
• LUKS (Linux Unified Key Setup): A disk encryption specification for Linux that provides a standard for volume encryption.
• VeraCrypt: An open-source disk encryption software that can create virtual encrypted disks within a file or encrypt specific partitions.

Best Practices for Volume Encryption

1. Use Strong Encryption Algorithms: Ensure that the encryption algorithms used are strong and up-to-date, such as AES-256.
2. Enable Encryption on Sensitive Volumes: Apply volume encryption to all volumes that store sensitive information.
3. Regularly Update Encryption Software: Keep encryption software and tools updated to protect against vulnerabilities.
4. Implement Access Controls: Use strong authentication methods, such as multi-factor authentication (MFA), to control access to encrypted volumes.
5. Backup Encryption Keys: Securely backup encryption keys to prevent data loss in case of key corruption or loss.
6. Monitor and Audit: Regularly monitor and audit encryption settings and access logs to ensure compliance and detect any unauthorized access attempts.

By following these best practices and using reliable volume encryption technologies, organizations can significantly enhance the security of their data and protect against unauthorized access and data breaches. $$

What Is It

This resource is a collection of best practices written in an abstract or general fashion to be applicable regardless of the specific technology. It serves as a comprehensive guide to help you secure various aspects of your Web3 projects and build resilience against potential threats.

This guide aims to centralize existing information, so you might not see novel features but rather a well-organized compilation of security-related topics, from simpler ones to more complex ones. The goal is to provide a comprehensive resource that brings together diverse security insights and practices into one accessible place.

Our hope is that these resources will help expand your security skill set.

What It Isn't

This resource isn't just a compilation of existing information. While it may initially seem like a collection of curated content, its primary focus is on providing in-depth, practical guidance.

Unlike other curations, compilations, or blog posts that often focus on the latest technologies, this guide delves into underlying concepts and technical aspects essential for securing Web3 projects. It’s not meant to be read like a "story" but rather used as a reference to enhance your understanding and application of security practices.

The content may not always follow the latest state-of-the-art technologies, as its focus is on fundamental security principles that are broadly applicable. Our aim is to provide valuable insights and practical advice to help you secure your projects effectively.

This guide is not intended to be offensive, though it might include strong examples to illustrate particular points. Our goal is to ensure clarity and effectiveness in conveying security best practices.

Contribute to the Security Framework

The Security Framework is an open and collaborative project. Whether you are part of the Security Alliance or not, we welcome your contributions! Help us to build the documentation and improve security in the ecosystem.

This mdBook-style handbook is designed for easy collaboration and automatic deployment through continuous integration. If you'd like to join our effort, feel free to fix typos, contribute new sections, or propose enhancements.

On each page, you will find a "Suggest an edit" button at the top-right corner. Clicking this sends you to the GitHub.com where you can suggest edits using their web interface.

If you want to contribute in a more organized manner, please read below.

Contributing

Before you start editing, adding or removing content, please read the code of conduct and make yourself familiar with the overall structure.

The source is hosted in github repository at github.com/security-alliance/frameworks.

The content of the Frameworks main website (.org) comes from the main branch, and when contributing to several frameworks, or generic changes, we would like you to open a PR into the development branch (.dev)

⚠️ Please sign and verify every commit.

Once a new update is warranted, the content from development is merged into main.

Framework-specific branches and Stewards

To understand how to contribute, follow this process:

1. Check for a framework-specific branch: First, check if there's a Steward for the specific framework you're interested in, and reach out. We usually have separate branches pre-develop for frameworks with stewards. Their naming convention is fw_framework_name, for example fw_opsec, fw_community_mgmt - the naming should be intuitive. For more information about stewards and their responsibilities, see the Stewards section.

2. Fork the right branch: Ideally, you will fork these framework-specific branches, since they will probably have more updated information than what's available in the develop branch.

3. Submit PR to framework specific branch: Once you have your suggestions, submit a PR and let the steward or maintainer know you're ready for a review. Feel free to assign reviewers as well. Once submited, you'll be able to see the deployment through Vercel's automation and make any final fixes.

4. Submit PR to develop: After reviews, a steward, a maintainer, or even yourself can submit a PR from the framework specific branch to the develop branch.

5. Become a steward: If there's no specific branch created, then that framework is still "headless," which means you can become its steward! See more in the Stewards section.

Development Environment Setup

Choose the development approach that works best for you:

Option A: DevContainer with VSCode (Recommended)

The easiest way to get started is using our pre-configured devcontainer with VSCode:

1. Prerequisites: VSCode with Dev Containers extension
2. Open the project: VSCode will detect the devcontainer configuration
3. Reopen in container: Command Palette (Ctrl+Shift+P) → "Dev Containers: Reopen in Container"
4. Start developing: All tools are pre-installed and ready to use

Option B: DevContainer CLI Only (No VSCode Required)

Using DevContainer CLI:

• Install DevContainer CLI

git clone https://github.com/security-alliance/frameworks.git
cd frameworks && git checkout develop
devcontainer up --workspace-folder .
devcontainer exec --workspace-folder . bash
# Get the IP address of the container, by running `hostname -I | awk '{print $1}'`. Should be printed automatically in the terminal after the creation as well
# Inside container: just serve
# Access the mdBook at http://<IP>:3000

Option C: Local Installation

If you prefer to install dependencies locally on your machine:

Prerequisites:

• Rust/cargo (For building/serving mdBook)
• markdownlint-cli2 (For linting markdown files)
• GNU Aspell (For spell checking) - Note: For macOs you can use Homebrew to install aspell. Just run brew install aspell.
• just (For running commands)
• Docker (Optional: For running the devcontainer)
• GitHub CLI (Optional: For using gh to interact with GitHub)

Setup:

1. Install all prerequisites listed above
2. Clone the repository:

   git clone https://github.com/security-alliance/frameworks.git
   cd frameworks && git checkout develop
   

3. Start the development server:

   just serve
   

(Optional) Authenticate with GitHub CLI: The GitHub CLI (gh) is already preinstalled in the devcontainer. You can authenticate by running gh auth login in the terminal, making it easy to interact with GitHub directly from your development environment.

Local Development with mdBook

If you want to locally experiment with mdBook, you can run just serve which will automatically run mdBook when installed, serving the project for local viewing.

Handling the Summary

Because of how we handle the .org and .dev domains in different branches, the main outline in src/SUMMARY.md is generated on the fly, based on config/SUMMARY.develop|main. You'll notice both differ - in .org we only publish reviewed frameworks, while in .dev we include most everything.

If you need to modify the outline for a framework, please make sure to update it accordingly in config/SUMMARY.develop.

You may explore existing issues or open a new one for missing content, although a PR is preferred. If you identify missing or unfinished content, feel free to open a PR. First, check existing PRs or branches to make sure your work is not redundant.

Attribution and Tags

Most pages have tags below the heading and a way to add attribution and filtering.

Page Tags

Tags like "Community Manager", "SRE", etc. help categorize content and make it discoverable. To add tags to your page, include them in the frontmatter:

---
tags:
  - Engineer/Developer
  - Security Specialist
  - Devops
  - SRE
---

Tags are currently in an exploratory phase. They are displayed at the top of each page and are also used for filtering and navigation throughout the site.

Attribution

Contributors are managed through a centralized system:

1. There's a contributor 'database' at src/config/contributors.json, where you add contributors or get their information from.

2. The file src/config/using-contributors.md contains all the information needed to understand how to add them to your pages.

To add contributors to a page, you can use frontmatter as shown in the using-contributors guide:

---
title: Your Page Title
contributors:
  - role: wrote
    users: [mattaereal, charlie_dev]
  - role: reviewed
    users: [fredriksvantes, zedt3ster]
---

Structure and collaboration

The book is supposed to cover all important parts of security for web3 projects. For contributors, we recommend focusing on specific topics contained in corresponding pages. It's best to own a single topic and work out all the details. Create a new page and add the category to the sidebar if it's not there yet. Join the discord server, let others know what you are working on in the group channel and collaborate with other contributors writing about related topics. If you are working with multiple people on a significant piece of content, you can have a dedicated branch in the repo for easier coordination.

Style guide

Wiki pages follow standard Markdown with some extensions by mdBook.

The audience of this wiki is technical and the content should reflect that. There are many guides on technical and documentation writing you can learn from, for example you can check this lecture to get started.

Here are main guidelines to follow when writing this wiki:

• Write in an objective, clear and explanatory tone
• Avoid unnecessary simplifications, describe the technical reality
• Avoid using too long and complex sentences or paragraphs
  • Use concise and clear statements
  • Break down your text using block-quotes, bullet points or images
• Always link your resources and verify them
• Use bullet points or tables for topics which require enumerating
• Highlight keywords to support scanning and skimming through the article
• Provide visualizations to explain the topic better
• When using acronyms or a technical jargon, make sure to introduce it first
• Web3 is changing fast, write the content to be as much future proof as possible
• Don't use LLMs to generate the text
  • We don't accept texts fully generated by AI, however we recommend using it to fix grammar or phrasing
• Consider creating tutorials and hands-on guides documenting technical steps
• Add recommended reading at the top, point to topics which are dependencies of yours
• You can use mermaid diagrams for visualizations

Goal is to produce a credible neutral text which is formal, well-structured, and maintains a clear progression of ideas. The content should be purely technical and shouldn't waste space on introducing high level/well known concepts. Introductory topics are necessary and can use comparisons, historical anecdotes, and concrete examples to make complex concepts more accessible.

Content standardization

The wiki uses American English over British spelling. Terminology, capitalization and nomenclature should match across all pages. Use Ethereum.org guide for the reference.

Usage of images and visualizations is encouraged. If you are using an image created by a third party, make sure its license allows it and provide link to the original. For creating your own visualizations, we suggest excalidraw.com.

Feel free to use emojis or icons where it fits, for example in block-quotes.

Linking resources

When adding an external link, you can use it directly in the text or on the bottom of the page in "Resources" section.

When linking resources use descriptive names, such as inevitableeth.com instead of generic phrases like this wiki.

Don't overwhelm reader with too many resources within the text.

When linking a page within this framework, use a relative path and if it references specific topic within the page, use a link to heading IDs.

For other important links, add a section on the bottom of the page with list of resources. Resources should have a name or short description with a link and alternative link to its archived mirror. We strongly suggest adding a link to the latest snapshot from archive.org.

In-page notices

We use block-quote notices at the top of the page to provide readers with appropriate context regarding the content of the page.

Incomplete pages

Pages with minimal content which need more work to cover the topic need to include a notice:

⚠️ This article is a stub, help the framework by contributing and expanding it.

Anything else?

This page is also opened for contributors! Suggest improvements to our style and guidelines in the github repo.

About this page

Originally based from the Ethereum Protocol Fellows

Contributors

This is the current list of individuals who have made substantial contributions to the project and deserve recognition.

Stewards

What is a Framework Steward?

A framework steward is the champion and caretaker for an individual security framework (most frameworks here are currently available for adoption). This role goes beyond casual contribution. It's about taking ownership and helping guide the framework's development through community engagement.

The Steward's Role

A framework steward is a project management role, responsible for:

• Rallying collaborators: Recruit contributors who share your passion for specific security challenges
• Managing contributions: Help triage GitHub issues and coordinate improvements
• Advocating for adoption: Work with SEAL to promote your framework within your networks and the broader Web3 community
• Creating content: Work with SEAL to write blog posts, host workshops, or share best practices related to your framework
• Representing the community: Be a voice for practitioners who use and rely on these standards

The core SEAL team will support you throughout this journey, helping you focus on specific challenges rather than drowning in administrative tasks.

Why Become a Steward?

Recognition and Growth

• Earn achievement badges: Receive public recognition with roles like Security Framework Ambassador or DAO Safeguards Steward
• Build your reputation: Establish yourself as a thought leader in Web3 security
• Develop new skills: Gain experience in open-source governance, technical writing, and community building

Tangible Benefits

• Access exclusive events: Receive tickets to security conferences and invite-only Security Alliance gatherings
• Showcase your expertise: Get featured through SEAL's official channels, including our blog and social media
• Connect with peers: Build relationships with other security professionals who share your interests

Lasting Impact

• Shape industry standards: Help develop frameworks that could become foundational to Web3 security
• Prevent security incidents: Your work will directly contribute to a safer ecosystem
• Leave a legacy: Carve your name into the DNA of Web3 security practices for years to come

Stewardship in Action: What It Looks Like

Time Commitment

Being a steward doesn't mean giving up your day job. We're looking for contributors who can dedicate approximately 3 hours per week to their framework. This might include:

• Reviewing pull requests and GitHub issues
• Participating in sporadic steward meetings
• Creating occasional content or presentations
• Engaging with the community on Discord

Support Structure

You won't be working alone. You will have:

• Access to a dedicated channel on our Discord server
• Coordination calls with the SEAL team as needed
• Documentation templates and contribution guidelines
• Access to technical advisors when needed

How to Apply

Ready to become a framework steward? Here's how to get started:

1. Review the proposed frameworks at frameworks.securityalliance.org and identify which one aligns with your expertise and interests.
2. Join our steward candidates Telegram channel and introduce yourself to let us know which Framework you want to adopt.

We're looking for diverse perspectives and experiences, and you don't need to have decades of experience. Passion, dedication, and a willingness to learn are just as important.

Join Us in Building a Safer Web3

The "Adopt a Framework" campaign isn't just about improving documentation. You'll be part of a movement where security becomes a shared responsibility across the Web3 ecosystem.

By becoming a steward, you're taking an active role in preventing the next major hack, protecting user funds, and ensuring that innovation can continue without compromising safety.

We're just getting started, and we need your expertise.

Have questions about the stewardship program or ideas for improving it? You can use the potential stewards Telegram channel for that too! 🙂