CryptoCurrency Security Standard

This document defines the CryptoCurrency Security Standard (CCSS), a

set of technological and procedural requirements for the secure handling of
bitcoin, cryptocurrencies and related data within a platform, business or
organization.
CCSS was first introduced on February 11, 2015, created in a
collaboration between CryptoCurrency Certification Consortium (C4), and BitGo,
Inc. with input from industry security experts and chief security officers at leading
companies.
C4 is responsible for ensuring CCSS is maintained and updated as best
practices and technologies evolve, and is kept open for anyone to use to improve
security in the cryptocurrency industry.

CCSS:1

Page 1 of 23

Table of Contents
Version History........................................................................................................3
Introduction.............................................................................................................4
Summary.................................................................................................................5
Overview.................................................................................................................5
Levels......................................................................................................................7
Level I..................................................................................................................7
Level II.................................................................................................................7
Level III................................................................................................................7
Aspects...................................................................................................................8
Key/Seed Generation..........................................................................................8
Wallet Creation....................................................................................................9
Key Storage.......................................................................................................11
Key Usage.........................................................................................................12
Key Compromise Policy....................................................................................14
Keyholder Grant/Revoke Policies & Procedures...............................................15
Third-Party Security Audits / Penetration Tests................................................16
Data Sanitization Policy....................................................................................17
Proof of Reserve...............................................................................................18
Audit Logs.........................................................................................................18
Conclusion............................................................................................................19
Appendices...........................................................................................................20
Appendix A Audit Checklist............................................................................20

CCSS:1

Page 2 of 23

Version History
0.33, 2015-01-30 Mike Belshe, BitGo Review and content edits
0.32, 2015-01-27 John Velissarios, Armory Enterprise Security Review and
content edits
0.30, 2015-01-20 Michael Perklin, C4 + Joshua McDougall, C4 Added
Fire/Flood/EMP controls, updated draft with feedback from
industry peers, and added checklist to Appendix A
0.20, 2015-01-07 Michael Perklin, C4 Updated draft with additional feedback
0.15, 2014-11-27 Michael Perklin, C4 Updated draft with first round of
industry feedback
0.10, 2014-11-03 Michael Perklin, C4 Completed first draft
0.05, 2014-11-03 Joshua McDougall, C4 Filled in details of many aspects
0.04, 2014-11-02 Will OBrien, BitGo Review and content edits
0.03, 2014-10-29 Michael Perklin, C4 Updates based on peer review
0.02, 2014-10-27 Michael Perklin, C4 Initial Draft for discussion purposes
0.01, 2014-10-10 Michael Perklin, C4 Document Skeleton
#.##, YYYY-MM-DD Author Name, Organization Version Comment

CCSS:1

Page 3 of 23

Introduction
Security is an evolution that requires constant updates to address new
threats. In the development of the commercial Internet, technologies like
TLS/SSL were invented by businesses to address a market need. The best of
these ideas emerged into standards and were embraced by leading web
companies and harnessed by service providers to build security platforms like
Verisign. The human and system processes for deploying these technologies
also became certifiable standards that could be audited. Once standards were in
place, the Internet ecosystem was able to thrive, and we experienced rapid
growth in e-commerce and web-based innovation.
As we begin 2015, Bitcoin sits at a similar stage of development as the
Internet in 1994. There is substantial merchant adoption, venture capital
financing, and company creation. However, the security of Bitcoin remains
fragmented and brittle because nearly every company in the industry is creating
their own custom security models, and many are taking dangerous shortcuts.
The result of this inconsistent and immature approach to security has
resulted in notable theft and loss, such as the collapse of leading Bitcoin
exchange MtGox, and the recent ~19,000 BTC theft from BitStamp. These
security breaches of course harm the employees, customers and shareholders of
these companies, while the industry as a whole loses credibility with each new
event. Although some companies are employing sophisticated technology and
techniques to secure customer funds, other companies ignore the risks and
operate without necessary protection of digital assets.
The security of digital and physical assets has been standardized in every
financial industry around the world including banking, stocks, bonds, and
commodities. In order for the cryptocurrency space to meet the security demands
of customers, a common industry standard is required.
Through a collaboration between BitGo, Inc., a company committed to
building high-security bitcoin platforms, and CryptoCurrency Certification
Consortium (C4), a not-for-profit organization dedicated to the standardization of
the cryptocurrency industry, the CryptoCurrency Security Standard (CCSS) was
authored and published. Additional input was provided by Armory Enterprise
Security.

