FEBRUARY 2020

SECURITY OF DLT NETWORKSA Distributed Ledger Technology Security Framework for
the Financial Services Industry

A WHITE PAPER TO THE INDUSTRYTABLE OF CONTENTSEXECUTIVE SUMMARY............................................................................................................................. 1
FINANCIAL SERVICES DLTs..................................................................................................................... 2
SECURITY ASSURANCE CONSIDERATIONS FOR DLTs............................................................................... 7
SECURITY BASELINE CONSIDERATIONS FOR DLTs................................................................................... 8
DLT SECURITY ASSESSMENTS................................................................................................................. 9
A DLT SECURITY FRAMEWORK FOR THE FINANCIAL SERVICES INDUSTRY................................................11

EXECUTIVE SUMMARY
The distributed ledger technology (DLT) landscape is filled with fragmentary standards and guidance with respect
to DLT-specific security considerations. Although numerous standard setting bodies have published industry-leading
security standards and guidance for traditional IT environments the adoption of DLT across the financial services
industry remains in its infancy. Organizations are still in the process of navigating the DLT landscape in order todevelop standards and guidance for DLT-specific security.
DLT provides a variety of value propositions for the financial industry. These include strengthened identity
measures, improvements in information preservation and data integrity, processing efficiencies, increased
operational capacity, and compliance effectiveness. Consequently, these potential value enhancements come witha variety of security risks.
To address these DLT security risks, the existing IT organizations, along with a plethora of new organizations, arepublishing various guides, standards, and best practices to assist with DLT security. This paper illustrates the mainareas that these guides are addressing, and highlights where there may be further opportunity in addressing
DLT-specific security risks.
To expand on the possible shortcomings of traditional IT security frameworks as applied to DLT, this paper
evaluates the intersection between traditional and DLT-specific security considerations. It is evident that many
security principles overlap in both traditional and DLT environments; however, gaps in addressing DLT-specificsecurity risks are also widely apparent. To demonstrate the proliferation of these gaps, this paper applies anexisting cybersecurity assessment to a DLT-environment. As demonstrated by the standard assessment
considerations, there are a multitude of special and additional factors to consider when operating in a DLTenvironment.
Lastly, this paper explains the importance of standards. Standards allow for DLT interoperability, agreed-upon
terminology, streamlined governance, and stronger digital identity management. The paper concludes with a call toaction, inviting all financial industry stakeholders to contribute to the best practices that will eventually develop
into an agreed-upon, industry-wide DLT security framework that may be used by the financial services sector andleveraged by other industry sectors. To establish a comprehensive and standardized DLT security approach requires
collaboration from professional organizations, the financial services sector, and its regulators.

1

FINANCIAL SERVICES DLTDLT introduces a multitude of value propositions for the financial sector. The core value propositions include
strengthened identity measures, technical components for enhanced information preservation and maintenance ofdata integrity, processing efficiencies, operational capacity and scalability, and compliance effectiveness.
This white paper highlights and expands on each of these value propositions and how they can be achieved throughthe DLT adoption. In order for the industry to realize these value propositions, the industry must develop acomprehensive and standardized approach to DLT security to ensure the confidentiality, integrity, and availabilityof an organization’s DLT operations. However, in addition to providing new value to the financial services industry,
DLT presents unique risk profiles and security exposures that must be addressed using both traditional and nontraditional methods.

