# A Security Risk Assessment Method for Distributed Ledger Technology (DLT)
based Applications: Three Industry Case Studies

Elena Baninemeh, Slinger Jansen, Katsiaryna Labunets E. Baninemeh, S. Jansen,
and K. Labunets are with the Department of Information and Computer Science at
Utrecht University, Utrecht, the Netherlands (e-mail:{e.baninemeh,
slinger.jansen, k.labunets)

###### Abstract

Distributed ledger technologies have gained significant attention and adoption
in recent years. Despite various security features distributed ledger
technology provides, they are vulnerable to different and new malicious
attacks, such as selfish mining and Sybil attacks. While such vulnerabilities
have been investigated, detecting and discovering appropriate countermeasures
still need to be reported. Cybersecurity knowledge is limited and fragmented
in this domain, while distributed ledger technology usage grows daily. Thus,
research focusing on overcoming potential attacks on distributed ledgers is
required. This study aims to raise awareness of the cybersecurity of
distributed ledger technology by designing a security risk assessment method
for distributed ledger technology applications. We have developed a database
with possible security threats and known attacks on distributed ledger
technologies to accompany the method, including sets of countermeasures. We
employed a semi-systematic literature review combined with method engineering
to develop a method that organizations can use to assess their cybersecurity
risk for distributed ledger applications. The method has subsequently been
evaluated in three case studies, which show that the method helps to
effectively conduct security risk assessments for distributed ledger
applications in these organizations.

###### Index Terms:

Distributed Ledger Technology; Cyber Security; Security Risk Assessment
Method; Smart Contracts;

##  I Introduction

Blockchain technology has received significant attention recently, as it
offers a reliable decentralized infrastructure for all kinds of business
transactions [1]. Distributed Ledger Technology (DLT) can provide an open,
decentralized, fault-tolerant transaction mechanism. Blockchain, for instance,
is a distributed ledger technology that has attracted considerable attention
from both industry and academia since it was initially introduced for Bitcoin
[2] to support the exchange of cryptocurrency [3]. DLT is disrupting today’s
industry at a breakneck pace with the potential to change the world [4] and
offers excellent potential to decentralize operations in collaborative
business networks and may even enable new business models [5].

DLT has been widespread beyond cryptocurrencies or financial usage. The
applications extend to several domains, including integrity verification,
governance, IoT, healthcare management, privacy and security, and supply chain
management [6]. DLT-based applications refer to software solutions and
platforms that utilize a decentralized, distributed, and tamper-resistant
ledger to record and manage data, transactions, or assets across a network of
multiple nodes or participants in the mentioned domains[7]. Benefits of DLT
include cost reduction and increased transparency in information sharing
between organizations [8, 9]. Many research papers have pointed out the
security and trust aspects of DLT, such as [10], [11], [4]. Nowadays, the
security posture of Blockchain and DLT remains one of the critical topics in
the industry and distributed services [4]. DLT offers extensive opportunities
such as financial services [12]; however, organizations that use DLT-based
applications face challenges and limitations such as security and privacy
compliance and governance issues that still haven’t been thoroughly
investigated and addressed [13]. Vulnerabilities and weaknesses lead to the
execution of various security threats to the distributed ledger platforms;
while such vulnerabilities have been thoroughly investigated in extant
research, understanding, and development of appropriate countermeasures are
still in their infancy. Thus, an examination of the security of DLT-based
applications can be valuable [14].

The literature lacks a security risk assessment method for DLT-based
applications. It is essential to design such a method to support the software
development lifecycle of such applications to enable creators of DLT-based
applications to rapidly assess the risks that are associated with their
technology and introduce countermeasures to prevent them.

DLTs offer various security features such as high availability, fault
tolerance, and tamper resistance to protect transaction data. However, DLTs
are still vulnerable to cyberattacks, and their maturity level is insufficient
to ensure the necessary security for business applications. Therefore,
additional conditions and requirements must be considered when applying DLTs
in a business context to enhance their security and protect against cyber
threats.

After conducting a literature review, it was found that most studies on
Blockchain provide an overview of attacks. However, studies that focus on
security in DLTs only define a limited set of attacks on DLTs. As a result,
definitions of attacks and potential risks in DLTs are scattered across the
literature, and most studies do not provide a countermeasure for each attack.
Thus, developing a knowledge base that collects potential attacks for DLTs and
suggests corresponding countermeasures to enhance DLT security is crucial.

In this study, we have developed a comprehensive knowledge base including 115
attacks on DLTs and identified the specific assets that are at risk for each
attack. Our objective is to enhance understanding and awareness of the
cybersecurity challenges in the DLT domain. We conducted a literature review
to achieve this goal and designed a novel risk assessment method specifically
for DLT-based applications. We further refined the method by performing method
engineering and then evaluated its effectiveness through three case studies.

The structure of this article is as follows: Section II defines DLT and
describes DLT abstraction layers. Section III formulates the research
objective, defines the study’s research questions, and explains our research
method. Section IV positions the proposed method in this study among the other
risk assessment method in the literature. The rest of the paper reports on the
following: Section V present a risk assessment method for DLT-based
application. Section VI explains our empirical observations in the context of
three real-world case studies that have been conducted to evaluate our
proposed method. Section VII analyzes the result of case studies and answer
research questions. Section VIII discusses the limitations of the study. The
conclusions are formed IX

##  II Background

A distributed ledger is a secure data structure that resides across multiple
computing devices, spread across locations or regions with no centralized
controller. This is a new way of keeping track of who owns financial,
physical, or electronic assets [15].

A DLT consists of six layers: (i) the network layer, (ii) the consensus layer,
(iii) the data model layer, (iv) the execution layer, (v) the application
layer, and (vi) the external layer [16]. Figure 1 shows the DLT layers.

Figure 1: DLT abstraction layers with example components per layer [17], [18]

Network layer: The network layer corresponds to the communication
infrastructure that is needed to facilitate transactions, information, and
data sharing between the nodes. Protocols and methods to facilitate discovery
and communication between the peer nodes belong in this layer. If nodes are
expected to transact by digitally signing data-in-transit or engage in
verification and validation of the transactions, such processes should be
defined in this layer [18]. Risks in this layer are centered around the
infrastructure and connectivity of the DLT network. They include threats such
as denial-of-service attacks, routing attacks, and network congestion that can
disrupt data transmission and compromise the integrity of the network [19].

Consensus layer: The consensus layer is a critical component of DLT
technologies, especially blockchains. This layer facilitates distributed
trust, ownership, and control. There are two common consensus types: (1)
proof-based consensus and (2) voting-based consensus. Consensus has two main
properties: (1) indicates an agreement among the distributed nodes and
synchronizes them, and (2) validates transactions and ensures reliable and
fault-tolerant operations [20]. Risks at this layer pertain to the consensus
mechanism that validates transactions and maintains the integrity of the
ledger. They include 51% attacks, protocol deviations, and the potential for
forks, which can undermine the trust and reliability of the consensus process,
leading to data manipulation and inconsistencies within the ledger [21].

Data model layer: This layer handles functions and operations related to the
blockchain creation itself in addition to ledger maintenance tasks. Note that
this layer does not define the final ledger state. A global consensus is
required to approve the final transactions and block creations. However, the
process of grouping the transactions into the block, creating a block (or
appending to the ledger), and maintaining a common state of the ledger are
handled in this layer [18]. Risks at the Data model layer relate to the
structure and management of data within the DLT. They include data integrity
risks, data privacy risks, and data access risks, which can agree to the
accuracy, confidentiality, and security of the data stored within the ledger
[22].

Execution layer: This layer contains the DLT rules and program logic such as
smart contracts, chain code, etc. The software applications from the
application layer trigger the code and rules in the execution layer and
instruct the code in the execution layer, resulting in the execution of a
transaction. In cases where the execution layer code requires data from off-
chain databases, the code can trigger oracles that reside in the application
layer (or between the application layer and the outside world) to fetch
data/information from off-chain sources to the execution layer code [20].
Risks at this layer involve the execution of transactions and smart contracts
within the DLT. They include privacy breaches, smart contract vulnerabilities,
and transaction errors, which can result in the exposure of sensitive data,
financial losses, and the exploitation of coding flaws, impacting the
reliability and security of the DLT system [22].

Application layer: This layer contains applications, software, scripts, and
programs that the users can use (e.g., human users and nodes) to interact with
the DLT. In a sense, these software applications are above the DLT core and do
not fully belong to the DLT. However, these applications should be developed
based on the boundary conditions and rules defined by the blockchain [20].
Risks at this layer affect the functionality and usability of DLT
applications. They include risks such as false data feeds, software bugs, and
vulnerabilities in user interfaces, which can lead to misinformation, system
malfunctions, and unauthorized access, affecting the overall user experience
and trust in the DLT application [21].

External layer: This layer is at the surface of DLT and includes external
additions to the DLT, such as oracles or cryptocurrency exchanges. These risks
originate from external factors surrounding the DLT ecosystem. They include
regulatory risks, interoperability challenges, market volatility, and adoption
barriers, which can impact the legal compliance, integration capabilities,
market stability, and acceptance of DLTs within the broader economic and
regulatory landscape [19].

These risks arise from vulnerabilities within the blockchain system at any
layer of the stacked model. They can be categorized depending on their origin
(for example, network layer risks like denial-of-service attacks or routing
attacks), their target (such as consensus layer risks like 51% attacks or
protocol deviations), their impact (like execution layer risks such as privacy
breaches or smart contract glitches), or their scope (such as application
layer risks like false data feeds or censorship) [23]. By categorizing DLT
risks based on their sources, impact, target, and scope, stakeholders can
develop targeted risk assessment strategies, including network monitoring,
data encryption, smart contract auditing, user education, regulatory
compliance, and industry collaborations, to mitigate these risks effectively
and ensure the security, integrity, and adoption of DLTs [19].

##  III Research Approach

###  III-A Research Objective

This study presents a method for assessing the risks of DLT-based applications
that organizations can utilize during their development process. The method
assists organizations in identifying potential risks and improving the aspects
of the DLT-based application to mitigate them. Usually, organizations do not
consider risks at the beginning of the development process since they may not
be well understood or challenging to assess. In the next section, we will
discuss the motivations for conducting this risk assessment.

1) The studies that refer to security in DLTs defined a limited set of attacks
on DLTs. Hence, the definition of attacks and potential risks in DLTs are
scattered, and most studies have not described a countermeasure for each
attack. Therefore, there is a need for a knowledge base documenting all
potential attacks for the DLTs and suggesting corresponding countermeasures.
In this study, we create a knowledge base for DLTs that contains over 200
attacks. Hence, no risk assessment methods in the literature have been
developed for DLT-based applications that include a knowledge base of risks
that may occur in DLT-based applications. Accordingly, developing a risk
assessment method to support the software development life-cycle of such
applications is essential.

