ISO/TR 23576:2020

TECHNICAL ISO/TR
REPORT 23576
First edition
2020-12
Blockchain and distributed ledger
technologies — Security management
of digital asset custodians
Reference number
©
ISO 2020
© ISO 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative reference . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Basic description of a model of online system for digital asset custodianship .3
5.1 General . 3
5.2 Example of a system for digital asset custodians and its functional components . 3
5.3 Examples of transactions . 5
5.4 Description of keys used for signature and encryption . 6
5.4.1 Type of keys . 6
5.4.2 Flow for key generation and key usage . 6
5.4.3 Using multiple keys . 8
5.4.4 Suspension of keys . 8
5.5 Characteristics of digital assets held in DLT / blockchain systems . 8
5.5.1 General. 8
5.5.2 Importance of signature keys . 8
5.5.3 Diversity of implementations . 9
5.5.4 Possibility of blockchain forks . 9
5.5.5 Risks for unapproved transactions .10
6 Basic objectives of security management for digital asset custodians .11
7 Approaches to basic security controls .11
8 Digital asset custodians’ risks .12
8.1 General .12
8.2 Risks related to the system / platform of the digital asset custodian .12
8.2.1 General.12
8.2.2 Signature key risks .13
8.2.3 Risks on asset data .16
8.2.4 Risks related to suspension of systems and operations .17
8.3 Risks from external factors . .17
8.3.1 General.17
8.3.2 Risks related to the internet infrastructure and authentication infrastructure .18
8.3.3 Risks inherent to digital asset DLT systems / blockchains .18
8.3.4 Risks arising from external reputation databases and anti-money-
laundering regulations .19
9 Consideration on security controls of digital asset custodians .20
9.1 General .20
9.2 Basis for considerations about security management .20
9.3 Considerations about security controls on digital asset custodians .21
9.3.1 Guidelines for the information security management .21
9.3.2 Information security policies .21
9.3.3 Organization of information security.21
9.3.4 Human resource security .22
9.3.5 Asset management .22
9.3.6 Access control .22
9.3.7 Security controls on signature keys .24
9.3.8 Physical and environmental security .28
9.3.9 Operations security .28
9.3.10 Communications security .30
9.3.11 Supplier relationships .32
9.3.12 Information security incident management .32
9.3.13 Information security aspect of business continuity management .32
9.3.14 Compliance .33
9.4 Other digital asset custodian system specific issues — Advance notice to user for
maintenance .34
Bibliography .35
iv © ISO 2020 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 307, Blockchain and distributed ledger
technologies.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
Introduction
A digital asset custodian holds customers' digital assets for safekeeping in order to minimize the risk
of their theft or loss. This document illustrates the security risks, threats, and measures which digital
asset custodians consider, design, and implement in order to protect the assets of their customers, based
on best practices, existing standards and research. For example, the management of signature keys for
digital assets requires special attention, taking into account the specific nature of blockchains and DLT
systems and the security challenges they face. A key topic discussed is the appropriate management of
signature keys by digital asset custodians in order to prevent misuse and transactions by unauthorized
individuals.
vi © ISO 2020 – All rights reserved