IDENTITY MEASURES
Identity and access management (IAM) encompasses the processes and technologies used by an organization toauthenticate and authorize an individual to access systems or services. Traditional IAM processes and technologies
are vulnerable to loss, theft, and fraud due to the storage of personal information on centralized servers, whichbecome primary targets for hackers. Since the inception and adoption of DLT networks, multiple organizations andgovernment agencies experienced attacks leading to the theft of customer personal identification information. DLT
provides the opportunity to strengthen IAM processes through the application of cryptography and decentralization.
This strategy is especially useful when and where the subject entity does not trust the verifying entity but still has
to prove to the verifying identity that it knows specific information. In a DLT scenario, this ability allows an entity toprove that its authenticating details fulfill certain requirements without revealing the actual details being
requested.
Traditional security guidance published by organizations such as The National Institute of Standards andTechnology (NIST), International Organization for Standardization, Center for Internet Security, Control Objectives
for Information and Related Technologies, The SysAdmin, Audit, Network and Security Institute, and Internet
Security Alliance are useful in addressing security concerns for traditional IAM processes and technologies with
DLT, however additional security considerations must be identified and addressed. DLT-specific security concerns
respective to IAM generally surround the key management lifecycle, which is critical to the related lifecycle of an
identity and its corresponding access privileges in a DLT environment. For example, an IAM-with-DLT scenario
would require an organization to evaluate IAM components such as key creation, maintenance, storage, anddisposal—each of which may not be considered critical security considerations within traditional IT security
publications.
As mentioned above, decentralization also provides additional possibilities to strengthen IAM. In a distributed
environment, entities may choose to retain control of their identity, as opposed to permitting their identity to becontrolled by a third-party. Assuming the user follows basic security protocols, this can be a more reliable form ofidentification and authorization than requesting proof of identity from a third-party provider who may have security
gaps or vulnerabilities.

2

DATA INTEGRITY
Digital ledgers provide an inherent level of security through their tamper-evident and tamper-resistantcharacteristics, which is a reason they are trusted for financial transactions. With DLT, tamper evident represents
the ability to identify modifications, malicious or otherwise, to transaction records in the validation or postvalidation processes. Tamper resistance is the difficulty of modifying past transaction records that have beenvalidated and appended to a digital ledger. Tamper evident and tamper resistant characteristics are establishedthrough the use of cryptographic hash functions. Cryptographic hash functions are critical to the security andpreservation of information being processed, stored, and transferred in a DLT environment as they encrypt sensitivetransaction information such as timestamps, which preserve the order, or history, in which transactions areappended to a digital ledger. Cryptographic hash functions also encrypt digital signatures, which identify theparties involved in a transaction, as well as other sensitive
information such as digital asset quantities and amounts.
There are a number of recommended, standardized cryptographic
hash functions used across DLT environments. These standardized
functions possess inherent security properties that are expected tofunction correctly to allow for a secure DLT environment. However,these generally accepted hash functions do not come without
process difficulties and increased security risks.
For example, larger hash functions take up more space on acomputer, and therefore lead to slower processing and validation
speeds. Unreliable validation can lead to security vulnerabilities
and distrust in the network. Furthermore, as computers increase inprocessing power, standard cryptographic hash functions are
subject to functional obsolescence. For this reason, it is importantthat organizations ensure that their cryptographic hashingmechanisms are flexible to changes in the marketplace.

Use Case:
In 2019, approximately $2M worth ofdigital assets were stolen from an emerging
technology investment fund using theprivate key stored on an officer’s mobile
device. The breach allowed the hackers togain access to the officer’s hot wallet, or
digital asset storage platform connectedto the internet—in this case via mobile
device—in order to compromise the walletand gain unauthorized access to the digitalassets. This use case highlights the needfor a comprehensive DLT security approachto address all aspects of the DLT key
management lifecycle including the DLTspecific security considerations associatedwith the creation, maintenance, storage,

and disposal of sensitive key information.
Traditional guidance for standardized cryptographic hash functions
has been published by organizations such as NIST, ISO, Open Web
Application Security Project (OWASP), and The Institute ofElectrical and Electronics Engineers Standards Association (IEEE), with respect to traditional IT environments.
However, there are a multitude of DLT-specific security considerations related to cryptographic hash functions
which have not been formally addressed by professional organizations. Such DLT-specific security considerations
include comprehensive code review for DLT protocols and smart contracts, monitoring of transaction processing
volumes and times, scalability of computational resources, the key management lifecycle as it pertains to DLT andcryptography, and authenticating users and transactions via cryptographic hash functions on a distributed ledger.

3