2) Distributed ledgers have become increasingly popular over these years due
to their suitability to be used in many distributed application scenarios
[24]. The convergence of security in a DLT still presents many challenges that
need to be addressed to take full advantage of the benefits offered by DLTs
[25]. Additional research and industry developments are necessary to gain a
thorough understanding of the various security aspects of DLT for
organizations to effectively address security issues during the DLT
development process in a timely manner. Some key security aspects to consider
when working with DLTs include consensus mechanisms, cryptography, identity
management, smart contracts, and network security. So, a comprehensive
approach to security is critical when working with DLTs, and organizations
must carefully consider and address each of these security aspects to ensure
the safety and integrity of their data and transactions. Furthermore, the
organizations using DLT-based applications are not security experts. So they
must continuously acquire volatile knowledge of potential risks and keep
themselves updated. Attacks and potential risks in DLTs are scattered; thus,
identifying risks specific to DLTs is difficult. Hence, we provide a security
risk assessment method for DLT-based applications to help organizations ensure
security in the development process.

###  III-B Research Questions

The main goal of this study is to design a method to assess cyber security
risks for DLT-based applications. To achieve our goal, we aim to answer the
following research questions:

$RQ_{1}$: What are existing security risk assessment methods for DLT-based
applications?
$RQ_{2}$: What cyber security risks are specific for DLT-based applications?
$RQ_{3}$: What method engineering technique can be used to develop the
security risk assessment method?
$RQ_{4}$: How does the effectiveness of the proposed method?

###  III-C Research Method

We employed a semi-systematic literature review (SLR) using the snowballing
method, combined with method engineering and case study research to design and
evaluate the method, collect data to create the knowledge base, and answer the
research questions.

TABLE I: An overview of the three research methods used in this study with their corresponding research questions (RQ) Research Method | RQ1 | RQ2 | RQ3 | RQ4
---|---|---|---|---
Literature study | ✓ | ✓ | ✓ |
Method Engineering |  |  | ✓ |
Multiple Case Study |  |  |  | ✓

1) Literature research: The overall goal of the literature study is to
understand the technologies and context of DLT, which is necessary for
discovering cybersecurity risks. Furthermore, it establishes a comprehensive
overview of what cyber security entails and what methods currently exist. The
literature study assists in the method engineering section to create a
knowledge base, as it constructs the foundation for the risk database, which
is a part of our proposed method. We created an extraction form to collect
knowledge, ensure it is consistent with relevant knowledge, and check that the
knowledge gathered answered the research questions. The literature study was
performed based on the snowballing suggested by Wohlin. Wohlin [26] presents
several guidelines for this method which will be used during the literature
study. Because by using snowballing in the literature study process, there is
a higher chance of finding research that was published in less-known journals
and conferences. Because it reduces the problem of inconsistent terminology,
and the critical benefit of snowballing is that it focuses on the cited or
referenced papers, which reduces the noise compared to the database approach
[26]. Researchers may use different terminology for the same concepts, and by
relying solely on search engines, relevant research may not be found by using
deviating terminology. Snowballing circumvents this problem. Hence it can be a
suitable method for the DLT context because, in this domain, concepts are
often used interchangeably. We aim to answer RQ1 and RQ2 With this literature
study.

2) Method engineering: We use the method engineering to answer RQ3. Based on
[27], ”Method engineering is the practice of engineering to design, construct
and adapt methods, techniques, and tools for developing information systems”.
It is used to visualize the design process of the method and to engineer it
thoroughly. The primary goal of method engineering is to improve the overall
efficiency and effectiveness of developing information systems by providing a
set of best practices and guidelines for managing the developing process. A
Process Deliverable Diagram (PDD) is used to visualize the design and
development. It illustrates the activities and artifacts of a specific
process. A PDD can be seen as a combination of a business process model and
data model [28]. We will discuss the steps to design our proposed method based
on the formal approach for method engineering [29] in section VII.