TECHNICAL REPORT ISO/TR 23576:2020(E)
Blockchain and distributed ledger technologies — Security
management of digital asset custodians
1 Scope
This document discusses the threats, risks, and controls related to:
— systems that provide digital asset custodian services and/or exchange services to their customers
(consumers and businesses) and management of security when an incident occurs;
— asset information (including the signature key of the digital asset) that a custodian of digital assets
manages.
This document is addressed to digital asset custodians that manage signature keys associated with
digital asset accounts. In such a case, certain specific recommendations apply.
The following is out of scope of this document:
— core security controls of blockchain and DLT systems;
— business risks of digital asset custodians;
— segregation of customer’s assets;
— governance and management issues.
2 Normative reference
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 22739, Blockchain and distributed ledger technologies — Vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 22739 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
digital asset custodian system
system that holds customers' digital assets for safekeeping in order to minimize the risk of their
theft or loss
Note 1 to entry: In this document, holding assets is considered in a broad sense, as it includes for instance, the case
of physically or digitally storing the assets, but also the case of holding the private keys associated with the assets,
or even the case of protecting access to the assets, like holding one of the keys protecting the access to the assets.
3.2
cold wallet
cold storage
offline application or mechanism used to generate, manage, store, or use private and public keys
3.3
hot wallet
hot storage
online application or mechanism used to generate, manage, store, or use private and public keys
3.4
hardware wallet
wallet which leverages a hardware device (e.g. HSM) to generate, manage, store, or use private and
public keys
3.5
deterministic wallet
wallet in which multiple key pairs are derived from a single starting point known as a seed
3.6
hierarchical deterministic wallet
deterministic wallet (3.5) in which child key pairs are derived from the master key pair
Note 1 to entry: Descendant key pairs can be derived from the child key pairs, in a hierarchical manner, hence
the name of the wallet. Child key pairs can be used and shared without having to share the master key pair. It is
defined within Reference [7].
4 Abbreviated terms
AML anti-money laundering
API application programming interface
APT advanced persistent threat
CFT countering financing of terrorism
DLT distributed ledger technology
DNS domain name system
FATF Financial Action Task Force
FQDN fully qualified domain name
HSM hardware security module
SMS short message service
ISMS information security management system
ISP internet service provide
KYC know your customer
OS operating system
OWASP Open Web Application Security Project
PII personally identifiable information
2 © ISO 2020 – All rights reserved

PKI public key infrastructure
PoW proof of work
TLS transport layer security
5 Basic description of a model of online system for digital asset custodianship
5.1 General
In this clause, an example implementation for an online digital asset custodian system is presented.
This model will then be used to explain the concepts and provisions in this document. However, it is
also worth noting that other types of custodian systems exist. For example, decentralized exchanges
(DEXs), have quite a different implementation compared to the one illustrated in Figure 1. Furthermore,
protocols like atomic swap and multisignature can be considered a type of custodian as well. Therefore,
although most of the content of this document applies to any kind of custodian, some of the risks and
potential controls discussed may or may not apply to other types of custodian systems.
5.2 Example of a system for digital asset custodians and its functional components
Figure 1 shows an example model for a digital asset custodian system.
Figure 1 — Basic example model of a digital asset custodian
Table 1 — Functional components of a digital asset custodian
Functional components Explanation
Interface (web application, APIs) Provides screen and input functions such as login, account management (deposit/
withdrawal) and trading for the customers (users). The most common interfaces
are web applications, APIs, and mobile apps.
Customer authentication function Performs user authentication for login purposes to the system.
Customer credential database Manages required IDs for login and verification information related to user au-
thentication process (e.g. password verification information).
Table 1 (continued)
Functional components Explanation
Transfer validation function Verifies the granted permission to proceed to the transfer of digital data or assets
by the owner or co-owners when the transfer implies the validation of multiple
parties. For example, the use of multisignatures schemes to validate an authorized
outgoing transaction.
Customer assets management A group of functions which provide customer account management. For example,
function these functions perform deposits or withdrawals (output coins) and, more gen-
erally, other asset manipulation processes according to user instructions. The
functions provided may refer to or update asset data.
DLT / Blockchain node A node in a DLT / blockchain system, which communicates with its peers (i.e.
other nodes).
Incoming transaction manage- Verifies transactions stored in DLT / blockchain to confirm whether incoming
ment function assets refer to the specified addresses.
Updates the asset database according to the transaction retrieved from the DLT
/ blockchain.
Order processing function A group of functions for the management of sales instructions from customers.
The order processing function performs actions related to trading of digital assets.
This function refers to and updates asset data.
Assets database Manages the record of assets both for fiat currencies and digital assets. The asset
database does not include the signature keys for signing transactions. These are
managed separately from the assets for each customer.
Transaction Transaction Generates transactions to be sent to the DLT / blockchain based on instructions
signing mod- generator from the customer asset management function or the custodian’s operation function.
ules
Transaction Sends the signed transaction to the DLT / blockchain. Transactions are broadcasted
broadcaster to blockchain nodes through network protocols.
Transaction Generates digital signatures based on the instructed transaction contents using
signing func- the relevant signature key (i.e. IDs and addresses).
tion
Address Manages verification keys related to the signature keys, or to addresses (i.e. such
management as values calculated from the verification keys).
function
Signature key Manages the signature keys of the digital assets (i.e. the keys used for the sig-
management nature of the transactions). Signature keys may be stored in a cold wallet as a
function security measure.
Signature key Generates signature keys. The generated keys are registered in the signature key
generator management function, and the verification keys and addresses are registered in
the address management function.
Custodian operation functions A group of functions dedicated to the custodian's operators and/or administrators.
Administrator and operators can instruct the module to perform function such
as generating new signature keys or transfer digital assets.
Operator authentication function Authenticates the operators and administrators of the system.
Operator audit database Manages auditing data related to the authentication processes of operators and
administrators for the system.
The functional components described in Table 1 are intended to logically distinguish the various
functions within the system, and do not represent an actual architecture of such a system. As
an example, in a real-world implementation, the address management function would probably
be implemented using a database. Also, there are implementations in which multiple functional
components are packaged together. All the functional components of the transaction signature system
could be integrated within the customer asset management system, or they could be operating as a
separate system. Many implementations of Bitcoin wallets provide all functions for the transaction
signature system as a single atomic system. It is also possible to imagine some of these functions being
provided by an external “subcontractor” system, such as a remote server.
4 © ISO 2020 – All rights reserved