CONSENSUS MECHANISMS
Unlike traditional distributed databases, DLT incorporates the functionality of consensus mechanisms. Consensus
mechanisms are mathematical algorithms which consist of validation rules that provide independent participants
the ability to verify the validity and integrity of transaction records being proposed to a DLT environment’s digitalledger. The ability for independent participants to reach consensus on the current state of a digital ledger supports
the maintenance of data integrity within an adversarial environment.
Consensus mechanisms are primary targets for the exploitation of DLT environments. When successfully exploited,consensus mechanisms may function inappropriately, leading to unauthorized transfers of digital assets,
unauthorized censorship of transactions, double-spending, or operational disruption to the transaction validation
process. Security must be considered at all stages of the DLT lifecycle including the design, development,
implementation, and production. DLT-specific security considerations related to consensus mechanisms include
consensus rule design, access management, separation of duties, deployment of consensus modifications,monitoring of consensus performance and prevention of attacks.

Use Case:
In 2019, a global digital asset exchange discovered a large-scale security breach where hackers stole $40M worth of digitalassets in one transaction via the compromise of a large number of application programming interface (API) keys, two-factor
authentication (2FA) passcodes, and other sensitive user account information. To obtain sensitive information, the hackers
bypassed the 2FA security algorithm, which had been used by the exchange to generate passcodes to access user accounts.
If the exchange had been aware that the 2FA security algorithm did not support the custom hash function leveraged by theexchange to encrypt the API keys, the hackers would not have been able to bypass the 2FA without having access to both theapplication and user devices. Using a 2FA security algorithm that supports a custom hash function would have forced thehackers to obtain access to both the application and the user devices in order to successfully breach the accounts in which
the stolen digital assets had been stored. This use case highlights the need for a comprehensive DLT security approach toprovide guidance and practices respective to securing account access with the use of cryptographic hash functions, standard
authentication methods, and bridging the security gap between DLT and traditional IT environments.

There are a range of consensus mechanisms that may be leveraged for DLT, each of which possess common andunique security considerations and weaknesses. One consensus mechanism often used by permissioned DLT
environments is the federated byzantine agreement (FBA), or distributed quorum. The FBA is a consensus
mechanism where DLT environment participants assign trust to other participants who have been identified astrusted by the greater DLT environment. However, no matter the degree of trust assigned to participants, theenvironment is constantly at risk of rogue actors. It is imperative that organizations operating with the FBA
consensus mechanism take into account appropriate DLT-specific security considerations including KYC/AML
procedures, participant lifecycle management, participant activity monitoring and reporting, and operational
capacity and scalability monitoring to ascertain whether the DLT environment may support, or require, additional
participants to adequately process transactions.

4

TRANSACTION EFFICIENCIESDLT is often promoted for enabling faster transaction
settlement times, lower costs associated with transaction
processing, enhanced transparency between transacting
entities, potentially higher scaling capabilities than traditional
databases and currencies, and the use of smart contracts forautomation.
Key finance operations that may be subject to the identified
processing efficiencies are procure-to-pay, intercompany
transactions, order-to-cash, and acquire-to-retire.
For example, DLT may provide the order-to-cash process forcustomer billing the opportunity to achieve real-time visibility
to involved entities and allow for external inputs to trigger
faster settlement of balances with customers. In order toachieve the identified processing efficiencies, organizations
need to evaluate a multitude of security considerations toensure that the implementation of DLT does not result in
operational disruption.

Use Case:
To counteract wide-spread or evolving security
vulnerabilities, Hyperledger Sawtooth, created
via the open source, collaborative effort of theHyperledger ecosystem, employs the ability totoggle between various consensus mechanisms.
Hyperledger Sawtooth is one example of how
this flexibility allows organizations using DLT
to adjust to emerging risks and vulnerabilities
in consensus mechanisms, and can serve as aform of security. To avoid the risk of stagnationin the face of evolving technology, this idea offunctional flexibility could be employed in other
DLT components, such as smart contracts.