3) Case study research [30, 31] is an empirical methodology that examines a
phenomenon within the context of the particular empirical domain. Interviews
are one of the key techniques in case study research to gather data regarding
a particular phenomenon or to evaluate a tool with respect to its efficiency
and effectiveness. A case study is a widely used and accepted empirical
approach for developing theory and conceptual models in the Information
Science literature [32]. This study employs multiple case designs, examining
multiple real-world DLT-based applications as multiple cases within their
context to evaluate our proposed method. Furthermore, our work has been
evaluated using the ACM SIGSOFT Empirical Standards 111Find the database
through the following link: (https://github.com/acmsigsoft/EmpiricalStandards)
for case studies and case synthesis. We used the case studies to answer RQ4.

We conducted a literature study to validate our research and evaluated our
proposed method through three case studies. Following the case study
methodology of Runeson and Höst [33], we performed five major steps as
follows:

(1) Case study design: Define objectives and plan the case study. Building a
valid security risk assessment method for the DLT-based application was the
primary goal of this research.
(2) Preparation for data collection: Procedures and protocols that govern the
data collection conduct. The analysis units were three industry case studies
performed in the Netherlands and Iran. To conduct the case studies and
evaluate the proposed method, we followed the protocol in AppendixAppendix:
Case Study Protocols
(3) Collecting evidence: Execution with data collection on the studied case.
We conducted multiple expert interviews with the case study participants to
understand their requirements, concerns, and preferences regarding the
security risk assessment method.
(4) Analysis of collected data : Data analysis is conducted differently for
quantitative and qualitative data. We analyzed the outcomes and observations
of the case studies and indicated the most harmed asset for each case study
that needs to emphasize safety to mitigate the risk.
(5) Reporting: The report communicates the findings of the study but is also
the primary source of information for judging the quality of the study. We
reported the outcomes to the case study participants and received their
feedback on the result.

TABLE II: shows three risks that have been extracted from the knowledge base [34]. Name |  Synonyms | Short Description |  Harmed asset |  Impacted Layer |  Contributes to |  Relates to |  Reference
---|---|---|---|---|---|---|---
Double Spending Attack |  - |  When the same single digital tokens can be spent on more than one because the attacker manages to spend both of them simultaneously. Double spending is one of the major security issues in most blockchain systems, but it is difficult to launch unless an adversary has massive computing power successfully. |  Network |  Network Layer |  - |  Finney attack; race attacks; 51 % attacks |  [35]
Eclipse Attack |  - |  a set of malicious, colluding overlay nodes arranges for a correct node to peer only with coalition members. If successful, the attacker can mediate most or all communication to and from the victim. By supplying biased neighbor information during normal overlay maintenance, a modest number of malicious nodes can eclipse a large number of correct victim nodes. |  Network |  Network Layer |  Consensus Majority Attack, Engineering block races, Splitting mining power (51% attack), selfish mining, 0-confirmation double spend, N-confirmation double-spend |  Sybil attack |  [36]
Long Range Attack |  History Attack |  Proof of Stake vulnerability, due to weak subjectivity and costless simulation, an attacker attempts to rewrite the history of a ledger by forking the ledger |  Transaction information |  Consensus Layer |  - |  - |  [37]

##  IV Systematic literature review

As mentioned in III, we have performed a semi-systematic literature review
(SLR) as the primary method to investigate the existing literature regarding
security risk assessment methods in different domains. The SLR was performed
using the guidelines proposed by [38]. Moreover, we have also considered a
systematic literature review performed by [39] as a reference when conducting
our SLR. We performed SLR in the following phase:

Data sources and search strategy: Generally, it consisted of two search
strategies: collection of the initial hypothesis and automatic search. Figure
2 shows the stages of the search process. We gathered a set of papers to
generate search terms from their generic keywords during the initial
hypothesis search. The search terms are used in the automatic search to
collect data from digital libraries. Primary sources for our search are
digital libraries, including ACM Digital Library, IEEE Xplore, Springer, and
Science Direct. We have primarily focused on these four libraries since they
offer high-quality papers which are valuable in the scientific community.
During the initial hypothesis search phase, we explored literature based on
the following search keywords: ”security risk assessment method”, ”risk
assessment for DLT”, ”distributed ledger technology”, and ”Cybersecurity
standards in risk assessment methods”, ”cybersecurity risk assessment method”.
Accordingly, We collected a set of papers based on the snowballing method
during this phase. Hence, we found 72 papers for risk assessment methods and
frameworks with different activities and features. In order to generate the
search terms to use in the automatic search, we extracted the keywords of the
papers and employed them in this process. The search terms are:
(“risk assessment” OR “security risk assessment” OR “risk assessment
framework” OR “assessment framework” OR “risk assessment method” OR “risk
assessment approach” OR “risk assessment model”) AND (“blockchain technology”
OR “distributed ledger” OR “distributed ledger technology” OR “ledger
technology” OR “blockchain-based application”).

Figure 2: This figure indicates the stages of the search process.

Afterward, the search term can be used to find publications from digital
libraries. Typically, the search results can be exported easily as CSV and
BibTex formats. We employed automatic search based on these search terms and
automatically extracted 425 manuscripts from the mentioned academic sources.
So, in two search methods ( manual and automatic search), we arrived at 495
studies in this phase

Inclusion/Exclusion criteria: Inclusion and exclusion criteria ensure that
relevant manuscripts are included and irrelevant manuscripts are excluded. At
this phase, based on [40], we emphasized excluding studies that clearly meet
the exclusion criteria, including titles and abstracts. If the titles and
abstracts clearly disqualify them, the studies are eliminated from the
candidate studies.

We extracted the required information, including title, keywords, abstract,
the venue where the paper was presented, the number of citations, year, and
also the relevancy of each paper with the research questions. Thus, based on
this information, we have ranked the studies using four qualitative values:
None, low, medium, and high. “none” indicates that the study is not valuable
to our research, and ”high” indicates that the study is highly relevant to our
research. Finally, we considered 86 studies in this phase.

Quality assessment: After the inclusion and exclusion criteria, it is
necessary to evaluate the quality of selected papers [38] We read and
discussed to eliminate concerns and develop consistent criteria for the study
quality assessment. Our quality assessment focused on the following questions:

  1. 1.

Does the study contain a clear problem statement?

  2. 2.

Does the study contain research questions?

  3. 3.

Are the clear research challenges of the study mentioned?

  4. 4.

Are the results and findings of the research mentioned clearly and
understandably?

  5. 5.

Does the study contain a real-world use case?

We analyzed and discussed all the studies to eliminate or consider for the
next phase. So, we read the full text and eliminated 18 manuscripts based on
the above quality assessment criteria. The first and second authors conducted
a quality assessment of all the results. In this round, 36 studies were
eliminated that focused on the risks and attacks in different domains because
we considered the studies that designed a security risk assessment method.
Finally, we used 32 studies in our data analysis.

Data extraction: We identified 25 studies from various domains through a
systematic literature review. The results, presented in III, include
information on the research method, evaluation technique, risk domain, risk
type, and the standards used in each study. Our analysis indicated that two
studies presented a risk assessment method exclusively for DLTs. Moreover, we
found that the majority of the methods employed in the previous studies were
based on ISO 27005 and NIST SP-800-30 standards. To design our proposed risk
assessment method, we also considered these standards. Additionally, we were
able to answer RQ1 and RQ2 by leveraging the results gained from the SLR. ISO
27005 is a widely recognized standard for information security risk
management. It provides a structured and systematic approach to identifying
and assessing risks and developing and implementing risk treatment strategies
[41]. By incorporating ISO 27005 into our proposed method, we can ensure that
the risk assessment process is comprehensive, consistent, and aligned with
industry best practices. NIST SP-800-30 is a similar standard that guides
conducting risk assessments for information systems. It offers a step-by-step
approach to identifying, analyzing, evaluating risks, and developing and
implementing risk management plans. By considering this standard in developing
our method, we can benefit from the best practices and insights provided by
NIST, which is widely recognized as a leading authority in information
security. By combining the insights and best practices from both ISO 27005 and
NIST SP-800-30, we can propose that the risk assessment method is likely to be
effective, comprehensive, and aligned with industry best practices.

TABLE III: An overview of the results of the SLR NIST |  Year | Research Method |  Evaluation Technique |  Risk Domain |  RS Type |  Derived
---|---|---|---|---|---|---
[42] |  2002 |  Literature study |  - |  Information security |  Qualitative |  NIST
[43] |  2002 |  Literature study |  Case study |  - |  Qualitative |  -
[44] |  2009 |  Literature study |  - |  - |  Qualitative |  ISO 27001
[45] |  2014 |  Literature study |  Experiment |  Cloud computing |  Qualitative |  ISO 27005
[46] |  2014 |  Literature study, Benchmarking |  Benchmarking |  Smart grid |  Qualitative |  CORAS, ISO 27001
[47] |  2015 |  Literature study, Benchmarking |  Benchmarking |  Medical devices |  Qualitative |  ISO 27001
[48] |  2016 |  Literature study, Benchmarking |  Benchmarking |  Information system security |  Qualitative |  ISO 27002
[49] |  2016 |  Literature study, Benchmarking |  Benchmarking |  SCADA systems |  Qualitative |  ISO 31000, NIST SP 800-30
[50] |  2018 |  Document Analysis, Literature study |  Benchmarking |  Blockchain |  Qualitative |  NIST SP-800-30
[51] |  2018 |  Design science, Literature study |  Case study |  DLT applications |  Qualitative |  ISO 27005
[52] |  2018 |  Literature study |  - |  Information |  Qualitative |  ISO 27005, NIST SP-800-30
[53] |  2018 |  Literature study |  - |  IoT |  Quantitative |  ISO 31000, NIST SP 800-30
[54] |  2019 |  Design science, Literature study |  - |  Cloud |  Qualitative |  ISO 31000, NIST SP 800-30
[55] |  2021 |  Document Analysis, Literature study |  - |  Blockchain |  Quantitative |  ISO 27005, ISO 31000
[56] |  2021 |  Document Analysis, Literature study |  - |  Automotive Cybersecurity |  Quantitative |  ISO 26262
[57] |  2021 |  Fuzzy set theory, Literature study |  Experiment |  Control System |  Quantitative |  ISO 26262
[58] |  2021 |  Literature study, Benchmarking |  Benchmarking |  - |  Quantitative |  -
[59] |  2021 |  Literature study, Benchmarking |  Benchmarking |  Funding |  Quantitative |  -
[60] |  2022 |  Literature study, Benchmarking, Case study |  Case study |  Information security |  Qualitative |  ISO/IEC 27005, CORAS
[61] |  2022 |  Document Analysis, Literature study , Benchmarking |  Benchmarking |  Cloud |  Qualitative |  NIST SP 800:30, ISO 27001, SO 30001
[62] |  2022 |  Literature study, Benchmarking, Case study |  Case study |  - |  Quantitative |  SO 27001, NIST SP 800:30
[63] |  2022 |  Literature study |  - |  Distributed Ledger |  Qualitative |  ISO 27005, ISO 27001
[64] |  2022 |  Literature study, Benchmarking |  Benchmarking |  Blockchain |  Qualitative |  -
[65] |  2022 |  Document Analysis, Literature study |  Benchmarking |  SCADA system |  Quantitative |  -
[66] |  2022 |  Document Analysis, Literature study , Benchmarking |  Benchmarking |  IT infrastructure |  Qualitative |  -

##  V Security Risk Assessment Method for DLT-based Applications (SRAMDA)

Following the method engineering approach, we propose a simple and holistic
approach to risk assessment of DLT-based applications. We call this approach
Security Risk Assessment Method for DLT-based Applications, abbreviated as
SRAMDA. Figure 3 illustrates the SRAMDA process. The method relies on the
existing knowledge that has to be collected before the core risk assessment
steps. Therefore, risk analysts following SRAMDA need to  1. analyze security
terminology,  2. conduct DLT analysis, and  3. gather data-related risk.  In
the latest step, analysts could use our DLT knowledge base which currently
contains 115 risks specific to DLT-based applications. The description of the
risks in SRAMDA knowledge base provides information about the name of the
attack, description, related risks, possible harmed assets, impacted layer
(based on stack model of DLT), and references to the source of information
about the attack [34]. However, we indicated whether each attack was
specifically targeting DLTs or if it belonged to well-known cybersecurity
attacks. Based on our findings, 28.95% of the attacks were identified as
common cybersecurity threats, while a significant majority of 71.05% were
explicitly tailored to exploit vulnerabilities within DLTs. It was imperative
for us to maintain the integrity of our examination by providing valid
references for each of the included attacks, thereby ensuring the validity and
reliability of our research. Table II demonstrates a fragment of the knowledge
base.

Once the knowledge base preparation is done, the SRAMDA guides analysts into
the core risk assessment steps. This part consists of ten steps which we
describe in what follows:

##### Project specification collection

The first step is gathering project specifications, or ’context establishment’
as known in ISO 27005. This step requires risk analysts to understand the
project’s specifics and discover the ‘crown jewels’ to be protected. The risk
analyst and stakeholders must define common terminology and decide the scope
boundaries in order to focus on the future risk assessment and make it
feasible. This step aims to set common ground and reduce possible
misunderstandings between stakeholders and risk analysts.

##### Attackers motivation detection

Based on the project description and scope produced in the previous step, the
risk analyst can analyze possible cyber criminals’ motivations for attacking
the system. This risk assessment assumes an opportunity to attack the system
under analysis, and the motive is the specific type of attack. With early
design and development systems, performing a risk assessment method can be
difficult because specific components are undefined. However, one can reason
why an attacker would want to attack this specific system. For example, if
there are monetary assets. This eliminates some attacks, as their probability
will be very low. The main objective of this step is to determine the motive
behind an attack on the system under analysis, such that the risk analyst can
decide what risks are most likely to be exploited.

We adopted the following classification of the attacker’s motivations:

  * Monetary: The probably most apparent extrinsic motivation for an attacker is the financial benefit the attack can result in. An attacker could, for instance, commit fraud or extort other people with the help of cyberattacks.

  * Damage: Causing damage is another extrinsic motivation that an attacker may have. The willingness to cause damage can come from various reasons.

  * Knowledge: The other motivation is an attacker’s knowledge from performing an attack and how advantage is reached through the theft of information and essential data.

  * Trust: An attacker interested in notoriety within a community intends to destroy trust.

##### Attacks domain detection

In this step, the risk analyst determines the domain of interest for attackers
by annotating each motivation. The risk analyst should determine where the
attacker would seek motivation to get his desired asset. For example, if the
attack’s motive is monetary assets, they might attack the layer in which the
value exchange occurs. In this step, the risk analyst identifies the risks
based on the knowledge base and which assets might be vulnerable.

##### Potential risks identification

In this step, the risk analyst can identify potential risks by comparing the
information earned from previous steps with the knowledge base. In previous
steps, the motivations of the attacker and the domain of interest (type of
motivations) were determined. We collected 226 attacks in the DLT-based
applications and determined the DLT layer for each attack and the type of
attacks (Monetary, Damage, Knowledge, and Trust) in the knowledge base. Hence,
the risk analyst can filter the attacks in the knowledge base based on these
data.

####  V-1 New risks detected

This step is unique compared to most risk assessment methods. As mentioned
before, this method utilizes a risk knowledge base that was earned during an
extensive literature study. The knowledge base consists of all relevant
identified risks on DLT.

If the risk analyst reviews the knowledge base and does not identify any risks
or attacks based on the information gathered from previous steps. In that
case, they can explore the possibility of discovering new attacks by
conducting a literature study focused on identifying potential risks in DLT-
based applications.

OR-gateway:

  * If yes: Add new risks to the knowledge base, then continue to the next step.

  * If no: Continue to the next step.

##### Analysis of the identified risks

The risk analyst must identify and describe threats based on the identified
assets. In this step, the risk analyzer describes the attack scenarios (Events
produced by the attacker to attain its attack goal) leading to the achievement
of the attack goals determined in the second step to estimate the probability
of occurrence of threats.

Figure 3: The Step-by-step Process of SRAMDA

##### Rank risks

The identified and analyzed risks are reported to the project leaders in this
step. If they confirm that the risks can be potential threats and attacks on
their project, the risk analyst asks them to rank the risks because the risk
analyst might not be capable of assessing the severity of a risk. This step’s
objective is to rank the identified and evaluated risks and determine what
risks are essential in the project to take into account. Also, it eliminates
irrelevant risks and diminishes the number of treatments that have to be
presented for the next step.

##### Suggesting risks countermeasure

The result of this step should be a structured list of possible risk treatment
and countermeasure options per risk. Countermeasures can be collected from
scientific literature, querying search engines, asking security experts, or
using their own experiences and knowledge of the analyst. Risk treatments are
not included in the database by default, as not every treatment might work on
each project. Treatments are very project-specific; hence it is dangerous to
blindly assume that a specific treatment in a database will completely
mitigate risk without acquiring more understanding. Consequently, it might be
best to let the analyst survey the treatment description intensively to
conclude what treatment options might be most relevant and effective.

##### Final recommendation

This step is the last step that has to be documented. Here, the risk analyst
concludes the risk assessment and provides the project leaders with her final
recommendation. The recommendations are presented to the project leaders based
on the most vulnerable asset. The risk analyst checks the number of identified
risks that are detected based on the harmed asset in Step 6. Then the risk
analyst provides the mitigation and prevention operation against these risks
as final recommendations.

##  VI Empirical Evidence: The Case Studies

We aimed to evaluate the effectiveness of SRAMDA through three case studies.
To ensure a diverse evaluation, we selected case study organizations from
three different domains: data security (SecureSECO), financial services
(Mobifi), and crypto exchange (Aratoo). These organizations were located in
the Netherlands and Iran. We specifically chose companies as our case studies
that were in the process of developing DLT-based applications.

###  VI-A SecureSECO

In this section, we outline all the steps of SRAMDA that were conducted for
the SearchSECO project.Figure IV shows the summary of employing these steps.

####  VI-A1 Gather project specifications

SecureSECO aims to secure and increase trust in the software ecosystem through
DLT and empirical software engineering research. SearchSECO aim to create a
secure software ecosystem. This project uses DLT to store valuable trust facts
about software and users. This project relies on trust, which is hard to
measure, but it is possible to protect and use smart contracts and consensus
mechanisms. The project leaders determined the scope of risk assessment during
the interview as follows: To provide valuable insights and awareness of
cybersecurity risks. It can provide the assessment results for further
designing and developing the project.

TABLE IV:  A step-by-step application of SRAMDA to SearchSECO.

####  VI-A2 Attackers Motivation

The motivations of an attacker are as follows:

Altering trustful data for self-interest: For this motive, the attacker seeks
to disrupt the system completely. This will probably be done with a direct
attack. Altering the trust facts can lead to discrediting SecureSECO.
Replicating the project and making SecureSECO useless: An attack could have
the motive of replicating the project and making the original SecureSECO
redundant. For example, The attacker could monetize the new project and add
more data than in the original project. Furthermore, A group of attackers
could have the motive of taking over the network, either shutting it down,
poisoning the well or having other malicious activities on the network.
Financial gain: obtaining salable information, either resell personal details
or the trust facts.

####  VI-A3 Attacks domain detection

In this step, we determined the domain of interest for attackers by annotating
each motivation (see Table IV).

####  VI-A4 Potential risks identification

This step identified potential risks by comparing the information earned from
previous steps with the knowledge base. We identified the following attacks
for SecureSECO:

Potential Risk: Sybil attack: A Sybil attack is one where an attacker pretends
to be so many people simultaneously. (Attackers create multiple virtual
identities) [67].

Potential Risk: Eclipse attack: Eclipse attacks are network attack that aims
at eclipsing specific nodes from the entire P2P network [68].

Potential Risk: Nothing-at-stake attack: Validators motivate to operate on
various forks, notwithstanding the protocol diversity of PoS. Validators could
make conflicting blocks on the probable forks with nothing at stake. This
problem is called the nothing at stake attack, which reduces the consensus
time of the network, lessens the system efficiency, and decreases the
blockchain capability to solve double-spending attacks and other threats [69].

Potential Risk: Hard fork: When a system splits into two systems and a new
version is created, which is not compatible with the old version, as the old
nodes could not agree with the mining of the new nodes: consensus cannot be
reached. A hard fork is not reversible. [68].

####  VI-A5 New risks detected?

We did not identify new risks for SecureSECO and found all attacks based on
our knowledge base. So we can continue to the next step.

####  VI-A6 Analysis of the identified risks

In this step, we described the attack scenarios for SecureSECO based on the
information earned from previous steps (See Table IV).

####  VI-A7 Rank risks

In this step, we reported the identified and analyzed risks to the SecureSECO
project leaders. They confirmed that the risks could be potential threats and
attacks for SecureSECO, and they ranked the attacks for their project to
indicate the prioritization and importance of risks.

####  VI-A8 Suggesting risks countermeasures

In this step, we prepared a list of possible risk treatment and countermeasure
options per risk.

Countermeasure: Sybil attack: Pure PoW is one-CPU-one-vote which defends Sybil
attack [70].

Countermeasure: Eclipse attack: Set up more buckets; Add more outgoing links;
Prohibit unsolicited ADDR messages; Diversify incoming links; Detect abnormal
behavior [68].

Countermeasure: Nothing-at-stake attack: The primary countermeasure to the
”nothing-at-stake” problem in the proof of stake protocols is the punishment
of participants who validate two conflicting paths [69].

####  VI-A9 Final recommendations

Most of the risk occurs in the Network layer in the DLT of SecureECO, which is
more vulnerable to attacks. Thus the recommendation to mitigate these attacks
can be helpful for their project. Eclipse attacks and Replay attacks are
performed on the network layer. A mitigation strategy against eclipse attacks
is to use redundant network links or out-of-band connections to verify
transactions (e.g., by a blockchain explorer). To mitigate the replay attack
in the Network layer, one of the solutions is utilizing both the current
timestamps and random nonces. To achieve this goal, all the entities in the
network are assumed to be synchronized with their clocks. This is a typical
assumption applied in designing various security protocols in networks.

###  VI-B Case Study 2: Mobifi

####  VI-B1 Gather Project Specifications

MobiFi is a financial organizer for Mobility as a Service (MaaS) — which aims
to solve this. It is based on a DLT-based payment engine that automates the
mobility credit system for enterprises, all managed in one control portal.
They provide a transparent platform with a tokenized payment system to connect
mobility service providers and users. MobiFi bridges the gap between the
mobility industry and Decentralized Finance (DeFi).

The scope of this risk assessment was determined along with the project
leaders during the group interview and is formulated as follows: The scope of
this risk assessment is to provide valuable insights and awareness of the
cyber security of Mobifi, such that it can take the results of SRAMDA into
account while further designing and developing the project.

####  VI-B2 Attackers Motivation

The motivations of an attacker are as follows:

Motivation: Gaining knowledge - There is significant competition between
companies that produce transportation information. For example,
telecommunication companies generate data that can be used for transportation
modeling. Similarly, the logs of available mobile devices registered by
cellphone towers can be used to monitor traffic.

Motivation: Access sensitive data on the network nodes - Mobility data is
continuously generated by different network nodes. According to the
identification layer of the multi-layered blockchain model for the Mobifi data
market, transportation data is stored in Identification files. Each entity
contains metadata, static data, and dynamic data. Nodes need consent from the
owner to access the static and dynamic data, which can be attractive to many
actors.

Motivation: Sabotage activities - Cybercriminals may use the blockchain
ecosystem for sabotage activities. Since the process is anonymous, it is hard
to track user behaviors and be subject to legal sanctions. For example,
criminals can leverage smart contracts for various malicious activities, which
may threaten our daily lives. Manipulate and modify blockchain information:
Blockchains are made to be practically immutable, where, in theory, no one can
modify the blockchain’s distributed ledger of all committed blocks. The
blockchain relies on the distributed consensus mechanism to achieve
immutability and establish mutual trust.

####  VI-B3 Attacks domain detection

In this step, we determined the domain of interest for attackers by annotating
each of the motivations (See Table V).

####  VI-B4 Potential risks identification

This step identified potential risks by comparing the information earned from
previous steps with the knowledge base. We identified the following attacks
for Mobifi:

Potential Risk: Wormhole attack within a channel - The permissioned blockchain
technology is prone to wormhole attack because the sender and receiver
identities are not hidden on the channel of a permissioned blockchain as per
lack of peer privacy. Within a channel, compromising a member causes to
leakage of all members’ ledger information to everyone outside the channel.
Within a private network, a malicious node creates a virtual private network
with the outside network and leaks the information of its private network.
This attack can be launched without any knowledge of honest nodes of the
private network [55].

Potential Risk: Node spoofing attack - Node spoofing is when an attacker
steals Decentralized Identifier (DID) credentials exploiting a vulnerability
in an improper key protection mechanism and communicates with another node on
behalf of the user. If cryptographic keys are not stored or maintained
properly, it could cause the compromise and disclosure of private keys leading
to fraudulent transactions or loss of assets. This will lead to compromising
the integrity and privacy of the operations. Wallet theft uses classic
mechanisms such as phishing, including system hacking, the installation of
buggy software, and the incorrect use of wallets [71].

Potential Risk: Dictionary Attack - Attackers use dictionaries of known
passwords, a subset of brute force attacks. This can be used against services
requiring login or against cryptographically protected data requiring a
password or passphrase to access it, such as a wallet [72].

Potential Risk: Sybil attack - Attackers create multiple virtual identities,
which means a single faulty entity can present multiple identities, and it can
control a substantial fraction of the system, thereby undermining this
redundancy [73].

Potential Risk: Credential Stuffing - Attackers use spilled or otherwise
leaked credentials and account names to try name/password combinations with a
higher likelihood of success against services requiring authentication [74].

Potential Risk: Time hijacking attack - Time hijacking attacks occur because
of the vulnerability of Bitcoin time stamp processing. The time counter of the
Bitcoin network is modified, and nodes’ time changes as well. Hardware-
oriented system time will be adopted to replace the previous network time.
Time hijacking is prone to occur when an adversary executes a Sybil attack
with inaccurate timestamps simultaneously, which adds multiple Sybil nodes to
the network [75].

Potential Risk: BGP routing attack - Border Gateway Protocol belongs to
external routing protocols connecting different networks on the Internet. In
BGP routing attacks, known as BGP hijacks, any malicious AS (Autonomous
System) can create fake advertisements for any prefix and advertise them to
its neighbors, redirecting traffic directed to given destinations [76].

Potential Risk: Malleability attack - In the Hyperledger network, the ledger
of a channel inside the Hyperledger limits the accessibility to only members
that are part of the channel. The client can choose an endorser of its choice
during the transaction proposal phase, due to which the identity of the
endorser is disclosed to everyone in the network, including an insider
adversary. Suppose an attacker is a channel member on Hyperledger, as in
conventional data-sharing schemes. In that case, the attacker can eavesdrop on
all the network traffic inside a channel of Hyperledger fabric by exploiting
vulnerability related to lack of peer privacy. The attacker also has access to
every transaction present in the ledger [75].

TABLE V: A step-by-step application of SRAMDA to MobiFi.

####  VI-B5 New risks detected?

We needed to perform a literature study for some motivation, So we found new
risks. Wormhole attacks within a channel, Node spoofing attacks, and
Malleability attacks were new risks we detected based on the literature study.
Hence, we added them to our knowledge base.

####  VI-B6 Analysis of the identified risks

In this step, we described the attack scenarios for Mobifi based on the
information earned from previous steps (See Table V).

####  VI-B7 Rank risks

In this step, we reported the identified and analyzed risks to the Mobifi
project leaders. They confirmed that the risks could be potential threats and
attacks for Mobifi, and they ranked the attacks for their project to indicate
the prioritization and importance of risks.

####  VI-B8 Suggesting risks countermeasures

In this step, we prepared a list of possible risk treatment and countermeasure
options per risk.

Countermeasure: Wormhole attack within a channel - To address this weakness in
the consensus design, techniques to anonymize sender and receiver identity
inside a channel should be implemented [55].

Countermeasure: Node spoofing attack - Spoofing attack is mitigated by
introducing an anonymous communication among nodes [71].

Countermeasure: Dictionary attack - inserting observers in the network, notify
the merchant about an ongoing double-spend [77].

Countermeasure: Sybil attack - Pure PoW is one-CPU-one-vote which defends
Sybil attack [76].

Countermeasure: Credential Stuffing - password breach alerting [78].

Countermeasure: Malleability attack - Separates script signature of the
transaction into a newly added duration field.

Countermeasure: Time hijacking attack - Tolerance ranges constraint and
network time protocol can be exploited to handle the time hijacking attacks
[76].

Countermeasure: BGP routing attack - A Bitcoin relay network with scalability
and security which can keep away from BGP routing attack [76].

####  VI-B9 Final recommendations

After the analysis of Mobifi, we realized that most attacks damage the network
layer of their DLT, including Wormhole attacks within a channel, Node spoofing
attacks, Sybil attacks, Credential Stuffing, Malleability attacks, Time
hijacking attacks, BGP routing attack. Hence, mitigating the mentioned risks
in the network layer is essential. Credential stuffing is easy to execute on
vulnerable systems, which makes it all the more important to protect the
organizations and the data of millions of users who trust them. Multi-
signature technology is commonly employed in cryptocurrency exchanges to
prevent unauthorized access to users’ accounts because it requires more than
one signature to authorize a process. Malleability attacks have been mitigated
on the network layer by implementing a soft fork protocol upgrade. There are
several problems a Sybil attack may cause, such as Block users from the
network. Identity validation can help prevent Sybil attacks by disclosing the
true identity of hostile entities. Economic costs can work as artificial
barriers to entry that make a Sybil attack much more expensive. Personhood
Validation is another solution to mitigate the Sybil attack. A validation
authority can use a mechanism that does not require knowing the real identity
of participants.

###  VI-C Case Study 3: Aratoo

####  VI-C1 Gather Project Specifications

Aratoo is an Iranian decentralized autonomous organization that aims to
liberate the Iranian cryptocurrency market. They are developing, amongst other
products, a DeFi wallet for managing cryptocurrencies. A DeFi wallet is a non-
custodial wallet where the users have complete access and control of their
private keys and funds. DeFi wallets are at the core of the concept “be your
own bank”. Aratoo is a transparent platform that uses smart contracts and
native protocol to reduce investment risk, increase profits, and expand
blockchain technology and decentralized systems. They have employed DeFi
ecosystems, such as MakerDAO and CurveDAO, for lending, borrowing, exchanging,
and governing. The DAO will allow liquidity providers to decide on adding new
pools, changing pool parameters, token incentives, and many other protocol
aspects. A pool is a smart contract that implements the StableSwap invariant,
thereby exchanging two or more tokens. The scope of this risk assessment was
determined along with the project leaders during the group interview and is
formulated as follows: to provide valuable insights and awareness in the cyber
security of Aratoo, such that it can take the results of SRAMDA into account
while further designing and developing the project.

####  VI-C2 Attackers motivation detection

The motivations of an attacker are as follows:

Motivation: Financial profit - These are the operations carried out by the
attacker to acquire assets or goals and are not limited to brute-forcing
credentials, reconnaissance surveillance, exploit delivery, etc.

Motivation: Access sensitive data - attacker aims to take over a user account
through various attacks and gain access to protected data.

Motivation: Information theft - This attack aims to obtain a token without the
attacker paying for it with its currency.

Motivation: Acquisition of cryptocurrency: The attacker needs to obtain
somehow the target user’s private key or the login ID and password for the
user’s web or another wallet.

Motivation: Steal information - The attacker aims to shut down communication
between parties or steal information from an unsuspecting victim.

Motivation: Sabotage activities - The attack targets those ordinary users and
exchanges that identify transactions based solely on hashes without checking
the contents of the transactions.

####  VI-C3 Attacks domain detection

In this step, we determined the domain of interest for attackers by annotating
each motivation (See Table IV).

####  VI-C4 Potential risks identification

This step identified potential risks by comparing the information earned from
previous steps with the knowledge base. We identified the following attacks on
Aratoo:

Potential Risk: Cryptomining - Cryptomining (also known as Cryptojacking)
involves an attacker using victims’ compute resources to mine
cryptocurrencies; this can range from using malware to stolen credentials to
gain access to systems [79].

Potential Risk: Account Hijacking - Account Hijacking is an attack where a
malicious user (attacker) can retrieve a cloud user credential and use it in
the attacker’s favor [80].

Potential Risk: Double spending attack - When the same single digital token
can be spent on more than one because the attacker simultaneously manages to
spend both of them. Double spending is one of the significant security issues
in most blockchain systems, but it is challenging to launch unless an
adversary has massive computing power successfully [81].

Potential Risk: Wallet theft - Where credentials, such as keys associated with
peers in the system, are stored in a digital wallet, the ”wallet theft” attack
arises with specific implications for the application [82].

Potential Risk: Replay Attack - In Blockchain systems, the replay attack is
the most common issue faced by Blockchain transactions and can cause a long
delay in the communication between the two parties [83].

Potential Risk: Selfish mining Attack - Selfish mining is a strategy in which
a group of miners cooperate and tactically withhold transactions to enter the
ledger and then release them to increase their profits [7].

Potential Risk: Transaction Malleability - Transaction malleability is one of
the critical threats to the blockchain, which can facilitate double-spending
attacks by tampering with the state of a blockchain [81].

TABLE VI: A step-by-step application of SRAMDA to Aratoo.

####  VI-C5 New risks detected?

We needed to perform a literature study for some motivation, So we found new
risks. Cryptomining, Account Hijacking, and Wallet theft were new risks that
we detected based on the literature study. Hence, we added them to our
knowledge base.

####  VI-C6 Analysis of the identified risks

In this step, we described the attack scenarios for Aratoo based on the
information earned from previous steps (See Table IV).

####  VI-C7 Rank risks

In this step, we reported the identified and analyzed risks to the Aratoo
project leaders. They rejected two risks, including crypto mining and selfish
mining attacks. They mentioned that their project’s probability of these
attacks happening is low. However, they confirmed the rest of the risks and
ranked the attacks for their project to indicate the prioritization and
importance of risks.

####  VI-C8 Suggesting risks countermeasures

In this step, we prepared a list of possible risk treatment and countermeasure
options per risk.

Countermeasure: Account Hijacking - Condition monitoring and OPC UA server: an
attacker uses compromised/stolen credentials to access and impersonate the
account. Typically, account hijacking is done through phishing, sending fake
emails to the user, password guessing, or various other tactics. By accessing
these systems, it is possible to send valid fake data easily. An attacker
could also compromise the active session and gain access to the transmitted
data [80].

Countermeasure: Double spending attack - Consensus protocols, digital
signatures.

Countermeasure: Wallet theft - The Bitcoin system offers a multi-signature
scheme that assigns multiple private keys to one address. Under this scheme,
the theft of one of the necessary private keys alone would not enable the
coins to be stolen unless the rest of the necessary keys are stolen as well
[84].

Countermeasure: Replay Attack - Add nonce in each transaction; mixing
techniques and digital signatures can be used to prevent replay attack [85].

Countermeasure: Transaction Malleability - Restrict the syntax of the Bitcoin
scripting language so that different scripts will not produce the same outcome
[80].

####  VI-C9 Final recommendation:

As shown in Table VI, most of the risks sabotage the exchange component in the
DLT of the Aratoo project. These attacks are Account Hijacking, Wallet theft,
and Double spending attacks. Thus the exchange component is vulnerable, and
they need to consider the prevention operation against the mentioned attacks.
Preventing double-spending involves a more strenuous verification process and
ensures that the same input cannot be shared over multiple transactions. To
mitigate the attacks of exploits to a wallet theft, not to store private key
information within the wallet. Without private keys, access to a wallet
provides minimal value to an attacker.

##  VII Analysis

Four research questions were created to give guidance in developing the
method. These research questions will be answered and reflected upon in this
section.

RQ1: What are existing security risk assessment methods?

There are several security risk assessment standards and frameworks for
conducting risk assessments in organizations, such as NIST 800-30 and ISO
27005. These standards provide the general and main steps to conduct security
risk assessments. NIST SP 800-30 includes a series of practical guidance on
information security technology and management issues (NIST, 2002). ISO 27005
(ISO, 2011) is a standard for information security risk management [49]. Many
methods have adopted the ISO 27005 standards, which standardized risk
assessment methods for industrial use. An example of such a method is the
CORAS method [46] which is a model-based risk assessment methodology for
security-critical systems. The ISO27000 method consists of seven steps, from
defining the risk assessment context to reviewing, monitoring, and auditing
the performed method. It can be concluded that it is hard to perform risk
assessments, as they are often probabilistic, and likelihood and consequences
are therefore hard to estimate precisely [49]. Most risk assessment methods
focus on threat modeling, mitigation, and response planning and are performed
for well-defined concepts [86]. We examined other risk assessment methods that
provided insight into how risk assessments are performed, and the results
helped us as guidelines for the method engineering approach. We reviewed the
most popular security risk assessment methods (based on the table III), such
as ISO 27005, and NIST SP800-30, to determine the critical steps in security
risk assessment. In this paper, we relied on the ISO27005 and NIST SP800-30
standards to define the main steps of the security risk assessment.

RQ 2: What cyber security risks are specific for DLT-based applications?

There are hundreds of cyber security risks for DLT-based applications. Based
on the literature study, we reviewed the studies that introduced attacks and
risks for DLTs and blockchain. The most studies employed benchmarking to
analyze and compare a collection of risks against each other in literature.
Finally, a database could be constructed with 115 risks for DLT-based
applications. The process starts with the knowledge-based creation process,
which consists of three steps: (i) analysis of security terminology, (ii)
analysis of DLT, (iii) the gathering of data-related risks, including the name
of the attack, description of the attack, related risks, harmed asset,
impacted layer, and a citation [34]. The ”Relates to” column in the data set
represents the relationships that we found in the literature between different
attacks. However, please note that this list is likely to be incomplete, as we
only considered a limited set of peer-reviewed and grey literature. Table II
shows a piece of the knowledge base. The DLT risk knowledge base already
contains 115 risks for DLT-based applications in the different security areas,
and each cyber security risk was related to at least one layer of DLT.

RQ3: What method engineering technique can be used to develop the cyber risk
assessment method?

Based on the formal approach for method engineering proposed [29], we use the
following steps to design our proposed method:
1\. Method selection: Based on the SLR that we mentioned in III, we realized
that ISO 27005 and NIST SP 800-30 are the most popular standard in the
studies. So, we employed their guidelines for risk assessment to determine the
critical steps in security risk assessment.
2\. Method modeling: In order to design and develop a risk assessment method,
a process-deliverable diagram is used for creating the meta-model of the
method. It is a valuable method for determining the activities and the outputs
of the method [28]. This meta-modeling technique is straightforward and
consistent with UML standards (see figure 3.
3\. Method development: The method, modeled in PDD, is decomposed into
activities and concepts. In V, we described all activities and concepts of all
steps.

RQ4: How does the effectiveness of the proposed method?

In order to evaluate the method, we used the case study research and
guidelines of Runeson et al. [33], Yin [87] and Robson [88]. We selected ten
companies that used DLT-based applications in their project and reviewed the
documents we found on their website. Our criteria for selecting the companies
as a case study are: 1) currently, they have used DLT, or they want to develop
their own DLT. 2) We also considered the size of the companies on our list. We
checked the size of the companies on our list. The size was different in the
range of 10 to 500. We excluded the companies that they had less than 50
employees. Because we wanted to keep the well-known and larger companies on
our list. 3) We contacted the companies and asked them if they were interested
in participating as a case study in our research. Finally, we ended up with
three case studies on our list. Three industry case studies have been
conducted to evaluate and signify the risk assessment’s efficiency and
effectiveness. We conducted a set of interviews with the experts at three case
study organizations and asked them a set of questions based on the case study
protocol. Then, we analyzed the results of the interviews. Table VII shows a
comparison between three case studies.