5.3 Examples of transactions
— Fiat currency deposit
a) The customer sends fiat currency to the custodian's bank account.
b) The custodian confirms the reception of the fiat currency transfer and updates its assets
database to reflect the customer’s asset status in relation to the transfer just received.
— Digital asset deposit
a) The customer transfers digital assets to an address specified by the custodian. The transfer
is performed by using the customer’s digital assets wallet (i.e. other custodian or web/app
wallet).
b) The custodian confirms that the digital assets have been transferred to the correct address
and updates its assets database to reflect the customer’s asset status in relation to the transfer
just received.
— Trading transaction
a) The customer accesses the interface made available by the custodian and instructs the system
to perform some actions (e.g. trading).
b) The instructions to perform an action are received by the custodian and are processed by the
custodian operations functions module. The result of the trade operations is processed by the
custodian operations functions module which updates the asset database accordingly.
— Customer digital asset withdrawal
a) The customer accesses the interface made available by the custodian and instructs the system
to transfer their digital assets to another address (i.e. output coins).
b) The instruction to output coins is processed by the customer assets management functions
module. The transaction generator creates a transaction message based on the received
instructions such as receiving address and the amount of digital assets to transfer.
c) The transaction message will be digitally signed by the transaction signing functions module.
d) The signed transaction message is delivered to all nodes on the DLT / blockchain by the
transaction broadcaster module.
— Internal transfer by operator or administrator
a) The administrator or operator instructs the system to transfer digital assets to another
address through the custodian operations functions module. For example, the digital assets
may be sent between addresses managed within the custodian.
b) The instructions to output coins are then processed by the custodian operations functions
module. The transaction generator creates a transaction message based on the received
instructions such as receiving address and the amount of digital assets to transfer.
c) The transaction message will be digitally signed by the transaction signing functions module.
d) The signed transaction message is delivered to all nodes on the DLT / blockchain by the
transaction broadcaster module.
5.4 Description of keys used for signature and encryption
5.4.1 Type of keys
Table 2 describes the different types of keys which can be used for signature and encryption within a
digital asset custodian system.
Table 2 — Types of keys
Types Description
Signature key A signature key for signing transactions (for digital signature schemes standard-
ized in ISO/IEC 9796 (all parts) and ISO/IEC 14888 (all parts))
Verification key A public key for verification of transactions (for digital signature schemes
standardized in ISO/IEC 9796 (all parts) and ISO/IEC 14888 (all parts))
It is common practice in public blockchains to calculate addresses as unique values
derived from the verification key. In private DLT systems / blockchains this may
not be necessary
Encryption/decryption key for Secret key (symmetric key cryptography) used to keep signature key confidential
signature key / protected
Master seed A seed to generate a signature key in a deterministic wallet
5.4.2 Flow for key generation and key usage
Figure 2 shows a typical lifecycle for the different type of keys described in Table 2.
Figure 2 — Lifecycle of signature key, verification key and encryption/decryption key for
signature key
6 © ISO 2020 – All rights reserved