CCSS:1

Page 4 of 23

This standard will be a catalyst for the next phase of growth for Bitcoin and
cryptocurrencies. Companies that comply with the standard will instill more
confidence in their customers, investors, and business partners. Traditional
players like auditors and insurance carriers will see this standard as a pathway
for them to engage in the industry, much like predecessors SAS70/SSAE-16
engendered a vibrant ecosystem for the Internet.
The simple goal of this standard is to collect and define the current best
practices and give Bitcoin organizations a bar to meet when holding digital assets
for their customers.

Summary
CryptoCurrency Security Standard (CCSS) is a set of requirements for all
information systems that make use of cryptocurrencies. By standardizing the
techniques and methodologies used by systems around the globe, end-users will
be able to easily make educated decisions about which products and services to
use and with which companies they wish to align.
CCSS is designed to complement existing information security standards
(i.e. ISO 27001:2013) by introducing guidance for security best practices with
respect to cryptocurrencies such as Bitcoin. CCSS is not designed to substitute
or replace these standards. As with any standard, knowledgeable and
experienced security professionals and/or auditors are necessary when
implementing any information system to ensure coverage of all classes of attack
as well as the appropriate handling of all potential risks.

Overview
CCSS covers a list of 10 security aspects of an information system that
stores, transacts with, or accepts cryptocurrencies. An information system is a
collection of technologies (hardware and/or software), personnel, policies and
procedures that work together to provide a secure environment. A security aspect
is a discrete technique of securing one piece of an information system. The
minimum value of all 10 aspects determines an information systems overall
score within three (3) levels of increasing security: Level I is the lowest and offers
strong security measures, while Level III is the highest and offers the most
comprehensive security.

CCSS:1

Page 5 of 23

These 10 aspects are organized into 2 domains that help structure the
guidelines. A summary of the standard can be expressed with the CCSS Security
Matrix, which is provided on the next page:

CCSS:1

Page 6 of 23

Figure 1 - CCSS Overview

CCSS:1

Page 7 of 23

Levels
CCSS is broken into three (3) levels of increasing security. Details of these
are outlined in this section.

Level I
An information system that has achieved Level I security has proven by
way of audit that they protect their information assets with strong levels of
security. Most risks to the systems information assets have been addressed by
controls that meet industry guidelines. While this is the lowest level within CCSS,
it still represents strong security.

Level II
An information system that has achieved Level II security has proven by
way of audit that they exceed strong levels of security with additional enhanced
controls. In addition to covering most risks to the information systems assets, the
use of decentralized security technologies such as multiple signatures have been
employed which exceed industry guidelines and provide redundancy if any one
key or person becomes unavailable or compromised.

Level III
An information system that has achieved Level III security has proven by
way of audit that they exceed enhanced levels of security with formalized policies
and procedures that are enforced at every step within their business processes.
Multiple actors are required for all critical actions, advanced authentication
mechanisms ensure authenticity of all data, and assets are distributed
geographically and organizationally in such a way to be resilient against
compromise of any person or organization.

CCSS:1

Page 8 of 23

Aspects
CCSS is comprised of 10 aspects, each of which represents a different
piece of the information systems security. These aspects, their descriptions, and
the possible values are explained in this section.

Key/Seed Generation
This aspect covers the generation of cryptographic keys and seeds that
will be used within a cryptocurrency system. The secure creation of cryptographic
keys and seeds requires two things to be secure: privacy and un-guessable
numbers. Privacy is required to ensure that the newly created keys or seeds are
not read/copied by an unintended party. Un-guessable numbers are required to
ensure the newly created key cannot be guessed or determined by an unintended
party. Each of the goals listed below provide assurance that the keys and/or
seeds are created in a private and un-guessable manner.
The 3 Levels associated with this aspect are as follows, building on top of
one another:
I. The following goals must be met to classify as Level I:

The cryptographic keys and seeds are created by the actor