There are efficiencies to be obtained with the adoption of DLT, however, security considerations related togovernance structure, DLT integration, operational capacity and scalability, legal risk, and data protection andprivacy must be adequately addressed in order to achieve these efficiencies. A wide range of resources exists toassist organizations with the previously mentioned security considerations for traditional IT environments, however,there is no one-size-fits-all approach to addressing the considerations for DLT environments. For example, to ensure
operational resilience, organizations need to consider how their DLT environments’ transaction throughput andprocessing volumes are monitored to guarantee the environment maintains adequate capacity to processtransactions during peak volume periods. Several factors must be considered when evaluating transaction
processing, including the scalability of the environment, the number of active nodes, and the consensus
mechanism used to process the transactions.

Use Case:
In 2016, a decentralized autonomous organization developed on the open-source Ethereum protocol was victim to a successful
Reentry Attack, which ultimately led to a hard fork of the Ethereum protocol and the theft of approximately $50M in Ether fromthe organization. The attack exploited a smart contract vulnerability wherein attackers were able to write a piece of malicious
code referred to as a “recursive call bug.”The “recursive call bug” was executed against the decentralized autonomous organization’s code to repeatedly withdraw Ether
funds from the single wallet where the decentralized autonomous organization stored its initial coin offering (ICO) proceeds.
Once withdrawn from the organization, the attacker anonymously transferred the funds to its own wallet.

5

COMPLIANCE
Compliance leaders in the financial industry are focused on assessing and enhancing their complianceeffectiveness in response to the continuously evolving DLT and digital asset regulatory environment. DLT provides
an opportunity to enhance the compliance function by providing more accessible, transparent, and secure dataprocessing, increased transaction processing efficiency, multi-party transaction validation, and continuous
monitoring of assurance capabilities.
Security considerations include
design and execution strategy, timely
response to issues, and readiness forregulatory change.
DLT plays host to a variety of value
propositions for the financial services
sector. This section identifies gaps thatcurrently exist between security
standards and guidance published for
traditional IT environments and DLT
environments, specific to the value
propositions identified. In thesubsequent section, the paper will
explore the gaps in greater detail andpresent the need for collaboration fromthe financial services sector to produce
a comprehensive and standardized
approach to DLT-security.

Use Case:
In 2018, a major Canadian bank explored a number of use cases for DLT.
The objective of the bank’s technology function was to validate the benefitsof DLT, to enable greater efficiency in the intercompany sharing of clientknow-your-customer (KYC) data. With the engagement of a consulting
firm, the bank was able to develop a KYC data proof-of-concept using theHyperledger Fabric DLT platform. The platform was selected for its ability
to provide features respective to privacy and its ability to restrict sharingof sensitive intercompany client data through the implementation of smart
contracts.
Ultimately, the bank transformed their KYC data process from a siloed, lineof business process, into a distributed operation wherein KYC data could
be aggregated and stored in a distributed manner, yet accessed by any
authorized participant with access to the DLT environment.

6

SECURITY ASSURANCE CONSIDERATIONS FOR DLTs
There are a range of DLT security-related frameworks, guides, standards, and practices available to organizations.
While maturity levels may vary, it is important to consider how DLT may impact organizations at all levels bydeveloping a comprehensive understanding of DLT current security threat vectors. The chart below illustrates
fifteen categories of the DLT security landscape. Data was collected from 20+ guides, frameworks, assessments,and other methodologies published by professional organizations.
The chart categorizes the most frequently mentioned DLT security and general IT-security categories, comprised of150+ subcategories. Larger blocks in the chart indicate that a greater count of organizations mentioned thatcategory as a part of their DLT security considerations.
While this chart does not comprise an exhaustive search of all possible DLT security publications and related
security considerations, it does provide high-level insight into the most commonly researched and utilized security
considerations. It is clear that organizations have thought carefully about how their DLT environments will be
impacted by identification, authentication, access controls, secure coding, governance and compliance, network
security, and consensus mechanisms. These security “themes” comprise a majority of the literature surrounding
how to protect an organization’s operating environment.
Three areas which have received less collective thought include incident management, transactions, and business
continuity related to DLT. Some of these categories clearly overlap—as such, it is not imperative that organizations
categorize their security protocols in the manner presented above. However, it is important that each of thesecategories are considered in the implementation and continuous maintenance of a secure DLT environment.