##  VIII Discussion

In this study, we developed a method to assess the risks for DLT-based
applications. A case study was the best suitable method for evaluating the
SRAMDA, as the method is designed to be applied to a real-world case. We
conducted three case studies and asked them a set of questions based on the
case study protocol (See Appendix Appendix: Case Study Protocols) to analyze
their project and assess potential risks that they might face during the
development. For two steps of SRAMDA appeared to be very difficult to
determine which of the 115 risks were most relevant to a project still in the
proof-of-concept stage. These two steps include the attacker’s motivation
detection and attack domain detection. Determining the motivation and attacks
domain made it easier to define the most relevant risks. It provided a clear
rationale for these decisions. It is unusual to use the attacker’s motivation
for risk assessment. However, it might be a solution for the standardized risk
assessment methods that need to estimate probability and consequence. When the
motivation of attackers and attacks domain were determined, the relevant risks
for the project were easily defined.

###  VIII-A Threats to validity

The validity assessment is an essential part of any empirical study. Validity
discussions typically involve Construct Validity, Internal Validity, External
Validity, and Conclusion Validity. This study includes some threats to
validity and is analyzed following a checklist by Robson [88], which consists
of concrete approaches for enhancing the validity of case studies.

TABLE VII: summarizes all findings through the case study research and
compares the selected three case studies against each other.

