General Security and Privacy Guidelines, version 2

Purpose

Security failures in blockchain are often made possible, or even more likely, by inadequate operational security.

The General Security and Privacy Guidelines (GSP) is a set of requirements that defines baseline risk management, security, and privacy requirements relevant to all participants in blockchain.

These guidelines provide a subset of requirements provided in other recognized security standards such as [ISO 27001], [SOC2] or [CCSS] that are specifically targeted to blockchain operations. These requirements are categorized according to the NIST Cybersecurity Framework [NIST-CSF], to follow a standard taxonomy for addressing blockchain-based security and privacy concerns.

Important: It is not possible to provide a security guarantee for working with blockchains. Meeting the requirements in these guidelines does not constitute such a guarantee, it simply identifies that the organization has taken reasonable care to protect itself from operational risks and is thus less likely to encounter operational issues or be maliciously exploited.

Please see also the Disclaimer of Warranty and Liability below.

Audience

This specification is directed at several audiences.

Primarily, people who are managing security for organizations, and looking for a standard that reflects industry best practices.

People who are looking to hire a security expert, whether as an employee or a third-party contractor, can expect them to be reasonably familiar with the requirements in this specification, and to be able to explain the rationale and implementation strategies.

Security reviewers or auditors can make use of the specification, whether making a formal assessment of conformance, or for providing general guidance on what to implement.

Scope

These Guidelines are intended to be applied by organisations working with blockchains, in order to make that part of their operations more secure.

1. Govern

Appropriate governance structures, and in many case documentation of those structures and evidence that they are applied in practice, is an important part of addressing multiple risks: These include regulatory compliance failures, poor market reputation, and a heightened risk of attacks specifically targeted at organizations with weak governance.

To ensure appropriate governance especially from a security perspective:

Manage Blockchain among Risks
Organizations SHOULD take Blockchain-specific security risk into account in the organization's overall risk-assessment, -management and -accounting processes.

Manage Blockchain Risks
Organizations SHOULD maintain a risk management governance framework, including a risk register, which includes regular reviews with stakeholders.

Dedicate Governance Resources
Organizations SHOULD assign organizational resources to manage governance and compliance.

Individuals familiar with relevant standards such as this one, with the authority and capacity to monitor the organization's conformance to them and to ensure it is maintained, are necessary to obtain the associated benefits. Compliance needs maintenance and regular assessment - a single effort to reach compliance is only of fleeting value, and outdated compliance is almost as reputationally damaging as a failure to ever achieve it.

Define Data Risks
Organizations SHOULD define data classification tiers, criteria for assigning a tier, access restrictions to higher tiers, and protection requirements per tier.

Maintain Public Compliance Information
Organizations SHOULD maintain a publicly accessible "trust center" that includes compliance documentation, privacy policy, and other pertinent information.

Regulatory and Ecosystem Monitoring

Monitor Regulation
Organizations SHOULD monitor and adapt to evolving global and local regulatory frameworks that impact blockchain operations, such as Anti-Money Laundering (AML), asset classifications, cross-border transactions etc.

Manage Vendor Relationships
Organizations SHOULD conduct and document a vendor relationship management process when working with vendors and other third-parties.

Supply Chain attacks are a significant source of risk. If a vendor is compromised, malicious, or simply goes out of business, it is important to know what part of an organization's operations are threatened and how to replace the relevant services.

Monitor Cryptographic Standards
Organizations SHOULD monitor and incorporate developments in cryptographic standards, including post-quantum cryptography guidance from NIST and other authoritative bodies, into the organization's risk management framework.

2. Identify

Inadequate risk assessment and threat identification underpins many security failures. In the context of blockchains, where attractive assets are potentially exposed to malicious actors or loss through operational error, failure to identify risks often means inadequate preparation leads to significant loss of assets, and consequently reputation. It is important that these assessments are kept up to date with changes both within the organization and in the external ecosystem where the organization operates.

To identify and understand cybersecurity risks:

Monitor Blockchain Risk
Organizations SHOULD conduct regular risk assessments that address blockchain-specific risks.

Some risks are related to organizational capacity, such as increasing time-to-fix for identified vulnerabilities. Others are external, such as newly-discovered compiler vulnerabilities or the like.

Document Risk to Customer Funds
Organizations SHOULD document all risks associated with customer funds and make that documentation readily accessible.

Assess Ecosystem Risk
Organizations SHOULD deliberately assess ecosystem and external risks.