who will be using it. This ensures privacy of the key as the
only person/system that will ever hold it is the one that will
use it. Any system that involves one actor creating a key or
seed and then giving it to another actor for use will fail to
achieve Level I.

II. In addition to the Level I goals above, the following goals must be met
to classify as Level II:

CCSS:1

The key or seed generation methodology is validated prior to

use. Software that is used to generate seeds should be free
from any features that restrict the generated seed to conform
to deterministic values, or features that store or transmit the
generated seed to another party. Once this assertion has
been made, a digital signature should be validated prior to
each use to ensure the software has not been altered since it
passed its security audit. In cases where keys or seeds are
created without the use of software (i.e. dice, a deck of
Page 9 of 23

cards, or other non-digital means), the creation methodology

should be validated to ensure determinism is not present (i.e.
there are no weighted dice, each card in the deck is unique,
etc.)
III. In addition to the Level II goals above, the following goals must be
met to classify as Level III:

The key or seed is generated using a Deterministic Random

Bit Generator (DRBG) that conforms to NIST SP 800-90A,
and has been seeded with at least two separate
cryptographically secure sources of entropy that have been
combined in a cryptographically secure manner (i.e.
SHA256[UnguessableFactor1 + UnguessableFactor2]). NIST
SP 800-90A is a standard that ensures that deterministicallygenerated numbers follow a random distribution with respect
to a deterministic seed. Thus, the ability to determine these
random numbers lays in the ability to discover the DRBGs
seed.

Optionally, instead of a NIST SP 800-90A compliant DRBG

with a combination of two seeds as specified above, the key
or seed may also be generated by a Non-deterministic
Random Bit Generator (NRBG), or a True Random Number
Generator (TRNG) that passes industry-standard statistical
tests for randomness such as Diehard, Crypt-X, or NIST
STS.

Wallet Creation
This aspect covers the creation of wallets or cryptocurrency accounts
(addresses) that can receive cryptocurrencies. Wallets are created using key
signing methodologies that can require a single keys signature, multiple keys
signatures, or a minimum number of signatures from many keys. Furthermore,
wallets can be created individually (commonly referred to as JBOK wallets, or
Just a Bunch Of Keys) or in a deterministic way that allows a set of
addresses/key pairs to be created from a single master seed.
Security of wallet creation is derived from the integrity of the wallet in the
face of various risks such as a lost/stolen/compromised key, and the

CCSS:1

Page 10 of 23

confidentiality of the wallet that would make it difficult to associate a wallet with a
particular actor. The three levels associated with this aspect are as follows:
I. The following goals must be met to classify as Level I:

Unique wallets must be generated for every transaction. This

enhances privacy by making it more difficult to determine
which wallets belong to which entities. One of the most
common methods of implementing this requirement is to use
a deterministic seed for all wallets.
In addition, systems that enforce new wallets for every
transaction implicitly prevent cases where a compromised
wallet continue to receive funds from actors who are not
informed about the compromise as was seen in the days
following the BitStamp compromise of early 2015.

II. In addition to the Level I goals above, the following goals must be
met to classify as Level II:

CCSS:1

Wallets must require a minimum of 2 signatures in order to

spend funds, where a separate actor holds each key.
Requiring 2 or more signatures on a wallet increases the
integrity of funds by reducing the risk of theft associated with
a compromised key or key holder. This is commonly referred
to as a multi-sig wallet. The actors can either be human or
system (i.e. two humans, two systems, or one human and
one system) but must be separate entities that each manage
their own key for the wallet.

Redundant keys are assigned to each wallet for recovery

purposes. This ensures that the funds are still available in
the event one of the primary keys becomes inaccessible for
any reason. One common method of achieving this goal is to
create a wallet that requires any 2 of 3 possible signatures in
order to spend funds (i.e.: there is 1 redundant key)

Wallets are assigned deterministically based on a seed that

is kept private. Using JBOK wallets requires regular backups
of each new key that is generated which increases the
complexity of the system and raises the risk of human error
that can cause disruptions to the business or accidental loss
Page 11 of 23

of funds if a backup does not include certain keys. Wallets

that are assigned deterministically remove this risk and
improve the integrity of the system.

Keys that have signing authority on a single wallet must be