7

SECURITY BASELINE CONSIDERATIONS FOR DLTsAs DLT evolves, it is apparent that DLT-specific security considerations exist and require analysis from industry
experts. The block chart in the previous section includes both traditional IT security considerations and DLTspecific security considerations. It is important to illustrate the difference between traditional IT security
considerations and the new developments surrounding DLT-specific security considerations. For example, smart
contracts, or programmatically-executable code, can perform legally binding requests on behalf of multiple entities
within a DLT environment. To add to the complexity, smart contracts are irreversible. The security consequences
related to this functionality are novel, and worth considering in more detail.
The illustration below demonstrates foundational elements for a security function, its functional domains, andareas for incremental program enhancements. In understanding what was uncovered in the previous section, manyof the functional domains still have opportunity to be described, vetted, and published against DLT–specificrequirements. Until these actions occur, it will be difficult to extend to areas of enhancements (e.g., strategic
threat management, or advance analytics and detection).
Some traditional IT security considerations may help users gain comfort with the strength of DLT-specific security;
however, additional coverage may be needed to ensure that DLT-specific security considerations are addressed intheir entirety. Although traditional IT security may assist in addressing DLT security, there are various DLT-specificnuances and risks which may require additional security controls above and beyond the standard employed for
traditional IT environments. It is promising to note that the block chart above illustrates that some key security
domains are commonly addressed across DLT-specific and traditional IT security literature.
Security domains such as incident management, business continuity, and threat/vulnerability management should
be considered for DLT. For example, business continuity planning for a centralized database has one set ofcharacteristics and related controls, and a completely different set for a decentralized database. Given theirreversibility of DLT transactions, policies and procedures must also account for DLT-specific considerations suchas immutability. These DLT-specific concerns can be extrapolated across all traditional IT security domains;therefore, it would be prudent for organizations to keep these differences in mind while evaluating the DLT-specificsecurity domains such as wallets and smart contracts.

8

DLT SECURITY ASSESSMENTS
At this point, several DLT-specific and several traditional IT security considerations have been described. An
example of how these risks overlap with a real-world use case can be useful in determining where potential
strengths and areas for improvement exist in a traditional framework when applied to a DLT use case.
In the table below, slightly modified versions of each of the five domains of a popular security assessments areevaluated for their impact on traditional IT and DLT environments. Areas where there are similarities or overlap
between processes for a traditional IT environment and a DLT environment are identified in the middle column.
In the right column, gaps in the security assessment in regard to DLT environments are noted.
The following table discusses all the sub-components of the assessment. This is not an exhaustive list of all
overlapping controls. It is intended to illustrate areas for improvement in current standard financial services
security frameworks when applied to DLT environments, as well as to provide an example of how an organization
can apply current industry frameworks to a DLT environment in order to find overlapping controls or new areasof improvement.

Behavioral Analysis:
Tests and assessments of security do not need to pinpoint every transaction, node, and account balance. In 2019, a security
analytics company prevented a large DDoS attack by comprehensively analyzing the behavior and network connections,instead of pinpointing specific IP addresses as the culprit. This “behavioral analysis” to prevent network attacks and analyze
performance can be extrapolated to a DLT environment. Verification of all transactions on a network can be extraordinarily
burdensome compared to gaining assurance of a network’s security by looking at its general behavioral patterns.

ASSESSMENT CRITERIATRADITIONAL AND DLT ENVIRONMENT SIMILARITIESADDITIONAL CONSIDERATIONS FOR DLT ENVIRONMENTS

Risk Management
and Oversight• Strategy/Policies: Policies and procedures arecommensurate with risk and are communicatedenterprise-wide.

• Decentralization: While decentralization is a major advantage ofblockchain, it is also a main security concern as it limits the amount ofcontrol any single participating node on the blockchain can exercise.

• IT Asset Management: An IT asset inventory is
maintained.