Failures in critical systems that subtantial parts of the ecosystem depend on, such a centralised cloud storage/computing providers used by large proportions of an ecosystem have exposed entire networks to major disruption through seemingly localised failures. Major disasters such as a war or natural disaster leading to loss or incapacitation of multiple key staff, or systemic dependencies on specific asset classes that are assumed to be reliable but are subject to values shocks can likewise create a "black swan" event, albeit one that could be foreseen in principle.

Threat Intelligence

Monitor Threat Intelligence
Organizations SHOULD subscribe to and integrate threat intelligence data from reputable sources.

Actively Hunt Threats
Organizations SHOULD conduct regular documented threat hunting activities.

Ordinary activity logs can provide indicators of external threats such as repeated failed access attempts from a source that does not subsequently succeed and behave as a normal authorized entity.

Share Threat Intelligence
Organizations SHOULD establish protocols for sharing information about threats with other blockchain organizations and industry stakeholders

Code Analysis

Monitor Production Code
Organizations SHOULD perform dynamic code analysis on all production code

Dynamic analysis can help identify runtime vulnerabilities, and resilience against real-world attacks, that might not be revealed by static analysis alone.

Analyze Code
Organizations SHOULD perform static code analysis on all code before deployment

Static code analysis is an important tool to identify potential bugs or vulnerabilities.

Monitor Dependencies
Organizations SHOULD inventory and monitor third party dependencies for existing and newly published Common Vulnerabilities and Exposures (CVE).

Vulnerability Management

Document Vulnerability Management
Organizations SHOULD formally document and define procedures for network and application vulnerability management, with monthly vulnerability assessments conducted.

3. Protect

Malicious actors seeking to attack an organization will actively search for the least-protected part of that system. In addition, ensuring that data and operational processes are protected is likely to identify internal operational risks, which have caused multi-billion-dollar failures in blockchain organizations.

To adequately protect systems and manage cybersecurity risks:

Access Control

Implement Least Privilege
Organizations SHOULD implement the Principle of Least Privilege, applied to all functions that can impact the correct expected behavior of the system.

Review All Access
Organizations SHOULD review access to production systems and applications annually, with privileged access being reviewed at least once every six months.

Restrict PII Access
Organizations SHOULD restrict access to sensitive data and Personally Identifiable Information (PII) to users with a legitimate business need.

Review Individual Access
Organizations SHOULD revise individuals' access to corporate and production systems when their roles change.

This includes cases such as termination of an employee or of a contractor, or a change in status meaning that new access is required or existing access is no longer required.

Verify Privileged Access
Organizations SHOULD require additional verification for all privileged (administrator) access, and maintain documented procedures to specifically audit and limit privileged use and users.

Perform Background Checks
Organizations SHOULD perform enhanced background checks, additional to those completed during initial onboarding, on those whose privileged access includes access to customer funds, that are refreshed periodically.

Training and Awareness

Provide Training
Organizations SHOULD require all staff to complete annual security awareness training that covers at least how to handle sensitive data, phishing, and social engineering.

Provide Security Training
Organizations SHOULD provide developers with additional Secure Software Development LifeCycle (SSDLC) training that incorporates security guidance and best practices relevant to their area of practice.

Data Protection

Prevent Exfiltration
Organizations SHOULD implement and maintain a Data Loss Prevention (DLP) solution to detect and prevent exfiltration of sensitive data through mediums including email, web storage, and removable media (USB, etc.).

Protect Customer Data
Organizations SHOULD implement controls to prevent customer data from being exported or copied from production systems, unless explicitly required by a business workflow, in which case, care must be taken to ensure minimization of both the data copied, and of any additional access granted to these data.

Infrastructure Security

Manage Key Material Securely
Organizations SHOULD implement the requirements of the BSSC Key Management Standard [KMS], or equivalent.

Private Keys are a fundamental security technology for all blockchains, so ensuring that they are available to those who need to be able to use them, them and not at risk of compromise or misuse by a malicious third party is crucially important. The BSSC Key Management Standard [KMS] is one of several available standards that describe how to mitigate against possible loss or malicious attack and misuse of private keys.

Use Secure Communication Channels
Organizations SHOULD deploy secure communication channels and authentication mechanisms for both internal and external communication.

Communication channels are often subject to attack, whether through eavesdropping on communications or social engineering approaches such as phishing. It is important to take a realistic approach to communications, and understand how it really happens - if official methods are "too cumbersome", very often people will resort to an informal side channel that enables them to communicate efficiently. This can increase the risk of a security breach.

Set Password Standards
Organizations SHOULD document and implement password standards across all production and corporate systems that at a minimum addresses length and complexity.

Software Security
Organizations SHOULD ensure the integrity and security of software components and dependencies used in blockchain applications.