Construct validity refers to whether an accurate operational measure or test
has been used for the concepts being studied. In literature, SRAMDA is defined
as a method for assessing the risks of DLT-based applications, which contains
nine steps. We followed the SRAMDA method and the nine-step risk assessment to
mitigate the threats to construct validity. Moreover, we employed document
analysis and literature study as two knowledge acquisition techniques to
capture knowledge regarding risks and threats in DLTs. The SRAMDA method has
been evaluated through three real-world case studies at three different real-
world enterprises in the Netherlands and Iran.

Internal validity attempts to verify claims about the cause-effect
relationships within the context of a study. In other words, it determines
whether the study is sound or not. To mitigate the threats to the method’s
internal validity, we emphasize that the case study participants’ opinion as a
measurement instrument is risky, as they may not have sufficient knowledge to
make a valid judgment. We counter this risk by conducting more than one case
study, assuming that the case study participants are handling their interests.

External validity concerns the domain to which the research findings can be
generalized. External validity is sometimes used interchangeably with
generalizability (feasibility of applying the results to other research
settings). To mitigate threats to the research’s external validity, we
captured knowledge from different sources of knowledge without any regional
limitations to define the constructs.

Conclusion validity verifies whether the methods of a study, such as the data
collection method, can be reproduced with similar results. We captured
knowledge from the sources of knowledge. The accuracy of the extracted
knowledge was guaranteed through the protocols that were developed to define
the knowledge extraction strategy and format (See II). A review protocol was
proposed and applied by multiple research assistants, including bachelor’s and
master’s students, to mitigate the threats to the research’s conclusion
validity. By following the framework and the protocols, we keep the knowledge
extraction process consistent and check whether the acquired knowledge
addresses the research questions. Moreover, we crosschecked the captured
knowledge to assess the quality of the results, and we had at least two
assistants extract data independently.