• Distributed infrastructure: The main risk of distributed infrastructure
is a decreased level of oversight.

• Risk Management Program: A risk management
function exists within the organization.

• Data Immutability: Immutability of a distributed ledger means thatchanges to information stored on a blockchain compromised
maliciously or by error often require a non-trivial amount of time andresources to correct.

• Training: Training is implemented as new issues
emerge.

• Consensus: Consensus can be a major threat vector across all
blockchains regardless of algorithm choice. Consensus based
attacks have many access entry points across code, networks, users
and nodes.

• Culture: Employees are held accountable forcompliance with security program.

• Smart contracts: Smart contracts allow organizations to run
programmable logic on blockchains. However, their autonomous
operations, without human oversight, make them more difficult tomonitor and expose a greater risk of exploitation.

9

Vulnerability
Management• Threat Intelligence and Information:
The organization monitors new threats andvulnerabilities.
• Information Sharing: Security threats are gatheredand shared with employees and law enforcement.
• Malware: While blockchain core technology, with its
cryptographic protections, is generally resistant todirect exploitation by malware, the ancillarysupporting systems in a blockchain ecosystem suchas wallets and browsers are subject to the same
malware attacks as non-blockchain systems.

• Cryptography: Cryptographic public key algorithms and hash functions
are fundamental components of blockchain security. These criticalsecurity functions are used for identities, transaction and block
signing, and form the foundation of blockchain’s integrity andimmutability guarantees. Theft or loss of cryptographic private keys
may result in identity theft, user obfuscation, and loss ofcryptocurrency and assets.
• Code vulnerabilities: Smart contracts are executable code designed torun distributed and autonomously on blockchains. Their distributed
nature make smart contracts difficult to maintain due to theirimmutability and without human interaction can lead to exploitations
resulting in direct financial loss.
• Malware: Blockchain core technology, with its cryptographic
protections, is resistant to direct exploitation by malware.
• Peer-to-Peer: Blockchain’s peer-to-peer design makes it difficult andcomplicated to keep distributed code, such as smart contracts,
synchronized across different organizations’ security and change
control rules and procedures

Cybersecurity
Controls• Secure Coding: DLT introduces nuance to coding
languages and execution styles. However, secure
SDLC practices remain generally the same.
• Anomalous Activity: Anomalous activities should
be monitored where possible.
• Event Detection: Mechanisms to alert managementof potential attacks should be used in allenvironments.

Third Party
Management• Due Diligence: The due diligence process for
permissioned DLT environments should include thesame elements as in traditional environments.
• Ongoing Monitoring: Monitoring of malicious third
parties should continue.

Incident andEvent Management• Event Detection: Event detection can be more difficult with blockchain
technologies due to the autonomous execution of code such as
smart contracts. Often transactions are conducted anonymously athigh velocity and are only observed after they have occurred, making
recovery difficult.
• Nascent technology: Since the blockchain technologies are relatively
new, the same level of expertise and security as in traditional
cybersecurity does not yet exist.

• Developer skills: Most smart contract languages and technologies,
when compared to existing traditional programming languages, areimmature and lack widely accepted secure development practices andguidance.
• End point security: Blockchains themselves, are by design inherently
secure. It is the third party supporting systems and the APIs that allow
external systems to interact with the blockchain network that introduce
security vulnerabilities.

• Testing: Testing should continue to include
collaboration with critical third parties and routine
tests of systems, applications, and data recovery.

• Contract management: Smart contracts can be considered as legallybinding, although common and internationally recognized legal
standards for “code as law” do not yet exist.

• Detection: Organizations should continue to utilize
alert parameters and system performance reports.

• Business continuity and disaster recovery strategy: Blockchain, due
to it properties of immutability and distributed code and data features
provide inherent business continuity and disaster recovery capabilities.

It is apparent from the above illustration that a variety of additional considerations exist when applying a traditional IT security
assessment to a DLT environment. This may also make obvious the need for a comprehensive DLT security framework. There areoften too many nuances and technology limitations to apply existing frameworks to entirely new problems; especially ones ascomplex as DLT.