stored in different locations. By separating the wallets keys
across multiple locations, the risks associated with localized
disruptions to business (i.e. fire, flood, earthquake, breakins) do not affect the organizations ability to spend funds.

III. In addition to the Level II goals above, the following goals must be
met to classify as Level III:

Keys that have signing authority on a single wallet must be

stored by multiple organizational entities. By giving keys to
separate legal entities, such as lawyers, accountants, or
other businesses, legal risks that can disrupt your business
will not necessarily disrupt your funds.

Key Storage
This aspect covers how cryptographic private keys and seeds are stored
when not being used. To maximize the confidentiality of keys/seeds, they should
be stored in as secure a manner as the business will allow and make use of
strategies such as encryption, secret sharing, and physical locks where
appropriate. To maximize the integrity of keys/seeds, backups should exist that
allow the keys/seeds to be recovered in the event the primary keys become
inaccessible. Care should be taken to ensure that backups are stored with at
least as much security as the primary keys, if not more. The three levels
associated with this aspect are as follows:
I. The following goals must be met to classify as Level I:

CCSS:1

Cryptographic keys and/or seeds must be stored with the

use of strong encryption when not in use. Strong encryption
is defined as using an industry-standard encryption algorithm
with an encryption key that would take the estimated global
combined computing power 1,000x more time to brute force
than the expected life of the key or seed. An example of an
encryption algorithm that would provide the necessary level

Page 12 of 23

of security at the time of this writing (and potentially for the

next few decades barring the discovery of a new attack
vector) is AES-256.

A backup of the cryptographic key/seed must exist. The

backup can take any form (paper, digital, etc.).

The backup must be protected against environmental risks

such as fire, flood, and other acts of God. While the specific
mechanisms of environmental protection may change
depending on the type of medium used for backup, in
general, common methods to achieve this include a watertight bag for flood protection and a safe or firebox for fire
protection.

II. In addition to the Level I goals above, the following goals must be
met to classify as Level II:

CCSS:1

A backup must exist for at least as many keys as is required

to spend funds. For example, in a 2-of-3 signing setup where
any two of three keys are required to spend funds, backups
must exist for at least 2 of these keys. In a 5-of-9 setup,
backups must exist for at least 5 keys.

The backup key/seed must be stored in a location that is

geographically separate from the usage location of the
primary key/seed. For example, if you use the primary key at
work, the backup key can be stored at home but not at work.
Another example includes leaving the backup in escrow with
a trusted 3rd party.

The backup must be protected by access controls that

prevent unauthorized parties from accessing it. Examples of
this include safes, safe deposit boxes, or locked drawers
where only the operator holds the key/combination for the
lock.

The backup must employ some form of tamper evident

mechanism that allows an operator to determine when it has
been accessed. A secure method of achieving this involves a
serial-numbered tamper-evident bag, however properly
sealed paper envelopes with handwritten signatures over the
Page 13 of 23

seal could also suffice provided the specific envelopes in use

are able to reveal evidence of tampering.
III. In addition to the Level II goals above, the following goals must be
met to classify as Level III:

Backups of cryptographic keys and/or seeds must be stored

with the use of strong encryption when not in use that is at
least equal to the security prescribed for cryptographic
keys/seeds above. If backups use a less-secure mechanism
than the key/seed itself, the system should not be certified as
Level III

Backups are resistant to electromagnetic pulses that could

induce currents in electronics and damage the data stored
within. A common methodology to secure against this risk is
to store the seed in Extended Key format on paper, wood,
metal, or on another non-digital medium, or to place the
digital medium within a sealed faraday bag designed to
protect contents from electro-magnetic interference.

Key Usage
This aspect covers the use of cryptographic keys and/or seeds to ensure
they are used in a secure manner that minimizes the risks to the confidentiality of
private keys and integrity of funds. This section does not cover the usage of key
backups which are only used in the event the primary key is
lost/damaged/inaccessible. A variety of risks are present when using keys that
can lead to the loss of funds including dirty signature vulnerabilities (i.e. re-used
R values), opportunity for malware to copy or modify keys, and malicious
insiders who use their authorized access to send unauthorized transactions. The
three levels associated with this aspect are listed below along with the security
goals for each level.
I. The following goals must be met to classify as Level I:

CCSS:1

Access to the primary key/seed requires a username,

password, and at least 1 (one) other factor of authentication,
which restricts access to the authorized operator. This other
factor of authentication can take any form provided it

Page 14 of 23

identifies the authorized operator. Common forms of

supplementary authentication include a Google
Authenticator token, a digital signature from a private key, inperson verification by a guard, the possession of a physical
key thats required to access a locked container, or a
countersigning organization who can remotely attest to the
authenticity of the key holder.

CCSS:1

Keys/seeds are only used in trusted environments. This

reduces the risks of unauthorized copies being made by
malware and key loggers, as well as the risk that the key
may remain resident on a machine, allowing it to be
recovered by another user. A trusted environment guards
against unauthorized persons learning private keys,
passwords, or other sensitive information. Trusted
environments include a machine owned by the organization
with appropriate antivirus/anti-malware software installed, a
machine owned by a keyholder, or other machine upon
which the organization permits the use of keys/seeds.
Furthermore, trusted environments involve minimum forms of
access control to prevent shoulder surfing of keyboard and
screen by unauthorized individuals. Public machines such as
those in Internet cafes, libraries, and other public spaces are
not trusted environments.

Key/seed holders have had their references checked prior to

being trusted to hold one of the organizations keys/seeds.
This helps ensure the person is being truthful about their
past and were not dismissed from prior employment for
reasons that would represent a risk to the organization.

No two keys/seeds of the same wallet are ever present on

the same device. Placing two keys of the same wallet on a
single device exposes the keys to information leakage by
either a malicious operator or malicious software. Ensuring
every key of a wallet is used on dedicated devices reduces
these risks, thereby increasing security.

Digital signatures must use a k value that is never repeated.

This can be accomplished through the use of a deterministic
Page 15 of 23

random bit generator (DRBG) that is compliant with NIST SP

800-90A, or a deterministic scheme compatible with RFC
6979. Using strong sources of un-repeated numbers is
required in order to prevent dirty signature vulnerabilities
that can allow attackers to recover the private key that was
used to compute the signature. A common implementation of
this is to use the pseudo-random number generator (PRNG)
supplied by popular operating systems, or an RFC 6979compatible scheme.
II. In addition to the Level I goals above, the following goals must be
met to classify as Level II:

Key/seed holders have undergone identity verification to

ensure they are who they say they are. This reduces the
risks associated with impersonation and social engineers
gaining access to organizational or customer funds.
Identities must be verified with at least two forms of
government-issued identification (drivers license, passport,
etc.) and two proofs of residency at the persons home (utility
bills, bank statements, etc.).

Verification is performed of fund destinations and amounts

prior to key/seed use. This can be performed by humans
before using their keys/seeds to ensure theyre sending the
right amount of funds to the right
addresses/people/companies, or by systems that perform
automated signing by checking destination addresses
against whitelists and spending limits before the signature is
applied. The implementation of payment protocols that
provide digitally signed addresses, or the use of systems that
display images and business names instead of
cryptocurrency addresses greatly simplify this verification
process.

III. In addition to the Level II goals above, the following goals must be
met to classify as Level III:

CCSS:1

Access to the key/seed requires a username, password, and

at least 2 other factors of authentication. Similar to the

Page 16 of 23

requirement of 1 additional factor in Level I, the other two

factors of authentication in Level III can take any form that
provides confirmation of an authorized users identity. Two
factors of authentication in addition to username and
password help provide additional security that discovered
keys, passwords, or authenticator tokens cannot be used by
unauthorized individuals to gain access to organization or
user funds.

Key/seed holders have background checks performed by law

enforcement personnel or investigative firms. This ensures
each key/seed holder is who they say they are and does not
have evidence in their past of actions that would represent a
risk to the organization if they had signing authority on
organization or user funds.

Key Compromise Policy