###  VIII-B Limitations

The literature study, especially the construction of the risk knowledge base
and knowledge collection, was a very time-consuming phase of the research.
Most of the risks include many synonyms and ambiguous descriptions, So
summarizing and extracting valuable knowledge took a long time for the
research. This issue led to a comprehensive overview of all the DLT risks. On
the other hand, DLT is a continuously evolving subject, and the literature is
still very immature. Thus, the risk database might not have been complete, as
new risks arise every day from the most distant corners of the Internet.
However, much meticulous energy has been put into creating the knowledge base,
and the probability of a significant risk missing at that time is negligible.
Furthermore, It is challenging to find an appropriate countermeasure for
risks. Sometimes, we are faced with a risk in the assessment process; then, we
realize there is no countermeasure for such risk. It is essential to
understand that no countermeasure can eliminate risk. It is one of the
challenges for risk assessment because applying countermeasures at least
decreases the probability of occurrence of the risk in the project.

Security vulnerabilities arising from centralization, such as Total Value
Locked (TVL) concentration, Miner Extractable Value (MEV) exploitations, and
account abstraction, significantly compromise the integrity and
confidentiality of blockchain systems. Concentrated TVL within specific
protocols or platforms creates a single point of failure, rendering the entire
system susceptible to targeted attacks and manipulations. MEV vulnerabilities
enable malicious actors to engage in front-running and other manipulative
tactics, exploiting the transaction ordering in decentralized environments.
Additionally, the potential for account abstraction threatens the security and
privacy of sensitive information stored within the network, allowing
unauthorized access and control over user accounts.

Furthermore, economic security vulnerabilities embedded in the token design,
notably the distinction between algorithmic and asset-backed stablecoins,
underscore the intricacies associated with maintaining stable value and
sustainable market equilibrium. The inherent volatility of algorithmic
stablecoins poses challenges, as their value is subject to significant
fluctuations, while the reliance on underlying assets in asset-backed
stablecoins introduces risks related to asset liquidity and valuation
dynamics. Bridging assets across distinct blockchain networks, particularly
the transfer of assets from platforms with changing security guarantees, like
wrapping assets from Solana onto Ethereum, exposes the transferred assets to
the vulnerabilities inherent in the less secure network, potentially
compromising the integrity and safety of the transferred assets [89].

##  IX Conclusion and future work

In this article, a method is provided that performs security risk assessment
for DLT-based applications. The method was created through systematic analysis
of in-depth knowledge about DLT, cyber security, and other risk assessment
methods. The designed method was evaluated in three real-world case studies.
Furthermore, 200+ risks for DLT-based applications were identified as part of
the method and are also part of the contribution of this work.

A security risk assessment method is considered successful when it provides
new insights and a clear direction of where to focus while further developing
(security aspects of) the project. The findings from the case studies are that
the method does contribute new insights and that the method is deemed useful
by developers of DLT-based applications.

A number of recommendations for future work are given. Firstly, future
research may further validate the conclusions drawn in this study. For
instance, the SRAMDA can be evaluated with expert interviews. So, future work
may further develop this method and assess its effectiveness for other domains
such as DAOs. Secondly, the importance of researching the cybersecurity domain
of DLT is stressed in this paper and calls for more attention in research. For
example, research into the security aspects of each layer of DLT can be
performed for a more in-depth understanding of the risks in each layer.
Thirdly, besides studying the risks, future work should also consider possible
countermeasures. For instance, there still is no ideal solution to Sybil
attacks.

Summarizing, this article brings the risk assessment field forward by
extensively identifying risks in DLT-based applications, which is a necessity
for this fast developing field. Furthermore, the risk database can serve as a
basis for future risk analysis and other kinds of research.

## Appendix: Case Study Protocols

This project captured knowledge regarding potential security threats for DLT
based on an extensive literature study. Additionally, we have designed a
framework for rapidly assessing threats software-producing organizations might
face when developing a dApp. We will analyze your project and assess potential
risks you might deal with during the meeting. The analysis results will be
confidential, and we will only use them to evaluate the framework. During this
meeting, the first seven steps of the framework will be performed to define
the context of your project. As you might already be noticed, the first step
has already been undertaken. Step two indicates participants and the time of
the meeting. Steps 3-7 are the core elements of the meeting. These steps are
summarized as follows. The meeting will walk through these steps in the form
of a semi-structured interview. The participants can be prepared for the
meeting by reading the questionnaire. However, be aware that the questions
might change or be formulated differently in the meeting.

Step 1) Context Establishment

  * •

Can you introduce your company briefly?

  * •

What is the main goal of the project? Why is it being developed?

  * •

What technologies do you use? What consensus mechanisms? Smart contracts? Etc.
Technical details are important here.

  * •

At what stage of design/development is the project? What decisions are set,
and which decisions are still to be taken?

  * •

Has your company ever participated in another cybersecurity exercise with
another party?

  * •

What would you like to see achieved at the end of this assessment?

  * •

How do you think a security risk assessment could contribute to the
organization? What is its purpose?

Step 2) Determine the scope of the assessment

  * •

What is the scope of this security risk assessment for you?
For example, The scope of this risk assessment is to provide valuable insights
into your company’s cyber security, such that you can take the results of the
assessment into account while further designing and developing your projects.

Step 3) Organizational characterization

  * •

Who is accountable for the top risks?

  * •