10

A DLT SECURITY FRAMEWORK FOR
THE FINANCIAL SERVICES INDUSTRY
Given the variety of use cases, there is no one-size-fits-all approach to DLT security. However, there is thepossibility of a reliable and comprehensive framework to follow when approaching DLT security, regardless of theuse case. Agreed-upon standards will prove invaluable to making such a framework possible. Standards performseveral vital functions in regard to providing strong DLT security for all participants in the financial industry.
Standards can play an important role in ensuring interoperability between multiple DLT implementations, which
can reduce the risk of a fragmented ecosystem within the industry. As the technology develops and the number of
DLT participants increases, many stakeholders will want to interact with and use other blockchain platforms that
operate independently from their own. If each industry participant lays its respective DLT foundations in a silo, thissynergistic result will be difficult to achieve. Standards can be the guiding light for organizations to ensure thatthey will be able to work with others and build on top of their previous infrastructure investments in a controlled
and modular manner.
Standards also can result in shared vernacular, which will in turn provide for an improved understanding of thetechnology. This increased understanding will expedite adoption by the industry, as decision makers will be able tomore quickly understand some of the risks and opportunities associated with DLT. Standardized terminology canalso assist with the development of robust, easy-to-understand DLT security standards.
Governance, and specifically data governance, is a critical security issue that often delays the adoption of newtechnologies like DLT. Standards can also help alleviate this concern. By establishing a principles-based
framework, firms have the flexibility to identify potential security weaknesses in their DLT implementations.
A principles-based framework will also increase the likelihood that disparate DLT implementations from different
organizations could be linked or otherwise exchange information. In addition, supervisors and regulators will havea consistent measure for understanding potential strengths and weaknesses in different DLT implementations.
Lastly, standards play a role in digital identity management and can foster end-user trust in the technology. Digital
identity is the compilation of an individual’s collective actions performed online. The collection of actions can becorroborated to provide a very comprehensive view of that individual’s reliability, interests, and general personality.
DLT can enable users to retain more control of this identity, allowing them to have greater privacy and trust in theactions they perform online.

11

In creating this standardized approach, the financial industry has the opportunity to develop, share, reuse, andcontinuously improve upon an approach to DLT security. This effort will require the collaboration of the financial
industry at large. Further, it will benefit from continuous innovation and iteration. An example of the DLT security
collaboration and coordination life-cycle will likely resemble this format:

As is common in IT security communities, frameworks must be widely available, generally agreed upon, andcommonly adopted. As best practices mature, they can be adopted into a formal framework and used for financial
industry participants and regulators alike.
In light of the speed of digital transformation within the financial services sector, DTCC calls for a coordinatedstrategy for the development of a principles-based framework to identify and address DLT specific security risks.
Because these risks may cross multiple critical infrastructure sectors, the coordinated strategy should be across-sector effort beginning with a conversation between the financial services sector, DLT providers andconsumers. As a first step, we will leverage our unique role within the financial services sector to begin theconversation, and we encourage interested parties to contact one of the individuals in the Contacts section ofthis white paper to participate.

12

CONTACTS
Stephen Scharf
Chief Security Officersscharf@dtcc.com
Chris Koutras
Executive Director Security Architecture and Technology
ckoutras@dtcc.com
William Izzo
Director Security Technology
wizzo@dtcc.com
Questions or comments about this white paper can be addressed to your
DTCC Relationship Manager at DTCCClientCommunications@dtcc.com

ABOUT DTCC
DTCC is a premier, global, financial markets infrastructure provider, owned and governed by the financial industry, with nearly
50 years of experience providing governance, risk management and operational efficiencies to regulated financial markets aroundthe globe. DTCC has established processes, standards and rules, supported by technology platforms and enforced by control
models to promote the safety and soundness of an efficient and accountable financial markets industry. DTCC provides governanceservices that address the requirements of public and private sector supervisors and regulators in the U.S., Europe (and U.K.
post-Brexit) and in the major markets of Asia Pacific.
25452TC020620

13