This aspect covers the existence and use of a policy that dictates the
actions that must be taken in the event a cryptographic key/seed or its
operator/holder is believed to have become compromised. Organizations must be
prepared to deal with a situation where a private key has even potentially
become known, determinable or destroyed. Proper policies and procedures to
govern these events decrease the risks associated with lost funds and disclosed
trade secrets, and increase the availability of the information system to its users.
As a critical aspect, the lack of a KCP will prevent an organization from achieving
Level III certification.
The three Levels associated with this aspect are as follows:
I. Internal Knowledge: An inventory of all keys/seeds exists, and
awareness of which keys are critical to the successful operation of
the information system exists within the organization. While no formal
KCP documents exist, there are staff members who are able to direct
operators in the procedures necessary to regenerate cryptographic
keys, regenerate cryptocurrency wallets, and send funds to these
newly-generated wallets in the event any operator or their keys
become compromised;

CCSS:1

Page 17 of 23

II. Detailed Key Compromise Policy: A proper Key Compromise

Policy outlines each specific class of key used throughout the system
along with a detailed plan of dealing with its compromise. The plan
identifies actors via roles and not names and includes secondary
actors in the event any primary actor is unavailable to carry out the
KCP;
III. Regular Tests and Revisions: Tests of the Key Compromise Policy
are executed regularly to confirm the viability of the procedures and
to ensure staff remain trained to use them in the case of a
compromise. Improvements identified during the tests are written
back into the policy to ensure the most effective and efficient policy is
always maintained. As changes are made to the information system,
the Key Compromise Policy is revisited to assure it is updated with
any new class of key;

Keyholder Grant/Revoke Policies & Procedures

This aspect covers the policies and procedures surrounding granting and
revoking access to cryptographic keys that protect organizational or end-user
funds. Staff typically have greater access to an information system with respect to
accessing its information, invoking privilege-restricted actions, and representing
the organization to the public. Improper management of the onboarding and
offboarding of personnel introduce risks of privileged accounts remaining when
staff depart, as well as unrevoked keys that persist signing authority for certain
transactions.
The three values associated with this aspect are as follows:
I. Permission Changes Handled Internally: An awareness of how
roles should be managed when onboarding or offboarding staff from
keyholder positions exists within the organization. A staff member
who is knowledgeable about the system is able to ensure that
permissions are granted/revoked to/from the affected staff
appropriately;
II. Checklists for On/Offboarding: The organization maintains
checklists that cover all tasks that must be completed when staff
vacate or transition into keyholder roles within the organization.
These checklists have been reviewed by knowledgeable personnel to
CCSS:1

Page 18 of 23

ensure least privilege principles are applied to the information

system, as well as necessary access where required. This eliminates
the risks associated with missed privileges and the possession of unrevoked keys;
III. Checklists with Audit Trail: The organizations checklists include
auditing information that record the identity of the staff member that
performs the grant/revoke operations. Each entry within the audit trail
is attested to by the staff member who performed that task;

Third-Party Security Audits / Penetration Tests

This aspect covers third-party reviews of the security systems, technical
controls, and policies that protect the information system from all forms of risk as
well as penetration tests designed to identify paths around existing controls.
Regardless of the technical skills, knowledge, and experience of staff who build
and maintain an information system, it has been proven that third-person reviews
very often identify risks and control deficiencies that were either overlooked or
underestimated by staff. For the same reasons that development companies
require different people to test a product from those who write it, different people
than those who implement a cryptocurrency system should assess its security.
Third parties provide a different viewpoint and are independent of the technical
controls and can be objective without risk of retaliation;
The three values associated with this aspect are as follows:
I. Internal Security Assessment: A developer who is knowledgeable
about bitcoin security has assisted in the design and implementation
of the information system. Having this knowledge available during the
design and implementation stages helps ensure best practices are
followed to minimize risk;
II. Pre/Post Launch Audit: A single audit and/or penetration test has
been completed by a third-party entity prior to or shortly after launch. The audit covered both static and dynamic analysis of source
code to ensure secure programming patterns were used wherever
applicable, and cryptographic libraries were used properly wherever
they have been employed. In addition, documentation shows that all
concerns raised by the audit have been addressed by the systems

CCSS:1

Page 19 of 23

team in order to remove the concerns from the system. These audits
decrease the risks associated with institutional blindness and provide
confidence in the organizations controls and procedures;
III. Regular Audits: Security audits and/or penetration tests are
performed on a defined schedule of at least once per calendar year,
and documentation exists that shows how each of the concerns
within the audit were addressed. Regular audits/penetration tests not
only reduce the risks of unknown deficiencies in security but also
reduce the overall cost of security as each audit builds on top of the
last ones results allowing for a more focused and cost effective
assessment;