Error Handling
Organizations SHOULD incorporate robust error handling, input validation, and fallback mechanisms to ensure resilience against receiving malformed or malicious data into all systems that rely on third-party data (e.g., from APIs).

Managed Devices
Organizations SHOULD ensure all devices (laptops, mobile, etc.) that connect directly to corporate or production systems are enrolled in and centrally managed by an MDM solution that can perform security posture assessments, force minimum hardening requirements, and remotely wipe the device in the event of loss or theft.

Anti-virus
Organizations SHOULD implement and maintain a solution for all web applications and internet facing systems to detect and prevent common threats including DDoS, malware, malicious bot traffic, and viruses.

Event Logs
Organizations SHOULD log all security events within production systems and applications.

Cryptographic Security

4. Detect

Failure to detect an attack in time can come about through lack of identification of a risk, or lack of appropriate detection systems. These failures, alongside a failure to promptly activate a response, can make the difference between an attack being completely thwarted, and catastrophic organizational failure.

To identify and promptly detect cybersecurity threats:

Continuous Monitoring

Use Real-time Monitoring
Organizations SHOULD employ real-time threat monitoring services.

Use Breach Detection
Organizations SHOULD implement and maintain a breach detection solution to detect anomalous or potentially malicious activity that alerts security staff and activates the relevant Incident Response Plan

Security Assessment

Review Software Security
Organizations SHOULD perform and document security reviews and assessments of all produced software (on-chain and off-chain).

Repeat Penetration Testing
Organizations SHOULD conduct independent third party penetration testing on your corporate network and production systems, including all external facing applications, at least once every 12 months.

Vulnerability Reporting

Enable Responsible Reports
Organizations SHOULD provide a mechanism for external security researchers to responsibly report vulnerabilities.

Process Vulnerability Reports
Organizations SHOULD maintain and use a process to triage and remediate reported vulnerabilities.

5. Respond

How effectively an organization responds to an attack can determine whether it will be in a position to recover, or whether it will be destroyed. Response plans depend on accurately identifying and being able to deploy critical resources promptly. Because they often need to work under pressure, with some information unavailable, it is important that they are carried out by staff who are already familiar with all the necessary resources and actions.

To effectively respond to and take action against cybersecurity incidents:

Test and Update IRP
Organizations SHOULD test and update your IRP regularly (annual minimum), and train key security staff on the procedures contained within.

6. Recover

Major security incidents often have a significant impact, causing a business to fail either immediately or within a relatively short period. Recovery plans are designed to ensure a business can restore assets, operations, and their reputation.

To provide the best chance of successful recovery from a cybersecurity incident:

Document Continuity Plans
Organizations SHOULD document a business continuity plan for critical business processes to ensure timely recovery and minimize downtime in the event of an unplanned disruption.

Document Recovery Plans
Organizations SHOULD document a disaster recovery plan for all critical applications with defined Recovery Time Objectives to bring the applications back online, Recovery Point Objectiives to recover and maintain integrity of data, and processes for failover to backup applications in the event the Recovery Time Objective is exceeded.

Maintain Updated Plans
Organizations SHOULD annually review and test both the business continuity plan and the disaster recovery plan, and test upon significant organization and or environmental changes.

7. Privacy

On-chain data is generally permanent, publicly visible, and over time becomes increasingly linkable to individuals even when no name is attached. The requirements in this section address regulatory and reputational needs to respect user privacy both in general operations and specifically when storing data on-chain.

To honor consumer and end user Privacy rights:

Comply with Privacy Regulation
Organizations SHOULD identify relevant privacy regulations, and implement processes to ensure compliance.

In many cases (such as the European Union's [GDPR], California's [CCPA] and [CPRA], or Brazil's [LGPD], as well as equivalents in many other countries) regulation applies to information covering any users in a given jurisdiction irrespective of where the organisation managing their data is located.

Wallet addresses can be linked to individual users and used to reveal transaction history and patterns, and transaction data can reveal information about individuals and financial habits/behaviors

Define PII Uses
Organizations SHOULD collect and process any type of personal data, including on-chain personal data, only for a defined, explicit, and legitimate purpose that has been clearly communicated to users.

Follow PII Policies
Organizations SHOULD use personal data only for the purpose(s) communicated. Only use on-chain personal data for explicit and legitimate purposes communicated in your Privacy Policy (it must not be further used in a manner that is incompatible with those purposes).

Renew Consent
Organizations SHOULD obtain consent from and/or provide disclosures to individuals if there is a business need to use personal data for a new purpose that is not compatible with the original purpose.

Minimize Stored PII
Organizations SHOULD design products and services such that the minimum amount of personal data necessary to meet the intended use case is stored on-chain.