After a pair of keys (signature and verification, hereafter "key pair") is generated, an address, which
will be used to receive transactions, is derived from the verification key. A sender will only need this
address to be able to transfer one or more assets to it.
A signature key is considered inactive, when it is stored in a manner in which it cannot directly be used
to sign (i.e. if it is encrypted). As an example, within the key management function module in Figure 1,
a signature key could be encrypted using a pass phrase, rendering it inactive. Decrypting the signature
key will return the key in an active state.
In the example model presented in Figure 1, the activation of a key is assumed to be executed within
the transaction signing function module. Activation and deactivation of keys are standard functions
provided by most wallets. The signature key is only needed when a transaction needs to be signed.
Therefore, these can be stored offline for increased security, until needed. On the other hand, verification
keys and addresses are stored online as they are needed more often for verification purposes.
Figure 3 — Lifecycle of the signature key, verification key and encryption/decryption key for
signature key in a deterministic wallet
A deterministic wallet uses a mechanism by which after generating one master seed, multiple signature
key pairs are derived from it. Figure 3 shows the lifecycle of the different types of keys within a
deterministic wallet. On the one hand, by backing up and restoring the master seed, all derived
signature key pairs can be recalculated. On the other hand, if the master seed is compromised (i.e.
stolen), all crypto assets which are managed by any of the derived keys (and related addresses) may
be stolen as well. Also, if the master seed is lost, the derived signature key pairs cannot be recalculated
and access to the assets managed by these will be impossible.
An extension to the deterministic wallet model is provided by the hierarchical deterministic wallet (HD
wallet). In a HD wallet, a master key pair is created from the master seed, and child key pairs are derived
from the master key pair. Descendant key pairs can be derived from the child key pairs, in a hierarchical
manner, hence the name of the wallet. Since child key pairs can be derived from parent key pairs, it is
not necessary to access the master seed when generating the child key pairs. The possibility of using
HD wallets will depend on the signature algorithm used by the digital asset in question. Therefore, for
some digital assets it will not be possible to use HD Wallets.
Although this document refers mainly to the security control measures for managing signature keys,
it is noted that the master seed needs an equal, if not higher, security management compared to
signature keys.
5.4.3 Using multiple keys
Digital asset systems (e.g. Bitcoin) recommend or enforce the fact of not using the same key pair twice,
thus producing multiple key pairs. This feature prevents easy tracking and tracing of transactions, and
also protects against possible attacks on used keys, but is not relevant to the business efficiency of a
digital asset custodian. Digital asset custodians, as part of the management of customers’ addresses,
may need to support this kind of scenario. Within a digital asset custodian, a user may have one address
or multiple addresses. The number of addresses and key pairs the custodian will have to support will
depend on the type and number of digital assets managed and on the method with which they are
managed. For example, if a digital asset custodian is managing assets which allow inserting tags related
to transactions such as Ripple or NEM, it may use only one address and distinguish different customers
using the tags. On the other hand, where digital assets which cannot contain tags are managed, a
custodian may use a separate address for each customer, in which case the number of addresses and
key pairs would increase, or the custodian may rely on less addresses and additional balance sheets
to track the ownership of assets per user, in which case potential errors or transparency issues may
arise. The risk evaluation regarding the use of multiple addresses will depend not only on the type and
quantity of digital assets (e.g. Bitcoin, Ethereum, etc.) but also on the use of hot and cold wallets.
5.4.4 Suspension of keys
The suspension of a key is an operation which is specific to digital asset custodians. By definition, in any
DLT / blockchain-based digital asset system, no user (or system) can cancel a transaction once it has
been made. Therefore, digital asset custodians are encouraged to be cautious when revoking signature
keys, even after the suspension of a key. For example, if a user accidentally sends some digital assets to
a suspended address, the suspended / revoked key would be needed to make the reimbursement.
5.5 Characteristics of digital assets held in DLT / blockchain systems
5.5.1 General
Digital assets based on DLT / blockchain systems have some unique characteristics compared to
general information systems and also from the traditional use of signature / encryption keys. When
considering the risk assessment described in Clause 8 and the security requirements and measures
described therein, these unique characteristics will require particular attention.
5.5.2 Importance of signature keys
As described in 5.3, by signing and transmitting a transaction with the signature key, it is possible to
transfer digital assets from one address to another. Once this transaction is written to a block in a
blockchain or to a ledger in a distributed ledger, and is approved, it will not be possible to revert or
revoke it. In order to remedy the transaction an equal inverse transaction would be necessary. This is
in contrast with how digital payments work today, in which a payment process is completed only once
settled and can be cancelled or voided before it completes.
8 © ISO 2020 – All rights reserved