Data Sanitization Policy

This aspect covers the removal of cryptographic keys from digital media.
Due to the manner in which file systems allocate data on digital media, digital
forensic techniques can be employed to read old data that has previously been
deleted. Proper sanitization of digital media ensures the proper removal of all
keys, eliminating the risk of information leakage from decommissioned devices
like servers, hard disk drives, and removable storage;
The three values associated with this aspect are as follows:
I. Staff Awareness: The organizations staff is aware of how data
persists on digital media after deletion. Staff also have access to
tools that perform secure deletion of data and understand when to
use such tools to permanently destroy any transient copies of
cryptographic keys that may be required during the maintenance of
the information system
II. Sanitization Policy: A detailed policy outlining the requirements for
sanitization of digital media that holds/held cryptocurrency keys exists
and is read/understood by all staff who have access to cryptographic
keys. Procedure documents outline where sanitization is required in
their processes;
III. Sanitization Policy with Audit Trails: In addition to the above, an
audit trail is maintained for every piece of sanitized media. These
audit documents identify the staff member who performed the
sanitization, the specific identifiers of the media that was sanitized,

CCSS:1

Page 20 of 23

which tool and configuration was used to perform the sanitization,

and all other relevant pertinent information;

Proof of Reserve
This aspect covers the proof of control of all funds that should be held by
the information system. There have been known cases where information
systems that should be operating with a full reserve of user funds have been
operating with a fraction of that reserve instead leading to an inability of the
system to cover simultaneous withdrawals by all users. These proofs of reserve
provide assurance to the public that all funds are available to the system which
eliminates the risks of fund loss;
The three values associated with this aspect are as follows:
I. Proof of Reserve Audit Completed: An audit has been completed
and published online that proves full control of all funds held by the
information system. The audit has been signed by an independent
party that attests to the accuracy of the audit at the time it was
performed which reduces the risks associated with inaccurate or
misleading reports;
II. Regularly-Scheduled PoR Audits: The organization conducts
regularly-scheduled proof of reserve audits that provide proof that the
organization continues to operate on a full reserve and that all user
funds are accessible at the time each audit is completed;
III. No PoR Audits Necessary (Open Ledger): The information system
is designed in such a way that an independent audit is not necessary
to prove complete accessibility of user funds. The information system
makes use of public ledgers such as blockchains themselves to make
this information available to the public allowing anyone to conduct an
audit independently;

Audit Logs
This aspect covers the information systems maintenance of audit logs that
provide a record of all changes to information throughout the system. In the event
of unexpected behaviour or security incidents, audit logs are an extremely

CCSS:1

Page 21 of 23

valuable tool that can help investigators understand how the unexpected
symptoms occurred and how to resolve the inconsistencies to return the
information system to a consistent state. The maintenance of audit logs
significantly reduce the risks associated with operational awareness and increase
the information systems ability to correct any inaccuracies.
The four values associated with this aspect are as follows:
I. Partial Audit Logs: Audit trails exist for a subset of actions that are
performed within the information system. Examples of this would
include recording audit information of all withdrawals and deposits
made with the system;
II. Full Audit Trail of All User Actions: All actions by all users are
logged. These records provide significant assistance to investigations
into unexpected behaviour of the information system and can help
identify malicious actors and responsible systems or persons;
III. Full Audit Trail with Backup: In addition to recording all actions
performed within the system, this audit information is regularly
backed up to a separate server. This act helps preserve valuable
investigative information in the event the audit log is altered/destroyed
during an attack on the information system;

Conclusion
Securing an information system goes beyond simply choosing a fullfeatured piece of wallet software. It doesnt matter how secure the technology is if
the users arent properly trained in its use, or if proper procedures arent followed
to protect sensitive pieces of information.
CCSS provides a framework for organizations and developers to work
within to ensure their software and services meet a standard level of security, as
well as providing auditors and assessors a common methodology so that
systems can be graded consistently by anyone who understands the standard.

CCSS:1

Page 22 of 23

Appendices
Appendix A Audit Checklist

CCSS:1

Page 23 of 23