CCSS Draft Proposal

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 20

Table of ContentsVersion History......................................................................................................3Introduction............................................................................................................4Summary...............................................................................................................5Overview...............................................................................................................5Levels....................................................................................................................7

Level I................................................................................................................7Level II...............................................................................................................7Level III..............................................................................................................7

Aspects..................................................................................................................8Key/Seed Generation........................................................................................8Wallet Creation..................................................................................................9Key Storage.....................................................................................................11Key Usage.......................................................................................................12Key Compromise Policy...................................................................................14Keyholder Grant/Revoke Policies & Procedures.............................................15Third-Party Security Audits / Penetration Tests...............................................16Data Sanitization Policy...................................................................................17Proof of Reserve..............................................................................................18Audit Logs........................................................................................................18

Conclusion...........................................................................................................19Appendices..........................................................................................................20

Appendix A – Audit Checklist...........................................................................20

CCSS:1 Page 2 of 20

Version History

0.33, 2015-01-30 – Mike Belshe, BitGo – Review and content edits0.32, 2015-01-27 – John Velissarios, Armory Enterprise Security – Review and

content edits0.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 feedback0.15, 2014-11-27 – Michael Perklin, C4 – Updated draft with first round of

industry feedback0.10, 2014-11-03 – Michael Perklin, C4 – Completed first draft0.05, 2014-11-03 – Joshua McDougall, C4 – Filled in details of many aspects0.04, 2014-11-02 – Will O’Brien, BitGo – Review and content edits0.03, 2014-10-29 – Michael Perklin, C4 – Updates based on peer review0.02, 2014-10-27 – Michael Perklin, C4 – Initial Draft for discussion purposes0.01, 2014-10-10 – Michael Perklin, C4 – Document Skeleton#.##, YYYY-MM-DD – Author Name, Organization – Version Comment

CCSS:1 Page 3 of 20

IntroductionSecurity 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.

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.

CCSS:1 Page 4 of 20

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.

SummaryCryptoCurrency 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.

OverviewCCSS 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 system’s 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.

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 5 of 20

Figure 1 - CCSS Overview

CCSS:1 Page 6 of 20

LevelsCCSS 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 system’s 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 system’s 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 7 of 20

AspectsCCSS is comprised of 10 aspects, each of which represents a different

piece of the information system’s 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:

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 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:

CCSS:1 Page 8 of 20

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 deterministically-generated 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 DRBG’s 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 key’s 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 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:


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.


CCSS:1 Page 9 of 20

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 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 wallet’s keys across multiple locations, the risks associated with localized disruptions to business (i.e. fire, flood, earthquake, break-ins) do not affect the organization’s ability to spend funds.


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

CCSS:1 Page 10 of 20

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:


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 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 water-tight bag for flood protection and a safe or firebox for fire protection.


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 seal could also suffice provided the specific envelopes in use are able to reveal evidence of tampering.


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.


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 identifies the authorized operator. Common forms of supplementary authentication include a Google Authenticator token, a digital signature from a private key, in-person verification by a guard, the possession of a physical key that’s required to access a locked container, or a


countersigning organization who can remotely attest to the authenticity of the key holder.

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 organization’s 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 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 6979-compatible scheme.


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 (driver’s license, passport, etc.) and two proofs of residency at the person’s 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 they’re 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.


Access to the key/seed requires a username, password, and at least 2 other factors of authentication. Similar to the 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 user’s 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;

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 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 un-revoked keys;

III. Checklists with Audit Trail: The organization’s 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;


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 system’s team in order to remove the concerns from the system. These audits


decrease the risks associated with institutional blindness and provide confidence in the organization’s 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 one’s 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;


I. Staff Awareness: The organization’s 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, 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;


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 system’s 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 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 system’s 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;

ConclusionSecuring an information system goes beyond simply choosing a full-

featured piece of wallet software. It doesn’t matter how secure the technology is if the users aren’t properly trained in its use, or if proper procedures aren’t 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.


Appendices

Appendix A – Audit Checklist


Documents

CCSS Draft Proposal