How is the project prepared to respond to extreme events? Is it prepared at
all?

  * •

Are there any contradicting security needs with internal or external
stakeholders? Such as, privacy is less important for us but important for our
users.

  * •

Can your company be deployed with some risks? When is your company secure
(enough)?

Step 4) Perfunctory risk identification

  * •

What assets need protection? What target do you wish to have analyzed?

  * •

What worries you the most concerning your assets? What are the main unwanted
incidents that come to mind?

  * •

Are you already considering some identified risks while further designing and
developing the project?

  * •

Are there already some risks you request to see in the security risk
assessment?

  * •

Are there any organizational ’blind spots’ that need attention? (Areas that
are easily and often overlooked or forgotten within the organization)

  * •

Are you already taking certain countermeasures? If yes, what are the current
countermeasures you are taking?

  * •

How are you planning on keeping the project secure?

Step 5) Concluding on the assessment context

  * •

Do you think any crucial information is missing after this meeting? Do you
have anything else to add?

## References

  * [1] Siamak Farshidi.  Multi-criteria decision-making in software production.  PhD thesis, Utrecht University, 2020.
  * [2] Satoshi Nakamoto and A Bitcoin.  A peer-to-peer electronic cash system.  Bitcoin.–URL: https://bitcoin. org/bitcoin. pdf, 4, 2008.
  * [3] Zhiyuan Wan, Xin Xia, David Lo, Jiachi Chen, Xiapu Luo, and Xiaohu Yang.  Smart contract security: a practitioners’ perspective.  In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE), pages 1410–1422. IEEE, 2021.
  * [4] Marek R Ogiela and Michal Majcher.  Security of distributed ledger solutions based on blockchain technologies.  In 2018 IEEE 32nd International Conference on Advanced Information Networking and Applications (AINA), pages 1089–1095. IEEE, 2018\.
  * [5] Hans Schaffers.  The relevance of blockchain for collaborative networked organizations.  In Working Conference on Virtual Enterprises, pages 3–17. Springer, 2018.
  * [6] Grégory Bénassy, Fukuhito Ooshita, and Michiko Inoue.  Eventually consistent distributed ledger despite degraded atomic broadcast.  Concurrency and Computation: Practice and Experience, page e6199, 2021.
  * [7] Harish Natarajan, Solvej Krause, and Helen Gradstein.  Distributed ledger technology and blockchain.  2017\.
  * [8] Vincent Chia, Pieter Hartel, Qingze Hum, Sebastian Ma, Georgios Piliouras, Daniël Reijsbergen, Mark Van Staalduinen, and Pawel Szalachowski.  Rethinking blockchain security: Position paper.  In 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), pages 1273–1280. IEEE, 2018.
  * [9] Hoang Tam Vo, Ziyuan Wang, Dileban Karunamoorthy, John Wagner, Ermyas Abebe, and Mukesh Mohania.  Internet of blockchains: Techniques and challenges ahead.  In 2018 IEEE international conference on internet of things (iThings) and IEEE green computing and communications (GreenCom) and IEEE cyber, physical and social computing (CPSCom) and IEEE smart data (SmartData), pages 1574–1581. IEEE, 2018.
  * [10] Fang Hou, Siamak Farshidi, and Slinger Jansen.  Trustseco: A distributed infrastructure for providing trust in the software ecosystem.  In International Conference on Advanced Information Systems Engineering, pages 121–133. Springer, 2021.
  * [11] Efthimios-Enias Gojka, Niclas Kannengießer, Benjamin Sturm, Jan Bartsch, and Ali Sunyaev.  Security in distributed ledger technology: An analysis of vulnerabilities and attack vectors.  In Intelligent Computing, pages 722–742. Springer, 2021.
  * [12] Roger Maull, Phil Godsiff, Catherine Mulligan, Alan Brown, and Beth Kewell.  Distributed ledger technology: Applications and implications.  Strategic Change, 26(5):481–489, 2017.
  * [13] Rowan van Pelt, Slinger Jansen, Djuri Baars, and Sietse Overbeek.  Defining blockchain governance: A framework for analysis and comparison.  Information Systems Management, 38(1):21–41, 2021.
  * [14] Robert Campbell.  The need for cyber resilient enterprise distributed ledger risk management framework.  The Journal of The British Blockchain Association, page 12257, 2020\.
  * [15] Dylan Yaga, Peter Mell, Nik Roby, and Karen Scarfone.  Blockchain technology overview.  arXiv preprint arXiv:1906.11078, 2019.
  * [16] Kyle Croman, Christian Decker, Ittay Eyal, Adem Efe Gencer, Ari Juels, Ahmed Kosba, Andrew Miller, Prateek Saxena, Elaine Shi, Emin Gün Sirer, et al.  On scaling decentralized blockchains.  In International conference on financial cryptography and data security, pages 106–125. Springer, 2016.
  * [17] International Telecommunication Union.  a • Technical report on SS7 vulnerabilities and mitigation measures for digital financial services transactions Security aspects of distributed ledger technologies.  Technical report.
  * [18] Sri Nikhil Gupta Gourisetti, Ümit Cali, Kim-Kwang Raymond Choo, Elizabeth Escobar, Christopher Gorog, Annabelle Lee, Claudio Lima, Michael Mylrea, Marco Pasetti, Farrokh Rahimi, et al.  Standardization of the distributed ledger technology cybersecurity stack for power and energy applications.  Sustainable Energy, Grids and Networks, 28:100553, 2021.
  * [19] Ivan Homoliak, Sarad Venugopalan, Daniël Reijsbergen, Qingze Hum, Richard Schumi, and Pawel Szalachowski.  The security reference architecture for blockchains: Toward a standardized model for studying vulnerabilities, threats, and defenses.  IEEE Communications Surveys & Tutorials, 23(1):341–390, 2020.
  * [20] Michel Rauchs, Andrew Glidden, Brian Gordon, Gina C Pieters, Martino Recanatini, François Rostand, Kathryn Vagneur, and Bryan Zheng Zhang.  Distributed ledger technology systems: A conceptual framework.  Available at SSRN 3230013, 2018.
  * [21] Ivan Homoliak, Sarad Venugopalan, Qingze Hum, and Pawel Szalachowski.  A security reference architecture for blockchains.  In 2019 IEEE International Conference on Blockchain (Blockchain), pages 390–397. IEEE, 2019.
  * [22] Benedikt Putz and Günther Pernul.  Detecting blockchain security threats.  In 2020 IEEE International Conference on Blockchain (Blockchain), pages 313–320. IEEE, 2020.
  * [23] How to secure blockchains from attacks: A security reference architecture for distributed ledger technologies — by eray altili — medium.  https://ealtili.medium.com/how-to-secure-blockchains-from-attacks-a-security-reference-architecture-for-distributed-ledger-3c988e045538.
  * [24] Luca Serena, Gabriele D’Angelo, and Stefano Ferretti.  Security analysis of distributed ledgers and blockchains through agent-based simulation.  Simulation Modelling Practice and Theory, 114:102413, 2022.
  * [25] Advait Deshpande, Katherine Stewart, Louise Lepetit, and Salil Gunashekar.  Distributed ledger technologies/blockchain: Challenges, opportunities and the prospects for standards.  Overview report The British Standards Institution (BSI), 40:40, 2017\.
  * [26] Claes Wohlin.  Guidelines for snowballing in systematic literature studies and a replication in software engineering.  In Proceedings of the 18th international conference on evaluation and assessment in software engineering, pages 1–10, 2014.
  * [27] Sjaak Brinkkemper.  Method engineering: engineering of information systems development methods and tools.  Information and software technology, 38(4):275–280, 1996.
  * [28] Inge van de Weerd and Sjaak Brinkkemper.  Meta-modeling for situational analysis and design methods.  In Handbook of research on modern systems analysis and design technologies and applications, pages 35–54. IGI Global, 2009.
  * [29] Shuguang Hong, Geert van den Goor, and Sjaak Brinkkemper.  A formal approach to the comparison of object-oriented analysis and design methodologies.  In [1993] Proceedings of the Twenty-sixth Hawaii International Conference on System Sciences, volume 4, pages 689–698. IEEE, 1993.
  * [30] Slinger Jansen.  Applied multi-case research in a mixed-method research project: Customer configuration updating improvement.  In Information systems research methods, epistemology, and applications, pages 120–139. IGI Global, 2009.
  * [31] Siamak Farshidi, Slinger Jansen, and Mahdi Deldar.  A decision model for programming language ecosystem selection: Seven industry case studies.  Information and Software Technology, 139:106640, 2021.
  * [32] Graham Pervan and M Maimbo.  Designing a case study protocol for application in is research.  In Proceedings of the Ninth Pacific Asia Conference on Information Systems, pages 1281–1292. PACIS, 2005.
  * [33] Per Runeson, Martin Host, Austen Rainer, and Bjorn Regnell.  Case study research in software engineering: Guidelines and examples.  John Wiley & Sons, 2012.
  * [34] Slinger Jansen Elena Baninemeh.  Dlt risk database of ramda project.  https://docs.google.com/spreadsheets/d/16Nyg2lmo5A6qFOJu7O2HqQM6L0x9-jSzUmRE8UKSek0/edit?usp=sharing.
  * [35] Ghassan O Karame, Elli Androulaki, and Srdjan Capkun.  Double-spending fast payments in bitcoin.  In Proceedings of the 2012 ACM conference on Computer and communications security, pages 906–917, 2012.
  * [36] Atul Singh et al.  Eclipse attacks on overlay networks: Threats and defenses.  In In IEEE INFOCOM. Citeseer, 2006.
  * [37] Nirupam Roy, Sheng Shen, Haitham Hassanieh, and Romit Roy Choudhury.  Inaudible voice commands: The $\\{$Long-Range$\\}$ attack and defense.  In 15th USENIX Symposium on Networked Systems Design and Implementation (NSDI 18), pages 547–560, 2018.
  * [38] Barbara Kitchenham.  Procedures for performing systematic reviews.  Keele, UK, Keele University, 33(2004):1–26, 2004.
  * [39] Siamak Farshidi, Slinger Jansen, and Jan Martijn van der Werf.  Capturing software architecture knowledge for pattern-driven design.  Journal of Systems and Software, 169:110714, 2020.
  * [40] Timothy Meline.  Selecting studies for systemic review: Inclusion and exclusion criteria.  Contemporary issues in communication science and disorders, 33(Spring):21–27, 2006.
  * [41] Muhamad Al Fikri, Fandi Aditya Putra, Yohan Suryanto, and Kalamullah Ramli.  Risk assessment using nist sp 800-30 revision 1 and iso 27005 combination technique in profit-based organization: Case study of zzz information system application in abc agency.  Procedia Computer Science, 161:1206–1215, 2019.
  * [42] Zeki Yazar.  A qualitative risk analysis and management tool–cramm.  SANS InfoSec Reading Room White Paper, 11:12–32, 2002.
  * [43] Jan Oyvind Aagedal, Folker Den Braber, Theodosis Dimitrakos, Bjørn Axel Gran, Dimitris Raptis, and Ketil Stolen.  Model-based risk assessment to improve enterprise security.  In Proceedings. Sixth International Enterprise Distributed Object Computing, pages 51–62. IEEE, 2002.
  * [44] Abbas Asosheh, Bijan Dehmoubed, and Amir Khani.  A new quantitative approach for information security risk assessment.  In 2009 2nd IEEE International Conference on Computer Science and Information Technology, pages 222–227. IEEE, 2009.
  * [45] Sameer Hasan Albakri, Bharanidharan Shanmugam, Ganthan Narayana Samy, Norbik Bashah Idris, and Azuan Ahmed.  Security risk assessment framework for cloud computing environments.  Security and Communication Networks, 7(11):2114–2124, 2014.
  * [46] Kristian Beckers, Maritta Heisel, Bjørnar Solhaug, and Ketil Stølen.  Isms-coras: A structured method for establishing an iso 27001 compliant information security management system.  In Engineering Secure Future Internet Services and Systems, pages 315–344. Springer, 2014.
  * [47] Srinivasan Jagannathan and Adam Sorini.  A cybersecurity risk analysis methodology for medical devices.  In 2015 IEEE Symposium on Product Compliance Engineering (ISPCE), pages 1–6. IEEE, 2015.
  * [48] Sari Widya Sihwi, Ferry Andriyanto, and Rini Anggrainingsih.  An expert system for risk assessment of information system security based on iso 27002.  In 2016 IEEE International Conference on Knowledge Engineering and Applications (ICKEA), pages 56–61. IEEE, 2016.
  * [49] Yulia Cherdantseva, Pete Burnap, Andrew Blyth, Peter Eden, Kevin Jones, Hugh Soulsby, and Kristan Stoddart.  A review of cyber security risk assessment methods for scada systems.  Computers & security, 56:1–27, 2016.
  * [50] Giacomo Morganti, Enrico Schiavone, and Andrea Bondavalli.  Risk assessment of blockchain technology.  In 2018 Eighth Latin-American Symposium on Dependable Computing (LADC), pages 87–96. IEEE, 2018.
  * [51] Jaap Vermeij.  Creating an it risk maturity model for distributed ledger applications.  Master’s thesis, University of Twente, 2018.
  * [52] Shi-Cho Cha and Kuo-Hui Yeh.  A data-driven security risk assessment scheme for personal data protection.  IEEE Access, 6:50510–50517, 2018.
  * [53] Petar Radanliev, David Charles De Roure, Razvan Nicolescu, Michael Huth, Rafael Mantilla Montalvo, Stacy Cannady, and Peter Burnap.  Future developments in cyber risk assessment for the internet of things.  Computers in industry, 102:14–22, 2018.
  * [54] Timothy Weil.  Risk assessment methods for cloud computing platforms.  IT Professional, 22(1):63–66, 2020.
  * [55] Ranwa Al Mallah, David López, and Bilal Farooq.  Cyber-security risk assessment framework for blockchains in smart mobility.  IEEE Open Journal of Intelligent Transportation Systems, 2:294–311, 2021.
  * [56] Yunpeng Wang, Yinghui Wang, Hongmao Qin, Haojie Ji, Yanan Zhang, and Jian Wang.  A systematic risk assessment framework of automotive cybersecurity.  Automotive Innovation, 4:253–261, 2021.
  * [57] Shuang Wang, Lei Ding, He Sui, and Zhaojun Gu.  Cybersecurity risk assessment method of ics based on attack-defense tree model.  Journal of Intelligent & Fuzzy Systems, 40(6):10475–10488, 2021\.
  * [58] Rafał Leszczyna.  Review of cybersecurity assessment methods: Applicability perspective.  Computers & Security, 108:102376, 2021.
  * [59] Panagiotis Chatzigiannis, Foteini Baldimtsi, and Konstantinos Chalkias.  Sok: auditability and accountability in distributed payment systems.  In Applied Cryptography and Network Security: 19th International Conference, ACNS 2021, Kamakura, Japan, June 21–24, 2021, Proceedings, Part II, pages 311–337. Springer, 2021.
  * [60] Ya-Ping Fu, Kwo-Jean Farn, and Chung-Huang Yang.  Coras for research of considering the integration risk management with iso/iec 27005.
  * [61] Carlos Bendicho.  Cyber security in cloud: Risk assessment models.  In Intelligent Computing: Proceedings of the 2021 Computing Conference, Volume 1, pages 471–482. Springer, 2022.
  * [62] Marco Angelini, Silvia Bonomi, and Alessandro Palma.  A methodology to support automatic cyber risk assessment review.  arXiv preprint arXiv:2207.03269, 2022.
  * [63] Anatoly P Durakovskiy, Victor S Gorbatov, Dmitriy A Dyatlov, and Dmitriy A Melnikov.  Security risk management methodology for distributed ledger systems.  In Biologically Inspired Cognitive Architectures 2021: Proceedings of the 12th Annual Meeting of the BICA Society, pages 96–112. Springer, 2022.
  * [64] Fang Zhang and Wenyan Song.  Sustainability risk assessment of blockchain adoption in sustainable supply chain: An integrated method.  Computers & Industrial Engineering, 171:108378, 2022.
  * [65] Nazmul Hossain, Taposh Das, Tariqul Islam, and Md Alam Hossain.  Cyber security risk assessment method for scada system.  Information Security Journal: A Global Perspective, 31(5):499–510, 2022.
  * [66] Ali Al-Zahrani.  Assessing and proposing countermeasures for cyber-security attacks.  International Journal of Advanced Computer Science and Applications, 13(1), 2022.
  * [67] Brian Neil Levine, Clay Shields, and N Boris Margolin.  A survey of solutions to the sybil attack.  University of Massachusetts Amherst, Amherst, MA, 7:224, 2006.
  * [68] Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg.  Eclipse attacks on bitcoin’s peer-to-peer network.  In 24th USENIX Security Symposium (USENIX Security 15), pages 129–144, 2015.
  * [69] Gabriel Antonio F Rebello, Gustavo F Camilo, Lucas CB Guimarães, Lucas Airam C de Souza, Guilherme A Thomaz, and Otto Carlos Duarte.  A security and performance analysis of proof-based consensus protocols.  Annals of Telecommunications, pages 1–21, 2021.
  * [70] Craig S Wright.  Bitcoin: a peer-to-peer electronic cash system.  Available at SSRN 3440802, 2008.
  * [71] Mubashar Iqbal and Raimundas Matulevičius.  Blockchain-based application security risks: a systematic literature review.  In International Conference on Advanced Information Systems Engineering, pages 176–188. Springer, 2019.
  * [72] Nazri Abdullah, Anne Hakansson, and Esmiralda Moradian.  Blockchain based approach to enhance big data authentication in distributed environment.  In 2017 Ninth international conference on ubiquitous and future networks (ICUFN), pages 887–892. IEEE, 2017.
  * [73] John R Douceur.  The sybil attack.  In International workshop on peer-to-peer systems, pages 251–260. Springer, 2002.
  * [74] Kurt Thomas, Jennifer Pullman, Kevin Yeo, Ananth Raghunathan, Patrick Gage Kelley, Luca Invernizzi, Borbala Benko, Tadek Pietraszek, Sarvar Patel, Dan Boneh, et al.  Protecting accounts from credential stuffing with password breach alerting.  In 28th USENIX Security Symposium (USENIX Security 19), pages 1556–1571, 2019.
  * [75] Christian Decker and Roger Wattenhofer.  Bitcoin transaction malleability and mtgox.  In European Symposium on Research in Computer Security, pages 313–326. Springer, 2014.
  * [76] Yujuan Wen, Fengyuan Lu, Yufei Liu, and Xinli Huang.  Attacks and countermeasures on blockchains: A survey from layering perspective.  Computer Networks, 191:107978, 2021.
  * [77] Nidhee Rathod and Dilip Motwani.  Security threats on blockchain and its countermeasures.  Int. Res. J. Eng. Technol, 5(11):1636–1642, 2018.
  * [78] How does blockchain technology tackle the credentials stuffing cyberattack in gaming?  https://www.gamesd.app/how-blockchain-technology-tackle-credentials-stuffing-cyberattack-in-gaming.
  * [79] Hilary Tuttle.  Cryptojacking.  Risk Management, 65(7):22–27, 2018.
  * [80] Jan Stodt, Daniel Schönle, Christoph Reich, Fatemeh Ghovanlooy Ghajar, Dominik Welte, and Axel Sikora.  Security audit of a blockchain-based industrial application platform.  Algorithms, 14(4):121, 2021.
  * [81] Markos Zachariadis, Garrick Hileman, and Susan V Scott.  Governance and control in distributed ledgers: Understanding the challenges facing blockchain technology in financial services.  Information and Organization, 29(2):105–117, 2019.
  * [82] Alexis Collomb and Klara Sok.  Blockchain/distributed ledger technology (dlt): What impact on the financial sector?  Digiworld Economic Journal, -(103), 2016.
  * [83] N Anita and M Vijayalakshmi.  Blockchain security attack: a brief survey.  In 2019 10th International Conference on Computing, Communication and Networking Technologies (ICCCNT), pages 1–6. IEEE, 2019.
  * [84] Juho Lindman, Virpi Kristiina Tuunainen, and Matti Rossi.  Opportunities and risks of blockchain technologies–a research agenda.  -, 2017.
  * [85] Mauro Conti, E Sandeep Kumar, Chhagan Lal, and Sushmita Ruj.  A survey on security and privacy issues of bitcoin.  IEEE Communications Surveys & Tutorials, 20(4):3416–3452, 2018\.
  * [86] Shari Pfleeger and Robert Cunningham.  Why measuring security is hard.  IEEE Security & Privacy, 8(4):46–54, 2010.
  * [87] Robert K Yin.  Case study research: Design and methods.  sage, 2009.
  * [88] C. Robson.  Real world research, 2nd edition., 2002.
  * [89] Kaihua Qin, Liyi Zhou, and Arthur Gervais.  Quantifying blockchain extractable value: How dark is the forest?  In 2022 IEEE Symposium on Security and Privacy (SP), pages 198–214. IEEE, 2022.