This procedure can be followed as long as the remittance is not complete, despite typically requiring
considerable administrative overhead. In addition, if a signature key were to be lost or eliminated
the digital assets associated with the corresponding address would be inaccessible and could not
be transferred to any other address. The irreversible nature of transactions in digital asset systems
requires paying extreme attention to theft, fraudulent use and elimination of signature keys.
5.5.3 Diversity of implementations
5.5.3.1 General
There are numerous digital assets (i.e. 5 500 listed on https:// coinmarketcap .com on 23/05/2020)
of which Bitcoin is just one implementation. The specifications vary widely between different digital
assets. For example, there are differences in the encryption algorithms and hash functions used, in
the methods of generating / transmitting transactions, in the wallet implementations to protect the
signature key(s), to name a few. Due to these differences in specifications, effective countermeasures for
one digital asset may not be effective or even possible for another one. Also, thanks to the hype-driven
trend in digital assets, the appearance of new assets, and the functional expansion and specification
change of existing assets, happen at an extremely fast pace.
5.5.3.2 Cryptographic algorithms of digital assets
There have been cases in which new cryptographic algorithms, which have not been sufficiently
reviewed in terms of security, have been adopted by digital asset systems. Normally, when using
cryptographic technology, designers tend to use cryptographic algorithms and techniques which
have been scientifically verified, mathematically proven, and approved by official authorities /
agencies. Instead digital assets designers are sometimes known to adopt “immature and unverified”
cryptographic algorithms. To have cryptographic algorithms proven for security and approved by
official authorities / agencies requires a lot of time. This seems mostly incompatible with the blockchain
/ distributed ledger world in which competition is extremely high, and evolution is extremely fast,
therefore technology with low maturity is often used to gain competitive advantage with respect
to other digital assets. In some cases, the algorithms used have not been carefully reviewed in their
implementation, and therefore, the risk of vulnerabilities being discovered at a later stage and being
compromised is very high (compared to mature algorithms).
5.5.4 Possibility of blockchain forks
5.5.4.1 General
In blockchains using PoW, such as Bitcoin, in some cases a temporary fork of the chain can arise.
This is mainly due to two factors: specification change of software (i.e. the blockchain client), or the
reorganization which takes place during normal operation. Instead, in other cases, for example due to
the division of the developer community around a digital asset, a blockchain can be divided at a specific
point in time, and form two completely separate chains (i.e. hard fork) from then onwards, which most
of the time are operated as different digital assets entirely (e.g. Bitcoin and Bitcoin Cash). In the digital
asset world, various forks have already been executed and it may be difficult to adapt or respond to all
of them and each fork may introduce separate risk factors to be countered.
5.5.4.2 Rolling back due to reorganisation
When re-organisation of a chain occurs the orphan blocks and transactions are discarded. In this case,
the transactions which are discarded, as a consequence of the reorganisation, will not be reflected in the
main chain. This is one of the reasons for which a transaction in Bitcoin is considered truly confirmed
after it has passed a least six blocks. Note that transactions that have been discarded due to a fork can
still be included in subsequent blocks.
5.5.4.3 Handling forks of digital assets
As mentioned previously, there have been real-world examples of hard forks in which the two resulting
chains have been managed separately and as a different crypto asset. This has happened both with
Bitcoin and Ethereum. The forked coin is derived from the same underlying technology as the original
coin, but sometimes new features or changes are implemented in the forked chain therefore it is not
always compatible with the original one.
The two chains, until the fork, are identical (i.e. contain the same exact data and history of transactions).
This exposes the forked chain to replay attacks. A replay attack is an attack in which transactions
used in the original digital asset chain are retransmitted to the sender of the transaction in the forked
chain (which will exist thanks to the shared history), or vice versa, therefore illegally acquiring digital
assets. To countermeasure these attacks, monitoring techniques can be used to prevent these types of
transactions.
Also, if the fork occurs on a digital asset held by a custodian, the user may not have access to the forked
digital asset (of which they will have the same amount as the original) unless the custodian supports
the forked digital asset and assigns it to the user.
5.5.5 Risks for unapproved transactions
5.5.5.1 General
The action of signing and transmitting a transfer transaction to a DLT / blockchain node does not
instantly reflect the actual transfer of the assets. In order to approve a transaction, the transaction
needs to be stored in a block or ledger record which is created at set or variable time periods (e.g.
average of ten minutes for Bitcoin), and then the block needs to be accepted by the majority of mining
nodes. 5.5.5.2 and 5.5.5.3 provide some examples of cases in which a transaction may not be approved.
5.5.5.2 Handling unapproved transactions
Various implementations of digital assets (e.g. Bitcoin, Ethereum, etc.) which use a blockchain or
a distributed ledger allow or require a fee to be specified when transmitting a transaction. The
transaction fee is rewarded to the miner that creates the new block or ledger record containing that
transaction. The higher the fee the more interesting it is for a miner, and therefore the higher the
probability of the transaction being approved as soon as possible (i.e. in the first new block or ledger
record). If a low or even null fee is sent with the transaction it may take a long time to get approved, or
there is also a possibility in some cases, that the transaction will never be approved at all. In addition to
transaction fee related issues, temporary forks, as described in 5.5.4.2, can produce transactions which
are never authorized and are dropped (i.e. orphan transactions). Finally, double spending attacks can
create a second transaction which causes the first original transaction to not be approved.
In scenarios where digital asset transfer is required immediately, such as payment for goods in a store,
it may not be possible (or desirable) to wait for a transaction to be approved, and therefore it might be
necessary to take the risk of accepting unapproved transactions.
5.5.5.3 Transaction failure due to vulnerabilities from digital assets specifications and
implementations
Although not technically a case of unapproved transactions, in earlier versions of Bitcoin there was a
vulnerability called transaction malleability. This vulnerability allowed malicious nodes to manipulate
submitted transactions, effectively changing their transaction ID, and then retransmitting them with a
different transaction ID, trying to make this transaction approved before the original one. This has the
effect that the sender will not be able to find the original transaction ID and could be inclined to send the
same amount again, effectively paying double. It is important to point out that this attack is performed
after the transaction is transmitted to the chain, therefore the sender has no way of preventing this.
The Bitcoin network has introduced a protocol upgrade called segregated witness, which solves this
vulnerability. So, although this vulnerability is no longer present, it highlights an important issue, which
10 © ISO 2020 – All rights reserved

is the fact that security threats will not always be addressable by the custodian in its role of sender or
receiver but might depend on vulnerabilities in the protocols of the digital assets they have in custody.
6 Basic objectives of security management for digital asset custodians
The basic objectives of a security management system for digital asset custodians are to establish,
maintain and continuously improve a security-providing environment for the assets they protect. Items
described in ISO/IEC 27001:2013 can be considered as general requirements for a security management
system applied to the processes of a digital asset custodian. More specifically some key aspects are
recommended to be taken into careful consideration due to the nature of the services provided by a
digital asset custodian:
— Stakeholders (see ISO/IEC 27001:2013, Clause 4)
Protection of customers’ assets is of paramount importance, especially given that these may include
customers’ private keys. This requires a well-defined and well-understood division of responsibilities
between the customer and the custodian.
— Security policy (see ISO/IEC 27001:2013, Clause 5)
A security policy which includes security objectives and controls, as described in the following clauses,
is a key objective for digital asset custodians. Disclosure to customers of the security policies related to
digital asset management can have a beneficial impact and facilitate self-evaluation.
— Continuous risk evaluation and improvement (see ISO/IEC 27001:2013, Clauses 6, 8, 9 and 10)
Continuous risk monitoring specific to digital assets in addition to aligning the general security
management framework is considered best practice, because risks change and increase frequently due
to the rapid development of the underlying technology as described in 5.5.3.
7 Approaches to basic security controls
The following viewpoints are considered to be most relevant when formulating security objectives and
controls for digital asset custodian systems:
— countermeasures to loss, theft, leaks, and general abuse of customers’ asset data and signature keys;
— business requirements;
— compliance to laws and regulations;
— social responsibilities to prevent crimes such as the use of digital assets for scams and / or money
laundering.
Security controls commonly used by digital asset custodians include:
— conducting a threat analysis;
— conducting a vulnerability and ri
...