Security controls only work when they address the right risks.
An entity may use an HSM, require multiple signers, restrict access to key material, and monitor its systems. Those are all important security controls, but they are only part of managing risk. An entity also needs to understand what could go wrong and whether those controls address those risks.
CryptoCurrency Security Standard (CCSS) v9.0 addresses this through threat modeling.
Requirement 2.03.2.1 requires entities to identify security threats to the CCSS Trusted Environment and use a threat model to define and implement controls that reduce residual risk to an acceptable level. The entity must also periodically review the threat model to confirm that it remains current and its controls remain effective.
The requirement also states that when a security procedure requires a defined frequency, such as reviewing audit logs, the threat model determines that frequency.
The threat model identifies security threats to the CCSS Trusted Environment, including threats involving its people, processes, and technology.
Threats to a cryptocurrency system go beyond the theft or loss of private keys. An attacker might compromise the software that builds a transaction, change transaction data before it is signed, steal an operator’s credentials, or gain access through a service provider.
CCSS v9.0 references the threat model in several other requirements, including signing configurations, audit log monitoring, service provider management, and key compromise procedures.
Requirement 1.02.1.1 addresses the use of a single-signer mechanism. The entity must consider the criticality of the wallet, the impact of losing customer funds, the effectiveness of controls protecting the wallet, and the risk of wallet compromise identified in the threat model under requirement 2.03.2.1.
When deciding whether to use a single-signer mechanism, the entity must consider the risks identified in its threat model.
Requirement 2.02.3.1 requires entities to monitor audit logs for suspicious activity, generate alerts, and have appropriate personnel address those alerts. The entity uses its threat model to determine how frequently the logs need to be monitored.
Threat modeling also affects how entities manage third parties. Requirement 2.03.3.1 applies to vendors and service providers that could affect the security of the CCSS Trusted Environment. CCSS requires entities to review applicable service providers at least annually, but the threat model may require more frequent reviews.
What can the service provider access, and what could happen if it were compromised? Those questions help determine the risk it introduces to the CCSS Trusted Environment.
Threat modeling also plays a role in preparing for key compromise. CCSS Aspect 2.04 Key Compromise Documentation requires entities to maintain a key material inventory and document a Key Compromise Policy and procedures for when key material or an operator or holder may have been compromised.
At Level 3, 2.04.2.1 requires entities to test those procedures at least annually. The testing exercise must be documented, and any improvements identified during the test must be incorporated into the Key Compromise Policy and procedures.
The threat model can also call for more frequent testing based on the threats identified under 2.03.2.1.
CCSS includes requirements for key material generation, storage, access and usage, monitoring, service providers, governance, risk, and key compromise. The threat model helps entities apply those requirements based on the risks to their systems.
The goal is not simply to ask, “Do we have security controls?” It is to ask: What are our threats? Do our controls address them? What risk remains? And what happens if those controls fail?
Threat modeling is one part of the broader approach to cryptocurrency security in CCSS v9.0. Learn more about these requirements and how they work together in the CCSS v9.0 Standard.