U.S. patent application number 16/175715 was filed with the patent office on 2019-05-02 for system and method for validation of distributed data storage systems.
The applicant listed for this patent is PricewaterhouseCoopers LLP. Invention is credited to Muhammad Emad KHAN, Alfred Michael SMITH.
Application Number | 20190132350 16/175715 |
Document ID | / |
Family ID | 64277938 |
Filed Date | 2019-05-02 |
United States Patent
Application |
20190132350 |
Kind Code |
A1 |
SMITH; Alfred Michael ; et
al. |
May 2, 2019 |
SYSTEM AND METHOD FOR VALIDATION OF DISTRIBUTED DATA STORAGE
SYSTEMS
Abstract
Provided herein is a risk framework tool for a distributed
ledger-based computing system (i.e., blockchain) that can present a
common risk framework to a user that can then allow for the user to
determine what risks are important for it to manage. The risk
framework can then take those specified risks and convert them in
to a plurality of tests that can be used to validate the
organization's blockchain system. In one or more examples, the risk
framework can provide a graphical user interface to user that
allows them specify the risks they wish to manage within the
blockchain computing system, and based on the user's inputs, can
determine one or more continuous real-time validation tests to be
performed on the blockchain computing system so as to characterize
the risk specified by user using the risk framework.
Inventors: |
SMITH; Alfred Michael;
(Madison, NJ) ; KHAN; Muhammad Emad; (New York,
NY) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
PricewaterhouseCoopers LLP |
NewYork |
NY |
US |
|
|
Family ID: |
64277938 |
Appl. No.: |
16/175715 |
Filed: |
October 30, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62579093 |
Oct 30, 2017 |
|
|
|
62579095 |
Oct 30, 2017 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 41/22 20130101;
H04L 9/0637 20130101; G06F 21/55 20130101; G06F 9/54 20130101; G06Q
2220/00 20130101; H04L 63/14 20130101; G06F 2221/034 20130101; H04L
2209/56 20130101; H04L 9/3236 20130101; G06F 21/10 20130101; G06F
21/60 20130101; H04L 63/1433 20130101; G06F 2221/2101 20130101;
G06Q 20/38215 20130101; G06Q 20/40 20130101; G06F 21/577 20130101;
G06F 16/2365 20190101; H04L 9/3297 20130101; G06F 16/2379 20190101;
G06Q 20/065 20130101; H04L 2209/38 20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06; G06F 17/30 20060101 G06F017/30; H04L 9/06 20060101
H04L009/06; H04L 12/24 20060101 H04L012/24 |
Claims
1. A method comprising: at an electronic device with a display and
an interface configured to accept one or more inputs from a user of
the electronic device: displaying one or more risk categories to a
user using the display; prompting the user to input one or more
risk levels via the interface, wherein each risk level on the one
or more risk levels corresponds to the one or more risk categories
displayed; displaying one or more test objectives or controls via
the display; prompting the user to indicate which of the one or
more test objectives are to be evaluated via the displaying; and
wherein in response to the user providing one or more risk levels
and one or more test objectives, the electronic device is caused
to: convert the one or more user provided risk levels and one or
more test objectives into one or more test procedures to be
implemented by a real-time distributed ledger-based computing
system validation tool; and transmit the generated one or more test
procedures to an external user.
2. The method of claim 1, wherein the one or more risk categories
are selected from a group consisting of government and oversight,
cyber security, infrastructure layer, architecture layer,
operational layer, and transaction layer.
3. The method of claim 2, wherein if the user selects a transaction
layer risk category, the electronic device is caused to convert the
one or more user provided risk levels into one or more test
procedures configured to validate an application layer of a
distributed ledger-based computing system technology stack.
4. The method of claim 2, wherein if the user selects a blockchain
architecture risk category, the electronic device is caused to
convert the one or more user provided risk levels into one or more
test procedures configured to validate a decentralized protocols
and encryption layer of a distributed ledger-based computing system
technology stack.
5. The method of claim 2, wherein if the user selects an
operational layer risk category, the electronic device is caused to
convert the one or more user provided risk levels into one or more
test procedures configured to validate a permissioned network layer
of a distributed ledger-based computing system technology
stack.
6. The method of claim 2, wherein if the user selects an
infrastructure layer risk category, the electronic device is caused
to convert the one or more user provided risk levels into one or
more test procedures configured to validate a shared data layer of
a distributed ledger-based computing system technology stack.
7. The method of claim 6, wherein if the user selects an
infrastructure layer risk category, the electronic device is caused
to convert the one or more user provided risk levels into one or
more test procedures configured to validate a commercial API layer
of a distributed ledger-based computing system technology
stack.
8. The method of claim 7, wherein if the user selects an
infrastructure layer risk category, the electronic device is caused
to convert the one or more user provided risk levels into one or
more test procedures configured to validate overlay network layer
of a distributed ledger-based computing system technology
stack.
9. The method of claim 1, wherein transmitting the generated one or
more test procedures to an external user includes transmitting the
generated one or more test procedures to a real-time continuous
distributed ledger-based computing system auditing tool.
10. The method of claim 9, wherein transmitting the generated one
or more test procedures includes writing the generated one or more
test procedures to a planning file, and transmitting the planning
file to the real-time continuous distributed ledger-based computing
system auditing tool.
11. A computing system, comprising: a display; a user interface
configured to receive inputs from a user of the system; a memory;
one or more processors; and one or more programs, wherein the one
or more programs are stored in the memory and configured to be
executed by the one or more processors, the one or more programs
when executed by the one or more processors cause the processor to:
display one or more risk categories to a user using the display;
prompt the user to input one or more risk levels via the interface,
wherein each risk level on the one or more risk levels corresponds
to the one or more risk categories displayed; display one or more
test objectives or controls via the display; prompt the user to
indicate which of the one or more test objectives are to be
evaluated via the displaying; and wherein in response to the user
providing one or more risk levels and one or more test objectives,
the electronic processor is caused to: convert the one or more user
provided risk levels and one or more test objectives into one or
more test procedures to be implemented by a real-time distributed
ledger-based computing system validation tool; and transmit the
generated one or more test procedures to an external user.
12. The computing system of claim 11, wherein the one or more risk
categories are selected from a group consisting of government and
oversight, cyber security, infrastructure layer, architecture
layer, operational layer, and transaction layer.
13. The computing system of claim 12, wherein if the user selects a
transaction layer risk category, the electronic device is caused to
convert the one or more user provided risk levels into one or more
test procedures configured to validate an application layer of a
distributed ledger-based computing system technology stack.
14. The computing system of claim 12, wherein if the user selects a
blockchain architecture risk category, the electronic device is
caused to convert the one or more user provided risk levels into
one or more test procedures configured to validate a decentralized
protocols and encryption layer of a distributed ledger-based
computing system technology stack.
15. The computing system of claim 12, wherein if the user selects
an operational layer risk category, the electronic device is caused
to convert the one or more user provided risk levels into one or
more test procedures configured to validate a permissioned network
layer of a distributed ledger-based computing system technology
stack.
16. The computing system of claim 12, wherein if the user selects
an infrastructure layer risk category, the electronic device is
caused to convert the one or more user provided risk levels into
one or more test procedures configured to validate a shared data
layer of a distributed ledger-based computing system technology
stack.
17. The computing system of claim 16, wherein if the user selects
an infrastructure layer risk category, the electronic device is
caused to convert the one or more user provided risk levels into
one or more test procedures configured to validate a commercial API
layer of a distributed ledger-based computing system technology
stack.
18. The computing system of claim 17, wherein if the user selects
an infrastructure layer risk category, the electronic device is
caused to convert the one or more user provided risk levels into
one or more test procedures configured to validate overlay network
layer of a distributed ledger-based computing system technology
stack.
19. The computing system of claim 11, wherein transmitting the
generated one or more test procedures to an external user includes
transmitting the generated one or more test procedures to a
real-time continuous distributed ledger-based computing system
auditing tool.
20. The computing system of claim 19, wherein transmitting the
generated one or more test procedures includes writing the
generated one or more test procedures to a planning file, and
transmitting the planning file to the real-time continuous
distributed ledger-based computing system auditing tool.
21. A computer readable storage medium storing one or more
programs, the one or more programs comprising instructions, which,
when executed by an electronic device with a display and a user
input interface, cause the device to: display one or more risk
categories to a user using the display; prompt the user to input
one or more risk levels via the interface, wherein each risk level
on the one or more risk levels corresponds to the one or more risk
categories displayed; display one or more test objectives or
controls via the display; prompt the user to indicate which of the
one or more test objectives are to be evaluated via the displaying;
and wherein in response to the user providing one or more risk
levels and one or more test objectives, the device is caused to:
convert the one or more user provided risk levels and one or more
test objectives into one or more test procedures to be implemented
by a real-time distributed ledger-based computing system validation
tool; and transmit the generated one or more test procedures to an
external user.
22. The computer readable storage medium of claim 21, wherein the
one or more risk categories are selected from a group consisting of
government and oversight, cyber security, infrastructure layer,
architecture layer, operational layer, and transaction layer.
23. The computer readable storage medium of claim 22, wherein if
the user selects a transaction layer risk category, the electronic
device is caused to convert the one or more user provided risk
levels into one or more test procedures configured to validate an
application layer of a distributed ledger-based computing system
technology stack.
24. The computer readable storage medium of claim 22, wherein if
the user selects a blockchain architecture risk category, the
electronic device is caused to convert the one or more user
provided risk levels into one or more test procedures configured to
validate a decentralized protocols and encryption layer of a
distributed ledger-based computing system technology stack.
25. The computer readable storage medium of claim 22, wherein if
the user selects an operational layer risk category, the electronic
device is caused to convert the one or more user provided risk
levels into one or more test procedures configured to validate a
permissioned network layer of a distributed ledger-based computing
system technology stack.
26. The computer readable storage medium of claim 22, wherein if
the user selects an infrastructure layer risk category, the
electronic device is caused to convert the one or more user
provided risk levels into one or more test procedures configured to
validate a shared data layer of a distributed ledger-based
computing system technology stack.
27. The c computer readable storage medium of claim 26, wherein if
the user selects an infrastructure layer risk category, the
electronic device is caused to convert the one or more user
provided risk levels into one or more test procedures configured to
validate a commercial API layer of a distributed ledger-based
computing system technology stack.
28. The computer readable storage medium of claim 27, wherein if
the user selects an infrastructure layer risk category, the
electronic device is caused to convert the one or more user
provided risk levels into one or more test procedures configured to
validate overlay network layer of a distributed ledger-based
computing system technology stack.
29. The computer readable storage medium of claim 21, wherein
transmitting the generated one or more test procedures to an
external user includes transmitting the generated one or more test
procedures to a real-time continuous distributed ledger-based
computing system auditing tool.
30. The computer readable storage medium of claim 29, wherein
transmitting the generated one or more test procedures includes
writing the generated one or more test procedures to a planning
file, and transmitting the planning file to the real-time
continuous distributed ledger-based computing system auditing tool.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] The present application which claims the benefit of U.S.
Provisional Patent Application Ser. No. 62/579,093, filed Oct. 30,
2017, and U.S. Provisional Patent Application Ser. No. 62/579,095,
filed Oct. 30, 2017, each of which are incorporated herein by
reference in their entirety and for all purposes.
FIELD OF THE DISCLOSURE
[0002] The present disclosure relates generally to validation of
distributed data storage systems, such as, for example,
blockchain-based data storage systems.
BACKGROUND OF THE DISCLOSURE
[0003] A distributed data storage (which may be referred to as a
distributed database) system may include data storage devices that
are not connected to a common processing unit, but are in different
computing systems located at the same physical location or
dispersed across one or more networks of interconnected computing
systems at different physical locations. The data storage devices
may communicate with each other via one or more wired or wireless
communication networks. Typically, each of the data storage devices
includes a copy of the stored data. Storing copies of the data in
different data storage devices may eliminate a single
point-of-failure and may induce both higher availability and
increased reliability of the stored data.
[0004] Blockchain technology may be used to implement a distributed
data storage system. In the blockchain technology, a system of
networked nodes, e.g., computers or servers, each store a copy of
the entire distributed data storage system. The blockchain-based
distributed data storage system is often referred to as a
blockchain. Whenever a group of data records is to be added to the
distributed database, i.e., blockchain, each node may independently
verify the group of data records in a batch process known as
generating a block (also referred to as a data block). In the batch
process, a node verifies the group of data records based on its
copy of the blockchain storing previously verified data records. A
node that generates the block may transmit the generated block to
every other node in the system. In current implementations, only
after the block has been verified by each node in the system may
each node add the block to its copy of the blockchain. As each of
the nodes independently verifies the block, blockchain technology
may reduce the risk of a single point-of-attack or a single
point-of-failure. Further, since a copy of the blockchain is
maintained at each node, the data can be stored in a redundant
manner.
[0005] A blockchain is a record of data activities. These data
activities can be transactions in a distributed ledger, and/or any
movement of money, goods, and/or secured or unsecured data
involved, for example, in a purchase at a supermarket, in the
creation and storage of a user's digital identification, in the
assignment of a government ID number, in energy data exchange in
the energy industry, in an e-voting service, or in the recording,
tracking, and transferring of deeds and contractual agreements.
[0006] FIG. 1 illustrates a blockchain process flow in accordance
with examples of the disclosure. The blockchain process flow 100
can begin at step 102, wherein a user/party can request to
implement a transaction in the blockchain. Examples of transactions
can be storing data such as a record to a distributed ledger. Once
the request has been made at step 104, the transaction can be
broadcast to other computers (known as nodes) in the network. At
step 106, the network of nodes can then validate the transaction
using a mutually a priori agreed upon algorithm. Once each node in
the network of nodes validates the transaction, the process can
move to step 108, wherein the verified transaction can be combined
with other transactions (described in detail below) to create a new
block of data for the ledger. Once the verified transaction has
been combined, the process can move to step 110 wherein the new
block can be added to the network's block chain. The new block can
be added in such a way as to make it permanent and unalterable
(i.e., through the use of cryptography). Once the new block has
been added the process can move to step 112 wherein the transaction
is completed.
[0007] As shown in FIG. 1, a blockchain needs to do two things:
gather and order data into blocks, and then chain them together
securely using cryptography. A blockchain is a decentralized ledger
of all transactions in a network. Using blockchain technology,
participants in the network can confirm transactions without the
need for a trusted third-party intermediary.
[0008] FIG. 2 illustrates the process of generating a data block in
a blockchain in accordance with examples of the disclosure. In the
process 200, a piece of digital content (i.e., a new transaction
represented in binary) can be received. Once received, the process
can move to step 204 wherein a hash function is applied to the
received transaction, so as to combine it with data from a
pre-existing block in the blockchain. The output of the hash
function can produce a fixed and smaller-in-length unique digital
output. Hash algorithms can carefully designed to flow one-way
making it impossible to determine the original digital content from
the output once the hash algorithm is applied. Every new block in
the blockchain may be linked with the hash function of the previous
block to create a chain. At step 206, once the has function has
been applied, an output can be generated. The output of the hash
function can be a part of the data that is used in the creation of
blocks, and these blocks can then cryptographically chained
together at step 208. This process of creating blocks allows the
blockchain system to prove that a file existed in a particular
format at a given time without having to reveal the data in the
file.
[0009] One of the benefits of blockchain is that every participant
in the network has simultaneous access to a view of the
information, thus allowing almost real-time data availability and
transparency that can eliminate the need for reconciliation. Also,
the integrity and security of the information on the blockchain are
ensured with cryptographic functions that can prevent unwanted
intrusion on the network from non-authenticated participants. In
blockchain technology, verification can be achieved by participants
confirming changes with one another, thus replacing the need for a
third party to authorize transactions and providing a facility for
peers in the network to validate updated information, thereby
ensuring the validity and integrity of the data on the blockchain.
Another benefit of blockchain includes the ability to run
additional business logic; this means that agreement on the
expected behavior of financial instruments can be embedded in the
blockchain, which can facilitate the ability to design and
implement shared workflow and enhance automation. Also, the ability
to issue a digital currency or a digital asset designed to work as
a medium of exchange using cryptography to secure the transactions
and to control the creation of additional units facilitates the
ability to create and move assets without a trusted third party in
the blockchain.
SUMMARY OF THE DISCLOSURE
[0010] Blockchain presents a challenge to the traditional
validation (also referred to as audit) approach, given there's no
practical way to use point-in-time forensic analysis--the standard
validation tool. Attempting to conduct a point-in-time forensic
retrospective analysis can be ineffective and wildly inefficient.
The conventional approach to auditing can negate one of the
benefits of implementing blockchain in the first place: the promise
of increased administrative efficiency. Also, the traditional
validation approach can require the entire blockchain hash function
to be reversed to obtain transparency of the digital content
without breaking the chain or sequential order of the blocks. Such
approach could cause significant technical complexities,
challenges, and inefficiencies in the validation of a
blockchain-based data storage system.
[0011] Increases in the volume of data activities and rapidly
evolving complex technologies are creating a critical need for
business, technology, and compliance functions to be prepared,
adaptive, and agile to emerging challenges. Due to the increase in
data activities, current validation methodologies that are manual,
sample-based, and point-in-time do not provide the needed level of
confidence. Validation methodologies need to shift from a manual to
an automated and continuous approach to address a significant
increase in data activities and emerging, complex new technologies.
Current audit methodologies cannot provide the necessary assurance
in areas where a blockchain is used.
[0012] Accordingly, there is a need for systems and methods to
replace the conventional validation approach with a real-time
validating process to build confidence and assurance in the
blockchain technology. The concept behind real-time validating is
to inspect data activities closer and closer to the point of
occurrence. Real-time validating eliminates the concept of sampling
in the conventional validating process. The purpose of sampling is
to perform backwards-looking assessments of segments of populations
to draw conclusions about the rest of the population. The
embodiments described herein provide blockchain assurance-related
baselines that eliminate the need for sampling in blockchain
validating.
[0013] The type of validation and auditing required for a given a
distributed ledger-based system such as blockchain can be user
specific. No two organizations may need the same validation regime
to audit its blockchain system. Often times, various risks and
concerns may be important in one context, but not as critical in
others. Therefore, there is a need to specify the types of tests
that will be used based on a specific user/organization's risk
priorities. The present disclosure thus provides a common risk
framework that can allow for a user to conveniently determine what
risks are important for it to manage. The risk framework can then
take those specified risks and convert them in to a plurality of
tests that can be used to validate the organization's blockchain
system. The risk framework can thus be used to customize a software
tool that can then be used to perform real-time validation of an
organizations blockchain computing infrastructure and system.
[0014] In some embodiments, a validation tool/system for any given
blockchain use case may include tools for monitoring and validating
of data activities (also referred as transactions) in one or more
data blocks of the blockchain, risk evaluation of the data
activities, business and technical risk and reporting assessments,
and software that enables transaction level assurance for
operational processes running on any given blockchain use case. The
continuous assurance, compliance, monitoring, and validating
methodology may be a combination of services and software intended
to provide transparency in meeting the assurance and compliance
needs of stakeholders. In some embodiments, the continuous
assurance, compliance, monitoring, and validating of blockchains
may be based on an acceptance criteria. In some embodiments, the
acceptance criteria may include evaluating the current state of a
blockchain use case against different risk categories (e.g., six or
more different risk categories) and across sub-categories (e.g.,
100 or more different sub-categories) in order to address assurance
and compliance needs of stakeholders. This evaluation may be
performed by a risk evaluation system that is industry, use case
and Blockchain platform agnostic.
[0015] In some embodiments, a method for validating a
blockchain-based data storage system is provided. The method
comprising: conducting a risk analysis of using the
blockchain-based data storage system in a specified environment;
generating a risk profile of one or more data activities in a data
block of the blockchain-based data storage system based on the risk
analysis of using the blockchain-based data storage system in the
specified environment; determining a number of times a validity
test is to be performed on the one or more data activities in the
data block to achieve a predetermined level of assurance, wherein
the validity test tests compliance of the one or more data
activities with an operating protocol of the blockchain-based data
storage system; performing the validity test on the one or more
data activities; and generating one or more validity test reports
based on output of the validity test.
[0016] In some embodiments of the method, further comprising:
displaying a user interface for selecting one or more test
parameters of the validity test for testing compliance of the one
or more data activities with the operating protocol of the
blockchain-based data storage system; receiving from a user using
the user interface one or more selections of the one or more
validity test parameters based on the risk profile; and configuring
the validity test based on the selection of the one or more
validity test parameters.
[0017] In some embodiments of the method, the conducting the risk
analysis comprises determining one or more risk categories of one
or more risks involved in using the blockchain-based data storage
system in a specified environment
[0018] In some embodiments of the method, the validity test is
selected based on the risk categories.
[0019] In some embodiments of the method, the one or more risk
categories are selected from a group consisting of government and
oversight, cyber security, infrastructure layer, architecture
layer, operational layer, and transaction layer.
[0020] In some embodiments of the method, the one or more data
activities comprise storing one or more data in the data block.
[0021] In some embodiments of the method, the performing the
validity test comprises performing the validity test continuously
on the stored one or more data.
[0022] In some embodiments of the method, the generating the one or
more validity test reports comprises: receiving from the user using
the user interface a selection of one or more time periods within
the one or more validity test; analyzing the output of the validity
test during the one or more time periods; and generating the one or
more validity test reports at end of each of the one or more time
periods.
[0023] In some embodiments of the method, the performing the
validity test comprises displaying, using the user interface, the
output of the validity test; and wherein, in response to the output
indicating that the one or more data activities failed the validity
test, receiving from the user using the user interface a selection
of whether the one or more data activities are exceptions to the
operating protocol of the blockchain-based data storage system.
[0024] In some embodiments, a system comprising one or more
processors and a memory comprising one or more programs, which when
executed by the one or more processors, cause the one or more
processors to: conduct a risk analysis of using the
blockchain-based data storage system in a specified environment;
generate a risk profile of one or more data activities in a data
block of the blockchain-based data storage system based on the risk
analysis of using the blockchain-based data storage system in the
specified environment; determine a number of times a validity test
is to be performed on the one or more data activities in the data
block to achieve a predetermined level of assurance, wherein the
validity test tests compliance of the one or more data activities
with an operating protocol of the blockchain-based data storage
system; perform the validity test on the one or more data
activities; and generate one or more validity test reports based on
output of the validity test.
[0025] In some embodiments of the system, the one or more
processors are further caused to: display a user interface for
selecting one or more test parameters of the validity test for
testing compliance of the one or more data activities with the
operating protocol of the blockchain-based data storage system;
receive from a user using the user interface one or more selections
of the one or more validity test parameters based on the risk
profile; and configure the validity test based on the selection of
the one or more validity test parameters.
[0026] In some embodiments of the system, the one or more
processors are caused to determine one or more risk categories of
one or more risks involved in using the blockchain-based data
storage system in a specified environment
[0027] In some embodiments of the system, the validity test is
selected based on the risk categories.
[0028] In some embodiments of the system, the one or more risk
categories are selected from a group consisting of government and
oversight, cyber security, infrastructure layer, architecture
layer, operational layer, and transaction layer.
[0029] In some embodiments of the system, the one or more data
activities comprises storing one or more data in the data
block.
[0030] In some embodiments of the system, the validity test is
performed continuously on the stored one or more data.
[0031] In some embodiments of the system, the one or more
processors are caused to: receive from the user using the user
interface a selection of one or more time periods within the one or
more validity test; analyze the output of the one or more validity
tests during the one or more time periods; and generate the one or
more validity test reports at end of each of the one or more time
periods.
[0032] In some embodiments of the system, the one or more
processors are caused to display, using the user interface, the
output of the validity test; and wherein, in response to the output
indicating that the one or more data activities failed the validity
test, the one or more processors are caused to receive from the
user using the user interface a selection of whether the one or
more data activities are exceptions to the operating protocol of
the blockchain-based data storage system.
[0033] In some embodiments, a non-transitory computer-readable
storage medium storing one or more programs for validating a
blockchain-based data storage system, the one or more programs
configured to be executed by one or more processors and including
instructions to: conduct a risk analysis of using the
blockchain-based data storage system in a specified environment;
generate a risk profile of one or more data activities in a data
block of the blockchain-based data storage system based on the risk
analysis of using the blockchain-based data storage system in the
specified environment; determine a number of times a validity test
is to be performed on the one or more data activities in the data
block to achieve a predetermined level of assurance, wherein the
validity test tests compliance of the one or more data activities
with an operating protocol of the blockchain-based data storage
system; perform the validity test on the one or more data
activities; and generate one or more validity test reports based on
output of the validity test.
BRIEF DESCRIPTION OF THE FIGURES
[0034] FIG. 1 illustrates a blockchain process flow in accordance
with some embodiments.
[0035] FIG. 2 illustrates generation of a data block in a
blockchain in accordance with some embodiments.
[0036] FIG. 3 illustrates shift in validating and control processes
in distributed data storage systems in accordance with some
embodiments.
[0037] FIG. 4 illustrates steps of a validation method for
validating data activities in a data block of a blockchain data
storage system in accordance with some embodiments.
[0038] FIG. 5A illustrates a correspondence of the risk framework
testing procedures to a technology stack of a blockchain system
according to examples of the disclosure.
[0039] FIG. 5B illustrates sub-categories corresponding to each
risk framework category according to examples of the
disclosure.
[0040] FIG. 6 illustrates an exemplary process for generating
blockchain test procedures according to examples of the
disclosure.
[0041] FIG. 7 illustrates an example of a computing device in
according to examples of the disclosure.
[0042] Illustrative embodiments will now be described with
reference to the accompanying drawings. In the drawings, like
reference numerals generally indicate identical, functionally
similar, and/or structurally similar elements.
DETAILED DESCRIPTION
[0043] Embodiments of the present disclosure may be implemented in
hardware, firmware, software, or any combination thereof.
Embodiments of the present disclosure may also be implemented as
instructions stored on a machine-readable medium, which may be read
and executed by one or more processors. A machine-readable medium
may include any mechanism for storing or transmitting information
in a form readable by a machine (e.g., a computing device). For
example, a machine-readable medium may include read only memory
(ROM); random access memory (RAM); magnetic disk storage media;
optical storage media; flash memory devices, and others. Further,
firmware, software, routines, instructions may be described herein
as performing certain actions. However, it should be appreciated
that such descriptions are merely for convenience and that such
actions in fact result from computing devices, processors,
controllers, or other devices executing the firmware, software,
routines, instructions, etc.
[0044] The embodiments described herein may be implemented within a
local computer system. The computer system may be implemented in
the contexts of the likes of computing systems, networks, servers,
or combinations thereof. The computer system includes one or more
processors and main memory. Main memory may store, in part,
instructions and data for execution by processors. Main memory
stores the executable code when in operation, in this example. The
computer system may further include a mass data storage, a portable
storage device, output devices, user input devices, a graphics
display system, and/or peripheral devices.
[0045] The components of the computer system may be connected to a
communication infrastructure (e.g., a bus or network). Processors
and main memory may be connected via a local microprocessor bus,
and the mass data storage, peripheral device(s), portable storage
device, and graphics display system may be connected via one or
more input/output (I/O) buses.
[0046] Mass data storage, which can be implemented with a magnetic
disk drive, solid state drive, or an optical disk drive, is a
non-volatile storage device for storing data and instructions for
use by processor. Mass data storage may store the system software
for implementing embodiments of the present disclosure for purposes
of loading that software into main memory.
[0047] Portable storage device may operate in conjunction with a
portable non-volatile storage medium, such as a flash drive, floppy
disk, compact disk, digital video disc, or Universal Serial Bus
(USB) storage device, to input and output data and code to and from
the computer system. The system software for implementing
embodiments of the present disclosure may be stored on such a
portable medium and input to the computer system via the portable
storage device.
[0048] User input devices can provide a portion of a user
interface. User input devices may include one or more microphones,
an alphanumeric keypad, such as a keyboard, for inputting
alphanumeric and other information, or a pointing device, such as a
mouse, a trackball, stylus, or cursor direction keys. User input
devices can also include a touchscreen. Suitable output devices
include speakers, printers, network interfaces, and monitors.
[0049] Graphics display system may include a liquid crystal display
(LCD) or other suitable display device. Graphics display system may
be configurable to receive textual and graphical information and
processes the information for output to the display device.
[0050] Peripheral devices may include any type of computer support
device that adds additional functionality to the computer
system.
[0051] The components provided in the computer system are those
typically found in computer systems that may be suitable for use
with embodiments of the present disclosure and are intended to
represent a broad category of such computer components that are
well known in the art. Thus, the computer system can be a personal
computer (PC), hand held computer system, telephone, mobile
computer system, workstation, tablet, phablet, mobile phone,
server, minicomputer, mainframe computer, wearable, or any other
computer system. The computer may also include different bus
configurations, networked platforms, multi-processor platforms, and
the like. Various operating systems may be used including UNIX,
LINUX, WINDOWS, MAC OS, PALM OS, QNX ANDROID, IOS, CHROME, TIZEN,
and other suitable operating systems.
[0052] The processing for various embodiments may be implemented in
software that is cloud-based. In some embodiments, the computer
system described above may be implemented as a cloud-based
computing environment, such as a virtual machine operating within a
computing cloud. In other embodiments, the computer system may
itself include a cloud-based computing environment, where the
functionalities of the computer system are executed in a
distributed fashion. Thus, the computer system, when configured as
a computing cloud, may include pluralities of computing devices in
various forms.
[0053] The cloud may be formed, for example, by a network of web
servers that comprise a plurality of computing devices, such as the
computer system, with each server (or at least a plurality thereof)
providing processor and/or storage resources. These servers may
manage workloads provided by multiple users (e.g., cloud resource
customers or other users). Typically, each user places workload
demands upon the cloud that vary in real-time, sometimes
dramatically. The nature and extent of these variations typically
depends on the type of business associated with the user.
[0054] Computer program code for carrying out operations for
aspects of the present disclosure may be written in any combination
of one or more programming languages, including an object oriented
programming language such as Java, Smalltalk, C++ or the like and
conventional procedural programming languages, such as the "C"
programming language or similar programming languages. The program
code may execute entirely on the user's computer, partly on the
user's computer, as a stand-alone software package, partly on the
user's computer and partly on a remote computer or entirely on the
remote computer or server. In the latter scenario, the remote
computer may be coupled with the user's computer through any type
of network, including a local area network (LAN) or a wide area
network (WAN), or the connection may be made to an external
computer (for example, through the Internet using an Internet
Service Provider).
[0055] Aspects of the present invention are described below with
reference to flowchart illustrations and/or block diagrams of
methods, apparatus (systems) and computer program products
according to embodiments of the present invention. It will be
understood that each block of the flowchart illustrations and/or
block diagrams, and combinations of blocks in the flowchart
illustrations and/or block diagrams, can be implemented by computer
program instructions. These computer program instructions may be
provided to a processor of a general purpose computer, special
purpose computer, or other programmable data processing apparatus
to produce a machine, such that the instructions, which execute via
the processor of the computer or other programmable data processing
apparatus, create means for implementing the functions/acts
specified in the flowchart and/or block diagram block or
blocks.
[0056] These computer program instructions may also be stored in a
computer readable medium that can direct a computer, other
programmable data processing apparatus, or other devices to
function in a particular manner, such that the instructions stored
in the computer readable medium produce an article of manufacture
including instructions which implement the function/act specified
in the flowchart and/or block diagram block or blocks.
[0057] The flowchart and block diagrams in the Figures illustrate
the architecture, functionality, and operation of possible
implementations of systems, methods and computer program products
according to various embodiments of the present invention. In this
regard, each block in the flowchart or block diagrams may represent
a module, segment, or portion of code, which comprises one or more
executable instructions for implementing the specified logical
function(s). It should also be noted that, in some alternative
implementations, the functions noted in the block may occur out of
the order noted in the figures. For example, two blocks shown in
succession may, in fact, be executed substantially concurrently, or
the blocks may sometimes be executed in the reverse order,
depending upon the functionality involved. It will also be noted
that each block of the block diagrams and/or flowchart
illustration, and combinations of blocks in the block diagrams
and/or flowchart illustration, can be implemented by special
purpose hardware-based systems that perform the specified functions
or acts, or combinations of special purpose hardware and computer
instructions.
[0058] While various embodiments have been described below, it
should be understood that they have been presented by way of
example only, and not limitation. The descriptions are not intended
to limit the scope of the invention to the particular forms set
forth herein. Thus, the breadth and scope of a preferred embodiment
should not be limited by any of the exemplary embodiments described
herein. It should be understood that the description is
illustrative and not restrictive. To the contrary, the present
descriptions are intended to cover such alternatives,
modifications, and equivalents as may be included within the spirit
and scope of the invention as defined by the appended claims and
otherwise appreciated by one of ordinary skill in the art.
[0059] Blockchain validation tool/system (may be referred as
Blockchain Continuous Assurance, Compliance, Monitoring and
Validating Solution or Blockchain Continuous Validating Solution)
can include a Continuous Assurance, Compliance, Monitoring and
Validating Methodology (may be referred as continuous validating
methodology), Continuous Assurance, Compliance, Monitoring and
Validating Criteria (may be referred as blockchain validating
criteria or acceptance criteria), blockchain risk evaluation system
(may be referred as blockchain risk framework), business and
technical risk and reporting assessments, and software that enables
transaction level assurance for any given Blockchain use case. The
validation system can include a combination of services and
software designed for practitioners to provide transparency in
meeting the assurance and compliance needs of users of
blockchain-based data storage systems.
[0060] FIG. 3 illustrates an exemplary process for deploying a
distributed ledger validation tool according to examples of the
disclosure. In the example of FIG. 3, the process 300 can begin at
step 302 wherein the customer's (who will be using the validation
system) blockchain use-case is analyzed. The use-case analysis
performed at step 302 can include as an example, determining the
type of blockchain that is being used by the customer, analyzing
how the customer is using the block chain to effect transactions
and what solutions the blockchain is meant to deliver to the
customer.
[0061] Once a use-case analysis is completed at step 302, the
process can move to step 304, wherein a risk framework analysis is
applied to the customer blockchain. A risk framework is a tool that
can be used by stakeholders or auditors to assess and define the
assurance and compliance needs of a particular blockchain use-case.
The framework can allow the user to step through a series of
categories of risks (i.e., risks to an organization engendered by
their use of blockchain) to determine what risks they wish to audit
for, and to determine the extent to which those risks would harm
the organization. The risk framework described above can be
industry, use-case, and blockchain technology agnostic so that
practitioners across all industries and sectors can use to address
the risk assurance and compliance needs independent of the
Blockchain technology variant and use case.
[0062] Practitioners can use the risk framework as a standard
approach and framework to evaluate the current state of a
Blockchain use case which can be inclusive of upstream and
downstream (on-Blockchain and off-Blockchain) processes,
technologies, and underlying data elements (people, processes,
technologies) against 6 different risk categories, applicable
domains, and 100+ sub-risk categories in order to address assurance
and compliance needs (risks, control objectives, controls, testing
objectives and procedures, and reporting parameters) of the
following stakeholders simultaneously or exclusively. The risk
categories, domains and sub-risk categories can be used exclusively
or mutually exclusively to determine targeted and/or upstream and
downstream impacts. These parameters can be used to customize and
personalize an assurance or auditing software/tool to achieve
required level of assurance and compliance as by-product of
processed transactions.
[0063] In one or more examples, the risk framework can include such
categories as: governance and oversight of the blockchain,
cybersecurity issues with the blockchain, infrastructure risks,
blockchain architecture risks, operational risks, and transactional
risks. As part of using the risk framework, a user can (via user
interface) go over each risk category and the sub-categories within
each risk category and indicate which risks are pertinent to their
organization (or that they wish to be analyzed), and also indicate
the degree and scope of those risks using the risk framework.
[0064] Once a user has engaged the risk framework at step 304 to
identify the risks they want analyzed during an audit, the process
can move to step 306 wherein the user-preferences supplied to the
risk framework can be converted in to one or more testing
procedures to be performed during the real-time compliance testing
of the customer's blockchain. As will be described in further
detail below, the testing procedures can then be used by the
validation/auditing software to in real-time audit the
blockchain.
[0065] Once the results from the risk framework are converted to
testing procedures at step 306, the process can move to step 308,
wherein the real-time auditing tool is customized using the results
gleaned from the risk framework. In one or more examples,
customizing the auditing tool can include setting up one or more
testing procedures that the tool will engage in during its
operation, and also setting up the formatting of the reports that
the tool will ultimately produce for review by the customer
(described in further detail below).
[0066] Finally, once the tool has been customized per based on the
assessment of the use-case established at step 302 and the
application of the risk framework at step 304, the process can move
to step 310 wherein the tool is deployed in the customer
environment. As will be described in further detail below,
deploying the tool can refer to the creation of a validation node
that becomes part of the customer blockchain environment. The
validation node can be a read only node that includes the software
to run the test procedures discussed with respect to step 306 on
blockchain transactions as they occur in real time in the customer
environment.
[0067] In one or more embodiments, the validation system created by
the process described with respect to FIG. 3, may utilize a
permanent planning file that can contain the details and results of
the risk framework application, that can then be used at step 306
to convert the risk framework results into testing procedures. In
other embodiments, the permanent planning file can instead be
directly created by a user without the need to engage in the risk
framework analysis above.
[0068] In some embodiments, the above set of activities of the
validating methodology may be executed systematically (e.g., via
software, hardware, or a combination thereof) with manual input by
the auditor or compliance practitioner. In one or more examples,
the validating methodology described above with respect to steps
302 may be divided into three phases (e.g., planning, fieldwork,
and reporting sprints). The three phases are described below.
[0069] Planning Phase: In some embodiments, steps 302, 304, and 306
of FIG. 3 may constitute the planning phase. During the planning
phase, an assessment is performed to identify validating test
procedures using blockchain validating criteria and risk framework.
In order to provide a required level of assurance for any given
blockchain use case, a standardized acceptance criterion is
developed to capture inputs and outputs and set the right assurance
threshold level based on stakeholders' requirements, as needed. A
blockchain risk framework can be used to identify inputs and define
outputs in order to create the required level of assurance. Based
on the assessment results obtained from using the criteria and risk
framework of step 304, validity test and reporting parameters are
determined (at step 306).
[0070] Fieldwork Phase: In some embodiments, step 308 and 310 of
FIG. 3 may constitute the fieldwork phase. During the fieldwork
phase, the validating software may be customized with the test and
reporting parameters determined in the planning phase. Once the
customized software is deployed at step 310, transactional
information can be captured based on the defined data parameters
and passed through a rules engine (described in further detail
below), which can host the validity test rules. Practitioner uses
the validity software to execute real-time evidence gathering and
testing across a data activities--level data population set on a
real-time basis (or some other interval if preferred, e.g.,
bi-monthly or monthly).
[0071] As will be described in further detail below, the software
can classify testing results as either an observation (visual or
virtual alert) when the rule breaks/fails, or a no-observation if
the transaction passes the test rule with no breaks/fails. A
practitioner classifies an observation as either an
exception/deviation noted, or no exception/deviation noted.
Further, the practitioner raises exception(s)/deviation(s) noted
per test procedure as an issue, including exception/deviation
details, investigation results, issue summaries and details, impact
rankings and details, and management action plan details.
[0072] Reporting Phase: In some embodiments, step 310 of FIG. 3 may
constitute the reporting phase. Once the validity tests and other
fieldwork activities (i.e., exceptions/deviations and issues) are
complete, the deployed tool can produce an issue and interim audit
report, including ratings and details at the process and subprocess
levels to achieve continuous reporting and monitoring (or some
other interval if preferred, e.g., bi-monthly or monthly. In some
embodiments, after the interim reporting cycle for the quarter (or
some other interval if preferred) is complete, practitioner
produces and issues a quarterly audit report including ratings and
opinions at the process and subprocess levels to the
stakeholders.
[0073] The testing and reporting can provide the required assurance
level information at the process and subprocess levels based on the
applicable risks, controls, testing objectives, and reporting
parameters across the entire population data set to address
stakeholders' needs.
[0074] In some embodiments, the exception can be replaced with the
deviation in the flow described above to address the process and
functional needs of the stakeholders in compliance or
non-compliance areas (outside of audit).
[0075] In some embodiments, the validating methodology provides a
practitioner with an end-to-end standardized audit process and sets
of activities that can be used to obtain real-time transparency
around given business processes (i.e., non-blockchain and
blockchain) and provide compliance and audit-type reporting
automatically or manually. In some embodiments, the methodology
enables the practitioner to execute set of audit and compliance
activities by the computer in a continuous fashion, which can bring
a significant increase in efficiency and effectiveness, achieving a
higher/maximum level of confidence.
[0076] In some embodiments, the blockchain validation tool/system
is designed and developed to provide real-time transaction-level
assurance with immediate results across a full population data set,
which can be used by stakeholders and end-users simultaneously or
exclusively to address their assurance, audit, and/or compliance
needs. Some examples of stakeholders would be such personnel as the
head of innovation, head of corporate development, chief technology
officer, head of business segment(s), and chief audit executive.
Some examples of end-users would be internal users (e.g.,
operations (first line of defense), enterprise risk management
(second line of defense), internal audit (third line of defense),
and tax); and external users (e.g., legal and regulatory).
[0077] Some assumptions in performing real-time assurance may
include that: (1) off-chain data (i.e., data not stored within the
blockchain) exists and may be required for key assurance reporting;
(2) ordering, integrity, and completeness of data activities in a
blockchain can be critical to assurance; (3) while the integrity of
blockchain data can be validated, third-party "off-chain" data is
not immutable and subject to change; and (4) assurance is being
conducted on the qualitative and quantitative data activities of
the blockchain, rather than the technical blockchain implementation
(consensus protocols, block formation rules, blockchain forks,
etc.).
[0078] The blockchain validation system may include major five
components: (1) customer environment 404, (2) integration unit 406,
(3) data block service unit 408, (4) front-end service or reporting
unit 410, and (5) interfaces 412. In addition, the system 400 may
interface with third-party computing systems (as indicated by block
402) as well as the customer blockchain 404. The following sections
discuss these architectural components of the blockchain validation
system (which may be referred to as the blockchain assurance and
validation solution, blockchain assurance and validating software,
or blockchain assurance solution).
[0079] FIG. 4 illustrates an exemplary blockchain validation system
according to examples of the disclosure. The following discussion
with reference to FIG. 4 outlines a structure to establish a
validation node capable of performing real-time assurance off
third-party blockchains. The validation system consists of
individual microservices performing discrete pieces of
functionality, which, when holistically viewed, can enable
real-time assurance and validation of data activities in data
blocks of blockchains in a blockchain network. The blockchain
network may have a plurality of blockchain nodes having
blockchain-based data storage systems in each blockchain node as
described above with respect to FIG. 1. In some embodiments, the
blockchain network and the blockchain node of FIG. 4 may be
represented by the network and nodes shown in FIG. 1. The
discussion below provides insight into the primary responsibilities
of each service as a new blockchain event or data block is added to
a node in the blockchain network.
[0080] Some assumptions in performing real-time assurance may
include that: (1) off-chain data (i.e., data not stored within the
blockchain) exists and may be required for key assurance reporting;
(2) ordering, integrity, and completeness of data activities in a
blockchain can be critical to assurance; (3) while the integrity of
blockchain data can be validated, third-party "off-chain" data is
not immutable and subject to change; and (4) assurance is being
conducted on the qualitative and quantitative data activities of
the blockchain, rather than the technical blockchain implementation
(consensus protocols, block formation rules, blockchain forks,
etc.).
[0081] The blockchain validation system may include major five
components: (1) customer environment 404, (2) integration unit 406,
(3) data block service unit 408, (4) front-end service or reporting
unit 410, and (5) interfaces 412. In addition, the system 400 may
interface with third-party computing systems (as indicated by block
402) as well as the customer blockchain 404. The following sections
discuss these architectural components of the blockchain validation
system (which may be referred to as the blockchain assurance and
validation solution, blockchain assurance and validating software,
or blockchain assurance solution) with reference to FIG. 4.
[0082] To illustrate the functionality of the components contained
within system 400, a description of the data flow in the
architecture of FIG. 4 can be pertinent. The process of validating
blockchain transaction can begin with the addition of a new data
block from one of the blockchain nodes 418 residing in the
customer's blockchain environment. When a node 418 attempts to
introduce new data into the blockchain, that activity can be sent
to chain listener 422. The chain listener can serve as the initial
integration point between the blockchain assurance and validation
tool, and the customer blockchain. The goals of the chain listener
can be to emit transactional blockchain events occurring within the
blockchain. In most cases, blockchains provide varying levels of
"feed" data in instances where generic events or transactions are
published to subscribers of its services; in these cases, the chain
listener can leverage those existing services to provide events for
downstream service consumers.
[0083] Events trigger the initial action that results in a
transaction or data activity (or the addition of a block) within
the blockchain. Events should trigger one or more transactions
within the blockchain, indicating that some key information should
be delivered across the blockchain network. These transactions will
manifest as a simple key-value pair, as illustrated below:
TABLE-US-00001 { //on the blockchain _id: 3199444, //a unique
identifier dateTime: 2103323223 //unix timestamp, transaction;
2193298439843984381212211 //a transaction, sender: John Doe,
//string receiver: Jane Doe, //string amount: 10 //integer }
[0084] In most industry use-cases, blockchains will not actually
store transactional data. The use of a shared ledger implies the
likely scenario in which sensitive-data transactions occur.
Moreover, storage costs can escalate, and blockchains are not
intended to store items such as images, documents, etc. As such, an
event transaction may have a simple encrypted "hash," which can
contain a secret location that can be unencrypted by the asset
owner. The same object described above can easily be represented as
such:
TABLE-US-00002 { // on the blockchain _id: 3199444, //a unique
identifier dateTime: 2103323223 //unix timestamp, hash;
2193298439843984381212211 //an encrypted value that could represent
anything } { // off the blockchain (such as in a relational
database). _id:2193298439843984381212211, transaction;
2193298439843984381212211 //a transaction, sender: John Doe,
//string receiver: Jane Doe, //string amount: 10 //integer }
[0085] A "push" feed (built within the blockchain protocol) is the
ideal setup, because it properly segregates the responsibilities
across the blockchain network and the assessment and validating
software. As such, it is up to the blockchain to provide guarantees
that ensure transactions are emitted while the chain listener is
responsible for relaying those events into the validation system.
If this service is ever stopped or interrupted, it should possess
enough awareness and understanding to resume starting with its last
acknowledged transaction. This ensures that transactions are not
"duplicated" within the environment and that unnecessary work to
"reprocess" blockchain transactions will not occur.
[0086] Thus, once the chain listener detects that a new transaction
is occurring on the blockchain, it can tag the event and send them
to event listener 442 by placing the events onto a queue 434. The
event listener 442 may then pick up the new data block from queue
434 and perform a series of tasks with the new data block acquired
from queue 434. In one or more examples, the event listener 442 may
store a copy of the new data block by storing in event store 436.
The event store 436 can be the principal "record of truth" that
represents a historical copy of the blockchain from which all
downstream systems derive their system state. Records that live as
unstructured data, and events transacted from the blockchain
listener, will live as JSON objects within this document store
(e.g., MongoDB), and will live in its nearest representation to
data on the blockchain. The primary goals of the event store can be
twofold: (1) separating querying and data, extraction
responsibilities from the validation node (to avoid directly
querying the blockchain for events); and (2) creating a consistent
storage abstraction that can be leveraged regardless of the
blockchain platform.
[0087] The event store can also enable additional capabilities such
as data "snapshots," where events or transactions can be "replayed"
as they occur. The event log provides a strong audit capability
(e.g., accounting transactions are an event source for account
balances) where historic states can be recreated by replaying past
events.
[0088] Simultaneously to storing the event at event store 436, the
event listener 442 can transmit the new data block to data enricher
424 by placing it into a queue 432. The data enricher 424 can take
the data block stored at queue 432 and request information from
external data sources (e.g., from a customer or third party)
through the off-chain API 426 that collects third-party data stored
at 414, and off-chain data stored at 416. External data sources can
be centrally managed through the use of an off-chain API 426 that
can federate requests to one or many external data sources such as
third party data 414 or off-chain data 416. External data sources
are centrally managed through the off-chain API 426, which
federates requests to one or many external data sources. Off-chain
data (sometimes referred to as oracles) provide, contextual
information about blockchain data, including real-time data
elements (e.g., stock prices), personally identifiable or sensitive
information (e.g., names or addresses), or extraneous metadata,
which could bloat the size of the blockchain ledger. Through the
creation of its own independent service, the application reduces
the tight coupling between internal and external application logic,
and limits exposure to third-party systems.
[0089] Customer environment 404 which can store off-chain data 416,
as well as third party data coming from data store 414 can describe
the spectrum of tasks occurring within third-party networks and the
original inception of the transaction, data activities, or data
block onto the blockchain-based data storage system. While upstream
(i.e., actions prior to hitting the blockchain) activities should
be considered "out of scope" of the tool 400--need for assurance
can require that examination occurs as close to the original
"source of truth" as possible--it can therefore be essential for
critical data elements or keys to exist within the blockchain, or
else they will not be captured by the downstream processes. Careful
design of blockchain metadata is needed to enable the ability for
assurance and validation. Thus, customer environment 404 can
collect and store various "off-chain" data at data store 416.
[0090] As an example of off-chain data, if a distributed ledger is
storing emails being sent back and forth from the customer, the
names associated with each email address could be an example of
"off-chain data" that could be used to help validate and audit the
blockchain itself. Thus, the type of data that while not needed for
action block creation itself, may be needed to validate
transactions occurring in real-time can be stored at data store
416. Off-chain storage contains data that is not readily available
for public consumption. Off-chain storage may reference anything
from trade data to vendor/sales information, or anything that
provides context to the transactions inscribed on the block.
[0091] While blockchain data is historic and immutable, off-chain
data is not immutable or immune to tampering. This makes logical
sense: off-chain data will likely be sensitive, business-contextual
data and will often be used by multiple consumers within an
organization. The duplication of data across off-chain and on-chain
data which poses consistency issues and the two are in-sync. It is
possible that records reflected within the blockchain are not
represented off-chain. Downstream processes will need to reflect
this known hazard when they are working with off-chain data by
properly rebuilding or reconstructing records that require updates
to ensure the audit solution accurately reflects the historic
state.
[0092] Once the data enricher 424 adds in the off-chain data, it
can then transmit the augmented even to rules engine 428 via queue
430. Customer-specific business assurance rules can applied to the
data block in the rules engine 424. Rules can be highly specific to
the business and industry concerned and be customized according to
each customer as described above with respect to the risk
framework. Rules can the cornerstone of the validation solution,
providing the basis of when/why transactions violate specified
conditions.
[0093] The rules engine 428 can be implemented as a worker with a
specified set of instructions on how to apply rules against
transactions. Because the user interface also relies on the
awareness and knowledge of rules, the rules engine can retrieve the
latest inventory of rules from a shared database (not pictured).
While this extra network request may seem unnecessary, it also can
enable user-features such as the dynamic toggling of rules, the
addition/subtraction of rules without hard resets, etc.
[0094] Two categories of rules may be applied to transactions or
data activities in the blockchain: streaming rules that assess
against individual transactions, and batch rules that assess
against an aggregate of transactions.
[0095] Streaming Rules: Incoming transactions can be evaluated
against a set of one or many business rules that can assess
validity across a variety of dimensions (e.g., completeness of a
transaction, blacklisting of specific values, application of
transaction logic such as input=output, etc.).
[0096] Batch Rules: Incoming transactions that possess some
relationship to historical or past events can leverage the event
store to identify patterns that may violate assurance rules (e.g.,
aging transactions, number of transactions from an account,
etc.).
[0097] These rules are generators of "observations" within the
solution. Observations indicate the violation of a pre-defined
guideline set by business or assurance rules, which Users of the
system will evaluate within the web interface. As will be described
in detail below, the observations can be collected and presented to
a user, who can then review each observation and determine whether
the observation warrants further scrutiny.
[0098] Once the rules engine 428 applies the one or more rules to
the data block, the results of the tests performed by the rules
engine can be sent to reporting database 444. Reporting database
can store the results of the application of the rules to the data
block.
[0099] The reporting DB is the final staging area where
business-oriented data structures can be queried and analyzed. Any
blockchain transaction saved within the event store will create one
or many transactions within the reporting DB; this will allow a
variety of views to be "staged" and immediately ready for
analytics, assurance reports, etc.
[0100] In order to create this reporting state for user interfaces,
any off-chain data must be already "enriched" and co-located with
other blockchain events. The integration of off-chain and on-chain
data will require a high degree of collaboration and integration
between the third party and the tool.
[0101] Reliability and uptime of external systems can be
unpredictable, and the present invention anticipates "offline"
scenarios where external systems are unavailable. Moreover, the
current state of the reporting DB can be off-sync with its original
source of truth if records have been updated within the host
system.
[0102] To resolve these issues, the architecture should incorporate
several precautionary measures to ensure the reporting DB is in an
accurate representation of its source of truth. In the "offline"
scenario, worker jobs should fail, persist, and retry to ensure
transactions are not lost. Additionally, periodic background
validation jobs should have the ability to check the accuracy and
updates of records. This integration has the potential to be
complex, depending on the auditability and traceability of
third-party systems.
[0103] The results stored in reporting database 444 can be sent to
user interface 412 for further evaluation via reporting API 448.
The reporting platform will be the sole interface through which
users interact and communicate with blockchain data. A separate
"reporting API" provides external users with access into data that
has already been relayed, saved, and transformed into contextual
and relevant pieces of information. This information is ready to be
consumed by the web interface, which enables risk assurance
professionals to make decisions according to real-time events on
the blockchain.
[0104] The user interface presents the results of the test
procedures to the rules engine. The user interface may be a web
page, a web dashboard, a mobile device, or any other device that is
configured to display or output the validation report.
[0105] Referring back to FIG. 3, at step 304 a risk framework can
be used to generate one or more tests. Those tests can then be
transmitted to rules engine 428 in the system described in FIG. 4
to perform real-time and continuous validation of a blockchain
system. The risk framework can allow for a user to specify the
risks they wish to monitor for during their testing and the level
of assurance they are seeking, and those inputs can be converted
into a plurality tests that are run during the operation of the
blockchain. Thus, while all users of the validation tool can be
presented with a common risk framework, the output of the risk
framework can be specific to each individual user/organization to
ultimately generate a unique validation tool that addresses the
specific needs of the organization.
[0106] The discussion below can illustrate how the risk framework
described above can fit in with an overall approach to risk
management for validating a blockchain system.
[0107] In some embodiments, determining the acceptance criteria
(may be referred to as assurance threshold formula) may include the
five steps discussed below.
[0108] 1--Purpose (P1)--Gain an understanding of the blockchain use
case, business purpose, and the resultant effect on the risks and
control objectives.
[0109] 2--Process (P2)--Assess on and off blockchain processes and
technologies to understand continuous assurance methodology
affects, up and downstream, on audit expectations and the entire
process risk profile.
[0110] 3--Risks (Rs)--Assess the blockchain architecture variant
and identify applicable control objectives using the blockchain
risk framework.
[0111] 4--Stakeholder (Sr)--Identify assurance related
stakeholders, determine and inventory their expectations and needs
for reporting purposes.
[0112] 5--Assurance Threshold Formula (ATx)--Total number of test
procedures required to achieve the required level of assurance. The
test procedures can be coded into the rule engine of the audit
software/tool for automated testing and transaction level
assurance.
[0113] Based on the results obtained from these four activities in
combination of the blockchain risk framework, the following
Assurance Threshold Formula (ATx) is determined:
P1+P2+Rs+Sr=ATx
[0114] The solution sum of Y (Continuous Audit) must always be
equal or greater than ATx in order to create the necessary level of
assurance. Therefore Y ATx.
[0115] As shown above, the risk framework (step 3) can work to
provide a required level of assurance to a customer that their
blockchain system is operating with minimal risk.
[0116] In some embodiments, the blockchain risk evaluation system
or risk framework may assess the current state of a blockchain use
case against different risk categories (e.g., six or more different
risk categories) and across sub-categories (e.g., 100 or more
different sub-categories) in order to address assurance and
compliance needs of stakeholders. This assessment may be performed
by a risk evaluation system that is industry, use case and
Blockchain platform agnostic. In some embodiments, the results of
these assessments provide the necessary information to identify
applicable risks, control objectives, testing reporting and
reporting parameters that are used to customize our the continuous
validating software.
[0117] The blockchain risk framework is a component of the
blockchain continuous validating solution. Due to availability and
use of several variants of blockchain technology for use cases and
lack of a standard approach or risk frameworks that can be used to
obtain required level of transparency for a given blockchain use to
meet compliance, assurance, and audit requirements, an approach has
been designed and the supporting framework is developed that is
industry, use case and blockchain technology variant agnostic so
that practitioners across all industries and sectors can use to
address the risk assurance and compliance needs independent of the
blockchain technology variant and use case.
[0118] Practitioners can use blockchain risk evaluation system as a
standard approach and framework to evaluate the current state of a
Blockchain use case which can be inclusive of upstream and
downstream (on-Blockchain and off-Blockchain) processes,
technologies, and underlying data elements (people, processes,
technologies) against 6 different risk categories, applicable
domains, and 100+ sub-risk categories in order to address assurance
and compliance needs (risks, control objectives, controls, testing
objectives and procedures, and reporting parameters) of the
following stakeholders simultaneously or exclusively. The risk
categories, domains and sub-risk categories can be used exclusively
or mutually exclusively to determine targeted and/or upstream and
downstream impacts. These parameters can be used to customize and
personalize an assurance or validating software/tool to achieve
required level of assurance and compliance as by-product of
processed transactions.
[0119] Some examples of stakeholders provided below: [0120] Chief
Executive Officer [0121] Chief Financial Officer [0122] Chief
Technology Officer [0123] Chief Information Security Officer [0124]
Chief Audit Executive (3rd Line of defense) [0125] Head of
Enterprise Risk Management (2nd line of defense) [0126] Head of
Operations (1st line of defense) [0127] Head of Innovation [0128]
Head of Corporate Development [0129] Head of Compliance and legal
[0130] Head of Tax [0131] External Regulators [0132] Head of
Business Segment(s)
[0133] Risk Categories:
[0134] In Some Embodiments, Some Examples of Risk Categories and
their relevant domains are provided in Table 1.
TABLE-US-00003 TABLE 1 Risk Category Domain Governance and Business
Objectives Oversight Program Sponsorship Leadership Commitment MIS
and Metrics Program Management Operational and Capital Expenditure
Oversight Project Management Third-party Risk Cyber Security Cloud
Security Data Security Data Privacy Penetration Testing Programming
Security Network Security Patch and vulnerability Threat detection
Threat response Infrastructure Layer Servers and Databases
Configuration ITGCs Business Continuity and Disaster Recovery IT
Asset Management Architecture Layer Blockchain Platform &
Protocol Configuration Hardware Security Modules Signature
Management Cryptography Scalability Availability Operational Layer
Permissioned network management Participant Onboarding and
Off-boarding Application layer Blockchain consensus program
management Integration with off-Blockchain systems and processes
Transactional Layer Smart Contracts Digital Assets Digital Currency
Clearing and settlement Business Use Case Transactions
[0135] The sub-risk categories, control and testing objectives,
test procedures and request lists for each for the above risk
categories and domains of Table 1 are provided below. When engaging
with the risk framework, a user using a computer/laptop or some
other computing device, can be guided through each risk category
and specify parameters relating to the category. In one or more
examples, the user can specify if a particular risk is to be
classified as low, medium, or high. In one or more examples, the
categories, low, medium, high, can change for one risk, from one
blockchain system to another. As an example, because there may be
other surrounding controls in place or there may be some
compensating controls in place, a particular risk may be
categorized as low. Alternatively another in another blockchain
environment, a user may assess that risk to be high because the
system doesn't have certain compensating controls in place or
certain processes or technology or checks and balances in place. In
such a system the risk maybe categorized as high. Thus classifying
a risk as low, medium, high, can mean that there's a possibility
that this can fall into either of these three categories, depending
on the use case and depending on the environment, that is being
examined.
[0136] In some embodiments, governance and oversight risk category
in the blockchain risk framework covers relevant risks, control
objectives and descriptions, testing objectives and procedures, and
reporting parameters designed to address assurance and compliance
needs for the blockchain portfolio and program management,
governance, and oversight. Focus areas for this category includes
blockchain strategy, research and development, investment,
business, operations, product and use case solution development
activities.
[0137] The sub-risk categories, control and testing objectives,
test procedures and request lists for Governance and Oversight risk
category are provided below in Tables 2-4. Table 2, is an exemplary
sub-risk category table for the governance and oversight risk
category. The table below can be presented to a user accessing the
risk framework from a computing device configured to receive inputs
from a user. The table below can include a risk category indicator
that specifies the category of risk as defined above. Each of the
Risk Categories cover Blockchain including upstream and downstream
processes, technologies stacks, and people and associated risk
profiles.
[0138] The table below can include a domain column can identify the
areas relevant to the blockchain that is covered by each risk
category. In one or more examples, the table below can include a
risk classification column that identifies the applicable processes
and technologies within each domain, where the risk is present. In
one or more examples, the table below can also include a risk
number that simply provides a method for identifying the risk in
numerical form. In one or more examples, the table below can also
include a risk description that describes the risk applicable
to/associated with the processes and technologies within each
domain. In one or more examples, and as described above, the table
can also include a risk level rating (low, medium, high) as
described above.
[0139] When the user is presented with the framework, they can
initially review each risk category, and specify whether such a
risk is a low, medium, or high concern. Presented below is an
example risk table for the government and oversight risk
category.
TABLE-US-00004 TABLE 2 Risk Level (L, M, H) Risk Risk (As Risk
Category Domain Classification Number Risk Description applicable)
Governance Business Strategic, GO-BO1 At the senior management
level, L, M, H and Oversight Objectives Operational, business
objectives and justification is Financial, not clearly defined
leading to failure Compliance, of program and misalignment with
Legal, or strategy and overarching governance Reputational
framework. Governance Business Strategic, GO-BO2 The Blockchain
Program is L, M, H and Oversight Objectives Operational,
implemented in silos without a formal Financial, oversight
committee resulting in Compliance, inefficient utilization and
duplication Legal, or of efforts. Reputational Governance Business
Strategic, GO-BO3 Unapproved or miscommunicated L, M, H and
Oversight Objectives Operational, scope can lead to failure of
program or Financial, poor utilization of program resources.
Compliance, Legal, or Reputational Governance Program Strategic,
GO-PS1 Lack of involvement from Senior L, M, H and Oversight
Sponsorship Operational, Management can lead to low Financial,
organizational awareness and failure Compliance, of the Blockchain
program. Legal, or Reputational Governance Program Strategic,
GO-PM1 Failure to define and monitor Key L, M, H and Oversight
Management Operational, Performance Indicators (KPIs) may
Financial, lead to failure of the program. Compliance, Legal, or
Reputational Governance Program Strategic, GO-PM2 Failure to
formalize methodology for L, M, H and Oversight Management
Operational, inventorying, analyzing, prioritizing Financial, and
selecting eligible the Blockchain Compliance, use cases may lead to
failure of the Legal, or program. Reputational Governance Program
Strategic, GO-PM3 Failure to define and effectively L, M, H and
Oversight Management Operational, monitor project progress may lead
to Financial, failure of the program. Compliance, Legal, or
Reputational Governance Program Strategic, GO-PM4 Failure to assess
the level of change L, M, H and Oversight Management Operational,
readiness for the organization when Financial, implementing
Blockchain may lead to Compliance, failure of program. Legal, or
Reputational Governance Program Strategic, GO-PM5 Failure to define
the go-live criteria L, M, H and Oversight Management Operational,
within the program objectives may Financial, lead to failure of the
program. Compliance, Legal, or Reputational Governance Program
Strategic, GO-PM6 Failure to identify proper resources to L, M, H
and Oversight Management Operational, fulfill roles with the
Blockchain Financial, program and lack of learning and Compliance,
development to ensure that employees Legal, or skills are in line
with the needs of the Reputational Blockchain program leads to
excessive turnover and inadequate resources. Governance Program
Strategic, GO-PM7 Failure to consider changes in the L, M, H and
Oversight Management Operational, business process due to
Blockchain Financial, technology could lead to loss of Compliance,
institutional knowledge. Legal, or Reputational Governance Program
Strategic, GO-PM8 Lack of acceptance from users and L, M, H and
Oversight Management Operational, employees of the Blockchain
program Financial, could lead to failure of the program.
Compliance, Legal, or Reputational Governance Program Strategic,
GO-PM9 Lack of acceptance from users and L, M, H and Oversight
Management Operational, employees of the Blockchain program
Financial, could lead to failure of the program. Compliance, Legal,
or Reputational Governance Program Strategic, GO-PM10 Inadequate
processes to setup L, M, H and Oversight Management Operational,
Blockchain vendor software could Financial, lead to increased risks
to security Compliance, requirements. Legal, or Reputational
Governance Program Strategic, GO-PM11 Inadequate assessment of
hardware, L, M, H and Oversight Management Operational,
applications, software and software Financial, components may leave
information Compliance, systems vulnerable and unable to Legal, or
fulfill business objectives. Reputational Governance Program
Strategic, GO-PM12 Lack of a standard process to L, M, H and
Oversight Management Operational, document functional
specifications for Financial, each business process can lead to
Compliance, incomplete or inaccurate Legal, or documentation.
Reputational Governance Program Strategic, GO-PM13 Failure to
define and develop a clear L, M, H and Oversight Management
Operational, benefits strategy could lead to failure Financial, of
the Blockchain program. Compliance, Legal, or Reputational
Governance Project Strategic, GO-PM14 Failure to assign appropriate
resources L, M, H and Oversight Management Operational, to aid in
the design of application Financial, security and controls may
result in Compliance, increased risks to the business and Legal, or
insufficient controls around the Reputational business processes.
Governance Project Strategic, GO-PM15 Employees who are not
appropriately L, M, H and Oversight Management Operational, trained
may result in an increased risk Financial, of bypassed or forgotten
Compliance, considerations essential to the Legal, or Blockchain
Program. Reputational Governance Project Strategic, GO-PM16 Failure
to allocate appropriate L, M, H and Oversight Management
Operational, representation and resources for the Financial,
duration of the program, may lead to Compliance, the misuse of
organizational funds and Legal, or unintended risks to business
Reputational objectives. Governance Project Strategic, GO-PM17 Lack
of monitoring activities in place L, M, H and Oversight Management
Operational, could lead to inaccurate and Financial, incomplete
transactions processed Compliance, within the Blockchain
application. Legal, or Reputational Governance Leadership
Strategic, GO-LC1 Poor stakeholders and leadership L, M, H and
Oversight Commitment Operational, commitment can lead to a lack of
Financial, unity on program goals, objectives Compliance, and
performance. Legal, or Reputational Governance MIS and Metrics
Strategic, GO-MM1 Failure to allocate appropriate L, M, H and
Oversight Operational, resources, while considering business
Financial, requirements, may lead to the misuse Compliance, of
organizational funds and Legal, or unintended risks to business
Reputational objectives. Governance MIS and Metrics Strategic,
GO-MM2 Inadequate controls to monitor the L, M, H and Oversight
Operational, capacity, availability, and Financial, functionality
of the application may Compliance, lead to interruption and/or
failure to Legal, or key applications. Reputational Governance
Operational and Strategic, GO-OC1 Failure to allocate appropriate
L, M, H and Oversight Capital Operational, resources, while
considering business Expenditure Financial, requirements, may lead
to the misuse Oversight Compliance, of organizational funds and
Legal, or unintended risks to business Reputational objectives.
Governance Operational and Strategic, GO-OC2 Failure to allocate
appropriate L, M, H and Oversight Capital Operational, resources,
while considering business Expenditure Financial, requirements, may
lead to the misuse Oversight Compliance, of organizational funds
and Legal, or unintended risks to business Reputational objectives.
Governance Operational and Strategic, GO-OC3 Failure to allocate
appropriate L, M, H and Oversight Capital Operational, resources,
while considering business Expenditure Financial, requirements, may
lead to the misuse Oversight Compliance, of organizational funds
and Legal, or unintended risks to business Reputational objectives.
Governance Operational and Strategic, GO-OC4 Inadequate controls to
govern and L, M, H and Oversight Capital Operational, address
security risks in a project may Expenditure Financial, lead to loss
of sensitive data. Oversight Compliance, Legal, or Reputational
Governance Smart Contracts Strategic, GO-SC1 Blockchain software
use cases are not L, M, H and Oversight Operational, consistent
with participants' business Financial, or industry-specific
requirements; Compliance, smart contracts cannot be effectively
Legal, or leveraged for normal operations Reputational Governance
Smart Contracts Strategic, GO-SC2 Blockchain implementation lacks a
L, M, H and Oversight Operational, coherent governance model for
Financial, development, execution, and oversight Compliance, Legal,
or Reputational Governance Smart Contracts Strategic, GO-SC3 Lack
of IP safeguards compromise the L, M, H and Oversight Operational,
organization's DLT innovations Financial, Compliance, Legal, or
Reputational
[0140] After categorizing the risks as described above, the
framework can then present the user with series of control/test
objectives (with corresponding descriptions) which the user can
review and determine whether such controls/test objectives should
be considered in-scope to the audit or out of scope to the audit.
An exemplary control/test objective table is provided below for the
governance and oversight risk category.
TABLE-US-00005 TABLE 3 In-scope/Out- of-Scope Risk (TBD - As per
Category Domain Control/Test Objective Control Description
engagement) Governance Business At the senior management level, The
Blockchain Program Charter is In-scope and Oversight Objectives
business justification and created and includes specific details of
objectives for the Blockchain goals and business objectives of the
Program is documented and overall Blockchain Program. The aligns
with business strategy. Blockchain steering committee reviews The
Blockchain Program is and approves The Blockchain Program
considered in the overarching Charter to ensure it is in alignment
with governance framework with the firm's organizational and
alignment to risk, compliance governance strategies. and IT/data
frameworks. Governance Business The Blockchain Program is A
Blockchain steering committee, In-scope and Oversight Objectives
appropriately prioritized against which includes executive
leadership other initiatives within the and senior members of the
business, organization. risk, compliance and the Blockchain program
management, meets on a quarterly basis to conduct business
performance reviews of how the Blockchain Program aligns with
business strategy. Governance Business The Blockchain program
project The scope of the Blockchain program is In-scope and
Oversight Objectives plan has been defined outlined in the
Blockchain project addressing each phase of the plan/roadmap. The
project plan is Blockchain program project and reviewed and
approved by the steering is consistent with the scope and committee
to ensure the plan is in objectives defined within the alignment
with the Blockchain Program program charter. The scope of Charter.
the Blockchain Program has been approved and communicated by all
participants. Governance Program Senior Management is actively The
Blockchain Program Charter is In-scope and Oversight Sponsorship
involved in creating created and includes specific details of
organizational awareness, the communication strategy to the
championing the Blockchain broader organization. The Blockchain
program. steering committee reviewed and approved The Blockchain
Program Charter. Governance Program Key Performance Indicators Key
Performance Indicators (KPIs) are In-scope and Oversight Management
(KPIs), specific to the established to monitor the Blockchain
Blockchain use case, to monitor program performance. program
performance have been developed. Governance Program Formalized
methodology for The Blockchain program policies and In-scope and
Oversight Management inventorying, analyzing, procedures, which
includes prioritizing and selecting methodology for inventorying,
eligible the Blockchain use analyzing, prioritizing and selecting
cases exists. This method is eligible the Blockchain use cases, are
formally documented to ensure reviewed and approved on a periodic
consistently across business basis. units that may potentially
utilize the technology. Governance Program The Blockchain program
project The Blockchain Program steering In-scope and Oversight
Management plan has been defined committee reviewed and approved
The addressing every phase of the Blockchain program project plan.
The Blockchain program project and Blockchain program management is
consistent with the scope and monitors individual project work
plans objectives defined within the to measure progress against The
program charter. Individual Blockchain project plan. project work
plans are well defined and effectively monitored for project
progress; an integrated master plan that provides a comprehensive
view of work effort and dependencies across all project teams has
been defined. Governance Program Affected stakeholders are The
processes selected for Blockchain In-scope and Oversight Management
actively involved in the implementation are evaluated on a planning
process and the quarterly basis by the Blockchain Blockchain
Program team has program management team to ensure formally
assessed the level of the Blockchain technology is being change
readiness for the optimized and decisions adhere to the
organization and its business Blockchain selection criteria
outlined in units, stakeholders, and the Blockchain program
policies and customers. procedures. The results of this evaluation
are reported to the Blockchain steering committee. Governance
Program Formal go-live criteria for each Formal policies and
procedures have In-scope and Oversight Management application/use
case is been established and documented to adequately linked back
to the outline the methodology for the program scope and
objectives. Blockchain configuration and maintenance, including
decision making criteria to go live being formally documented.
Policies and procedures are reviewed and approved on a periodic
basis. Governance Program Management has updated The Blockchain
program policies and In-scope and Oversight Management staffing and
hiring practices to procedures, which includes details of ensure
the right people within the formal the Blockchain organization the
organization are identified structure, staffing and training and
assigned as the Blockchain requirements are reviewed and program
resources. Learning approved on a periodic basis. and development
personnel have been engagement to ensure training program has been
instituted to train the Blockchain Program staff. Governance
Program There has been adequate Periodically, management performs a
In-scope and Oversight Management considerations for loss of risk
assessment of the Blockchain institutional knowledge as the
technology and evaluates the risk Blockchain technology alters/
associated with loss of institutional eliminates steps in business
knowledge. processes. Governance Program There is adequate
Management has considered the impact In-scope and Oversight
Management considerations for the that the Blockchain program will
have organizations resistance to on resources and has designed a
formal change and appropriate people people and change process to
mitigate and change management possible disruptions and resistance
processes are put into place to across the organization. clearly
articulate the future state and address possible disruption
discomfort with a new technologically sophisticated process that
will result in large decreases in manpower requirements. Governance
Program A formal process to address The Blockchain Program Charter
In-scope and Oversight Management organizational changes, outlines
a formal process to address including the ability to perform
organizational changes. The tasks in case of the Blockchain
organizational change process is failure. analyzed and evaluated on
a monthly basis by the Blockchain program management team. The
results of this evaluation are reported to The Blockchain steering
committee. Governance Program The setup of the Blockchain The
Blockchain vendor software for In-scope and Oversight Management
vendor software includes initial integration into the firm's
consideration of new security environment follows a well-defined
requirements to maintain integration plan and is monitored by the
confidentiality, integrity, and Blockchain program management.
availability have been considered. Governance Program Hardware
(including Impact of software integration on the In-scope and
Oversight Management configurations, locations, firm's existing
hardware configurations, capacity/capacity utilization, software
and applications is and age and data requirements), documented and
evaluated. The results applications, software and of this
evaluation are reported to the software components impacted
Blockchain Program steering by the Blockchain integration
committee. have been identified, evaluated and reported on.
Governance Program The process to create functional The Blockchain
program policies and In-scope and Oversight Management
specifications for each new procedures, which includes the process
Blockchain business process to create functional specifications for
follows a standard process each new the Blockchain business
documented in the Blockchain process, are reviewed and approved on
Program policies and a periodic or as needed basis. procedures.
Governance Program A benefits realization strategy The Blockchain
Program Charter is In-scope and Oversight Management has been
developed and created and includes the Blockchain approved.
Benefits Management process. The Blockchain Program steering
committee reviews and approves the Blockchain Program Charter to
ensure it is in alignment with the firm's organizational and
governance strategies. Governance Project Appropriate members of
the The Blockchain program management In-scope and Oversight
Management business, the Blockchain team includes members from risk
and program team, risk, and compliance responsible for designing
compliance are actively and implementing key controls being
involved in design of executed by the Blockchain application
security and technology. The functional controls. specifications
for each new the Blockchain business process are reviewed by the
Blockchain Program risk & compliance team member to assure the
appropriateness of the design and operating effectiveness of
controls the Blockchain is executing. Governance Project
Individuals are properly trained The Blockchain Program
configuration In-scope and Oversight Management to configure the
Blockchain analysts are required to complete technology. training
prior to being involved with functional or technical Blockchain
design. On an ongoing basis, individuals involved in the Blockchain
program receive updated education to keep current with emerging
technology issues. Governance Project There is adequate commitment
The Blockchain policies and In-scope and Oversight Management to
provide appropriate procedures are defined and include a
representation and resources for description of key Blockchain
program the duration of the Blockchain management positions,
responsibilities program. and overall organization structure for
governance. Governance Project Post implementation, there are Post
implementation reviews are In-scope and Oversight Management
monitoring activities in place to performed by the required
business monitor the completeness and and/or technology management
or accuracy of processing for the designee to test the completeness
and Blockchain transactions. accuracy of processing for the
Blockchain transactions. Governance Leadership The Blockchain
program Leadership discusses and engages with In-scope and
Oversight Commitment stakeholders have been the business to
determine Blockchain adequately engaged and goals and objectives.
The Blockchain understand the Blockchain Program Charter is created
and program goals and objectives. includes specific details of
goals and business objectives of the overall the Blockchain
Program. The Blockchain steering committee reviews and
approves The Blockchain Program Charter to ensure it is in
alignment with the firm's organizational and governance strategies.
Governance MIS and There is a formal process for The Blockchain
project plan/roadmap In-scope and Oversight Metrics monitoring the
Blockchain details the financial needs of each program project
performance individual project work stream. The and details of
performance is Blockchain program management has a communicated to
appropriate formal process to monitor project costs stakeholders.
as it relates to project progress, milestones, and deliverables, as
well as specifics to measure KPI, ROI per process and overall ROI.
Monthly, the project costs are reported back to the Blockchain
steering committee. Governance MIS and There is sufficient
oversight Daily, the Blockchain Operational In-scope and Oversight
Metrics over the application by to management reviews capacity,
ensure the Blockchain is logged, availability and performance
metrics of functioning, and workloads, the Blockchain in
production. availability and capacity are Deviations from standard
metrics are being efficiently and effectively noted, researched and
resolved. balanced. Monthly these metrics are report to the
Blockchain Program steering committee. Governance Operational and
Financial needs of the program The Blockchain Program Charter is
In-scope and Oversight Capital have been reviewed and created and
includes the financial needs Expenditure approved by senior
management of the Blockchain program. The Oversight and assessment
of those needs Blockchain steering committee reviews are reassessed
on an ongoing and approves the Blockchain Program basis. Charter.
Additionally, the Blockchain project plan/roadmap details the
financial needs of each individual project work stream. Governance
Operational and The organization allocates The organization
establishes a plan for In-scope and Oversight Capital appropriate
resources to the allocation of appropriate resources Expenditure
information security and risk to projects and programs based on
Oversight management. assessing organizational, operational, and
strategic considerations. Governance Operational and The
organization allocates Resources (human, technology, In-scope and
Oversight Capital appropriate resources to finance) required to
achieve security Expenditure information security and risk
objectives are allocated for the Oversight management.
establishment, implementation, maintenance and continual
improvement of the information security management system.
Governance Operational and Implement security controls in
Information security is addressed in In-scope and Oversight Capital
projects. project management, regardless of the Expenditure type of
the project. Oversight
[0141] Finally once the user has identified the risks (including
their particular levels), and has determine which test objectives
are in-scope and out-of-scope to the validation, the risk framework
can then provide the user with the applicable tests that will be
applied to the user's blockchain validation system. The table below
can be created based on the user's inputs to the reference
framework described above. The table below can indicate the test
procedures to be performed that determine the design or operating
effectiveness of a control specified in table 3. The table below
can also specify the test type which can be inquiry, inspection and
observation, as well as attribute or substantive type of testing
using a manual or automated approach. Finally, the table below can
also present the user with a request list that can show the user
requested items to be gathered to provide supporting information
such as documentation or evidence including data parameters to
execute test procedures in order to obtain the specified level of
assurance and confidence surrounding the process and
technology.
TABLE-US-00006 TABLE 4 Test Type (TBD - As Risk per Category Domain
Test Procedure (#) engagement) Request List (#) Governance Business
1. Verify the Blockchain Program Inquiry, 1. Blockchain Program
Charter and Objectives Charter has been created and review
Inspection, 2. Meeting minutes from the Steering Oversight the
overall goals and business and/or committee meeting where the
Blockchain objectives. observation Program charter was reviewed. 2.
Inspect the Blockchain Program Charter to ensure the Steering
committee has reviewed and approved it. Governance Business 1.
Inquire with Blockchain steering Inquiry, 1. Meeting minutes from
the Steering and Objectives committee members to determine
Inspection, committee where business performance Oversight criteria
for business reviews to and/or reviews of how the Blockchain
Program assess the Blockchain program's observation aligns with
business strategy are discussed alignment with business strategy
and reviewed. 2. Inspect Quarterly meeting minutes to confirm that
business performance reviews were conducted by the established
criteria. Governance Business 1. Inspect the Blockchain project
Inquiry, 1. Blockchain project plan/roadmap and Objectives
plan/roadmap to confirm that scope Inspection, 2. Blockchain
Program Charter Oversight of program is outlined. and/or 3. Meeting
minutes from the Steering 2. Inquire with Steering committee
observation committee where project plan/roadmap was to ensure that
plan was reviewed reviewed and approved. and approved, as evidence
that plan is in line with Blockchain Program Charter. Governance
Program 1. Inquire and inspect the Inquiry, 1. Blockchain Program
Charter and Sponsorship Blockchain Program Charter to Inspection,
2. Evidence that the Blockchain Program Oversight confirm details
regarding the and/or Charter was reviewed and approved.
communication strategy to the observation broader organization. 2.
Inspect that the Blockchain Program Charter has been reviewed and
approved. Governance Program 1. Inquire with Blockchain Inquiry, 1.
Blockchain Program KPIs and Management Operational Management to
ensure Inspection, Oversight Key Performance Indicators (KPIs)
and/or have been established and observation monitored. 2. Inspect
evidence to determine KPIs are monitored periodically. Governance
Program 1. Inquire with management on Inquiry, 1. Blockchain
program policies and and Management methodology for inventorying,
Inspection, procedures. Oversight analyzing, prioritizing and
selecting and/or 2. Evidence of review and approval on a eligible
the Blockchain use cases. observation periodic basis of the
Blockchain program 2. Obtain and inspect Blockchain policies and
procedures. program policies and procedures and confirm that
methodology for inventorying, analyzing, prioritizing and selecting
eligible the Blockchain use cases is included. 3. Inquire with
management and inspect that program policies and procedures are
reviewed and approved on a periodic basis. Governance Program 1.
Inquire with Steering committee Inquiry, 1. Blockchain Program
Charter and Management to ensure that plan was reviewed Inspection,
2. Meeting minutes from the Steering Oversight and approved, as
evidence that plan and/or committee meeting where the Blockchain is
in line with Blockchain Program observation Program charter was
reviewed. Charter. 3. Blockchain Project Plan 2. Inquire with the
Blockchain program management to determine the criteria of
monitoring the individual project work plans to ensure the progress
is measured against the Blockchain project plan. Governance Program
1. Inquire with the Blockchain Inquiry, 1. Blockchain Program
Charter (policies and Management program management team to
Inspection, and procedures) Oversight determine that the Blockchain
and/or 2. Evidence of Blockchain selection criteria implementation
processes are observation within the Blockchain Program Charter
evaluated on a quarterly basis and 3. Blockchain implementation
processes to ensure they adhere to the 4. Blockchain implementation
evaluation Blockchain selection criteria report outlined in the
Blockchain Program Charter. 2. Inquire with Steering Committee to
ensure they receive the evaluation of the Blockchain implementation
processes. Governance Program 1. Inspect the Blockchain Inquiry, 1.
Blockchain Configuration and and Management Configuration and
Maintenance Inspection, Maintenance Methodology Oversight
methodology to ensure formal and/or 2. Evidence of decision making
criteria to policies and procedures have been observation go live
documented and include decision 3. Evidence of review and approval
of the making criteria to go live. Blockchain Configuration and
Maintenance 2. Inspect the Blockchain Methodology on a periodic
basis Configuration and Maintenance methodology to ensure the
policies and procedures have been reviewed and approved on a
periodic basis. Governance Program 1. Obtain and inspect the
Inquiry, 1. Blockchain program policies and and Management
Blockchain program policies and Inspection, procedures Oversight
procedures, and review for details and/or 2. Evidence of review and
approval on a of the formal the Blockchain observation periodic
basis of the Blockchain program organization structure, staffing
and policies and procedures. training requirements. 2. Inquire with
management and inspect the policies and procedures to confirm that
they have been reviewed and approved on a periodic basis.
Governance Program 1. Inquire with management about Inquiry, 1.
Risk assessment performed by and Management the process to evaluate
the risks Inspection, management Oversight regarding loss of
institutional and/or knowledge. observation 2. Obtain and inspect
the risk assessment performed by management, review that the risk
has been evaluated. Governance Program 1. Inquire with management
about Inquiry, 1. Formal people and change process and Management
the people and change process. Inspection, document Oversight 2.
Obtain and inspect the formal and/or people and change process.
observation Governance Program 1. Inquire with management Inquiry,
1. Blockchain Program Charter and Management regarding the formal
process to Inspection, 2. Evidence that evaluation of the change
Oversight address organizational changes. and/or process is
evaluated and presented to the 2. Obtain and inspect the
observation Blockchain steering committee. Blockchain Program
Charter to confirm that is outlines a formal process to address
organizational changes. 3. Inquire with the Blockchain program
management team to confirm that the change process is analyzed and
evaluated on a monthly basis. 4. Inquire with Blockchain steering
committee to confirm that results of the evaluation are reported.
Governance Program 1. Inquire with management on the Inquiry, 1.
Integration procedures for vendors and Management integration
procedure in place for Inspection, Oversight new vendor software.
and/or 2. Obtain and inspect the integration observation plan and
review to confirm that the Blockchain program management team
Governance Program 1. Inquire with management on the Inquiry, 1.
Documentation and evaluation of and Management documentation and
evaluation of Inspection, hardware, applications, software and
Oversight hardware, applications, software and/or software
components related to the and software components related to
observation Blockchain the Blockchain. 2. Evidence of evaluation
reported to the 2. Obtain and inspect the formal Blockchain Program
steering committee. documentation and evaluation of hardware,
applications, software and software components related to the
Blockchain. 3. Inspect evidence that the results of the evaluation
are presented and reported to the Blockchain Program steering
committee. Governance Program 1. Inquire with management on
Inquiry, 1. Policies and procedures to create the and Management
policies and procedures to create the Inspection, functional
specifications. Oversight functional specifications. and/or 2.
Evidence that the process was reviewed 2. Obtain and inspect the
policies observation and approved. and procedures to create the
functional specifications. 3. Inspect evidence that the process is
reviewed and approved on a periodic or as needed basis. Governance
Program 1. Inquire and inspect the Inquiry, 1. Blockchain Program
Charter and Management Blockchain Program Charter to Inspection, 2.
Evidence that the Blockchain Program Oversight confirm details
regarding the and/or Charter was reviewed and approved. Benefits
Management process. observation 2. Inspect that the Blockchain
Program Charter has been reviewed and approved by the Blockchain
program steering committee. Governance Project 1. Inquire with
management on the Inquiry, 1. Functional specifications and
Management process and appropriateness of Inspection, 2. Evidence
that employees involved in the Oversight resources used to design
functional and/or design are appropriate and possess the
specifications and confirm that they observation proper
qualifications are reviewed by the Blockchain program risk and
compliance team. 2. Inspect functional specifications to assure
appropriateness of the design and operating effectiveness of
controls. Governance Project 1. Inquire with management about
Inquiry, 1. Training plan and Management the training requirements
for Inspection, 2. Training materials Oversight analysts involved
with the and/or functional and/or technical design. observation 2.
Inspect training plan or training materials provided to analysts,
including any on-going training. Governance Project 1. Inquire with
management on Inquiry, 1. Policies and procedures that provide a
and Management policies and procedures that provide Inspection,
description of key Blockchain program Oversight a description of
key Blockchain and/or management positions,
responsibilities and program management positions, observation
overall organization structure for responsibilities and overall
governance. organization structure for governance. 2. Obtain and
inspect the policies and procedures that provide a description of
key Blockchain program management positions, responsibilities and
overall organization structure for governance. Governance Project
1. Inquire with management on the Inquiry, 1. Reviews performed to
test completeness and Management reviews performed to test
Inspection, and accuracy of processing for the Oversight
completeness and accuracy of and/or Blockchain transactions.
processing for the Blockchain observation transactions. 2. Obtain
and inspect the reviewed performed to test completeness and
accuracy of processing for the Blockchain transactions. Governance
Leadership 1. Verify the Blockchain Program Inquiry, 1. Blockchain
Program Charter and Commitment Charter has been created and review
Inspection, 2. Meeting minutes from the Steering Oversight the
overall goals and business and/or committee meeting where the
Blockchain objectives. Review the members of observation Program
charter was reviewed. the organization who have contributed to the
Blockchain Program Charter to confirm appropriate leadership
engagement. 2. Inspect the Blockchain Program Charter to ensure the
Steering committee has reviewed and approved it. Governance MIS and
1. Inspect the Blockchain project Inquiry, 1. Blockchain Project
Plan/roadmap and Metrics plan/roadmap to confirm the Inspection, 2.
Evidence of formal process to monitor Oversight financial needs are
outlined. and/or and report project costs 2. Inquire with the
Blockchain observation 3. Evidence of performance metrics program
management to determine there is a formal process to monitor
project costs and measure performance in place. 3. Inquire with the
Blockchain steering committee to ensure the project costs are
reported to them on a monthly basis. Governance MIS and 1. Obtain
daily Blockchain Inquiry, 1. Daily Blockchain Capacity,
Availability, and Metrics capacity, availability, and Inspection,
and Performance Metrics Oversight performance metrics. and/or 2.
Evidence of daily review of the metrics 2. Inquire with Blockchain
observation by the Blockchain Operational Operational Management to
Management determine the criteria for reviewing 3. Evidence of
reporting the metrics to the the metrics daily and inspect the
Blockchain Program Steering Committee evidence to ensure the
metrics are reviewed daily and if there are deviations they are
noted, researched and resolved. 3. Inspect the evidence of the
metrics to ensure they are reported monthly to the Blockchain
Program Steering Committee. Governance Operational 1. Inquire with
the Blockchain Inquiry, 1. Blockchain Program Charter and and
Capital steering committee members to Inspection, 2. Meeting
minutes from the Steering Oversight Expenditure determine criteria
for financial and/or committee meeting where the Blockchain
Oversight needs are included in the observation Program charter was
reviewed. Blockchain Program Charter. 3. Blockchain Project
Plan/Roadmap 2. Inspect the Blockchain Program 4. Evidence of each
individual Blockchain Charter to ensure the Steering project work
stream's financial needs committee has reviewed and approved it. 3.
Inspect the Blockchain Project Plan/Roadmap to ensure the financial
needs of each individual project work stream is included and
outlined. Governance Operational 1. Obtain a copy of the Inquiry,
1. Organizations plans and/or documents and and Capital
organizations process and/or plans Inspection, for allocation of
funds Oversight Expenditure for allocating resources and verify it
and/or Oversight takes the following factors into observation
consideration: people, skills, experience and competence; resources
needed for each step of the risk management process; the
organization's risk processes, methods and tools to be used for
managing risk; documented processes and procedures; information and
knowledge management systems; training programs. Governance
Operational 1. Inquire with the control owner Inquiry, 1.
Documentation for the most recent and and Capital and confirm if
the organization has Inspection, annual budget planning exercise.
Oversight Expenditure processes in place to identify and/or 2.
Evidence that the organization has Oversight additional expertise
needed to observation processes in place to identify additional
improve information security expertise needed to improve
information defenses. security defenses. 2. Determine if the size
and quality 3. Provide a list the organization's security of the
organization's security staff staff, including their positions and
is adequately staffed and structured expertise. handle the impact
of staff turnover. Governance Operational 1. Inquire with
management how Inquiry, 1. Project management methodology or and
and Capital security is embedded in the project Inspection, process
documentation. Oversight Expenditure management process/lifecycle.
and/or 2. Population: System extract or register of Oversight 2.
Obtain project methodology or observation projects process
documentation and validate 3. For a sample of projects selected,
that it considers security risks as evidence of risk assessment
activities being part of the process. performed as part of the
project management lifecycle. 4. ISMS manual - Description of the
security requirements department managers are to include in
projects.
[0142] In some embodiments, cybersecurity risk category in the
blockchain risk framework covers relevant risks, control objectives
and descriptions, testing objectives and procedures, and reporting
parameters designed to address assurance and compliance surrounding
the cybersecurity and privacy management activities.
[0143] The sub-risk categories, control and testing objectives,
test procedures and request lists for Cyber Security risk category
are provided below in Tables 5-7. The tables below are formatted in
the same manner as tables 2-4 described above, and thus for an
explanation of each column below, the corresponding discussion
above can be referenced.
TABLE-US-00007 TABLE 5 Risk Level (L, Risk Risk M, H) Risk Category
Domain Classification Number Risk Description (As applicable) Cyber
Security Cloud Security Strategic, CS-CS1 Without clearly defined
roles L, M, H Operational, and responsibilities with cloud
Financial, service providers and SLA in Compliance, place,
accountability is lost Legal, or when issues in the relationship
Reputational arise. Cyber Security Cloud Security Strategic, CS-CS2
Without clearly defined roles L, M, H Operational, and
responsibilities with cloud Financial, service providers and SLA in
Compliance, place, accountability is lost Legal, or when issues in
the relationship Reputational arise. Cyber Security Cloud Security
Strategic, CS-CS3 Lack of established and L, M, H Operational,
implemented safeguards may Financial, lead to supply chain
Compliance, information, system component, Legal, or and
information system Reputational vulnerabilities Cyber Security
Cloud Security Strategic, CS-CS4 Lack of adherence to the L, M, H
Operational, documented production Financial, network standards may
lead to Compliance, increased security risk. Legal, or Reputational
Cyber Security Cloud Security Strategic, CS-CS5 Unauthorized access
of L, M, H Operational, information stored in shared Financial,
resources can result in Compliance, inappropriate access, changes
or Legal, or loss. Reputational Cyber Security Data Security
Strategic, CS-DS1 Data exchanged through L, M, H Operational,
communication facilities may Financial, be intercepted and accessed
by Compliance, unauthorized agents within or Legal, or outside the
organizations Reputational network. Cyber Security Data Security
Strategic, CS-DS2 Procedures which do not L, M, H Operational,
facilitate appropriately Financial, classifying, labeling and
Compliance, handling information based on Legal, or its value,
business and legal Reputational requirements may expose information
to deliberate or accidental misuse. Cyber Security Data Security
Strategic, CS-DS3 Lack of controls to protect L, M, H Operational,
information can lead to data Financial, leaks or exposures that
threaten Compliance, the organization's reputation Legal, or and
could lead to litigation. Reputational Cyber Security Data Security
Strategic, CS-DS4 Lack of alignment with the L, M, H Operational,
organization's risk strategy and Financial, risk appetite in the
protection of Compliance, data may compromise the Legal, or
confidentiality, integrity and Reputational availability of
information in Blockchain systems. Cyber Security Data Security
Strategic, CS-DS5 Failure to establish and L, M, H Operational,
communicate policies and Financial, procedures for information
Compliance, security relevant to Blockchain Legal, or use case may
result in gaps in Reputational security capabilities needed to
reduce the organization's cyber risk exposure in accordance with
its risk appetite. Cyber Security Data Privacy Strategic, CS-DP1
Lack of controls to protect L, M, H Operational, information can
lead to data Financial, privacy or exposures that Compliance,
threaten the organization's Legal, or reputation and could lead to
Reputational litigation. Cyber Security Data Privacy Strategic,
CS-DP2 Failure to establish and L, M, H Operational, communicate
policies and Financial, procedures for privacy may Compliance,
result in gaps in privacy Legal, or capabilities needed to reduce
Reputational the organization's privacy risk exposure in accordance
with its risk appetite. Cyber Security Data Privacy Strategic,
CS-DP3 Lack of a privacy policy may L, M, H Operational, increase
the risk that Financial, information is disclosed or used
Compliance, without the owner's consent, Legal, or resulting in
litigation and Reputational reputational damage. Cyber Security
Penetration Strategic, CS-PT1 Inadequately defined processes L, M,
H Testing Operational, for technical vulnerability Financial,
management and ineffective Compliance, testing or detection of
Legal, or vulnerabilities may result in Reputational inappropriate
or unauthorized access to information. Cyber Security Network
Strategic, CS-NS1 Failure to protect network L, M, H Security
Operational, perimeter may result in Financial, unauthorized
access. Compliance, Legal, or Reputational Cyber Security Patch and
Strategic, CS-PVM1 Lack of proper information L, M, H Vulnerability
Operational, system management flaw Management Financial,
management may result in Compliance, security vulnerabilities
Legal, or Reputational Cyber Security Patch and Strategic, CS-PVM2
Inadequately defined processes L, M, H Vulnerability Operational,
for technical vulnerability Management Financial, management and
ineffective Compliance, testing or detection of Legal, or
vulnerabilities may result in Reputational inappropriate or
unauthorized access to information. Cyber Security Patch and
Strategic, CS-PVM3 Inadequate processes for system L, M, H
Vulnerability Operational, updates and patch management Management
Financial, may result in compromise of Compliance, system security
due to the latest Legal, or updates and patches not being
Reputational installed in a timely manner. Cyber Security Threat
Strategic, CS-TD1 The lack of logging L, M, H Detection
Operational, mechanisms results in the Financial, inability to
track unauthorized Compliance, activity. Legal, or Reputational
Cyber Security Threat Strategic, CS-TD2 Inadequate processes for L,
M, H Detection Operational, logging and monitoring Financial,
Blockchain system activities Compliance, may result in unauthorized
Legal, or information processing Reputational activities going
undetected. Cyber Security Threat Strategic, CS-TD3 Lack of
monitoring mechanisms L, M, H Detection Operational, may result in
breaches and Financial, sensitive data exposure. Compliance, Legal,
or Reputational Cyber Security Threat Response Strategic, CS-TR1
Absence of a formalized L, M, H Operational, Security Incident
Response Financial, Program may result in Compliance, uncoordinated
processes in Legal, or response to a security incident.
Reputational Cyber Security Threat Response Strategic, CS-TR2
Absence of a formalized L, M, H Operational, Security Incident
Response Financial, Program may result in Compliance, uncoordinated
processes in Legal, or response to a security incident.
Reputational Cyber Security Threat Response Strategic, CS-TR3
Incidents that are not controlled L, M, H Operational, may lead to
pervasive problems Financial, throughout the organization.
Compliance, Legal, or Reputational Cyber Security Programming
Strategic, CS-PS1 In adequate security measures L, M, H Security
Operational, within the development Financial, lifecycle of
information systems Compliance, may lead to unauthorized Legal, or
changes. Reputational Cyber Security Programming Strategic, CS-PS2
Systems with vulnerabilities L, M, H Security Operational, may be
developed and Financial, implemented in the production Compliance,
environment. Legal, or Reputational Cyber Security Programming
Strategic, CS-PS3 Systems with vulnerabilities L, M, H Security
Operational, may be developed and Financial, implemented in the
production Compliance, environment. Legal, or Reputational Cyber
Security Programming Strategic, CS-PS4 Systems with vulnerabilities
L, M, H Security Operational, may be developed and Financial,
implemented in the production Compliance, environment. Legal, or
Reputational Cyber Security Programming Strategic, CS-PS5 Untested
changes may lead to L, M, H Security Operational, interruption
and/or unintended Financial, consequences to the Compliance,
organization. Legal, or Reputational Cyber Security Programming
Strategic, CS-PS6 Insecure coding practices, L, M, H Security
Operational, especially within the application Financial, layer,
can introduce security Compliance, vulnerabilities and increase the
Legal, or risk to internal and external Reputational threats. Cyber
Security Programming Strategic, CS-PS7 Use of production or live
data L, M, H Security Operational, for development and/or testing
Financial, purposes can cause unintended Compliance, corruption or
manipulation of Legal, or the data. Reputational Cyber Security
Smart Contracts Strategic, CS-SM1 Input validation mechanisms for
L, M, H Operational, fields and records are not in Financial,
place, creating the risk of failed Compliance, conversion of data
from input to Legal, or outputs Reputational
TABLE-US-00008 TABLE 6 In-scope/Out-of- Scope Control/Test (TBD -
As per Risk Category Domain Objective Control Description
engagement) Cyber Security Cloud Security Contracts with the Cloud
Contracts between the Cloud In-scope Service provider specify
Service Provider and the required information organization
specifies appropriate security and processing security and
processing measures, measures. and establish data are not processed
for any non-specified purpose without approval. Cyber Security
Cloud Security Cloud service providers A contract is signed between
both In-scope and understand roles & parties detailing the
roles and responsibilities, responsibilities of each party,
including requirements to including information security address
information requirements, confidentiality/non- security risks for
disclosure agreements, confidentiality, and the obligations, and
the obligations of secure transfer of employees and subcontractors.
information. Cyber Security Cloud Security The organization
Organizational safeguards such as In-scope employs measures to the
identification, management protect against supply and reduction of
vulnerabilities chain threats from cloud are employed to protect
the service providers that supply chain against information impact
the Blockchain system, system components, and information system,
information system services system component, or threats.
information system service. Cyber Security Cloud Security Cloud
services are Secure standardized network In-scope secured using
standard protocols are in place to manage network protocols, and
the cloud service and interoperability and documentation detailing
relevant portability standards are interoperability and portability
available to customers. standards are made available to customers.
Cyber Security Cloud Security Blockchain systems are The Blockchain
system are In-scope configured to prevent configured to prevents
unauthorized access and unauthorized and unintended transfer of
information information transfer via shared through shared system
system resources. Re-use of resources. shared resources is
monitored and controlled to prevent unauthorized access. Cyber
Security Data Security Data exchange is Formal information exchange
In-scope controlled, encrypted, requirements have been and
protected while the established and Blockchain information is at
rest or systems are configured to protect transferred between the
exchange of information systems. through the use of all types of
communication facilities and interfaces. Cyber Security Data
Security Resources (e.g., Information assets (e.g., In-scope
hardware, devices, data, hardware, devices, data, and and software)
are software) are classified based on classified based on their
their criticality and sensitivity. criticality and business
Information is handled and value. protected in accordance with its
classification, criticality, and business value to the
organization. Cyber Security Data Security Protections against data
The organization employs data In-scope leaks are implemented.
mining prevention and detection techniques for data storage objects
supporting Blockchain use case to adequately detect and protect
against data mining. Cyber Security Data Security Data in
Blockchain Information and records (data) in In-scope systems is
protected Blockchain systems are managed according to the risk
consistent with the organization's strategy and risk appetite risk
strategy to protect the of the organization. confidentiality,
integrity, and availability of information. Cyber Security Data
Security Policies and procedures Information security policies and
In-scope for direction and support applicable procedures have been
of organizational systems formally documented in and applications
exist in accordance with organization's accordance with business
risk objectives, applicable legal requirements and and regulatory
requirements, have relevant laws and been approved by Management,
regulations. and have been communicated to all employees and
relevant external parties. The policies and procedures are reviewed
on a periodic basis based on changes to the internal and external
environment and to support management's objective of continuous
improvement of the organization's information security
capabilities. Cyber Security Data Privacy Protections against data
Unauthorized leaks of data, In-scope privacy are implemented
specifically PII and PHI, are in Blockchain systems to prevented or
detected. The prevent unauthorized processor prevents or monitors
view or exposures of for unauthorized leakage of data, confidential
information. or enables the capability for its customers to prevent
or monitor for the unauthorized leakage of data. DLP tools monitor
outbound communications traffic at the external boundary of the
information system (i.e., system perimeter) and at interior points
within the system (e.g., subsystems, subnetworks) to detect covert
exfiltration of information. Cyber Security Data Privacy Policies
and procedures Information security policies and In-scope for
direction and support procedures around information of information
privacy privacy are documented and exist in accordance with
available to personnel on business requirements accessible
resources. The policies and relevant laws and and procedures are
regulations. reviewed/updated periodically. Cyber Security Data
Privacy The organization The privacy policy discloses the In-scope
discloses how it uses PII ways that the organization in accordance
with the gathers, uses, discloses, and public notice manages PII.
It fulfills the legal requirement. requirement to protect PII and
declares the company's policy on how it collects, stores, and
releases the PII it collects, and inform whether PII is kept
confidential, shared with partners, or sold to other firms or
enterprises. Cyber Security Penetration Asset vulnerabilities are
Penetration tests of the In-scope Testing monitored, identified and
production environment are documented. performed on a periodic
basis or after any significant infrastructure or application
upgrade or modification. Remediation plans are developed to address
the risks. The penetration testing methodology aligns with industry
standard practices and covers application-layer and network- layer.
Testing is performed both inside and outside the network. Test
results are retained for a specific period of time. Cyber Security
Network Network perimeter is Firewalls and routers are In-scope
Security protected using managed configured to: boundary protection
Restrict inbound and outbound devices. traffic to that which is
necessary (e.g., deny by default, permit by exception) Restrict
connections between untrusted networks and any system components
Fail securely in case of an operational failure Permit only
authorized traffic between wireless environment and cardholder data
environment Firewall and router configuration standards are in
place to define network connection requirements. The firewall and
router configuration standards include the following: Business
justification and approval for use of all services, protocols, and
ports allowed, including security features implemented for those
protocols considered to be insecure (e.g., FTP, Telnet, POP3, IMAP,
and SNMP v1 and v2) Roles and responsibilities for management of
network components. Exceptions to the standards are documented and
reviewed on a periodic basis. There is a formal process for testing
and approval of all network connections and changes to firewall and
router configurations. For any public-facing Web applications, an
automated technical solution that detects and prevents web-based
attacks (for example, a web-application firewall) has been
installed, to continually check all traffic. A DMZ is implemented
to limit inbound traffic to only system components that provide
authorized publicly accessible services, protocols, and ports.
Inbound Internet traffic is limited to IP addresses within the DMZ.
A firewall is required at each internet connection and between any
DMZ and the intranet. The information system routes internal
communications traffic to external networks through authenticated
proxy servers (e.g., web content filters with a defined list of
authorized and unauthorized websites) Anti-spoofing measures are
implemented to detect and block forged source IP addresses from
entering the network. Cyber Security Patch and Identify, report and
A vulnerability management In-scope Vulnerability correct
information program exists to identify and Management systems flaws
in a timely manage vulnerabilities in a manner. centralized,
streamlined and organized manner. The technical vulnerability
management program is evaluated on a quarterly basis. Cyber
Security Patch and System vulnerability Vulnerability scans and
rescans In-scope Vulnerability scanning is performed to are
performed by qualified Management identify threats. personnel on
both external and internal facing production systems using internal
scanning resources on a periodic basis and when new vulnerabilities
affecting the systems are known. Commercial and proprietary
vulnerability scanning tools are configured to identify
vulnerabilities. Identified critical
vulnerabilities are remediated timely. Remediation status is
monitored and non-compliance is escalated. Cyber Security Patch and
System vulnerabilities A patch management program In-scope
Vulnerability are mitigated through exists to incorporate, test,
and Management patches. implement firmware updates and patches in a
timely fashion Cyber Security Threat Detection Logging mechanisms
and Logging mechanisms are In-scope the ability to track configured
to enable the activity is established, monitoring, analysis,
tracked, and monitored. investigation, and reporting of unlawful,
unauthorized, or inappropriate information system activity: The
following events are tracked: General user access and activities
Root access and activities Access to audit logs Invalid access
attempts Changes to identification and authentication mechanisms
Changes to or elevation of privilege access rights Initialization,
stopping, or pausing of the audit logs Creation and deletion of
system- level objects exceptions system faults information security
events system/network events For each event, the following details
are captured: Type of event Time Where the event occurred Source of
the event Outcome of the event (success/failure) Unique identity of
individuals associated with the event Identity or name of affected
data, system component, or resource. Cyber Security Threat
Detection Risk-based monitoring to Risk based monitoring is
In-scope detect unauthorized performed using automated tools
connections, devices, (e.g., SIEM tools) to detect events, and
network unauthorized connections, services. devices, events, and
network services. Automated tools are used to perform analysis of
events. Monitoring is performed in compliance with legal and
regulatory requirements. Events are analyzed to understand attack
targets and methods. Cyber Security Threat Detection Automated
mechanisms The organization employs In-scope communicate security
automated mechanisms to make alert and advisory security alert and
advisory information following information available throughout
indicators of the organization when indicators compromise. of
compromise are found. Cyber Security Threat Response Incident
response A formal security incident In-scope program is in place to
response program is established provide timely and to respond,
report, escalate and effective response to user treat breaches and
reported requests and resolution to security events or incidents. A
all types of incidents. comprehensive incident response plan exists
to identify, manage, respond to, and recover from security (e.g.,
system breach) and IT operational (e.g., process errors) incidents
and is communicated to appropriate stakeholders. The incident
response plan is reviewed and modified on a periodic basis. Cyber
Security Threat Response Incident response The organization
develops, In-scope program is in place to documents, and
disseminate an provide timely and incident response policy. The
effective response to user policies and procedures are requests and
resolution to reviewed and updated, at a all types of incidents.
minimum, on an annual basis. Cyber Security Threat Response
Security incidents are Incident alert thresholds have In-scope
contained and mitigated been established and all incident to
prevent additional detection tools have been impact to business
calibrated with the thresholds. operations and loss of Incidents
(operational or IT information. security) are identified, logged,
documented, reported to different levels within the organization,
and tracked to closure. Cyber Security Programming Organizations
should The organization establishes and In-scope Security establish
and appropriately protects secure appropriately protect development
environments for secure development system development and
environments for system integration efforts that cover the
development and entire system development integration efforts that
lifecycle. cover the entire system development lifecycle. Cyber
Security Programming Systems are developed An established system
In-scope Security securely. development lifecycle (SDLC) process
and methodology is in place, documented, maintained, and applied
for system and software design, acquisition, implementation,
configuration, integration, testing, modification, and maintenance.
The process also specifies the tools to be used for system
development. The secure SDLC process, methodology, and tools are
reviewed on a periodic basis. Cyber Security Programming Systems
are developed The SDLC process is inclusive of In-scope Security
securely. information security considerations. Security roles and
responsibilities during the development lifecycle have been
defined. Organization's information security team and the risk
management methodology is appropriately integrated into the SDLC
process. Cyber Security Programming Systems are developed The
Security team coordinates In-scope Security securely. with the
system developers to define and develop system security plans.
System security plans that outline the security requirements are
documented and maintained for information systems. The plans are
communicated to relevant and authorized internal and external
users. Cyber Security Programming Test data should be Test data
shall be selected In-scope Security selected carefully, carefully,
protected and protected and controlled. controlled. Operational
data is protected when used for test purposes. Test data and
accounts are removed from system components before the system
becomes active/goes into production. Cyber Security Programming
Applications should be Developers employ secure coding In-scope
Security developed using secure guidelines to software and mobile
coding guidelines, in applications. Developers are order to address
common trained at least annually in up-to- coding vulnerabilities.
date secure coding techniques, including how to avoid common coding
vulnerabilities. (Refer the OWASP Guide, SANS CWE Top 25, CERT
Secure Coding, etc.) Cyber Security Programming Production data are
not Production data are not used for In-scope Security used for
testing or testing or development. development.
TABLE-US-00009 TABLE 7 Risk Test Type (TBD - As Category Domain
Test Procedure (#) per engagement) Request List (#) Cyber Cloud
Security 1. Obtain and review contracts with cloud Inquiry,
Inspection, 1. Contracts with Security service providers to
determine whether contracts and/or observation cloud service
include information security provisions to providers. protect
against cybersecurity and data security/data privacy risks. Cyber
Cloud Security 1. Inquire with the control owner and determine
Inquiry, Inspection, 1. Policies and Security if all relevant
information security requirements and/or observation procedures
related to are established and agreed with each supplier/ contracts
between the vendor that may access, process, store, organization
and communicate, or provide IT infrastructure suppliers/vendors.
components for, the organization's information. 2. Evidence of 2.
Inspect a sample of agreements and validate agreements between that
they include the following: the organization and Roles and
responsibilities suppliers/vendors. Service definitions and SLAs 3.
Population - Information security controls to be System generated
list implemented of contract System functions, ports, protocols,
and other amendments during services required for the use of such
services. the audit period. Requirement to provide notification of
changes 2. Evidence that a new to services or controls customer or
vendor Requirement to provide notification of 3rd contract addendum
or party personnel transfers and terminations new vendor contract
Laws and regulations that the third party needs was signed for a to
comply with sample of changes to Penalties or claw back clauses
confidentiality Locations that they can provide services out of
commitments Limitations on data storage locations requiring
customer or Incident management procedures vendor notification.
Breach notification Right to audit Limitations and constraints of
access Termination conditions Data disposal/return upon termination
Ownership of products after development Quality requirements
Security training requirements for employees Business-critical or
customer-impacting application design, development, and deployment
Business-critical or customer-impacting system designs and
configurations design, development, and deployment
Business-critical or customer-impacting infrastructure network and
system components design, development, and deployment IT Governance
and service management policies and procedures Customer
requirements policies and procedures for service-to-service
application Customer requirements policies and procedures for
information processing, interoperability, and portability for
application development Customer requirements policies and
procedures for information exchange, usage, and integrity
persistence 3. Inquire with the control owner to determine if
confidentiality commitments with vendors/ suppliers are changed
during the normal course of business. If changes to confidentiality
commitments are required, verify through inquiry with the control
owner that a vendor contract addendum or new vendor contract is
established. 4. Obtain the population of tickets related changes to
confidentiality commitments requiring vendor/supplier notification.
5. For a sample from the above #4 population, verify that a vendor
contract addendum or new vendor contract was signed. Cyber Cloud
Security 1. Inquire with the control owners and observe Inquiry,
Inspection, 1. System and Security the organization's processes for
defining the and/or observation services acquisition safeguards
that protect systems against supply policies and chain threats, as
well as the automated procedures. mechanisms supporting supply
chain threat 2. Procedures for the safeguards. Determine if the
organization integration of security protects its information
systems, system requirements into the components, or information
system services development process. from supply chain threats by
implementing 3. Service delivery security safeguards as defined by
the information agreements security strategy. 2. Inspect system and
services acquisition policies and procedures, procedures for the
integration of security requirements into the development process,
and supporting documentation to determine the following: if the
organization defines the security safeguards to implement as
protection to information systems, system components, or system
services against supply chain threats. if the organization assures
reasonable information security across their information supply
chain by performing annual reviews, including reviews of all
partners and third-party providers that the organization's
information supply chain depends on. 3. Inspect service delivery
agreements and determine the following: that third party service
providers are required to demonstrate compliance with information
security and confidentiality, access control, service definitions,
and delivery-level agreements defined. that third-party reports,
records, and services shall undergo audit and review at least
annually to govern and maintain compliance with the service
delivery agreements. Cyber Cloud Security 1. Inquire with the
control owner and determine Inquiry, Inspection, 1. Cloud service
Security the following: and/or observation policies and The
organization uses secure standardized procedures network protocols
(e.g., non-clear text and authenticated) to manage services. The
organization makes available to customers documentation detailing
relevant interoperability and portability standards. If the
organization, as a cloud service provider, uses an
industry-recognized virtualization platform and standard
virtualization format to help ensure interoperability. if any
custom changes made to any hypervisor in use and to all
solution-specific virtualization hooks are documented and made
available to customers for review. 2. Inspect cloud service
security policies and procedures and determine the following: The
organization uses secure standardized network protocols (e.g.,
non-clear text and authenticated) to manage services. The
organization makes available to customers documentation detailing
relevant interoperability and portability standards The
industry-recognized virtualization platforms and standard
virtualization formats are used to help ensure interoperability.
The custom changes made to any hypervisor in use and to all
solution-specific virtualization hooks shall be documented and made
available to customers for review. Cyber Cloud Security 1.
Determine through inquiry with control owner Inquiry, Inspection,
Security whether processes are in place to remove any and/or
observation previous content from shared resources when it is being
allocated for reuse to new set of users. Cyber Data Security 1.
Confirm the following have been addressed Inquiry, Inspection,
Security within policies and procedures for the use of and/or
observation electronic communication facilities: procedures
designed to protect exchanged information from interception,
copying, modification, incorrect routing, and destruction
procedures for the detection of and protection against malicious
code that may be transmitted through the use of electronic
communications procedures for protecting communicated sensitive
electronic information that is in the form of an attachment, policy
or guidelines outlining acceptable use of electronic communication
facilities procedures for the use of wireless communications,
employee, contractor and any other users' responsibilities not to
compromise the organization, use of cryptographic techniques,
retention and disposal guidelines for all business correspondence
in accordance with relevant national and local legislation and
regulations, not leaving sensitive or critical information on
printing facilities controls and restrictions associated with the
forwarding of communication facilities, not leaving messages
containing sensitive information on answering machines, reminding
personnel not to register demographic data in any software to avoid
collection for unauthorized use. Cyber Data Security 1. Inquire
with the control owner to determine Inquiry, Inspection, 1. Data
Classification Security whether the business value of each
information and/or observation Policy and asset has been
established and documented. procedures. 2. Inquire with the control
owner and obtain the 2. Evidence that Data Classification Guide to
determine if critical assets have classification schemes and
procedures for been identified and handling, processing, storing
and communicating documented. information consistent with its
classification, 3. Evidence that the criticality, and business
value are documented. security categorization 3. Inquire with the
control owner to determine decision is reviewed whether critical
assets have been identified and and approved by the documented.
authorizing official or 4. Determine whether logical and physical
authorizing official protection levels offered for data stored in
designated databases, removable media, etc. is in alignment
representative. with the classification level of the data. 4.
Sample of media to 5. Inspect if the security classification
decision is determine whether reviewed and approved by an
authorizing official they have been or authorizing official
designated representative. classified so that 6. Inspect if all
media has been classified so that sensitivity of the data the
sensitivity of the data can be determined. can be determined. 7.
Validate whether all assets have been assigned 5. Evidence that
assets an owner. are assigned to an owner. Cyber Data Security 1.
Obtain and inspect relevant documents to Inquiry, Inspection, 1.
Account Security determine if the organization implements various
and/or observation Management data mining protection program for
the Procedures. information system, system component, or 2.
Information information system service. Security technical For
example: standard. limiting the types of responses provided to 3.
Access database queries; Management limiting the number/frequency
of database procedures. queries to increase the work factor needed
to 4. Database access determine the contents of such databases; and
management notifying organizational personnel when procedures.
atypical database queries or accesses occur. 2. Inquire with
control owners to determine that established policies and
procedures are in place and define data mining prevention and
detection techniques, define that data storage objects are to be
protected, and define the organization-defined techniques for data
mining prevention and detection techniques for data storage 3.
Inspect the organizations Account Management Procedures,
Information Security Technical Standard, Access Management
Procedures, Database Access Management Procedure, and determine
that the established policies and procedures outline and define
data mining prevention and detection techniques and storage
protection: Cyber Data Security 1. Obtain and inspect relevant
documents to Inquiry,
Inspection, 1. Relevant policies Security determine if the
organization aligns with its risk and/or observation and
procedures. strategy and risk appetite when implementing 2.
Evidence of review data protection measures. (e.g., sign 2. Inquire
with control owners to determine that off/approvals policies and
procedures are in place that documented in policy prescribe data
protection measures based on revisions history). information
classification and risk ranking. 3. Screenshot of the location of
policies and procedures showing that they are available to company
personnel. 4. Evidence showing that policies are part of annual
security awareness. Cyber Data Security 1. Inquire with the control
owner and determine Inquiry, Inspection, 1. Relevant policies
Security if information security policies and procedures and/or
observation and procedures. are documented, available and
communicated to 2. Evidence of review personnel on accessible
resources (internal (e.g., sign network, shared drive, etc.).
off/approvals 2. Inspect policies and procedures to confirm if
documented in policy they are reviewed/updated at least annually or
revisions history). more frequently if required based on changes in
3. Screenshot of the the environment. location of policies 3.
Security policies and operational procedures and procedures should
address organization-determined areas showing that they are and
best practices, examples include: available to company Business
Continuity/Disaster Recovery; personnel. Data Protection/DLP; 4.
Evidence showing Access Management; that policies are part Vendor
Management; of annual security Physical Security; awareness. SDLC;
Security Awareness training; Mobile device management;
Legal/regulatory requirements; System/service acquisition; User
agreements. Incident Management Network Security Configuration
Management Application Security Cryptography and Key Lifecycle
Management Risk Assessment and Treatment Data confidentiality,
integrity and availability across multiple system interfaces,
jurisdictions, business functions Cyber Data Privacy 1. Inquire of
management and obtain evidence to Inquiry, Inspection, Special
Note: Security validate whether the organization has capabilities
and/or observation Personally identifiable to prevent or monitor
data leaks. information (""PII"") 2. Determine if the organization
performs and Protected Health activities to analyze potential
opportunities for Information (""PHI"") covert channels. If so,
determine if testing is fall under ""Customer performed to identify
exploitable channels and Data"" and is thus the bandwidth
associated with those channels. subjected to the 3. Inquire with
the control owner to determine if company's data the
above-mentioned capabilities in test classification schema
procedure #1 are aligned with legislative, and controls.
regulatory, or contractual obligations, 1. Data Classification 4.
Obtain and inspect policies, procedures, and and Protection other
supporting documentation to validate policies and whether the
aforementioned capabilities in test procedures. procedure #1 are in
place to enable the 2. Policies and organization to meet their
obligations to procedures related to customers in accordance with
contractual Data Loss Prevention requirements. and the handling of
customer data. 3. Evidence of the organizations capabilities to
prevent or monitor data leaks. 4. Evidence that data loss
prevention processes and procedures are aligned with legislative,
regulatory, or contractual obligations. Cyber Data Privacy [General
Privacy Requirements; Notice, Choice, Inquiry, Inspection, 1.
Privacy policies Security Consent] and/or observation and
procedures 1. Inquire with the control owner and determine
regarding where information security policies and confidentiality
and procedures are documented and available to non-disclosures.
personnel with access to PII on accessible 2. ISMS manual resources
(internal network, shared drive, etc.). (Executive 2. Review
policies and procedures to confirm Leadership, CTO) they are
reviewed/updated at least annually or 3. Evidence to more
frequently if required based on changes in demonstrate that the
environment, documents are 3. Inspect the information security
policies on available to personnel the company's internal network
and determine with access to PII on they are available and
communicated to accessible resources company personnel with access
to PII and such as internal include security roles,
responsibilities, and network, shared drive, procedures.
Specifically, privacy policies and etc. operational procedures for
the confidentiality 4. Data localization and non-disclosure
agreements. policy [Storage Location of PII] 5. List of countries
1. Inquire with the control owner and determine that might have
access that the organization has documented data to the
organization's localization policies and procedures available to
customers' PII. personnel on accessible resources (company 6.
Evidence intranet, shared drive). documenting the 2. Inspect the
data localization policy on the review and update company's
internal network and determine they procedures performed are
available and communicated to company by the organization to
personnel and address that the organization ensure that the list of
documents and makes available the countries countries is accurate
where PII might be stored as required. and up to date. 3. Inspect
policies and procedures to confirm they are reviewed and updated
based on changes in the environment. 4. Obtain and inspect the list
of countries that might have access to the organization's
customers' PII. 5. Obtain and inspect the list of countries to
determine the review and update procedures performed by the
organization to ensure that the listing is accurate and up to date.
Cyber Data Privacy 1. Inquire with control owners to understand
Inquiry, Inspection, 1. Data privacy policy Security where, within
the organization's data policies, and/or observation showing the
the expectations for the return, transfer, and/or expectations for
the destruction of PII is defined. In addition, return, transfer,
and/or determine how this is communicated to the destruction of PII
by customers (i.e. website, contract/amendments). the organization
for 2. Obtain and observe the appropriate the customers.
documentation (i.e. data policy) showing the 2. Data Classification
expectations for the return, transfer, and/or policy for restricted
destruction of PII by the organization for the class protection.
customers. Cyber Penetration 1. Inquire with the control owner to
determine Inquiry, Inspection, 1. Copy of most Security Testing
whether penetration tests are performed on a and/or observation
recent penetration test periodic basis and remediation plans are
and penetration test developed to address the risks. methodology
utilized. 2. Inspect the results of the most recent 2. Population
of risks penetration test to determine whether it was from most
recent completed within the organization-specified time penetration
test. period and performed by an independent 3. For a sample of
penetration agent or team. risks, please provide 3. Inspect ticket
details and supporting ticket/supporting documentation for a sample
of risks identified in details to document the most recent
penetration test to determine remediation. whether the risks were
remediated or were being 4. Please provide actively worked to
remediation. evidence that both external and internal penetration
tests are performed at least annually and after any significant
infrastructure or application modification. Cyber Network 1.
Inspect documented procedures and determine Inquiry, Inspection, 1.
Firewall and router Security Security that there is a formal
process for testing and and/or observation configuration approval
of all: standards Network connections; and 2. Evidence of Changes
to firewall and router configurations firewall rule review. 2.
Obtain a population of changes to network 3. Router rule sets
connections, firewalls, and router configurations. 4. Network
diagrams 3. Select samples and obtain tickets. 5. Population of 4.
Inspect tickets from selected sample to changes to network validate
that changes to network connections, connections, firewalls,
firewalls, and router configurations were tested and router and
approved. configurations. 5. Validate whether the network diagrams
are 6. Tickets for samples updated if there is a change in the
network of changes to network connection. connections, firewalls,
and router configurations. 7. Population of firewall reviews, from
which a sample will be selected. 8. Evidence of firewall reviews
for the sample selected. Cyber Patch and 1. Inquire with the
control owner to determine if Inquiry, Inspection, 1. Policies and
Security Vulnerability a formal vulnerability management program
and/or observation procedures related to Management exists and
tools are in place to detect, report, and vulnerability correct
vulnerabilities. management. 2. Determine if there is a formally
documented 2. Population of vulnerability management methodology
and vulnerability/patch procedures. tickets. 3. Through interviews
with the control owner, 3. Sample evidence of inspection of
reports, determine whether system ticket resolution vulnerabilities
are identified and tracked. including risk ranking. 4. Inspect
tickets to determine if the vulnerability 4. Information was
ranked, worked to resolution based on Security Policies and
criticality, authorized, tested, and approved prior procedures. to
implementation into production. 5. Verify whether the program is
evaluated on a quarterly basis. Cyber Patch and 1. Inquire with the
control owner and determine Inquiry, Inspection, 1. Evidence that
Security Vulnerability if vulnerability scans were performed on
both and/or observation vulnerability scans Management external and
internal facing production systems were performed on using internal
scanning resources on an both external and organization-defined
frequency. internal facing 2. Inspect the internal scanning
resource production systems configurations and determine
vulnerability scans using internal were scheduled to run with an
appropriate scanning resources. frequency and were configured to
run against 2. Scanning resource internal and external IP ranges.
configuration. 3. Inspect the vulnerability scan report for a 3.
Reference of sample of weeks and determine an internal and internal
IPs from a external vulnerability scan was completed in source that
is accordance with the configured schedule. independent from the 4.
Inspect if the organization performs privileged/ team responsible
for authenticated vulnerability scans vulnerability scanning 5.
Inspect if the organization employs 4. Internal and vulnerability
scanning procedures that can external vulnerability identify the
breadth and depth of coverage (i.e., scan reports for the
information system components scanned and for the selected weeks
vulnerabilities checked). (to be specified). 6. Inspect if the
organization employs vulnerability scanning procedures that updates
the information system vulnerabilities scanned. Cyber Patch and 1.
Determine the number of vulnerabilities Inquiry, Inspection, 1.
Obtain a listing of Security Vulnerability identified. and/or
observation application systems Management 2. Validate that patch
management process is with vulnerabilities. initiated to address
the known vulnerabilities. 2. Obtain a listing of 3. Validate that
patch is tested and applied timely patches deployed to to mitigate
the known vulnerabilities. address identified vulnerabilities in a
timely manner. 3. Obtain evidence
showing that the patches were tested before deployed into
production Cyber Threat 1. Inquire with the control owners and
inspect Inquiry, Inspection, 1. System generated Security Detection
evidence to validate whether or not the and/or observation list of
production organization performs logging related to both servers
and network unauthorized actions and access. The following devices
as of present items are examples of logging mechanisms that day
with source, filter/ should be in place: query details, etc.
Action-related logging events: 2. Log configurations all changes,
additions, or deletions to any for a sample of account with root or
administrative privileges; production servers Initialization,
stopping, or pausing of audit and network devices. logs; 3.
Evidence that the creation and deletion of system level objects;
organization performs creation, modification, enabling, disabling,
and logging related to both removing of accounts; unauthorized
actions initialization and the stopping or pausing of and access.
audit logs. 4. Policies and system security configuration changes
procedures related to activation and de-activation of protection
access control, systems (e.g., A/V and IDS) account management,
management activities, system and application audit and
startup/shutdown/errors, file changes, and accountability, storage
security policy changes. engineering, and audit Access-related
logging events: record content. successful and unsuccessful account
logon 5. Evidence that the events; organization all individual
access to cardholder data; configures access to all audit trails;
information systems elevation of privileges. to allocate storage 2.
Inquire of management and inspect evidence space for the retention
to validate whether the organization: of audit records. includes
user identification, event type, date and time stamp, indication of
success or failure, event origination, and identity of affected
data, system component, or resources in log entries; monitors
information system accounts for abnormal usage and activity;
reports abnormal usage and activity on information system accounts
to specified personnel; configures information systems to generate
audit records that contain information on what type of event
occurred, when and where the event occurred, the source and outcome
of the event, and the identity of individuals associated with the
event; continuously writes logs from production servers, network
devices, databases and storage management hosts to system logs and
forwards them to the logging and alerting system in real- time in
order to provide backup media for records other than the audited
system; configures the information system to provide the capability
to generate audit records for defined auditable events for
specified information system components; configures the information
system to allow specified personnel to select which auditable
events should be audited by specific system components; configures
the information system to provide capabilities for specified
individuals to change the performed audits on information system
components based on defined selectable event criteria within
specified thresholds. 3. Inspect policies and procedures around
access control, account management, audit and accountability,
storage engineering, and audit record content and validate whether
or not the organization. defines abnormal information system
account usage and the personnel to be notified upon the
identification of abnormal system usage; configures the information
system to generate audit records that contain information on what
type of event occurred, when and where the event occurred, the
source and outcome of the event, and the identity of individuals
associated with the event; defines the additional detailed
information required to be included in audit records that the
information system generates; defines the information system
components that provide audit record generating capabilities for
defined auditable events; defines the personnel whom are allowed to
select which auditable events are to be audited by specified
information system components, and change the validating performed
on specified information system components; defines the information
system components that validating is performed on; defines the time
thresholds that must be met for specified individuals to change the
audit functions performed on information system components; defines
the event criteria that can be selected by specified individuals or
roles to support the capabilities of changing audit functions
performed on information system components; continuously writes
logs from production servers, network devices, databases and
storage management hosts to system logs and forwards them to the
logging and alerting system in real- time in order to provide
backup media for records other than the audited system 4. Inspect
audit record storage capacity related to information system
configuration settings and determine that the organization
configures information systems to allocate storage space for the
retention of audit records and that it is sufficient in accordance
to defined requirements. Cyber Threat 1. Inquire with the control
owner to determine if Inquiry, Inspection, 1. Evidence that the
Security Detection documented procedures for monitoring are in
and/or observation organization monitors place to detect
vulnerabilities, indicators of the Blockchain potential attacks in
accordance with information system to (organization-defined)
monitoring objectives, detect unauthorized/ unauthorized local,
network, and remote malicious activity. connections; 2. Provide a
list of 2. Inquire with the control owner to verify tools and
processes in whether monitoring tools are implemented in place to
monitor the high risk systems and environments to detect Blockchain
anomalous events and activities: information system Inbound and
outbound communications and their Internal system activities,
including configurations. unauthorized system use and transactions
3. Provide a system Unauthorized connections generated list of
Unauthorized users vulnerability tickets Unauthorized devices for
the period under Unauthorized software review, from which a
Unauthorized remote access connections sample will be 3. Verify
whether action is taken as part of selected. incident response and
vulnerability management 4. Provide the internal plan when
anomalous events are detected tickets from the 4. Inspect the
monitoring tools to verify their selected sample. configuration and
validate whether they are configured to detect anomalous events.
Cyber Threat 1. Inquire with management to determine if the
Inquiry, Inspection, 1. Information Security Detection organization
employs automated mechanisms to and/or observation security
policies and make security alert and advisory information
procedures related to available throughout the organization.
security alerts and 2. Inspection information security policies to
advisories. determine if the organization has defined 2. Evidence
of requirements regarding automated mechanisms processes in place
for to make security alert and advisory information defining,
receiving, available throughout the organization. generating, and
3. Inspect organizational processes in place for disseminating
security defining, receiving, generating, and alerts and
advisories. disseminating security alerts and advisories, including
automated mechanisms supporting and/or implementing dissemination
of security alerts and advisories. Cyber Threat 1. Verify that a
formal incident response Inquiry, Inspection, 1. Information
Security Response program exists and includes formally defined
and/or observation Security Incident roles and responsibilities, an
incident response Management plan, and resources to support
incident response. documentation 2. Obtain the copy of the incident
response plan. 2. CSIRT/Incident Verify that it is formally
documented and has Response Plan been approved by a senior
Management 3. CSIRT/Incident executive. Response Process 3.
Validate that the incident response plan 4. Provide document has
been recently (within the last year) documentation for reviewed and
the latest plan has been shared with previously reported and
communicated to personnel with incident incidents or alerts.
response responsibilities. 4. Verify whether the incident response
plans covers both IT operational and security incidents. 5. Verify
that the incident response plan contains the following: Roles and
responsibilities, and structure and organization of the incident
response capability; Incident response process flows and procedures
that include steps for preparation, detection and analysis,
containment, eradication, and recovery; Defines reportable
incidents and incident classification; Incident communication and
notification; Analysis of legal requirements for reporting
compromises; Provides metrics for measuring the incident response
capability within the organization; Defines the resources and
management support needed to effectively maintain and mature an
incident response capability; System and data recovery; Data backup
processes. 6. Verify if the incident response plan is periodically
updated to address system/organizational changes or problems
encountered or lessons learned during plan implementation,
execution, training, or testing. 7. Review documentation from a
sample of previously reported incidents or alerts to verify that
the documented incident response plan and procedures were followed.
Cyber Threat 1. Inquire with control owner to determine if the
Inquiry, Inspection, 1. CSIRT Incident Security Response
organization develops, documents, and and/or observation Response
Plan disseminate an incident response policy. 2. Security Incident
2. Examine the incident response plan to Response Process determine
if an incident response policy exists 3. Corporate Critical and
whether the policy address the specific Incident Process purpose,
scope, roles and responsibilities, 4. Information management
commitment, and compliance. Security Policies 3. Examine the
information security policies and 5. Crisis Management procedures
(see evidence), CSIRT Incident Team Plan Response Plan, Security
Incident Response Process, Corporate Critical Incident Process and
determine if the incident response procedures are disseminated to
appropriate personnel. 4. Observe location of incident response
plan on the organization intranet (or other location) to determine
how the incident response policies are disseminated. 5. Examine the
incident response plan to determine if the organization has
reviewed and updated on an annual basis. Cyber Threat 1. Inquired
of the control owner to determine Inquiry, Inspection, 1. Listing
of recent Security Response whether security incidents were tracked
and and/or observation incidents for the documented from initiation
through closure. period under review 2. Obtain a listing of
incidents for the period and parameters/query under review and
select an appropriate number used to generate the of samples.
report. 3. Obtain tickets or documentation to validate 2.
Documentation of that the incidents were documented incident
containment (categorized/prioritized), reviewed, tracked and and
mitigation, such resolved in a timely manner and includes the as IT
tickets. following details: The identified solutions or workaround
are documented, applied and tested, and recovery actions are
performed to restore the IT-related service. The satisfactory
resolution of incidents and/or request fulfillment is verified and
is closed.
4. Determine whether incident thresholds have been established and
whether the tools have been calibrated with the thresholds. Cyber
Programming 1. Inquire with the control owner to determine Inquiry,
Inspection, 1. Information Security Security whether the
organization establishes guidelines and/or observation Security
Policies for the secure development environment for containing
technical critical systems. roles that address 2. Inspect the
information security policies to development determine whether the
policies outline guidance activities, and for technical roles and
secure development established guidelines environment for critical
systems. for the secure 3. Validate whether management reviewed the
development policy within the past 12 months and environment for
communicated it to employees. critical systems. 4. Review the
secure development standards to 2. Evidence that validate whether
appropriate measures have been management reviewed described for
security of development the Information environments. Security
Policies 5. Review the access list for a sample of within the past
12 development environments and validate whether months and the
access has been approved. Also validate communicated it to whether
any non-developers have access to the employees. development
environment. Cyber Programming 1. Inquire with control owner to
whether an Inquiry, Inspection, 1. SDLC policies and Security
Security established system development lifecycle and/or
observation procedures. process is in place, documented,
maintained, and 2. Evidence that an applied for all system and
software design, established system acquisition, implementation,
configuration, development lifecycle integration, testing,
modification, and process is in place, maintenance. documented, 2.
Obtain and inspect SDLC policies and maintained. procedures to
determine whether an established 3. Security system development
lifecycle process is requirements for documented. information
systems 3. Verify whether security requirements for and information
information systems and information services are services are
identified identified as part of SDLC efforts, business process
re-design, etc. Cyber Programming 1. Obtain the SDLC
process/methodology Inquiry, Inspection, 1. Policy for the Security
Security documentation and verify whether it specifies and/or
observation SDLC process that the developers should consider
information 2. System and security during the requirements
gathering, high Services Acquisition level design, low level
design, development, and Policies, Procedures systems integration
phases of developing an and Standards information system. 3.
Information 2. Verify whether the SDLC Security Procedures
process/methodology documentation specifies (SDLC process) whether
the testing phase should include security testing of information
systems. 3. Verify that during the functional requirements
gathering phase, the information security requirements are captured
and consider the following: the level of confidence required
towards the claimed identity of users, in order to derive user
authentication requirements access provisioning and authorization
processes required protection needs of assets involved requirements
derived from business processes, such as transaction logging and
monitoring, non- repudiation requirements requirements mandated by
other security controls, e.g., interfaces to logging and monitoring
or data leakage detection systems information users and operators
of their duties and responsibilities 4. Verify whether the SDLC
process/methodology defines the security roles and responsibilities
during the development lifecycle. 5. Verify whether there is a
clear integration between the organization risk management
methodology and SDLC methodology and whether it outlines how
information systems can be classified based on their inherent risk.
Cyber Programming 1. Inspect if the organization: Inquiry,
Inspection, 1. Security program Security Security Develops a
security plan for the information and/or observation plans, budget,
system that: procedures, and Is consistent with the organization's
enterprise policies architecture 2. Information Explicitly defines
the authorization boundary Security Governance for the system;
Program Describes the operational context of the documentation
information system in terms of missions and business processes;
Provides the security categorization of the information system
including supporting rationale; Describes the operational
environment for the information system and relationships with or
connections to other information systems; Provides an overview of
the security requirements for the system; Identifies any relevant
overlays, if applicable; Describes the security controls in place
or planned for meeting those requirements including a rationale for
the tailoring decisions; and Is reviewed and approved by the
authorizing official or designated representative prior to plan
implementation; Distributes copies of the security plan and
communicates subsequent changes to the plan to organization-defined
personnel or roles; Reviews the security plan for the information
system per organization-defined frequency; Updates the plan to
address changes to the information system/environment of operation
or problems identified during plan implementation or security
control assessments; and Protects the security plan from
unauthorized disclosure and modification. 2. Inspect if the
organization. Identifies organization-defined user actions that can
be performed on the information system without identification or
authentication consistent with organizational missions/business
functions; and Documents and provides supporting rationale in the
security plan for the information system, user actions not
requiring identification or authentication. Cyber Programming 1.
Inquire with control owner/interview Inquiry, Inspection, 1.
Provide written Security Security responsible personnel to
understand how and/or observation software-development production
data is sanitized, transferred, and procedures. used for test
purposes. 2. Provide a 2. Obtain and inspect written software-
population of project development procedures to verify that
plans/checklists, from operational data is sanitized, transferred,
when which a sample will used for test purposes. be selected. 3.
Observe testing processes and interview 3. Provide the project
personnel to verify operational data is protected plans and
checklists through testing. for the sample 4. Obtain a population
of project plans/checklists selected. for the period under review.
[PCI] 5. Select a sample of project plans and checklists 1. Provide
a to determine whether data protection activities population of
data and are built into the overall test approach. accounts from
production systems recently installed or updated for the period
under review, from which a sample will be selected. 2. Provide
supporting evidence for the selected sample of data and accounts
from production systems. Cyber Programming 1. Inquire with the
control owner to determine Inquiry, Inspection, 1. Secure Coding
Security Security the following: and/or observation Guidelines;
that documented software and mobile secure Infrastructure coding
guidelines are available to outline Hardening Guidelines
development and implementation guidance for and Secure Coding
software and mobile code Guidelines. that the organization
authorizes, monitors, and 2. System and controls mobile code use
within the information Communications system Protection Policies 2.
Inspect the Secure Coding Guidelines and and procedures determine
that acceptable and unacceptable software and mobile coding
guidelines along with implementation guidance are outlined within
the documents, including: a. Secure coding techniques training is
required for developers at least annually, based on industry best
practices and guidance; b. Software-development process procedures:
defines software-development processes based on industry standards
and leading practices defines information security throughout the
software development lifecycle defines that developers must develop
software applications in accordance with standards determine that
the software-development standards are implemented. c. Injection
flaws: Validate inputs to determine that user data cannot modify
meaning of commands and queries. Utilizing parameterized queries.
d. Buffer overflows: Validate buffer boundaries. Truncating input
strings. e. Insecure cryptographic storage Prevent cryptographic
flaws. Use strong cryptographic algorithms and keys. f. Insecure
communication Determine that insecure communications are addressed
by coding techniques that properly authenticate and encrypt all
sensitive communications. g. Improper error handling Validate that
improper error handling is addressed by coding techniques that do
not leak information via error messages h. All "high risk"
vulnerabilities identified in the vulnerability identification
process Verify that coding techniques address any "high risk"
vulnerabilities that could affect the application i. Cross-site
scripting (XSS) Validating all parameters before inclusion
Utilizing context-sensitive escaping j. Improper Access Control
Proper authentication of users Sanitizing input Not exposing
internal object references to users User interfaces that do not
permit access to unauthorized functions. k. Cross-site request
forgery (CSRF) to determine that cross-site request forgery (CSRF)
is addressed by coding techniques that ensure applications do not
rely on authorization credentials and tokens automatically
submitted by browsers. 1. Broken authentication and session
management: Flagging session tokens (for example cookies) as
"secure" Not exposing session IDs in the URL Incorporating
appropriate time-outs and rotation of session IDs after a
successful login. 3. Inspect system and communications protection
policy and procedures addressing mobile code and determine the
following: that the organization defines the mobile code and mobile
code technologies that are acceptable and unacceptable; that the
organization establishes restrictions for acceptable mobile code
and mobile code technology use; that the organization documents
implementation guidance for the defined acceptable mobile code and
code technologies.
4. Observe the organization's defined processes for controlling,
authorizing, monitoring, and restricting mobile code and determine
that the organization authorizes, monitors, and controls mobile
code use within the information system. Cyber Programming 1.
Inquire with the control owners and determine Inquiry, Inspection,
1. Policies and Security Security if procedures clearly define that
production data and/or observation procedures related to (live
PANs) are not used for testing or production data (live
development. PANs). 2. Observe the testing processes and determine
2. Population of data that the organization's personnel do not use
and accounts from production data (live PANs) in testing or in
recently installed or development. updated production 3. Obtain a
population of data and accounts from systems. recently installed or
updated production systems. 3. Sample of test data 4. Select a
sample of data and accounts and and accounts from the inspect test
data to determine whether production obtained population. data
(live PANs) are used for testing or development.
[0144] In some embodiments, infrastructure layer risk category in
the blockchain risk framework covers relevant risks, control
objectives and descriptions, testing objectives and procedures, and
reporting parameters designed to address assurance and compliance
needs for the blockchain infrastructure stack/layer supporting
functioning of the underlying hardware, software, servers,
databases, networks, interfaces technologies (e.g. APIs etc.).
[0145] The sub-risk categories, control and testing objectives,
test procedures and request lists for Infrastructure Layer risk
category are provided below in Tables 8-10.
TABLE-US-00010 TABLE 8 Risk Level (L, Risk Risk M, H) (As Risk
Category Domain Classification Number Risk Description applicable)
Infrastructure Layer Servers and Strategic, IL-SD1 Lack of guidance
and policy of L, M, H Databases Operational, functional
requirements and Configuration Financial, migration to production
may lead Compliance, to inaccurate Blockchain logic. Legal, or
Reputational Infrastructure Layer Servers and Strategic, IL-SD2
Lack of an established baseline L, M, H Databases Operational, for
information technology Configuration Financial, systems and
Blockchain may Compliance, affect operational environments Legal,
or and compromise security. Reputational Infrastructure Layer ITGCs
Strategic, IL-IT1 Unauthorized or untested L, M, H Operational,
changes, or the failure to make Financial, necessary changes to
operating Compliance, system, network or application Legal, or
configurations or programs Reputational prevent systems from
processing transaction records completely and accurately
Infrastructure Layer ITGCs Strategic, IL-IT2 Lack of segregation
for roles L, M, H Operational, and responsibilities and instance
Financial, environments may lead to Compliance, unauthorized
changes to Legal, or productions. Reputational Infrastructure Layer
ITGCs Strategic, IL-IT3 Lack of segregation for roles L, M, H
Operational, and responsibilities and instance Financial,
environments may lead to Compliance, unauthorized changes to Legal
or productions. Reputational Infrastructure Layer ITGCs Strategic,
IL-IT4 Transaction records are lost L, M, H Operational, (e.g. due
to system failure) Financial, and data is not recoverable or
Compliance, is corrupted/duplicated in the Legal, or recovery
process Reputational Infrastructure Layer ITGCs Strategic, IL-IT5
Transaction records transferred L, M, H Operational, between
systems are incomplete Financial, or inaccurate. Compliance, Legal,
or Reputational Infrastructure Layer ITGCs Strategic, IL-IT6 As
business processes are L, M, H Operational, redesigned and modified
to reflect Financial, use of Blockchain technology, Compliance,
they embed an agreed set of Legal, or appropriate controls
Reputational Infrastructure Layer ITGCs Strategic, IL-IT7
Application end-users bypass L, M, H Operational, systems-enforced
authorization Financial, and segregation of duties controls
Compliance, Legal, or Reputational Infrastructure Layer ITGCs
Strategic, IL-IT8 Application end-users bypass L, M, H Operational,
systems-enforced authorization Financial, and segregation of duties
controls Compliance, Legal, or Reputational Infrastructure Layer
ITGCs Strategic, IL-IT9 High-risk/powerful accounts L, M, H
Operational, (e.g., super-user, etc.) bypass Financial,
systems-enforced authorization Compliance, and segregation of
duties Legal, or controls Reputational Infrastructure Layer ITGCs
Strategic, IL-IT10 Unauthorized access to facilities, L, M, H
Operational, equipment and resources is not Financial, prevented
Compliance, Legal, or Reputational Infrastructure Layer ITGCs
Strategic, IL-IT11 Unauthorized access (by L, M, H Operational,
business users, IT users or Financial, outsiders) to data causes
data Compliance, destruction or improper Legal, or amendment of
records. Reputational Infrastructure Layer ITGCs Strategic, IL-IT12
Unauthorized access (by L, M, H Operational, business users, IT
users or Financial, outsiders) to data causes data Compliance,
destruction or improper Legal, or amendment of records.
Reputational Infrastructure Layer ITGCs Strategic, IL-IT13 Duties
are not appropriately L, M, H Operational, segregated Financial,
Compliance, Legal, or Reputational Infrastructure Layer ITGCs
Strategic, IL-IT14 Weak password controls or L, M, H Operational,
security configurations allow Financial, access rights to be
circumvented Compliance, Legal, or Reputational Infrastructure
Layer ITGCs Strategic, IL-IT15 Unauthorized access (by L, M, H
Operational, business users, IT Financial, users or outsiders) to
Compliance, Blockchain Operational Legal, or governance tools.
Reputational Infrastructure Layer ITGCs Strategic, IL-IT16
Unauthorized or untested L, M, H Operational, changes, or failure
to make Financial, necessary changes to scheduled Compliance, job
processes prevent systems Legal, or from processing transaction
Reputational records completely and accurately Infrastructure Layer
ITGCs Strategic, IL-IT17 Unauthorized or untested L, M, H
Operational, changes, or failure to make Financial, necessary
changes to scheduled Compliance, job processes prevent systems
Legal, or from processing transaction Reputational records
completely and accurately Infrastructure Layer ITGCs Strategic,
IL-IT18 Blockchain processing errors L, M, H Operational, are not
resolved. Financial, Compliance, Legal, or Reputational
Infrastructure Layer ITGCs Strategic, IL-IT19 Unauthorized access
to the L, M, H Operational, Blockchain technology (i.e. Financial,
code configuration tools) is Compliance, prevented. Legal, or
Reputational Infrastructure Layer ITGCs Strategic, IL-IT20
Management release L, M, H Operational, management policies and
Financial, procedures include processes Compliance, for making
emergency Legal, or configuration changes, including Reputational
formal review processes for all changes categorized as emergency.
Infrastructure Layer ITGCs Strategic, IL-IT21 Unauthorized or
untested L, M, H Operational, changes, or failure to make
Financial, necessary changes to scheduled Compliance, job processes
prevent systems Legal, or from processing transaction Reputational
records completely and accurately Infrastructure Layer Business
Strategic, IL-BC1 A lack of backups or ineffective L, M, H
Continuity and Operational, backups may lead to information
Disaster Financial, loss. Recovery Compliance, Legal, or
Reputational Infrastructure Layer Business Strategic, IL-BC2 Lack
of Business Continuity L, M, H Continuity and Operational, and
Disaster Recovery plans Disaster Financial, may inhibit the
organization's Recovery Compliance, ability to recover from an
outage. Legal, or Reputational Infrastructure Layer Business
Strategic, IL-BC3 A lack of backups or ineffective L, M, H
Continuity and Operational, backups may lead to information
Disaster Financial, loss. Recovery Compliance, Legal, or
Reputational Infrastructure Layer Business Strategic, IL-BC4 Lack
of Business Continuity L, M, H Continuity and Operational, and
Disaster Recovery plans Disaster Financial, may inhibit the
organization's Recovery Compliance, ability to recover from an
Legal, or outage. Reputational Infrastructure Layer Business
Strategic, IL-BC5 A lack of Business Continuity L, M, H Continuity
and Operational, plan and Disaster Recovery plan Disaster
Financial, testing may result in an effective Recovery Compliance,
or failed recovery process. Legal, or Reputational Infrastructure
Layer Business Strategic, IL-BC6 Lack of communication to key L, M,
H Continuity and Operational, stakeholders regarding their Disaster
Financial, responsibilities may result in Recovery Compliance,
ineffective recovery activities in Legal, or the event of an
outage. Reputational Infrastructure Layer IT Asset Strategic,
IL-IT1 Without clearly defined roles L, M, H Management
Operational, and responsibilities with Financial, Blockchain
vendors, Compliance, accountability is lost when Legal, or issues
arise within Reputational the relationship Infrastructure Layer IT
Asset Strategic, IL-IT2 Without clearly defined roles L, M, H
Management Operational, and responsibilities with Financial,
Blockchain vendors, Compliance, accountability is lost when Legal,
or issues arise within the Reputational relationship Infrastructure
Layer IT Asset Strategic, IL-IT3 Without a comprehensive due L, M,
H Management Operational, diligence process, vendor risks
Financial, may not be completely identified, Compliance, leaving
the organization Legal, or susceptible to direct and indirect
Reputational risks. Infrastructure Layer IT Asset Strategic, IT-IL4
Without clearly defined roles L, M, H Management Operational, and
responsibilities with Financial, Blockchain vendors, Compliance,
accountability is lost when Legal, or issues arise within the
Reputational relationship Infrastructure Layer IT Asset Strategic,
IL-IT5 Lack of required level of L, M, H Management Operational,
throughput and performance Financial, can compromise Blockchain
Compliance, use cases objectives. Legal, or Reputational
Infrastructure Layer IT Asset Strategic, IL-IF1 Data exchanged
through APIs, L, M, F Management Operational, system interfaces may
be Financial, intercepted and accessed by Compliance, unauthorized
agents within or Legal, or outside the organization's Reputational
network
TABLE-US-00011 TABLE 9 In-scope/Out- of-Scope (TBD-As per Risk
Category Domain Control/Test Objective Control Description
engagement) Infrastructure Servers and References to internal and
external Once the Blockchain has been In-scope Layer Databases
sources (including interaction with configured, a test plan is
Configuration external platforms, systems, developed to ensure
meeting networks, and third parties) in the all functional
requirements Blockchain logic are accurate. and approved by the
Blockchain program management. The Blockchain configurations are
tested by the impacted/required business and/or the Blockchain
program management team. Test exceptions are appropriately
recorded, monitored and tracked for resolution prior to migration
to production Infrastructure Servers and A baseline configuration
of A configuration management In-scope Layer Databases information
technology systems program and database exists Configuration and
Blockchain is created, to implement, maintain and implemented,
control configuration of and maintained systems and other
infrastructure elements. Infrastructure ITGCs Change Management
controls are Changes to Blockchain In-scope Layer defined,
established, and enforced Application and Operating including
proper documentation System/Network and approval configurations and
enhancements are adequately tested and approved before being
migrated into production and are monitored for appropriateness.
Infrastructure ITGCs Segregation of Duties is maintained Access to
migrate the In-scope Layer and enforced for any changes, in
Blockchain process addition the development, test, and
configurations into production production environments are is
restricted to personnel who separated. are independent of the
configuration team. Development, testing, and production
environments are segregated for changes to application
configurations and periodically reviewed to ensure access is
restricted to authorized personnel. Infrastructure ITGCs
Segregation of Duties is maintained Policies are maintained for
In-scope Layer and enforced for any changes. segregation of duties
within IT Infrastructure ITGCs Backups of information are Data is
appropriately backed In-scope Layer conducted, maintained, and
tested up and recoverable periodically. Infrastructure ITGCs
Information input and output Errors in production In-scope Layer
checks are performed. processing are identified and resolved
Infrastructure ITGCs Change Management controls are For each new
Blockchain In-scope Layer defined, established, and enforced
business process the including proper documentation associated
controls are and approval, documented and approved by the business
and the Blockchain program management. Infrastructure ITGCs Access
permissions are revoked Terminated employee's/third In-scope Layer
based upon access reviews and/or party or employee's/third user
terminations. party access no longer needed to Blockchain,
database, and operating system/network is disabled and/or removed
in a (timely manner). Infrastructure ITGCs Access to systems and
assets is Access requests to the In-scope Layer controlled by
incorporating the application, database, and principle of least
privilege. operating system/network are properly reviewed and
authorized by management Infrastructure ITGCs Privileged user roles
and Super-user/administrative In-scope Layer responsibilities are
managed and application, database, and tracked. operating
system/network transactions or activities and sensitive generic IDs
are monitored Infrastructure ITGCs Physical access controls are in
place Employees', contractors', and In-scope Layer to properly
authorize employees, visitors' access to data contractors, and
visitors to facilities, center/facility and the equipment and
resources, information system components located within the
facility is provided on a `need to know` basis and requires
organizational approval. Infrastructure ITGCs Physical access to
the secure areas There is physical security in In-scope Layer are
monitored. place over the data center from which financially
significant applications are run. Key card system is implemented in
the data center for access control. And video surveillance is also
in place to monitor the activities in the data center. The key card
system logs the visit to the data center per user and ID card. If
any incident happens, IT department will look into the system log
and video footage for investigation. Infrastructure ITGCs Access
permissions are reviewed Data Center Operations In-scope Layer
periodically for appropriateness. performs a semi-annual
recertification of all users with physical access to Data Centers
Infrastructure ITGCs Segregation of Duties is maintained Policies
and procedures are In-scope Layer and enforced for critical
business maintained for segregation of processes and in production
duties within IT environments. Infrastructure ITGCs Access to
applications, database, Passwords to applications, In-scope Layer
operating system and network is database/data file, operating
password protected on a global system/network, and security level
and complies with configurations are set in an documented policies
or working effective manner practices detailing password
configurations and configurable security parameters. Infrastructure
ITGCs Access to the Blockchain Access to the Blockchain In-scope
Layer Operational governance tools is operational governance tools
restricted to appropriate personnel. is recertified by appropriate
management at regular intervals as defined by policy guidelines.
The approver confirms access remains commensurate with the
individual's job responsibilities or requests changes/revocation to
access. Infrastructure ITGCs As changes to the Blockchain are The
Blockchain policies and In-scope Layer contemplated, appropriate
controls procedures on change are in place to ensure that they are
approval and propagation approved and rolled out across the across
the network are defined network in a manner consistent and include
a description of with the Blockchain governance key controls,
oversight and framework. escalation procedures. Infrastructure
ITGCs As changes to the Blockchain are Only approved and tested
In-scope Layer contemplated, appropriate controls changes are made
to the job are in place to ensure that they are scheduler and
rolled out approved and rolled out across the across the network in
a network in a manner consistent manner consistent with the with
the Blockchain governance Blockchain governance framework.
framework. Infrastructure ITGCs Formal policies and procedures The
Blockchain management In-scope Layer have been established to
identify has a documented problem the Blockchain processing errors.
management process for the Blockchain configurations during which
errors or exceptions are identified, tracked, escalated, root
causes identified and resolved. Infrastructure ITGCs Access
permissions are revoked Access to the Blockchain In-scope Layer
based upon access reviews and/or configuration tools is user
terminations, recertified by appropriate management at regular
intervals as defined by policy guidelines. The approver confirms
access remains commensurate with the individual's job
responsibilities or requests changes/revocation to access.
Infrastructure ITGCs Change Management controls are The formal
policies and In-scope Layer defined, established and enforced
procedures include detailed including proper documentation
processes and required and approval approvals necessary to make an
emergency change to the Blockchain configuration. A formal review
is conducted for all emergency changes to ensure proper protocol
and SODs were followed. Infrastructure ITGCs Consideration of
Blockchain has Prior to a Blockchain change In-scope Layer been
incorporated into ongoing being placed into production, business
operations procedures, operations policies and forms and processes.
procedures have been updated to include integration with Blockchain
to ensure the business end users are aware of the Blockchain
impact. Infrastructure Business Upon identified of a processing
Back out plans for Blockchain In-scope Layer Continuity and error,
management enables back configuration and plan to roll Disaster
Recovery out/back up plan including the over to human processors in
Blockchain being removed from case of a Blockchain failure
production. are formally documented for each Blockchain
configuration and routinely reviewed to ensure still complete and
accurate Infrastructure Business IT disaster recovery and business
Disaster recovery plan for the In-scope Layer Continuity and
continuity plans have been Blockchain technology exists Disaster
Recovery developed based on the framework for prolonged outages
(with and designed to reduce the impact internal systems or 3rd
party of a major disruption on the vendors) and has been tested
Blockchain functions and processes. to limit impact business The
plans are based on risk operations. understanding of potential
business impacts and address requirements for resilience,
alternative processing and recovery capability of all critical IT
services including the Blockchain use case. The plan is tested on a
semi-annual basis. Infrastructure Business Backups of information
are The Blockchain configuration In-scope Layer Continuity and
conducted, maintained, and tested tools and data is included in
Disaster Recovery semi-annually management standard backup
and recovely plan to ensure data is backed up within data centers
or the cloud and available if needed. Infrastructure Business IT
disaster recovery and business Risks to business continuity
In-scope Layer Continuity and continuity plans have been due to
prolonged outages Disaster Recovery developed based on the
framework (with internal systems or with and designed to reduce the
impact 3rd party vendor) have been of a major disruption on the
identified and procedures Blockchain Instance functions and have
been formally processes. The plans are based on documented to
mitigate any risk understanding of potential risks. business
impacts and address requirements for resilience, alternative
processing and recovely capability of all critical IT services
including the Blockchain use case. The plan is tested on a
semi-annual basis. Infrastructure Business Business Continuity and
Disaster Business Continuity and In-scope Layer Continuity and
Recovery plans are tested semi- Disaster Recovery plans are
Disaster Recovery annually to validate that the plans tested
semi-annually to verify meet the organizational the validity of
established and requirements. implemented information security
controls and to take appropriate corrective actions. Infrastructure
Business Recovery activities are Communication occurs to the
In-scope Layer Continuity and communicated to internal individuals
and teams Disaster Recovery stakeholders and executive and involved
in the recovery plan management teams prior to and to ensure key
stakeholders during declared outages. understand their
responsibilities in the event of an outage. Infrastructure IT Asset
The Blockchain vendors are The Blockchain vendors are In-scope
Layer Management monitored for compliance with monitored on an
ongoing contractual agreements. basis to ensure compliance with
contractual agreements. Infrastructure IT Asset Licensing
agreements are The Blockchain licensing In-scope Layer Management
monitored and renewed as needed. agreements are reviewed, tracked
and renewed as needed. Infrastructure IT Asset The Blockchain
program policies The Blockchain vendor In-scope Layer Management
and procedures, which includes selection was based on formal formal
the Blockchain vendor selection methodology and selection
methodology and detailed business standard contract templates and
requirements. requirements, are reviewed and approved on a periodic
basis. Infrastructure IT Asset The Blockchain program policies The
Blockchain vendor In-scope Layer Management and procedures, which
includes contracts clarifies resource The Blockchain contract
policies ownership and hardware including clarification of the
procurement requirements for Blockchain ownership, are client and
vendor. reviewed and approved on a periodic basis.
TABLE-US-00012 TABLE 10 Test Type (TBD- Risk Category Domain Test
Procedure (#) As per engagement) Request List (#) Infrastructure
Servers and 1. Inquire with the control owners to Inquiry,
Inspection, 1. Policies and procedures Layer Databases determine if
the organization and/or observation related to configuration
Configuration identifies and documents established settings,
specifically regarding configuration settings. Review the test plan
of all functional existing documentation around test requirements
for configuration. exceptions to ensure the test plans 2. Log of
test exceptions. identifies all functional requirements. 2. Verify
the test exceptions are recorded, monitored and tracked for
resolution prior to migration to production Infrastructure Servers
and 1. Verify whether a configuration Inquiry, Inspection, 1.
Policies, procedures, related Layer Databases management program is
documented and/or observation to the baseline configuration
Configuration and maintained settings on production
infrastructures. Infrastructure ITGCs 1. Inquire with the control
owner and Inquiry, Inspection, 1. Change Management Layer determine
that the organization has a and/or observation policies,
procedures, and documented Change Management standards Process and
it is reviewed at least 2. Evidence of the last review annually and
updated as needed. of documented Change 2. Obtain a list of changes
that were Management Process. migrated to production for the
testing 3. Population of changes for period. the applications and
systems 3. Select a sample of changes made to 4. Evidence of change
requests the production environment and and approvals determine if
it was documented, tested prior to migration to production, and
approved by the appropriate personnel. 4. Inspect that appropriate
SOD is implemented for roles and environments. Infrastructure ITGCs
1. Inquire with control owners to Inquiry, Inspection, 1.
Screen-prints for each of the Layer determine that the development/
and/or observation following environments: testing environments are
separate development from the production environment. testing 2.
Obtain and inspect screen-prints of production the development,
testing, and 2. Evidence of access control production environment
to determine settings to enforce separation that they are in
different between development/testing environments. and production
environments. Infrastructure ITGCs 1. Determine through interviews
with Inquiry, Inspection, 1. Evidence of segregation of Layer
control owners whether access and/or observation duties in place
for each in- controls are defined, documented, scope information
system. approved and enforced for changes to information systems.
Infrastructure ITGCs 1. Inspect relevant backup Inquiry,
Inspection, 1. Backup policies and Layer documentation and inquire
with the and/or observation procedures control to validate whether
the 2. Screenshot of backup following considerations have been
configuration settings determined, documented, and 3. Backup log
showing status implemented. of backups 2. Inspect the backup
confirmation 4. Evidence of successful settings and frequency to
determine backup restoration whether it is in accordance with 5.
Reports detailing testing policies and procedures. efforts and the
results of the 3. Review activity logs for backups to testing
efforts determine the completeness of the 6. Evidence of backup
organizations backup efforts. schedule 4. Review activity logs for
backups to determine if an alert is configured to notify
administrators of successful and failed backups. 5. Review
detailing testing efforts and the results of the testing efforts.
Infrastructure ITGCs 1. Inquire with management to Inquiry,
Inspection, 1. Provide the input validation Layer determine if the
production systems and/or observation rules/configuration on the
and applications have built in production systems and detective
alerts if an invalid input is applications. received and an error
message is generated. 2. Inspect the input validation rules and
program logic on the production systems and applications to
determine if input validation checks are appropriately configured
to validated information entered into a data field. Infrastructure
ITGCs 1. Inquire with control owners to Inquiry, Inspection, 1.
Blockchain use case risk and Layer determine the review and
approval and/or observation control matrix with approval process
for additional controls from a redesign. 2. Review an updated risk
and control matrix and inspect for evidence of approval
Infrastructure ITGCs 1. Inquire with control owners to Inquiry,
Inspection, 1. Information Security Policy Layer determine whether
the organization and/or observation of Access revokes user account
access in Provisioning/Deprovisioning response to terminations.
Policy 2. Obtain and inspect policies and 2. Population of total
procedures to determine the terminated users requirements are
clearly stated for the 3. Evidence that access is removal of
logical access as a result revoked within the timeframe of
terminations. specified by the access control 3. Select a sample of
terminated users procedures and inspect the evidence to determine
that access is revoked within the timeframe specified by the access
control procedures. Infrastructure ITGCs 1. Inquire with control
owners to Inquiry, Inspection, 1. Information Security Policy Layer
determine the review and approval and/or observation of Access
process for access requests. Provisioning/Deprovisioning 2. Obtain
the population of access Policy requests and inspect the evidence
to 2. User access requests determine that access is properly 3.
Evidence that access is reviewed and approved by reviewed and
approved by management. management Infrastructure ITGCs 1. Inquire
with control owners who is Inquiry, Inspection, 1. Information
Security Policy Layer responsible for assigning access to and/or
observation of Access verify that access to privileged user
Provisioning/Deprovisioning IDs are appropriate and restricted.
Policy 2. Obtain and inspect documentation 2. Population of users
with to determine that privileged access privileged access requests
are evaluated for 3. Evidence for selected appropriateness and
follow the samples, indicating the job principles of least
privilege. function(s) or role(s) 3. Obtain a population of users
with requested, as well as the privileged access and select a
sample approval for the access of users and inspect evidence to
requested. determine the access is necessary and 4. List of
privileged user approved by the designated authority. accounts and
associated roles. 5. Access approval matrix Infrastructure ITGCs 1.
Inquire with management and Inquiry, Inspection, 1. Physical access
policies and Layer inspect the documented process to and/or
observation procedures determine if procedures are defined 2.
Populationof new users for authorizing and granting physical 3.
Access lists to in-scope access to employees, contractors, and
facilities and equipment visitors based on role or function. 2.
Obtain a population of new users who have been granted access to
the in-scope facilities and equipment. 3. Select a sample of new
users and inspect that physical access was authorized and
documented prior to physical access granted. Infrastructure ITGCs
1. Inquire with management the key Inquiry, Inspection, 1. Key card
system Layer card system implementation process. and/or observation
implementation policy 2. Inquire/Observe with management 2. Key
card system access list that video surveillance is in place at 3.
Key card system logs to the the data centers. data centers 3.
Obtain the key card system logs to the data centers. 4. Select a
sample of users granted access to the data center and inspect that
key card access was authorized and documented prior to physical
access granted. Infrastructure ITGCs 1. Obtain the key card system
log to Inquiry, Inspection, 1. Key card system logs to the Layer
the data center operations and select a and/or observation data
center operations sample of users to inspect the 2. Evidence of
recertifications recertification occurs on a semi- for users with
physical access annual basis. Infrastructure ITGCs 1. Determine
through interviews with Inquiry, Inspection, 1. Evidence of
segregation of Layer control owners whether access and/or
observation duties in place for each in- controls are defined,
documented, scope information system. approved and enforced for
changes to information systems and critical business processes.
Infrastructure ITGCs 1. Examine the documentation and Inquiry,
Inspection, 1. Screenshots of password Layer security parameters to
verify they are and/or observation configurations aligned 2.
Password policy Infrastructure ITGCs 1. Inquire with control owner
and Inquiry, Inspection, 1. Information Security Policy Layer
determine that the organization has a and/or observation of Access
documented recertification policy and Provisioning/Deprovisioning
it is reviewed at least annually and Policy updated as necessary.
2. Evidence of recertifications 2. Select a sample of
recertifications for the Blockchain Operational for the Blockchain
Operational governance tools governance tools over the testing 3.
Evidence of users job period and inspect the evidence to function
and role determine the appropriate personnel confirmed the access
and the access based on the job function and role is appropriate.
Infrastructure ITGCs 1. Inquire with control owner and Inquiry,
Inspection, 1. Change Management Policy Layer determine that the
organization has a and/or observation inclusive of Blockchain
documented Blockchain change policies approval policy and procedure
and 2. If available, Blockchain inspect it includes key controls,
policy oversight and escalation procedures. Infrastructure ITGCs 1.
Inquire with control owner and Inquiry, Inspection, 1. Blockchain
Governance Layer determine that the organization has a and/or
observation Framework documented Blockchain governance 2. Evidence
of approved framework. changes 2. Select a sample of approved 3.
Job Scheduler changes and inspect the appropriate personnel
approved the change and it was tested in accordance with the
Blockchain governance framework. Infrastructure ITGCs 1. Inquire
with control owner and Inquiry, Inspection, 1. Problem Management
Layer determine that the organization has a and/or observation
Process for Blockchain documented problem management Configurations
process for Blockchain 2. Blockchain Configurations Configurations.
error or exceptions log 2. Select a sample of errors or exceptions
and inspect the evidence to ensure they were tracked, escalated,
root causes identified and resolved. Infrastructure ITGCs 1.
Inquire with control owner and Inquiry, Inspection, 1. Information
Security Policy Layer determine that the organization has a and/or
observation of Access documented recertification policy and
Provisioning/Deprovisioning it is reviewed at least annually and
Policy updated as necessary. 2. Evidence of recertifications 2.
Select a sample of recertifications for the Blockchain for the
Blockchain configuration tools configuration tools over the testing
period and inspect the 3. Evidence of users job evidence to
determine the appropriate function and role personnel confirmed the
access and the access based on the job function
and role is appropriate. Infrastructure ITGCs 1. Inquire with
control owner to Inquiry, Inspection, 1. Change Management Layer
determine if a Change Management and/or observation policies,
procedures, and policy exists and it is updated as standards
needed. 2. Evidence of the last review 2. Inspect the policy to
ensure of documented Change emergency changes to Blockchain
Management Process. configuration is included. 3. Population of
emergency 3. Select a sample of emergency changes for the
applications changes to Blockchain configurations and systems and
inspect the evidence to ensure 4. Evidence of emergency policies
were followed and the change and approvals appropriate personnel
approved the change. Infrastructure ITGCs 1. Inquire with control
owner to Inquiry, Inspection, 1. Blockchain Operations Layer
determine if a Blockchain Operations and/or observation policy and
procedures policy exists and it is updated as 2. Evidence of a
Blockchain needed. change 2. Inspect the evidence of a Blockchain
change to ensure the policies and procedures have been updated to
include the updated integration Infrastructure Business 1. Inquire
with the control owner to Inquiry, Inspection, 1. Back out plan
Layer Continuity determine if a formal Blockchain and/or
observation 2. Blockchain and Disaster failure plan exists. failure
plan Recovery 2. Obtain the most recent version of 3. Business
Continuity plan business continuity and disaster recovery plans and
verify a back out plan is included for Blockchain. Infrastructure
Business 1. Inquire with the control owner to Inquiry, Inspection,
1. Business Continuity and Layer Continuity determine if a formal
business and/or observation Disaster Recovery plan and Disaster
continuity and disaster recovery 2. Evidence of the organization
Recovery management program exists (i.e., conducting tests of
outages and governance, resources, plans) documenting the results.
2. Obtain the most recent version of business continuity and
disaster recovery plans and verify whether it has been approved by
a Senior Management executive and includes the following: Business
continuity objectives Business processes and critical information
assets in scope Information security continuity Business impact
analysis Recovery objectives and priorities, including Recovery
Time Objectives (RTO) and Recovery Point Objectives (RPO) Roles and
responsibilities Dependencies and critical functions for delivery
of critical services 3. Inquire with the control owner to determine
whether the business continuity and disaster recovery plans have
been communicated and shared with stakeholders with associated
responsibilities. 4. Inquire with control owner to determine how
often the business continuity and disaster recovery plans are
tested and how they document the results of the test.
Infrastructure Business 1. Verify the standard backup and Inquiry,
Inspection, 1. Standard backup and Layer Continuity recovery plan
includes a section and/or observation recovery plan and Disaster
regarding Blockchain configuration 2. Agreements for the data
Recovery tools and data. center or cloud if applicable 2. Inspect
the agreements with the data center or cloud providers to determine
whether they exist and cover the current period. Infrastructure
Business 1. Inquire with control owner and Inquiry, Inspection, 1.
Business Continuity and Layer Continuity inspect evidence to
determine and/or observation Disaster Recovery plan and Disaster
whether the risks identified and 2. Evidence of risks identified
Recovery documented have been mitigated within the business
continuity and disaster recovery plan. Infrastructure Business 1.
Inquire with control owner and Inquiry, Inspection, 1. Business
continuity and Layer Continuity inspect evidence to determine
and/or observation disaster recovery plan testing and Disaster
whether the business continuity and report. Recovery disaster
recovery plans are tested on a 2. Evidence that corrective
semi-annually basis, if test results are actions are taken if
necessary. reviewed and corrective actions are taken if necessary.
Infrastructure Business 1. Inquire with control owner to Inquiry,
Inspection, 1. Information Security Layer Continuity determine
whether communication and/or observation policies and procedures
and Disaster occurs to the individuals and teams 2. Business
Continuity Recovery involved in the recovery processes so
Management Policy that key stakeholders understand their 3.
Technology Operations responsibilities in the event of a Disaster
Recovery Plan disaster. Infrastructure IT Asset 1. Inspect a sample
of vendors and Inquiry, Inspection, 1. Vendor contracts Layer
Management validate that the vendor contracts are and/or
observation 2. Population of vendors monitored periodically.
Infrastructure IT Asset 1. Inspect a sample of vendors and Inquiry,
Inspection, 1. Vendor licensing Layer Management validate that the
vendor licensing and/or observation agreements agreements are
monitored 2. Population of vendors periodically and renewed as
needed. 3. Log of tracking vendor licensing agreements
Infrastructure IT Asset 1. Inquire with the control owner and
Inquiry, Inspection, 1. Vendor management policy Layer Management
determine if a vendor management and/or observation and procedure
policy exists. 2. Vendor contracts 2. Inspect a sample of
agreements and 3. Population of new vendors validate that the
policy and for the testing period procedures were reviewed and
approved on a periodic basis. 3. Verify each Blockchain vendor
includes the standard contract, templates and requirements that are
aligned with the vendor selection Infrastructure IT Asset 1.
Inquire with the control owner and Inquiry, Inspection, 1. Vendor
management policy Layer Management determine if all relevant
information and/or observation and procedure security requirements
are established 2. Vendor contracts and agreed with each
supplier/vendor 3. Population of new vendors that may access,
process, store, for the testing period communicate, or provide IT
infrastructure components for, the organizations information. 2.
Inspect a sample of agreements and validate they include resource
ownership, hardware procurement requirements, and Blockchain
ownership.
4.4 Architecture Layer Assessment Work Program
[0146] In some embodiments, blockchain architecture layer risk
category in the blockchain risk framework covers relevant risks,
control objectives and descriptions, testing objectives and
procedures, and reporting parameters designed to address assurance
and compliance needs for the blockchain architecture stack/layer
supporting blockchain permissioned and/or permissioned networks
operations and participant lifecycle management.
[0147] The sub-risk categories, control and testing objectives,
test procedures and request lists for Architecture Layer risk
category are provided below in Tables 11-13.
TABLE-US-00013 TABLE 11 Risk Level Risk Risk (L, M, H) Risk
Category Domain Classification Number Risk Description (As
applicable) Architecture Layer Blockchain Strategic, AL-BP1 Lack of
an established baseline for L, M, H Platform & Operational,
Blockchain systems may affect Protocol Financial, operational
environments and Configuration Compliance, compromise security.
Legal, or Reputational Architecture Layer Blockchain Strategic,
AL-BP2 If hardening standards have not been L, M, H Platform &
Operational, developed, defined, or implemented. Protocol
Financial, Blockchain systems are unprotected Configuration
Compliance, and vulnerable to malicious attacks. Legal, or
Reputational Architecture Layer Blockchain Strategic, AL-BP3
Inadequate processes in the design L, M, H Platform &
Operational, phase of the Blockchain Protocol Financial,
implementation may negatively Configuration Compliance, impact core
system performance. Legal, or Reputational Architecture Layer
Blockchain Strategic, AL-BP4 Lack of configuration standards L, M,
H Platform & Operational, and/or lack of adherence to Protocol
Financial, established configuration standards Configuration
Compliance, may lead to failures or inefficiencies Legal, or in the
Blockchain production Reputational environment. Architecture Layer
Blockchain Strategic, AL-BP5 Lack of configuration standards L, M,
H Platform & Operational, and/or lack of adherence to Protocol
Financial, established configuration standards Configuration
Compliance, may lead to failures or inefficiencies Legal, or in the
Blockchain production Reputational environment. Architecture Layer
Blockchain Strategic, AL-BP7 Insufficient test plans lead to the L,
M, H Platform & Operational, inability to meet the requirements
Protocol Financial, identified in the analysis and design
Configuration Compliance, phase. Legal, or Reputational
Architecture Layer Blockchain Strategic, AL-BP8 Insufficient test
plans lead to the L, M, H Platform & Operational, inability to
meet the requirements Protocol Financial, identified in the
analysis and design Configuration Compliance, phase. Legal, or
Reputational Architecture Layer Hardware Security Strategic, AL-BP9
HSM devices are properly L, M, H Modules Operational, configured
and maintained Financial, which may expose the Blockchain use case
Compliance, supporting systems or sensitive data Legal, or to
unauthorized parties. Reputational Architecture Layer Signature
Strategic, AL-SM1 Lack of effective cryptographic keys L, M, H
Management Operational, management may expose the keys to
Financial, potential modification, loss, Compliance, destruction or
disclosure to Legal, or unauthorized parties. Reputational
Architecture Layer Signature Strategic, AL-SM2 Lack of effective
cryptographic keys L, M, H Management Operational, management may
expose the keys to Financial, potential modification, loss,
Compliance, destruction or disclosure to Legal, or unauthorized
parties. Reputational Architecture Layer Signature Strategic,
AL-SM3 Lack of effective cryptographic keys L, M, H Management
Operational, management may expose the keys to Financial, potential
modification, loss, Compliance, destruction or disclosure to Legal,
or unauthorized parties. Reputational Architecture Layer Signature
Strategic, AL-SM4 Lack of effective cryptographic keys L, M, H
Management Operational, management may expose the keys to
Financial, potential modification, loss, Compliance, destruction or
disclosure to Legal, or unauthorized parties. Reputational
Architecture Layer Cryptography Strategic, AL-C1 Inadequate
protection of information L, M, H Operational, in Blockchain
systems through Financial, cryptographic techniques and Compliance,
effective key management may Legal, or result in the potential
compromise of Reputational confidentiality or integrity of
information in transmission or storage. Architecture Layer
Cryptography Strategic, AL-C2 Inadequate protection of information
L, M, H Operational, in Blockchain systems through Financial,
cryptographic techniques and Compliance, effective key management
may Legal, or result in the potential compromise of Reputational
confidentiality or integrity of information in transmission or
storage. Architecture Layer Cryptography Strategic, AL-C3
Inadequate protection of information L, M, H Operational, in
Blockchain systems through Financial, cryptographic techniques and
Compliance, effective key management may Legal, or result in the
potential compromise of Reputational confidentiality or integrity
of information in transmission or storage. Architecture Layer
Cryptography Strategic, AL-C4 Inadequate protection of information
L, M, H Operational, in Blockchain systems through Financial,
cryptographic techniques and Compliance, effective key management
may Legal, or result in the potential compromise of Reputational
confidentiality or integrity of information in transmission or
storage. Architecture Layer Cryptography Strategic, AL-C5 Lack of
compliance may result in L, M, H Operational, ineffective controls
thereby Financial, heightening organization's security Compliance,
and compliance risks. Legal, or Reputational Architecture Layer
Scalability /Capacity Strategic, AL-SC1 System capacity is not
monitored L, M, H Management Operational, which may lead to
interruption Financial, and/or failure to key systems. Compliance,
Legal, or Reputational Architecture Layer Scalability/Capacity
Strategic, AL-SC2 Inadequate procedures to monitor L, M, H
Management Operational, the capacity and performance of IT
Financial, resources may lead to delivery Compliance, failure of
service performance Legal, or agreements. Reputational Architecture
Layer Scalability/Capacity Strategic, AL-SC3 Failure to define,
agree, record and L, M, H Management Operational, manage the levels
of service as Financial, required by the business may result
Compliance, in the agreed service continuity and Legal, or
availability commitment to Reputational customers not being met in
all circumstances. Architecture Layer Availability Strategic, AL-A1
Lack of redundant information L, M, H Operational, processing
facilities may lead to Financial, disruption of critical services
in the Compliance, event Blockchain information Legal, or
processing facilities are unavailable Reputational due to excess
capacity or other threats. Architecture Layer Encryption (EN)
Strategic, AL-EN01 Privileged access is not L, M, H Operational,
appropriately restricted, logged, and Financial, monitored for
unencrypted data, Compliance, which can lead to unauthorized Legal,
or access Reputational Architecture Layer Encryption (EN)
Strategic, AL-EN02 Data in transit is not secure and may L, M, H
Operational, be compromised or accessed by Financial, unauthorized
participants, Compliance, compromising the integrity of the Legal,
or data Reputational Architecture Layer Encryption (EN) Strategic,
AL-EN03 Data at rest or in storage is not L, M, H Operational,
secure and may be accessible by Financial, unauthorized
participants, Compliance, compromising the integrity of the Legal,
or data Reputational Architecture Layer Encryption (EN) Strategic,
AL-EN04 Databases lack encryption to protect L, M, H Operational,
and recover data in the case of loss Financial, or theft
Compliance, Legal, or Reputational Architecture Layer Encryption
(EN) Strategic, AL-EN05 Data is not retained for DLT inputs. L, M,
H Operational, PKIs, or other critical systems; lack Financial, of
availability limits backup and Compliance, recovery capability
Legal, or Reputational Architecture Layer Encryption (EN)
Strategic, AL-EN06 PKI Certificate Authority (CA) is L, M, H
Operational, insufficiently isolated from tire rest Financial, of
the network Compliance, Legal, or Reputational Architecture Layer
Encryption (EN) Strategic, AL-EN07 No PKI Certificate Authority
(CA) L, M, H Operational, is present in the organization's
Financial, network to validate data Compliance, transmission or
transactions on the Legal, or blockchain Reputational Architecture
Layer Key Management Strategic, AL-EN07 Lack of proper physical and
logical L, M, H Operational, custody of the keys (private and
Financial, public) can compromise a single or Compliance, multiple
users on the Blockchain. Legal, or Reputational Architecture Layer
Data Retention Strategic, AL-DR01 Data is not retained for DLT
inputs, L, M, H (DR) Operational, PKIs, or other critical systems;
lack Financial, of availability limits backup and Compliance,
recovery capability Legal, or Reputational Architecture Layer
Consensus (CS) Strategic, TL-CS01 No formal consensus protocol is
L, M, H Operational, established, system validators for Financial,
DLT entries lacks authentication Compliance, Legal, or Reputational
Architecture Layer Consensus (CS) Strategic, AL-CS02 Implementation
processes for L, M, H Operational, system coding related to
consensus Financial, have not been defined: no formal Compliance,
channel for change management Legal, or exists Reputational
Architecture Layer Consensus (CS) Strategic, AL-CS03 System
development and L, M, H Operational, management life cycle does not
Financial, exist or does not apply to Compliance, consensus system
architecture Legal, or Reputational Architecture Layer Consensus
(CS) Strategic, AL-CS04 The organization has no approvals L, M,
H
Operational, process for change management Financial, affecting
consensus or docs not Compliance, secure against improper approvals
Legal, or being issued Reputational Architecture Layer Consensus
(CS) Strategic, AL-CS05 There is no access review or audit L, M, H
Operational, mechanism for the consensus Financial, protocol or any
users, systems, or Compliance, participants affiliated with DLT
Legal, or validation Reputational Architecture Layer Consensus (CS)
Strategic, AL-BC1 Consensus mechanisms L, M, H Operational,
implemented do not provide comfort Financial, on the immutability
of the data Compliance, stored on the Blockchain. Legal, or
Reputational Architecture Layer Consensus (CS) Strategic, AL-BC2
Consensus mechanisms L, M, H Operational, implemented do not
provide comfort Financial, on the immutability of the data
Compliance, stored on the Blockchain. Legal, or Reputational
TABLE-US-00014 TABLE 12 In-scope/Out- Risk of-Scope (TBD- Category
Domain Control/Test Objective Control Description As per
engagement) Architecture Blockchain Platform & The organization
has created A configuration management In-scope Layer Protocol
Configuration a configuration management program and database
exists to database (CMDB) that implement, maintain and control
houses all Blockchain configuration of Blockchain systems and
infrastructure. systems and oilier infrastructure A baseline
configuration of elements (including hardware, the Blockchain
system is software, firmware, and created, implemented, and
documentation). The program maintained. requires the identification
of baseline configurations (original versions) of Blockchain
infrastructure elements (hardware, software etc.). A central
repository of configuration items (Cl), their attributes, and their
inter-linkages is established and maintained. CIs are linked to the
services that they support. Current and prior configuration for all
CIs, including Blockchain production servers, network devices, and
databases is captured and maintained in the central repositon. in
order to support rollback Architecture Blockchain Platform &
Blockchain systems Blockchain system configuration In-scope Layer
Protocol Configuration hardening standards arc and hardening
standards arc established and maintained. developed, communicated,
Blockchain system implemented and maintained. The configuration and
hardening standards followed address all standards are consistent
known security vulnerabilities and with industry-accepted are
consistent with industry- standards, vendor specific accepted
system hardening guidelines and address all standards and any
vendor specific known security guidelines vulnerabilities
Architecture Blockchain Platform & The Blockchain Instance The
Blockchain Instance process In-scope Layer Protocol Configuration
impact on core processing impact on core system system performance
has performance is documented and been determined and approved by
IT and the appropriately addressed as Blockchain Instance program
part of functional management. specification process Architecture
Blockchain Platform & Newly implemented the Once the Blockchain
Instance has In-scope Layer Protocol Configuration Blockchain
Instances are been configured, a test plan is configured to
completely or developed to ensure meeting all accurately process
data. functional requirements and The Blockchain Instances approved
by the Blockchain are configured to effectively Instance program
management. meet the business The Blockchain Instance requirements.
configurations are tested by the impacted/required business and/or
the Blockchain Instance program management team. Test exceptions
are appropriately recorded, monitored and tracked for resolution
prior to migration to production. Architecture Blockchain Platform
& Auditability of the The audit logging of the In-scope Layer
Protocol Configuration Blockchain Instance Blockchain Instance
software tool processing has been enabled has been enabled. The
ability to within the tool. change the audit capacities is
restricted to authorized personnel outside of the configuration
function. Architecture Blockchain Platform & Testing
architecture and Once the Blockchain Instance has In-scope Layer
Protocol Configuration requirements have been been configured, a
test plan is defined and documented. developed to ensure meeting
all Test plan including test functional requirements and cases and
procedures are approved by the Blockchain formally defined.
Instance program management. The Blockchain Instance configurations
are tested by the impacted/required business and/or the Blockchain
Instance program management team. Test exceptions are appropriately
recorded, monitored and tracked for resolution prior to migration
to production. Architecture Blockchain Platform & Technical
test environments The Blockchain Instance In-scope Layer Protocol
Configuration are stable and managed configuration testing take
place in properly. environments which are logically segregated from
and mirror the legacy system production environment. Architecture
Hardware Security HSM devices are properly HSM devices are
deployed, In-scope Layer modules configured and maintained properly
configured and which may expose the maintained to prevent the
Blockchain use case Blockchain use case supporting supporting
systems or systems or sensitive data exposure sensitive data to to
unauthorized parties unauthorized parties Architecture Signature
Management The integrity of the A formal key management system
In-scope Layer Blockchain cryptosystem is and associated processes
exist to maintained through the securely manage (i.e.. generate,
proper management of distribute, store, access, backup encryption
keys. Public and and destroy) secret/private keys private keys are
securely and public keys issued by trusted managed through formal
Certification Authorities. Formal management processes. procedures
are in place to protect keys used to secure stored cardholder data
against disclosure and misuse. Public key certificates are issued
per defined standards or from an approved service provider.
Architecture Signature Management The integrity of the 1. Examine
user access lists to In-scope Layer Blockchain cryptosystem is
verify that access to keys is maintained through the restricted to
the fewest number of proper management of custodians necessary
encryption keys. 2. Verify whether equipment used Cryptographic key
access to generate, store, and archive and storage is restricted
and keys are protected. controlled. Architecture Signature
Management The integrity of the Cryptographic keys are stored in
In-scope Layer Blockchain cryptosystem is the fewest locations
possible. maintained through the Secret mid private keys used to
proper management of encrypt/decrypt cardholder data encryption
keys. are stored in one (or more) of the Cryptographic keys arc
following forms at all times: securely stored. Encrypted with a
key-encrypting The integrity of the key that is at least as strong
as the Blockchain cryptosystem is data-encrypting key, and that is
maintained through the stored separately from the data- proper
management of encrypting key encryption keys. Within a secure
cryptographic device (such as a hardware (host) security module
(HSM) or PTS- approved point-of-interaction device) As at least two
full-length key components or key shares, in accordance with an
industry- accepted method Architecture Signature Management The
integrity of the Cryptographic keys are changed at In-scope Layer
Blockchain cryptosystem is the end of their cryptoperiod. as
maintained through the defined by the associated proper management
of application vendor or key owner, encryption keys. and based on
industry best Cryptographic key change practices and guidelines.
Keys arc management is followed in retired or replaced (for
example, accordance with best archiving, destruction, and/or
practices and guidelines. revocation) as deemed necessary when the
integrity of the key has been weakened (for example, departure of
an employee with knowledge of a clear-text key component), or keys
are suspected of being compromised. Architecture Cryptography
Control: Stored classified Classified data (e.g.. CUI, PHI.
In-scope Layer data are encrypted and CHD. PII) is stored in an
access controlled. encrypted format regardless of the Control
Objective: Data-at- medium (including mobile rest is protected
through devices). Access to the encryption cryptographic
techniques. keys is restricted to authorized personnel.
Architecture Cryptography Data-at-rest is protected Logical access
for disk encryption In-scope Layer through cryptographic is managed
separately and techniques. Disk encryption independently of native
operating managed independently of system authentication. the
native operating system authentication. Architecture Cryptography
Data-in-transit is protected Cryptographic techniques are used
In-scope Layer through cryptographic to protect the confidentiality
and techniques. Data integrity in integrity of data in
transmission. transmission protected with While transmitting
cardholder secure cryptography. data, the following measures are
implemented: Only trusted keys and certificates are accepted. The
protocol in use only supports secure versions or configurations.
The encryption strength is appropriate for the encryption
methodology in use. Architecture Cryptography Data-in-transit is
protected Secure messaging utilities and In-scope Layer through
cryptographic facilities are used to protect data in techniques.
Data is transmission. Electronic protected in transmission
messaging such as MQ Series, through secure messaging middleware,
system to system utilities and facilities. application calls, batch
processing, email. Electronic Data Interchange (EDI), and instant
messaging, has security provisions in place to protect messages
from unauthorized access, modification, and denial of service.
Architecture Cryptography Cryptographic controls Cryptographic
controls are used in In-scope Layer comply with relevant compliance
with all relevant agreements, legislation, and agreements,
legislation, and regulations. Cryptographic regulations.
FIPS-validated controls have been cryptography is leveraged to
established to comply with protect the confidentiality of CUI. all
business relevant If cryptography is required based agreements,
legislation, and on the selection of other security regulations.
controls, each type of cryptography required is clearly defined.
Architecture Cryptography System capacity is Real time monitoring
of system In-scope Layer monitored in real time to capacity is
performed to enable the meet availability implementation of
additional requirements. System capacity to help meet availability
capacity is monitored for commitments and requirements, operations
regarding and reports are made available for information processing
management review. facilities Architecture Scalabiltiy/Capacity
Adequate capacity is Availability requirements are In-scope Layer
Management maintained to prevent agreed upon with customers.
interruptions. System Availability, capacity, and capacity is
adequately performance baselines have been monitored to ensure
system established based on customer availability is maintained.
needs, business impact analysis, organizational policies etc.
Adequate capacity, performance, and availability is maintained to
prevent business disruptions, and to meet existing and changing
business needs. Architecture Scalabiltiy/Capacity Baselines are
monitored for Deviations from established In-scope Layer Management
deviations and are resolved availability, performance, and or
followed up. Maintain capacity baselines are monitored, service
availability, efficient reported, and resolved. After management of
resources, monitoring, measuring, analyzing, and optimization of
system reporting, and reviewing performance through availability,
performance, and prediction of future capacity deviations from
performance and capacity established baselines, all requirements.
outstanding issues are followed up. Architecture Availability
Blockchain production Blockchain production systems In-scope Layer
system availability is are monitored for availability and monitored
and incidents are any incidents are documented in a documented.
Technical ticketing system. capabilities exist to enable resiliency
of Blockchain information processing facilities in accordance with
availability objectives in the event of disruption.
TABLE-US-00015 TABLE 13 Test Type Risk (TBD-As per Category Domain
Test Procedure (#) engagement) Request List (#) Architecture
Blockchain 1. Inquire with the control owner to Inquiry, 1.
Policies, procedures, Layer Platform & determine whether a
configuration Inspection, and/or related to the Blockchain Protocol
management database (CMDB) that observation baseline configuration
Configuration includes Blockchain configuration settings on
production items (Cl) is maintained. infrastructures. 2. Verify
whether a configuration 2. Enterprise Blockchain management plan is
documented and production infrastructure maintained and includes
the following: configuration management Roles and responsibilities
plan. Process for identifying and managing CIs Definitions of CI
Interlinkages between CIs 3. Inspect the CMBD and determine for a
sample of systems, where the Blockchain baseline configuration is
maintained. Also, validate whether previous versions of the CIs and
corresponding documentation is archived and maintained to support
rollback. 4. Verify whether the CMDB is reviewed for accuracy and
consistency on a periodic basis. Verify whether the organization
reviews and updates the baseline configuration of the Blockchain
system on a periodic basis or upon any upgrades or installations.
Architecture Blockchain 1. Inquire with control owner to Inquiry,
1. Provide evidence of the Layer Platform & determine if the
organization: Inspection, and/or organization's documented Protocol
Establishes and documents observation change management
Configuration configuration settings for Blockchain methodology for
the technology products employed within production environment. the
information system using the 2. Provide evidence of appropriate
security configuration Blockchain Network baseline that reflect the
most restrictive Hardening Guidelines. mode consistent with
operational Production Network requirements: Security Standard, and
Implements the configuration settings; Change Management 2. Inquire
of the control owner and methodology. determine the Blockchain
system 3. Change Management configuration standards are consistent
methodology with industry-accepted configuration 4. Production
Network and hardening standards and are applied Security Standard.
when new systems are configured and 5. Blockchain verified as being
in place before a Infrastructure Hardening Blockchain system is
installed on the Guidelines. network. 3. Inspect the Network
Hardening Guidelines. Production Network Security Standard, and
Change Management methodology and determine if the organization has
documented and implemented a change management methodology for the
production environment to govern the Blockchain configuration
management process. Architecture Blockchain 1. Inquire with control
owner to Inquiry, 1. SDLC policies and Layer Platform & whether
an established system Inspection, and/or procedures. Protocol
development lifecycle process is in observation 2. Evidence that an
Configuration place, documented, maintained, and established system
applied for all Blockchain system and development lifecycle
software design, acquisition, process is in place, implementation,
configuration, documented, maintained integration, testing,
modification, and for the development or maintenance. installation
of Blockchain 2. Obtain and inspect SDLC policies systems. and
procedures to determine whether mi 3. Performance established
Blockchain system requirements for development lifecycle process is
Blockchain information documented. systems and information 3.
Verify whether an impact assessment services are identified. and
performance requirements for Blockchain information systems and
information services are identified as part of SDLC efforts,
business process re-design, etc. Architecture Blockchain 1. Obtain
Blockchain systems Inquiry, 1. Obtain Blockchain Layer Platform
& configurations. Inspection, and/or systems configurations.
Protocol 2. Assess configuration relative to observation
Configuration functional requirements. Architecture Blockchain 1.
Obtain Blockchain systems Inquiry, 1. Obtain Blockchain Layer
Platform & configurations. Inspection, and/or systems
configurations. Protocol 2. Assess Audit logging capabilities in
observation Configuration the Blockchain system relative to
internal guidelines and leading practices. Architecture Blockchain
1. Obtain Blockchain systems test plans Inquiry, 1. Obtain
Blockchain Layer Platform & and requirements. Inspection,
and/or systems executed test plans Protocol 2. Determine if the
test plans are observation and requirements. Configuration executed
as per requirements. Architecture Blockchain 1. Obtain information
including version Inquiry, 1. Obtain information Layer Platform
& numbers of the test and production Inspection, and/or
including version numbers Protocol environments for Blockchain
systems. observation of the test and production Configuration 2.
Determine if the testing takes place in environments for
environments which are logically Blockchain systems. segregated
from and mirror the legacy system production environment.
Architecture Hardware Security Determine if HSM device(s) are
Inquiry, 1. Obtain HSM information Layer Modules deployed, properly
configured and Inspection, and/or including vendor, maintained to
prevent the Blockchain observation configuration and leading use
case supporting systems or sensitive practices guidelines. data
exposure to unauthorized parties. Architecture Signature 1. Review
key management procedures Inquiry, 1. Encryption and Key Layer
Management and determine if they address secure Inspection, and/or
Management policies and generation, distribution, storage,
observation procedures. backup, and access management of 2. User
access list of keys. cryptographic key 2. Review key management
standards to custodians. determine key strength aligns with 3.
Information Security industry leading standards. policies and
procedures 3. Determine through interview with 4. Security Incident
control owner that formal roles and Response Process
responsibilities have been established 5. Audit and for management
keys. accountability policies. 4. Examine key-management policies
6. Procedures addressing and procedures to verify processes arc
non-repudiation. specified to protect keys against 7. Automated
mechanisms disclosure and misuse and include at configured with
non- least the following: repudiation capabilities. Access to keys
is restricted to the fewest number of custodians necessary.
Key-encrypting keys are at least as strong as the data encrypting
keys they protect. Key-encrypting keys are stored separately from
data encrypting keys. Keys are stored securely in the fewest
possible locations and forms. 5. Verify that key-management
procedures specify how to generate strong keys. 6. Observe the
method for generating keys to verify that strong keys are
generated. 7. Observe the method for distributing keys to verify
that keys are distributed securely. 8. Observe the method for
storing keys to verify that keys are stored securely. Architecture
Signature 1. Inquire about Key Management Inquiry, 1. Obtain Key
Management Layer Management process. Inspection, and/or policies
and procedure 2. Review the key Management process observation 2.
Test approval, SOD and and determine if appropriate level of
ownership activities for approval, SOD, and ownership Key
Management mechanisms are in place. 3. Test approval. SOD. and
ownership mechanisms to determine if the Key Management process is
safe, secure and docs not lack required level of integrity.
Architecture Signature 1. Examine key storage locations and
Inquiry, 1. Identify and assess key Layer Management observe
processes to verify that keys are Inspection, and/or storage
locations, stored in the fewest possible locations. observation
documented procedures, 2. Examine documented procedures to system
configurations. verify that cryptographic keys used to
encrypt/decrypt cardholder data must only exist in one (or more) of
the following forms at all times. Encrypted with a key-encrypting
key that is at least as strong as the data- encrypting key, and
that is stored separately from the data-encrypting key Within a
secure cryptographic device (such as a hardware (host) security
module (HSM) or PTS-approved point- of-interaction device) As key
components or key shares, in accordance with an industry-accepted
method 3. Examine system configurations and key storage locations
to verify that cryptographic keys used to encrypt/decrypt
cardholder data exist in one (or more) of the following form at all
times. Encrypted with a key-encrypting key Within a secure
cryptographic device (such as a hardware (host) security module
(HSM) or PTS-approved point- of-interaction device) As key
components or key shares, in accordance with an industry-accepted
method 4. Wherever key-encrypting keys are used, examine system
configurations and key storage locations to verify: Key-encrypting
keys are at least as strong as the data-encrypting keys they
protect Key-encrypting keys are stored separately from
data-encrypting keys. Architecture Signature 1. Verify that
key-management Inquiry, 1. Identify and assess Layer Management
procedures include a defined crypto Inspection, and/or encryption
mechanism for period for each key type in use and observation Key
Management define a process for key changes at the end of the
defined cryptoperiod (s) ( (for example, after a defined period of
time has passed and/or after a certain amount of cipher-text has
been produced by a given key) 2. Interview personnel to verify that
keys are changed at the end of the defined cryptoperiod(s). 3.
Verify that key-management procedures specify processes for the
following: The retirement or replacement of keys when tire
integrity of the key has been weakened The replacement of known or
suspected compromised keys. Any keys retained after retiring or
replacing are not used for encryption operations 4. Interview
personnel to verify the following processes are implemented: Keys
are retired or replaced as necessary when the integrity of the key
has been weakened, including when someone with knowledge of the key
leaves the company. Keys are replaced if known or suspected to be
compromised. Any keys retained after retiring or replacing are not
used for encryption operations. Architecture Cryptography 1.
Inquire with the control owner to Inquiry, 1. Information Security
Layer determine how classified data is Inspection, and/or Policies.
encrypted at rest in all formats observation 2. Data Classification
(databases, media, mobile devices, Policy removable storage, etc.)
and how access 3. Information Security to the encryption keys is
restricted to Policy for encryption authorized personnel in
accordance with requirements. encryption requirements. For data at
4. System generated list of rest, assess whether one of the
individuals with access to following is implemented: the encryption
keys with Full disk encryption: names and respective job Partial
encryption where the access title. control will only allow writing
to the 5. Configuration or encrypted partition. evidence showing
systems 2. Obtain and inspect the cryptographic components/backups
are controls policy to determine whether it encrypted using AES-256
aligns to industry standards. via FIPS 140-2 validated 3. Obtain a
system generated list of encryption individuals with access to the
6. Evidence indicating the encryption keys and determine whether
use of either full disk access is restricted to the authorized
encryption, or partial personnel. encryption with access 4. Inspect
that only approved hard drive controls to allow writing to
encryption software has been deployed the encrypted partition to
mobile devices and systems that hold sensitive data. Architecture
Cryptography 1. Inquire with the control owner to Inquiry, 1.
Provide the policies and Layer determine if disk encryption is used
Inspection, and/or procedures related to (rather than file or
column-level observation access management. database encryption).
2. Provide the 2. Inspect policies and procedures and
configurations for the in the configurations for the in scope scope
systems validating systems to ensure that logical access is that
logical access is managed separately and independently managed
separately and of native operating system independently of native
authentication and access control operating system mechanisms (for
example, by not using authentication and access local user account
databases or general control mechanisms. network login
credentials). 3. Evidence that decryption 3. Validate that
decryption keys are not keys are not associated associated with
user accounts. with user accounts. Architecture Cryptography 1.
Inquire with control owners to Inquiry, 1. Information Security
Layer determine that sensitive data is Inspection, and/or Policies
and procedures encrypted while being exchanged observation related
to Encryption. between systems within the network 2. Screenshots of
the and also when transmitted over public applicable encryption or
networks. network protection utility. 2. Identify all locations
where sensitive 3. TLS implementation data is transmitted or
received over system configurations. open, public networks. Examine
4. Security documented standards and compare to Implementation
Guide. system configurations to verify the use of security
protocols and strong cryptography for all locations. 3. Select and
observe a sample of inbound and outbound transmissions as they
occur (for example, by observing system processes or network
traffic) to verify that all sensitive data is encrypted with strong
cryptography during transit. Architecture Cryptography 1. Inspect
if the organization ensures Inquiry, 1. Evidence that secure Layer
that the transmission, movement, and Inspection, and/or messaging
utilities and removal of information is restricted to observation
facilities are used to protect authorized users and processes, and
is data in transmission. protected. Thus enabling the entity to 2.
Policies and procedures meet its commitments and requirements
related to the protection of as they relate to security.
availability, data-in-transit. processing integrity, or
confidentiality or any combination thereof. 2. For the electronic
messaging systems, provide screenshots and/or documentation that
controls have been implemented to address the following :
protecting messages from unauthorized access, modification or
denial of service, ensuring correct addressing and transportation
of the message, general reliability and availability of the
service, legal considerations, obtaining approval prior to using
external public services such as instant messaging or file sharing,
stronger levels of authentication controlling access from publicly
accessible networks. Architecture Cryptography 1. Inquire with
control owner to Inquiry, 1. Relevant agreements and Layer
determine whether cryptographic Inspection, and/or guidance for
applicable controls are used in compliance with observation
legislation and regulations relevant agreements, legislation, and
2. Policies and procedures regulations. related to encryption and
2. Obtain and inspect the Encryption, key management. and
Cryptographic Controls. Encryption and Key Management security
policies and procedures to determine that each type of cryptography
is defined. Determine whether the policies outline the following:
Tenant-specific encryption; Security requirements on cryptographic
keys; Use of standardized cryptographic methods; Use of
cryptographic keys. Architecture Scalability/Capacity 1. Inquire
with the control owner and Inquiry, 1. Provide Capacity Layer
Management determine if real time monitoring of Inspection, and/or
Planning report system capacity is performed and the observation 2.
Provide screenshots of dashboard report is available for monitoring
dashboards management review. 3. ISMS Statement of 2. Inspect the
capacity monitoring tools Applicability for a sample of production
and sandbox instances and determine if they arc monitored in real
time for. among others. CPU, API request time, web request time,
transaction processing time, and report request times. 3. Inspect
if monitoring dashboards are available for management review, for
individual instances and in aggregate, to enable real-time
monitoring and future capacity planning Architecture
Scalability/Capacity 1. Verify that there is a formally Inquiry, 1.
Audit and accountability Layer Management documented capacity plan
associated Inspection, and/or policies and procedures with critical
systems and infrastructure. observation addressing audit storage 2.
Inquire with the control owner to capacity determine whether
business continuity 2. Evidence showing objectives are considered
while storage capacity. developing capacity plans. 3. Review the
capacity plan and validate that: Required capacity is provided,
taking into account aspects such as normal workloads,
contingencies, storage requirements and IT resource life cycles;
Provisions such as prioritizing tasks, fault-tolerance mechanisms
and resource allocation practices are in place: Business
criticality of systems are taken into account while determining
capacity: Projections of future capacity requirements take into
account business strategy and plans. Architecture
Scalability/Capacity 1. Examine security policies and Inquiry, 1.
Security policies and Layer Management procedures to validate a
process to Inspection, and/or procedures detailing follow up on
availability, performance, observation process of remediating and
capacity baselines exists capacity deviations 2. Examine sample of
deviations from 2. Record of capacity availability, performance,
and capacity deviations and subsequent baselines and records which
indicate remediation actions taken appropriate actions were taken
to 3. Executive/Board address outstanding issues. reporting on
handled 3. Determine through inquiry and capacity management
inspection of reporting how follow up incidents. activities to
deviations are tracked, measured, and reported to executives or the
Board of Directors. Architecture Availability For in-scope
Blockchain production Inquiry, 1. System generated list of Layer
systems: Inspection, and/or incident tickets for the 1. Inquire
with the control owner and observation period under review (to be
determine whether production systems specified) with screenshot are
monitored for availability and of parameters used to capacity, and
any incidents arc generate the listing. documented in a ticketing
system. 2. Incident tickets for 2. Obtain a population of incident
selected sample. tickets, select a sample, and inspect the 3.
Incident dashboard for ticket details for the selected sample of
population of performance organization services incident tickets
incidents tickets for the from the workflow ticketing system and
period under review (to be determine whether the incident
specified). determine the incidents were assigned 4. Tickets for
the samples an impacted environment, impacted of high severity
account, subject and description, performance incidents incident
type, severity rating, and customer impacted and were resolved or
are being actively worked to resolution. 3. Inspect the
configurations within the monitoring tool for a sample of
production servers, selected from the inventory management system,
and determine whether the servers were configured to be monitored
for availability and capacity and notify personnel in the event an
issue was identified. 4. Obtain a population of incident tickets,
select a sample of high severity performance incident tickets, and
inspect the sample of incident tickets to determine the incidents
were assigned an impacted environment, impacted account, subject
and description, incident type, severity rating, and customer
impacted and were resolved or are being actively worked to
resolution.
[0148] In some embodiments, blockchain architecture layer risk
category in the blockchain risk framework covers relevant risks,
control objectives and descriptions, testing objectives and
procedures, and reporting parameters designed to address assurance
and compliance needs for the blockchain architecture stack/layer
supporting blockchain permissioned and/or permissioned networks
operations and participant lifecycle management.
[0149] The sub-risk categories, control and testing objectives,
test procedures and request lists for Operational Layer risk
category are provided below in Tables 14-16.
TABLE-US-00016 TABLE 14 Risk Level Risk Risk Risk (L, M, H)
Category Domain Classification Number Risk Description (As
applicable) Operational Layer Permissioned Strategic, OL-PN1 As the
Blockchain is L, M, H Network Operational, implemented, the nature
of the Management Financial, instance (permissioned/non Compliance,
permissioned. use case etc.) is not Legal, or aligned with and the
governance Reputational practices put in place. Operational Layer
Participant Strategic, OL-PO1 User access controls are not L, M, H
Onboarding Operational, enforced, allowing unauthorized and Off-
Financial, individuals to have access to boarding Compliance,
systems and SOA services. Legal, or Reputational Operational Layer
Application Strategic, OL-AL1 The Blockchain technology's L, M, H
Layer Operational, impact on the controls attestations Financial,
(SOC 1/SOC 2 reports) or the Compliance, Financial Statemcnt/SOX
audit Legal, or scope is not assessed and therefore Reputational
the potential impact is unknown and not managed. Operational Layer
Application Strategic, OL-AL2 Risk and audit plans are not L, M, H
Layer Operational, updated and therefore do not Financial, reflect
and address the risks Compliance, associated with the Blockchain
Legal, or technology. Reputational Operational Layer Blockchain
Strategic, OL-BC1 Consensus mechanisms L, M, H Concensus
Operational, implemented do not provide Program Financial, comfort
on the immutability of the Management Compliance, data stored on
the Blockchain. Legal, or Reputational Operational Layer Blockchain
Strategic, OL-BC2 Consensus mechanisms L, M, H Concensus
Operational, implemented do not provide Program Financial, comfort
on the immutability of the Management Compliance, data stored on
the Blockchain. Legal, or Reputational Operational Layer
Integration Strategic, OL-IW1 The setup of the Blockchain L, M, H
with off- Operational, software lacks consideration of Blockchain
Financial, new security requirements to Systems and Compliance,
maintain confidentiality, integrity, Processes Legal, or and
availability. Reputational Operational Layer Integration Strategic,
OL-IW2 Hardware (including L, M, H with off- Operational,
configurations, locations, Blockchain Financial, capacity/capacity
utilization, and Systems and Compliance, age and data requirements)
Processes Legal, or impacted by the Blockchain Reputational
integration have not been collected and evaluated, potentially
causing an unknown impact. Operational Layer Integration Strategic,
OL-IW3 Applications, software and L, M, H with off- Operational,
software components impacted by Blockchain Financial, the
Blockchain software Systems and Compliance, integration have not
been Processes Legal, or identified and evaluated. Reputational
Operational Layer Integration Strategic, OL-IW4 User access and
segregation of L, M, H with off- Operational, duties controls are
not enforced, Blockchain Financial, allowing unauthorized users to
Systems and Compliance, migrate Blockchain process Processes Legal,
or configurations into production. Reputational Operational Layer
Integration Strategic, OL-IW5 System development or L, M, H with
off- Operational, maintenance on a system with Blockchain
Financial, Blockchain dependencies are not Systems and Compliance,
identified and evaluated, Processes Legal, or potentially causing
an unknown Reputational impact. Operational Layer Integration
Strategic, OL-IW6 The legacy system Software L, M, H with off-
Operational, Development Lifecycle Blockchain Financial,
methodology for change Systems and Compliance, management processes
docs not Processes Legal, or reflect the integration with the
Reputational Blockchain program management. Operational Layer
Integration Strategic, OL-IW7 Business process changes with L, M, H
with off- Operational, Blockchain dependencies are not Blockchain
Financial, identified and evaluated, Systems and Compliance,
potentially causing an unknown Processes Legal, or impact.
Reputational Operational Layer Smart Strategic, OL-SC2 Blockchain
data is stored on off- L, M, H Contracts Operational, chain
databases that are unsecure Financial, Compliance, Legal, or
Reputational Operational Layer Smart Strategic, OL-SC3 The
organization lacks a complete L, M, H Contracts Operational,
governance structure to provide Financial, oversight and security
for hard Compliance, forks in the blockchain Legal, or architecture
Reputational
TABLE-US-00017 TABLE 15 In-scope/Out-of- scope (TBD-As Risk
Category Domain Control/Test Objective Control Description per
engagement) Operational Permissioned As the Blockchain is
implemented, A Blockchain steering In-scope Layer Network there is
alignment with the nature of committee, which includes Management
the instance (permissioned/non executive leadership and senior
permissioned. use case etc.) and the members of the business, risk,
governance practices put in place. compliance and the Blockchain An
appropriate governance regime is program management, meets on
designed and agreed, if required a quarterly basis to conduct
across all participants in the network. business performance
reviews of how the Blockchain aligns with IT Governance.
Operational Participant All access is logged and monitored All
access is logged and In-scope Layer Onboarding and SOA services
maintain the monitored. and Off- appropriate restricted access. SOA
services are restricted from boarding being accessed by anyone
other than whitelisted processes/clients. Operational Application
Management has engaged appropriate The Blockchain Program In-scope
Layer Layer members of internal and external audit management meets
with external to assess if the Blockchain technology SOC
1/Financial Statement audit will have an impact on the controls
teams to review the status of the attestations (SOC 1/SOC 2
reports) or project plan and future the the Financial Statement/SOX
audit Blockchain process scope. considerations and management's
assessment on impact of the Blockchain technology to the audit
scope. Operational Application Internal audit has been properly The
Blockchain management In-scope Layer Layer engaged and the
Blockchain program team meets regularly with is being considered in
the internal members of risk and internal audit scoping exercises.
audit in each business unit leveraging the Blockchain technology to
ensure the risk and audit plans are evolving to address the
Blockchain risks. Operational Blockchain As Blockchain programs are
designed Blockchain consensus In-scope Layer Consensus and
implemented, appropriate mechanisms that assure Program consensus
mechanisms are agreed immutability are designed Management upon,
implemented and controlled to implemented and the associated
provide comfort on the immutability controls are documented and of
the data stored on the Blockchain. approved by the business and the
Appropriate controls are designed and Blockchain program
implemented to safeguard the management. Blocks are created
immutability of data captured on the for transactions validated
blockchain. through blockchain consensus mechanism and cannot be
modified once written. Operational Blockchain Conesus mechanism
automatically Economic trade terms arc In-scope Layer Consensus
determines whether the trade details validated through blockchain
Program match between counterparties or not. consensus mechanism
and Management Automatic validation will not take automatically
recorded on the place if consensus is not reached. blockchain
network in a timely manner. Operational Integration The Blockchain
software is aligned The Blockchain software for Layer with off-
with new security requirements to initial integration into the
firm's Blockchain maintain confidentiality, integrity, and
environment follows a well- Systems and availability. defined
integration plan and is Processes monitored by the Blockchain
program management. Operational Integration Hardware impacted by
the Blockchain Impact of software integration In-scope Layer with
off- integration is documented and on the firm's existing hardware
Blockchain evaluated, and results are escalated to configurations,
software and Systems and the Blockchain steering committee.
applications is documented and Processes evaluated. The results of
this evaluation are reported to the Blockchain steering committee.
Operational Integration Applications and software impacted Impact
of software integration In-scope Layer with off- by the Blockchain
integration is on the firm's existing hardware Blockchain
documented and evaluated, and results configurations, software and
Systems and are escalated to the Blockchain applications is
documented and Processes steering committee. evaluated. The results
of this evaluation are reported to the Blockchain steering
committee. Operational Integration Operations policies and
procedures Access to migrate the In-scope Layer with off- have been
updated to include Blockchain process Blockchain integration with
the Blockchain prior configurations into production is Systems and
to the Blockchain change being placed restricted to personnel who
are Processes into production. independent of the configuration
team. Access to migrate the Blockchain process configurations into
production is periodically reviewed to ensure access is restricted
to personnel. Operational Integration Impact of legacy system
development Business Unit IT management In-scope Layer with off-
and maintenance on the Blockchain notifies the Blockchain program
Blockchain configuration is considered during management if system
Systems and legacy System Development Lifecycle development or
maintenance on Processes for legacy systems. a system has been
identified as Impacts to interfaces between legacy having the
Blockchain systems have been identified., e.g. dependencies. The
Blockchain data flow architecture program management evaluates the
impact the legacy system change will have on the Blockchain.
Details of the evaluation are documented. If the Blockchain process
is impacted, the Blockchain is removed from production and a back
out plan is enabled while a configuration change order is
processed. Operational Integration An inventory, including
functional The legacy system Software In-scope Layer with off- use.
of all key interfaces and legacy Development Lifecycle Blockchain
systems utilized by the Blockchain is methodology for change
Systems and maintained. management processes has been Processes
Impacts to interfaces between legacy updated to include integration
systems have been identified., e.g. with the Blockchain program
data flow architecture management prior to making changes to the
Blockchain impacted systems or interfaces. Operational Integration
The Blockchain is reconfigured when Business Unit Operations
In-scope Layer with off- changes in business processes affect
management notifies the Blockchain the Blockchain. Management
Blockchain program Systems and considers both the downstream and
management if a business Processes upstream impact of changes to
process change has been business processes and the use of the
identified as having the Blockchain technology. Blockchain
dependencies. The Blockchain program management evaluates the
impact the business process change will have on the Blockchain
configuration. Details of the evaluation are documented. If a
Blockchain process is impacted, the Blockchain is removed from
production and back out plan is enabled while a configuration
change order is processed.
TABLE-US-00018 TABLE 16 Test Type (TBD-- Risk As per Category
Domain Test Procedure (#) engagement) Request List (#) Operational
Permissioned 1. Inquire with management about the process of
Inquiry, 1. Listing of the Layer Network ensuring alignment with
the nature of the instance Inspection, individuals on the
Management and the government practices put in place. and/or
Blockchain steering 2. Obtain relevant documentation evidencing the
observation committee consideration of the alignment. 2. Evidence
for the 3. Obtain a listing of the individuals on the most recent
quarterly Blockchain steering committee. meeting (meeting 4. Obtain
evidence for the most recent quarterly minutes/meeting meeting
(meeting minutes/meeting invites) to invites/emails) verify that
meeting took place and included showing the meeting members of the
Blockchain steering committee. took place 5. Through inspection of
the results of business 3. Documentation/ performance review,
verify an appropriate review results of the was performed of how
the Blockchain aligns with quarterly business IT Governance.
performance review of how the Block- chain aligns with IT
Governance 4. Documentation leveraged when considering the
alignment Operational Participant 1. Inquire with management about
the process Inquiry, 1. Listing of users with Layer Onboarding and
frequency in which access is logged and Inspection, access to the
SOA and Off- monitored. and/or services boarding 2. Obtain a
listing of users with access to the observation 2. Documentation
SOA services. showing all access is 3. Obtain documentation showing
that all access logged and monitored is logged and monitored and
through inspection, 3. Screenshot showing verify that only users
with permissioned access how access is logged appear on the
listing. and monitored Operational Application 1. Obtain evidence
for the most recent meeting Inquiry, 1. Evidence for the Layer
Layer (meeting minutes/meeting invites) to verify the Inspection,
most recent meeting meeting took place and included members of the
and/or (meeting Blockchain Program management team. observation
minutes/meeting 2. Through inspection of the documentation of the
invites/emails) assessment, verify the assessment was performed
showing the meeting and the results were documented. took place 2.
Documentation of management's assessment on the impact of the
Blockchain technology to the audit scope Operational Application 1.
Obtain evidence for the most recent meeting Inquiry, 1. Evidence
for the Layer Layer (meeting minutes/meeting invites) to verify the
Inspection, most recent meeting meeting took place and included
members of the and/or (meeting Blockchain management team.
observation minutes/meeting 2. Through inspection of an updated
risk and audit invites/emails) plan, verify changes and updates
have been made showing the meeting to reflect the Blockchain
program. took place 2. Risk and audit plan updated to address
Blockchain risks Operational Blockchain 1. Inquire with management
about the process in Inquiry, 1. Documentation of Layer Consensus
which appropriate consensus mechanisms are Inspection, the
associated controls Program agreed upon, implemented and
controlled, and/or for a new Blockchain Management 2. Obtain
documentation of the associated observation consensus mechanism
controls. 2. Evidence of the 3. Through inspection of documentation
review and approval evidencing associated controls have been by the
business and the documented, verify these controls were reviewed
Blockchain program and approved by the business and the Blockchain
management program management. Operational Blockchain 1. Inquire
with management about the process in Inquiry, Layer Consensus which
appropriate consensus mechanisms are Inspection, Program agreed
upon, implemented and controlled. and/or Management 2. Obtain
documentation of the associated observation controls. 3. Through
inspection of documentation evidencing associated controls have
been documented, verify these controls were reviewed and approved
by the business and the Blockchain program management. Operational
Integration 1. Inquire with management about the process of
Inquiry, 1. Integration plan used Layer with off- ensuring
alignment with new security Inspection, for initial integration
Blockchain requirements. and/or 2. Evidence showing Systems and 2.
Obtain the integration plan used for initial observation the
integration plan is Processes integration. monitored 3. Through
inspection of the integration plan, verify that there is evidence
that the integration plan is monitored by the Blockchain program
management. Operational Integration 1. Obtain the documentation of
the impact of Inquiry, 1. Documentation Layer with off- software
integration Inspection, showing the evaluation Blockchain 2.
Through inspection of the documentation, and/or performed of the
Systems and verify any impacts identified were appropriately
observation impact of software Processes evaluated. integration on
the 3. Obtain evidence of the communicated results firm's existing
and through inspection, verify the results of the hardware
evaluation were reported to the Blockchain configurations steering
committee. 2. Evidence of communication to the Blockchain steering
committee Operational Integration 1. Obtain the documentation of
the impact of Inquiry, 1. Documentation Layer with off- software
integration. Inspection, showing the evaluation Blockchain 2.
Through inspection of the documentation, and/or performed of the
Systems and verify any impacts identified were appropriately
observation impact of software Processes evaluated. integration on
the 3. Obtain evidence of the communicated results, firm's existing
and through inspection, verify the results of the hardware
evaluation were reported to the Blockchain configurations steering
committee. 2. Evidence of communication to the Blockchain steering
committee Operational Integration 1. Obtain a listing of users with
access to migrate Inquiry, 1. Listing of users with Layer with off-
the Blockchain process configurations. Inspection, access to
migrate the Blockchain 2. Obtain evidence for the most recent
periodic and/or Blockchain process Systems and review performed of
access, and through observation configurations Processes inspection
verify access was restricted to 2. Evidence that a personnel.
periodic review was 3. Obtain the Operations policies and
procedures performed of restricted Blockchain evidencing the
updates made to access and including include integration with the
Blockchain with evidence of the review a date in which these
updates were made. 3. Operations policies 4. Obtain evidence of the
Blockchain change and procedures updated being placed into
production and the date in with the integration which this
occurred. with Blockchain with 5. Through inspection, verify the
updates were the date in which the made to the policies and
procedures prior to the updates were made change being placed into
production. 4. Evidence of the change being placed into production
(change order ticket including the date in which the request was
processed and completed) Operational Integration 1. Obtain evidence
of communication between Inquiry, 1. Evidence of Layer with off-
Business Unit IT management and the Blockchain Inspection,
communication Blockchain program management of a system identified
as and/or between Business Unit Systems and having Blockchain
dependencies. observation IT management and the Processes 2. Verify
the Blockchain program management Blockchain program performed an
evaluation of the impact the legacy management for a system change
has on the Blockchain. system identified as 3. Obtain documentation
verifying the details of having Blockchain the evaluation were
documented. dependencies 4. Obtain evidence of a processed change
order 2. Evaluation request to remove the Blockchain from
production performed by the and through inspection, verify the
request was Blockchain program completed. management 5. Obtain
documentation of the back out plan and 3. Evidence that the through
inspection, verify that the back out plan Blockchain was was
enabled while a configuration change order removed from was
processed. production 4. Change order ticket showing this request
was processed and completed 5. Back out plan that was enabled
Operational Integration 1. Inquire with management about the
process of Inquiry, 1. The legacy system Layer with off- updating
the methodology to include integration Inspection, Software
Development Blockchain with Blockchain program management. and/or
Lifecycle methodology Systems and 2. Obtain documentation verifying
change observation for change Processes management processes have
been updated with management processes the date in which these
updates were made. updated with 3. Obtain evidence of the changes
made to the Blockchain with the Blockchain and the date in which
these changes date in which the were made. updates were made 4.
Through inspection, verify that the updates 2. Evidence of the were
made to the methodology prior to the changes made to the changes
being made. Blockchain impacted 5. Obtain the inventory listing and
through system (change order inspection, verify the listing
includes functional ticket including the use of all key interfaces
and legacy systems date in which the utilized by the Blockchain and
that the listing is request was processed properly maintained. and
completed) 3. Inventory listing with evidence of how the listing is
maintained Operational Integration 1. Obtain evidence of
communication between Inquiry, 1. Evidence of Layer with off-
Business Unit Operations and the Blockchain Inspection,
communication Blockchain program management of a business process
and/or between Business Unit Systems and identified as having
Blockchain dependencies. observation IT management and the
Processes 2. Verify the Blockchain program management Blockchain
program performed an evaluation of the impact the legacy management
system change has on the Blockchain. 2. Evaluation 3. Obtain
evidence verifying the details of the performed by the evaluation
were documented. Blockchain program 4. Obtain evidence of a
processed change order management request to remove the Blockchain
from production 3. Evidence that the and through inspection, verify
the request was Blockchain was completed. removed from 5. Obtain
documentation of the back out plan and production through
inspection, verify that the back out plan 4. Change order ticket
was enabled while a configuration change order showing this request
was processed. was processed 5. Back out plan that was enabled
4.6 Transactional Layer Assessment Work Program
[0150] In some embodiments, transaction layer risk category in the
blockchain risk framework covers relevant risks, control objectives
and descriptions, testing objectives and procedures, and reporting
parameters designed to address assurance and compliance needs for
the blockchain application stack/layer supporting business and
transaction level processing.
[0151] The sub-risk categories, control and testing objectives,
test procedures and request lists for Transactional Layer risk
category are provided below in Tables 17-19.
TABLE-US-00019 TABLE 17 Risk Level (L, M, H) Risk Risk Risk (As
Category Domain Classification Number Risk Description applicable)
Transactional Smart Strategic, TL-SC1 Incorrect SC terms are not L,
M, H (Business) Contracts Operational, selected for execution. (SC)
Financial, Compliance/ Legal, Reputational Transactional Smart
Strategic, TL-SC2 SC terms and conditions are L, M, H (Business)
Contracts Operational, not inclusive of required (SC) Financial,
information or standard Compliance/ terms and conditions. Legal,
Reputational Transactional Smart Strategic, TL-SC3 SC is executed
with wrong/ L, M, H (Business) Contracts Operational, incorrect
participants or SC (SC) Financial, does not include right/correct
Compliance/ participants. Legal, Reputational Transactional Smart
Strategic, TL-SC4 SC is not reviewed, appraised, L, M, H (Business)
Contracts Operational, and approved by appropriate (SC) Financial,
participants during or before Compliance/ execution. Legal,
Reputational Transactional Smart Strategic, TL-SC5 SC is completed
without L, M, H (Business) Contracts Operational, execution of
required terms (SC) Financial, and conditions by all Compliance/
participants. Legal, Reputational Transactional Smart Strategic,
TL-SC6 Required events (e.g. L, M, H (Business) Contracts
Operational, invoicing, payments, change (SC) Financial, or
ownership) are not initiated Compliance/ and completed successfully
Legal, during or after SC execution. Reputational Transactional
Smart Strategic, TL-SC7 Privileged access is not L, M, H (Business)
Contracts Operational, appropriately restricted, logged, (SC)
Financial, and monitored for Smart Compliance/ Contracts, which can
create a Legal, risk of unauthorized access to Reputational Smart
Contracts by developers/ admins/database admins Transactional Smart
Strategic, TL-SC8 End-user access is not L, M, H (Business)
Contracts Operational, appropriately restricted, creating (SC)
Financial, the risk of unauthorized changes/ Compliance/
deployments/executions/updates/ Legal, modifications performed for
the Reputational Smart Contract and workflow Transactional Smart
Strategic, TL-SC9 Smart Contract development and L, M, H (Business)
Contracts Operational, change management process is (SC) Financial,
not in place and followed, which Compliance/ may lead to
unauthorized Legal, unilateral actions by developers Reputational
to modify or remove Smart Contract functions or introduce
unnecessary or insecure functions Transactional Smart Strategic,
TL-SC10 Smart Contract development and L, M, H (Business) Contracts
Operational, change management process is (SC) Financial, not in
place and followed, which Compliance/ may lead to inappropriate and
Legal, incorrect terms and conditions Reputational [e.g. timeline,
pricing, resources, invoicing, settlement, etc.] defined for the
Smart Contract Transactional Smart Strategic, TL-SC11 Smart
Contract development and L, M, H (Business) Contracts Operational,
change management process is (SC) Financial, not in place and
followed, which Compliance/ may lead to inappropriate and Legal,
incorrect assets and services Reputational defined for the Smart
Contract Transactional Smart Strategic, TL-SC12 Smart Contract
development and L, M, H (Business) Contracts Operational, change
management process is (SC) Financial, not in place and followed,
which Compliance/ may lead to inappropriate and Legal, incorrect
participants defined for Reputational the Smart Contract
Transactional Smart Strategic, TL-SC13 Smart Contract development
and L, M, H (Business) Contracts Operational, change management
process is (SC) Financial, not in place and followed, which
Compliance/ may lead to unauthorized or Legal, incorrect Smart
Contracts being Reputational introduced into the production
environment Transactional Smart Strategic, TL-SC14 Unauthorized
access to Blockchain L, M, H (Business) Contracts Operational,
metadata or PII by unauthorized (SC) Financial, parties for
development or testing Compliance/ purposes Legal, Reputational
Transactional Smart Strategic, TL-SC15 Data is not retained for DLT
inputs. L, M, H (Business) Contracts Operational, PKIs. or other
critical systems; lack (SC) Financial, of availability limits
backup and Compliance/ recovery capability Legal, Reputational
Transactional Smart Strategic, TL-SC16 Input validation mechanisms
for L, M, H (Business) Contracts Operational, fields and records
are not in place, (SC) Financial, which may compromise the Smart
Compliance/ Contract execution Legal, Reputational Transactional
Smart Strategic, TL-SC17 Security mechanisms are not in L, M, H
(Business) Contracts Operational, place or effective in protecting
(SC) Financial, output (data), creating the risk Compliance/ of
unauthorized access or changes Legal, made to output Reputational
Transactional Smart Strategic, TL-SC18 Security mechanisms are not
in L, M, H (Business) Contracts Operational, place or effective in
protecting (SC) Financial, Smart Contracts mid their Compliance/
exposure to unauthorized parties Legal, via export and sharing
Reputational functionalities Transactional Smart Strategic, TL-SC19
Mechanisms are not in place or L, M, H (Business) Contracts
Operational, effective in ensuring subsequent (SC) Financial, Smart
Contracts are only triggered Compliance/ when appropriate and when
needed Legal, Reputational Transactional Smart Strategic, TL-SC20
Mechanisms are not in place or L, M, H (Business) Contracts
Operational, effective in ensuring subsequent (SC) Financial, smart
contracts, invoicing, billing Compliance/ is triggered and
processed Legal, appropriately as and if needed Reputational
Transactional Smart Strategic, TL-SC21 Mechanisms are not in place
or L, M, H (Business) Contracts Operational, effective in ensuring
subsequent (SC) Financial, movement of digital assets is
Compliance/ triggered and processed Legal, appropriately as and if
needed Reputational Transactional Smart Strategic, TL-SC22
Mechanisms are not in place or L, M, H (Business) Contracts
Operational, effective in ensuring subsequent (SC) Financial,
digital tokens are triggered and Compliance/ processed
appropriately as and Legal, if needed Reputational Transactional
Smart Strategic, TL-SC23 Monitoring mechanisms are not L, M, H
(Business) Contracts Operational, in place for Smart Contracts,
(SC) Financial, which can lead to non-detection Compliance/ of
Smart Contracts not performing Legal, as intended in the production
Reputational environment Transactional Smart Strategic, TL-SC24
Monitoring mechanisms are not in L, M, H (Business) Contracts
Operational, place for Smart Contracts, which (SC) Financial, can
create a risk of impaired Compliance/ network performance or
latency Legal, Reputational Transactional Smart Strategic, TL-SC25
Monitoring mechanisms are not L, M, H (Business) Contracts
Operational, in place for Smart Contracts, (SC) Financial, which
can create a risk of the Compliance/ Smart Contract not being
Legal, executed and completed as Reputational per defined terms
Transactional Smart Strategic, TL-SC26 Monitoring mechanisms are
not L, M, H (Business) Contracts Operational, in place for Smart
Contracts, (SC) Financial, which can create a risk of the
Compliance/ Smart Contract not being retired Legal, appropriately
if necessary Reputational Transactional Smart Strategic, TL-SC27
Monitoring mcclianisms are not L, M, H (Business) Contracts
Operational, in place for Smart Contracts, (SC) Financial, which
can create a risk of the Compliance/ Smart Contract being deployed,
Legal, modified, or changed by Reputational unauthorized
participants Transactional Smart Strategic, TL-SC28 Smart Contract
privacy is not L, M, H (Business) Contracts Operational, maintained
throughout the (SC) Financial, Smart Contract lifecycle,
Compliance/ creating tire risk of private Legal, information being
divulged, Reputational shared, or disseminated Transactional Smart
Strategic, TL-SC29 Interfaces are not configured L, M, H (Business)
Contracts Operational, to ensure all process data (SC) Financial,
transmissions within the Compliance/ blockchain are complete,
Legal, accurate, and secure Reputational Transactional Smart
Strategic, TL-SC30 Interfaces are not configured L, M, H (Business)
Contracts Operational, to ensure all process data (SC) Financial,
transmissions to off-chain Compliance/ platforms or systems are
Legal, complete, accurate, and secure Reputational Transactional
Smart Strategic, TL-SC31 Smart Contract arehitecture is L, M, H
(Business) Contracts Operational, unable to be updated/modified
(SC) Financial, and therefore docs not comply Compliance/ with new
requirements or Legal, regulations or is vulnerable to Reputational
newly-discovered security issues Transactional Smart Strategic,
TL-SC32 Insufficient side chain safeguards L, M, H (Business)
Contracts Operational, increase risk of incidents leading (SC)
Financial, to loss or invalidation of assets or Compliance/
transactions related to Smart Legal, Contracts Reputational
Transactional Digital Strategic, TL-DA1 Incorrectly DA onboarding
may L, M, H (Business) Assets Operational, cause delay or
compromise (DA) Financial, transactional level processing.
Compliance/ Legal, Reputational Digital Strategic, TL-DA2 DA
ownership is transferred L, M, H Assets Operational, incorrectly
which may compromise (DA) Financial, transactional level
processing. Compliance/ Legal, Reputational Transactional Digital
Strategic, TL-DA3 DA is not managed and maintained L, M, H
(Business) Assets Operational, appropriately during its lifecycle.
(DA) Financial, Compliance/ Legal, Reputational Transactional
Digital Strategic, TL-DA4 DA is not retired appropriately at L, M,
H (Business) Assets Operational, the end of the lifecycle. (DA)
Financial, Compliance/ Legal, Reputational Transactional Digital
Strategic, TL-DA5 Privileged access is not L, M, H (Business)
Assets Operational, appropriately restricted, logged, (DA)
Financial, and monitored for Digital Assets, Compliance/ which can
lead to unauthorized Legal, access Reputational Transactional
Digital Strategic, TL-DA6 End-user access is not appropriately L,
M, H (Business) Assets Operational, restricted, creating the risk
of (DA) Financial, unauthorized changes/deployments/ Compliance/
executions/updates/modifications Legal, performed for the Digital
Assets Reputational and workflow Transactional Digital Strategic,
TL-DA7 Digital Assets are not configured L, M, H (Business) Assets
Operational, with strong login credentials and (DA) Financial,
account security protocols to Compliance/ restrict unauthorized
access Legal, Reputational Transactional Digital Strategic, TL-DA8
Digital Assets are stored in an L, M, H (Business) Assets
Operational, unsecure environment, and hot/ (DA) Financial,
warm/cold risk factors systemic Compliance/ to each Digital Asset
platform Legal, are not taken into account, Reputational creating
greater risks to Digital Asset operations and security of
transaction data Transactional Digital Strategic, TL-DA9
Participants are not L, M, H (Business) Assets Operational,
appropriately and correctly (DA) Financial, defined which can lead
to Compliance/ unauthorized access or Legal, operation of the
Digital Asset Reputational Transactional Digital Strategic, TL-DA10
Digital Assets are not L, M, H (Business) Assets Operational,
appropriately or correctly (DA) Financial, protected, managed, and
Compliance/ monitored throughout Legal, their life cycle
Reputational Transactional Digital Strategic, TL-DA11 Unauthorized
or incorrect L, M, H (Business) Assets Operational, Digital Asset
platforms tire (DA) Financial, introduced, compromising the
Compliance/ security of the organization's Legal, Digital Asset
environment Reputational Transactional Digital Strategic, TL-DA12
Digital Asset software is not L, M, H (Business) Assets
Operational, updated in accordance with (DA) Financial, required
updates, leading to Compliance/ version mismatching and Legal,
potential compromises to Reputational security or operational
limitations Transactional Digital Strategic, TL-DA13 Digital Asset
management L, M, H (Business) Assets Operational, platforms are not
configured (DA) Financial, with recover) procedures to Compliance/
recover loss of data and Legal, information Reputational
Transactional Digital Strategic, TL-DA14 Mechanisms are not in
place L, M, H (Business) Assets Operational, or effective in
ensuring Digital (DA) Financial, Asset transactions are triggered
Compliance/ as and if needed Legal, Reputational Transactional
Digital Strategic, TL-DA15 Monitoring mechanisms are not L, M, H
(Business) Assets Operational, in place for Digital Assets, which
(DA) Financial, can lead to non-detection of Compliance/ Digital
Assets not performing as Legal, intended in the production
Reputational environment Transactional Digital Strategic, TL-DA16
Monitoring mechanisms are not L, M, H (Business) Assets
Operational, in place for Digital Assets, (DA) Financial, which can
create a risk of Compliance/ impaired network performance Legal, or
latency Reputational Transactional Digital Strategic, TL-DA17
Monitoring mechanisms tire L, M, H (Business) Assets Operational,
not in place for Digital Assets, (DA) Financial, which can create a
risk of a Compliance/ Digital Asset not being utilized Legal, per
defined terms Reputational Transactional Digital Strategic, TL-DA18
Monitoring mechanisms are L, M, H (Business) Assets Operational,
not in place for Digital Assets, (DA) Financial, which can create a
risk of the Compliance/ Digital Asset not being retired Legal,
appropriately if neccssary Reputational Transactional Digital
Strategic, TL-DA19 Monitoring mechanisms are L, M, H (Business)
Assets Operational, not in place for Digital Assets, (DA)
Financial, which can create a risk of the Compliance/ Digital Asset
being utilized, Legal, modified, or changed by Reputational
unauthorized participants Transactional Digital Strategic, TL-DA20
Digital Asset privacy is not L, M, H (Business) Assets Operational,
maintained throughout the (DA) Financial, Digital Asset lifecycle,
creating Compliance/ the risk of private information Legal, being
divulged, shared, or Reputational disseminated Transactional
Digital Strategic, TL-DA21 Interfaces are not configured to L, M, H
(Business) Assets Operational, ensure all process data (DA)
Financial, transmissions within the Compliance/ blockchain are
complete, Legal, accurate, and secure Reputational Transactional
Digital Strategic, TL-DA22 Interfaces are not configured to L, M, H
(Business) Assets Operational, ensure all process data (DA)
Financial, transmissions to off-chain Compliance/ platforms or
systems are Legal, complete, accurate, and secure Reputational
Transactional Digital Strategic, TL-DA23 Without price fluctuation
L, M, H (Business) Assets Operational, monitoring and defined (DA)
Financial, response/action plan, assets, Compliance/ contracts,
tokens can be Legal, processed with incorrect Reputational value at
a given point in time Transactional Digital Strategic, TL-DA24
Fluctuations in prices for L, M, H (Business) Assets Operational,
commodity items like Digital (DA) Financial, Asset storage create
Compliance/ opportunities for sunk costs Legal, or deadweight loss
Reputational expenditures Transactional Digital Strategic, TL-DA25
Digital Assets within the L, M, H (Business) Assets Operational,
organization are not linked (DA) Financial, with soft or intangible
assets Compliance/ (i.e. human resources) Legal, causing lack of
operational Reputational alignment across the organization
Transactional Digital Strategic, TL-DA26 Digital Assets within the
L, M, H (Business) Assets Operational, organization are not linked
(DA) Financial, with other real world assets Compliance/ (i.e. real
estate, property, Legal, etc.) causing lack of Reputational
operational alignment across the organization Transactional Digital
Strategic, TL-DA27 The existence of physical/ L, M, H (Business)
Assets Operational, logical assets is not tracked (DA) Financial,
or managed on a regular Compliance/ basis, causing inaccurate
Legal, and incomplete Reputational representation of physical
assets in a digital form Transactional Digital Strategic, TL-DA28
The organization's legacy L, M, H (Business) Assets Operational,
system accounts are not (DA) Financial, linked with DLT associated
Compliance/ Digital Assets, causing lack Legal, of operational
alignment Reputational across the organization Transactional
Digital Strategic, TL-DT1 Participants are not on- L, M, H
(Business) Tokens Operational, boarded for DC transactions. (DT)
Financial, Compliance/ Legal, Reputational Transactional Digital
Strategic, TL-DT2 Account balance cannot L, M, H (Business) Tokens
Operational, support DC transaction (DT) Financial, request for
processing. Compliance/ Legal, Reputational Transactional Digital
Strategic, TL-DT3 DC-in requests are not L, M, H (Business) Tokens
Operational, processed correctly. (DT) Financial, Compliance/
Legal, Reputational Transactional Digital Strategic, TL-DT4 DC-out
requests are not L, M, H (Business) Tokens Operational, processed
correctly. (DT) Financial, Compliance/ Legal, Reputational
Transactional Digital Strategic, TL-DT5 DC duplicate transactions
L, M, H (Business) Tokens Operational, are processed. (DT)
Financial, Compliance/ Legal, Reputational Transactional Digital
Strategic, TL-DT6 DC transactions are L, M, H (Business) Tokens
Operational, approved. (DT) Financial, Compliance/ Legal,
Reputational Transactional Digital Strategic, TL-DT7 DC transaction
information L, M, H (Business) Tokens Operational, is missing which
may (DT) Financial, compromise transaction Compliance/ processing.
Legal, Reputational Transactional Digital Strategic, TL-DT8 Address
is not generated or L, M, H (Business) Tokens Operational, shared
with participants for (DT) Financial, DC transactions. Compliance/
Legal, Reputational Transactional Digital Strategic, TL-DT9
Cancelled or failed L, M, H (Business) Tokens Operational,
transactions are not tracked (DT) Financial, or processed
correctly. Compliance/ Legal, Reputational Transactional Digital
Strategic, TL-DT10 DC is not moved from one L, M, H (Business)
Tokens Operational, participant to the other (e.g. (DT) Financial,
payor and payee) correctly Compliance/ and in a timely manner.
Legal, Reputational Transactional Digital Strategic, TL-DT11 DC is
not evaluated correctly L, M, H (Business) Tokens Operational,
relative to underlying asset or (DT) Financial, currency.
Compliance/ Legal, Reputational Transactional Digital Strategic,
TL-DT12 Privileged access is not L, M, H (Business) Tokens
Operational, appropriately restricted, (DT) Financial, logged, and
monitored for Compliance/ Digital Tokens, which can Legal, lead to
unauthorized access Reputational Transactional Digital Strategic,
TL-DT13 End-user access is not L, M, H (Business) Tokens
Operational, appropriately restricted, (DT) Financial, which can
lead to Compliance/ unauthorized changes/ Legal,
updates/modifications Reputational performed for the Digital Tokens
and workflow Transactional Digital Strategic, TL-DT14 Digital
Tokens are not L, M, H (Business) Tokens Operational, configured
with strong (DT) Financial, login credentials and Compliance/
account security protocols Legal, to restrict unauthorized
Reputational access Transactional Digital Strategic, TL-DT15
Digital Token development L, M, H (Business) Tokens Operational,
and change management (DT) Financial, process is not in place and
Compliance/ followed, which may lead to Legal, inappropriate and
incorrect Reputational participants defined for authorized use of
Digital Tokens Transactional Digital Strategic, TL-DT16 Digital
Tokens are not L, M, H (Business) Tokens Operational, appropriately
or correctly (DT) Financial, protected, managed, and Compliance/
monitored throughout their Legal, life Reputational Transactional
Digital Strategic, TL-DT17 Digital Tokens are not L, M, H
(Business) Tokens Operational, monitored appropriately (DT)
Financial, throughout their life cycle Compliance/ causing
inaccurate records Legal, for when tokens were created,
Reputational converted, updated, and retired Transactional Digital
Strategic, TL-DT18 Digital Token development and L, M, H (Business)
Tokens Operational, change management process is (DT) Financial,
not in place and followed, which Compliance/ may lead to
unauthorized or Legal, incorrect Digital Tokens being Reputational
introduced into the operational environment Transactional Digital
Strategic, TL-DT19 Lack of a clearly defined Digital L, M, H
(Business) Tokens Operational, Token platform can potentially (DT)
Financial, endanger the organization's Compliance/ transactional
data or create Legal, unauthorized operational Reputational
redundancies Transactional Digital Strategic, TL-DT20 Digital Token
platforms are not L, M, H (Business) Tokens Operational, configured
with recovery (DT) Financial, procedures to recover loss of
Compliance/ data and information Legal, Reputational TL-DT21
Ownership of assets linked to L, M, H Transactional Digital
Strategic, Digital Tokens is not defined (Business) Tokens
Operational, or managed by the organization (DT) Financial,
Compliance/ Legal, Reputational Transactional Digital Strategic,
TL-DT22 Data is not retained for DLT L, M, H (Business) Tokens
Operational, inputs, PKIs, or other critical (DT) Financial,
systems; lack of availability Compliance/ limits backup and
recovery Legal, capability Reputational Transactional Digital
Strategic, TL-DT23 Mechanisms are not in place L, M, H (Business)
Tokens Operational, or effective in ensuring Digital (DT)
Financial, Token transactions are triggered Compliance/ as and if
needed Legal, Reputational Transactional Digital Strategic, TL-DT24
Digital Tokens are not L, M, H (Business) Tokens Operational,
monitored to ensure tokens are (DT) Financial, utilized
appropriately for Compliance/ authorized transactions or Legal,
operations Reputational Transactional Digital Strategic, TL-DT25
Digital Token ownership and L, M, H (Business) Tokens Operational,
management of ownership is (DT) Financial, not monitored
appropriately Compliance/ Legal, Reputational Transactional Digital
Strategic, TL-DT26 The DLT and off-chain ledger L, M, H (Business)
Tokens Operational, or accounting mechanisms (DT) Financial, are
not monitored, Compliance/ compromising the ability to Legal,
accurately track usage of Reputational tokens during normal
operations and transactions Transactional Digital Strategic,
TL-DT27 Monitoring mechanisms are L, M, H (Business) Tokens
Operational, not in place for Digital Tokens, (DT) Financial, which
can create a risk of Digital Compliance/ Tokens being utilized,
modified, Legal, or changed by unauthorized Reputational
participants Transactional Digital Strategic, TL-DT28 Interfaces
are not configured to L, M, H (Business) Tokens Operational, ensure
all process data (DT) Financial, transmissions within the
Compliance/ blockchain are complete, accurate, Legal, and secure
Reputational Transactional Digital Strategic, TL-DT29 Interfaces
are not configured to L, M, H (Business) Tokens Operational, ensure
all process data (DT) Financial, transmissions to off-chain
Compliance/ platforms or systems are complete, Legal, accurate, and
secure Reputational Transactional Digital Strategic, TL-DT30
Without price fluctuation L, M, H (Business) Tokens Operational,
monitoring and defined response/ (DT) Financial, action plan,
tokens, contracts, Compliance/ tokens can be processed with Legal,
incorrect value at a given point Reputational in time Transactional
Digital Strategic, TL-DT31 Fluctuations in prices for L, M, H
(Business) Tokens Operational, commodity items like Digital (DT)
Financial, Token storage create opportunities Compliance/ for sunk
costs or deadweight loss Legal, expenditures Reputational
Transactional Digital Strategic, TL-DT32 The existence of digital
tokens or L, M, H (Business) Tokens Operational, funds used for
blockchain (DT) Financial, transactions are not validated
Compliance/ Legal, Reputational Transactional Digital Strategic,
TL-DT33 Digital tokens are not configured L, M, H (Business) Tokens
Operational, with strong login credentials and (DT) Financial,
account security protocols to Compliance/ restrict unauthorized
access Legal, Reputational Transactional Digital Strategic, TL-DW01
Privileged access is not L, M, H (Business) Wallets Operational,
appropriately restricted, logged, (DW) Financial, and monitored for
Digital Wallets, Compliance/ which can lead to unauthorized Legal,
access to Digital Wallets Reputational Transactional Digital
Strategic, TL-DW02 End-user access is not L, M, H (Business)
Wallets Operational, appropriately restricted, creating (DW)
Financial, the risk of unauthorized changes/ Compliance/
deployments/executions/updates/ Legal, modifications performed for
Reputational Digital Wallets and workflow Transactional Digital
Strategic, TL-DW03 Digital Wallets are not configured L, M, H
(Business) Wallets Operational, with strong login credentials and
(DW) Financial, account security protocols to Compliance/ restrict
unauthorized access Legal, Reputational Transactional Digital
Strategic, TL-DW04 Digital Wallets, ledgers, and L, M, H (Business)
Wallets Operational, access points are stored in an (DW) Financial,
insecure environment, and hot/ Compliance/ warm/cold risk factors
sy stemic Legal, to each wallet platform are not Reputational taken
into account, creating greater risks to Digital Wallet operations
and security of transaction data Transactional Digital Strategic,
TL-DW05 Digital Wallet development L, M, H (Business) Wallets
Operational, and change management (DW) Financial, process is not
in place and Compliance/ followed, which may lead to Legal,
inappropriate and incorrect Reputational participants defined for
the Digital Wallet Transactional Digital Strategic, TL-DW06 Digital
Wallet development and L, M, H (Business) Wallets Operational,
change management process is (DW) Financial, not in place and
followed, which Compliance/ may lead to unauthorized or Legal,
incorrect Digital Wallets being Reputational introduced into the
environment Transactional Digital Strategic, TL-DW07 Digital Wallet
software is not L, M, H (Business) Wallets Operational, updated in
accordance w ith (DW) Financial, required updates, leading to
Compliance/ version mismatching and Legal, potential compromises to
Reputational security or operational limitations Transactional
Digital Strategic, TL-DW08 Lack of a clearly defined Digital L, M,
H (Business) Wallets Operational, Wallet platform can potentially
(DW) Financial, endanger the organization's Compliance/
transactional data, create Legal, unauthorized operational
Reputational redundancies, or inhibit consistent and effective risk
management of specific Digital Wallet platforms (i.e. software,
hardware, ledger, etc.) Transactional Digital Strategic, TL-DW09
Digital Wallet platforms are not L, M, H (Business) Wallets
Operational, configured with recovery (DW) Financial, procedures to
recover lost data Compliance/ and information Legal, Reputational
Transactional Digital Strategic, TL-DW10 Data is not retained for
DLT L, M, H (Business) Wallets Operational, inputs, PKIs, or other
critical (DW) Financial, systems, lack of availability limits
Compliance/ backup and recovery capability Legal, Reputational
Transactional Digital Strategic, TL-DW11 Input validation
mechanisms for L, M, H (Business) Wallets Operational, fields and
records are not in place, (DW) Financial, which may compromise the
Compliance/ Digital Wallet's operations Legal, Reputational
Transactional Digital Strategic, TL-DW12 Security mechanisms are
not in L, M, H (Business) Wallets Operational, place or effective
in protecting (DW) Financial, output (data), creating the risk of
Compliance/ unauthorized access or changes Legal, made to output
Reputational Transactional Digital Strategic, TL-DW13 Security
mechanisms are not in L, M, H (Business) Wallets Operational, place
or effective in protecting (DW) Financial, Digital Wallets and
their exposure Compliance/ to unauthorized parties via export
Legal, and sharing functionalities
Reputational Transactional Digital Strategic, TL-DW14 Mechanisms
are not in place or L, M, H (Business) Wallets Operational,
effective in ensuring Digital Wallet (DW) Financial, transactions
are only triggered Compliance/ when appropriate and when needed
Legal, Reputational Transactional Digital Strategic, TL-DW15
Mechanisms are not in place or L, M, H (Business) Wallets
Operational, effective in ensuring off-chain (DW) Financial,
invoicing and billing is triggered Compliance/ and processed by
authorized Legal, participants appropriately as and Reputational if
needed Transactional Digital Strategic, TL-DW16 Mechanisms are not
in place or L, M, H (Business) Wallets Operational, effective in
ensuring digital token (DW) Financial, transactions are triggered
and Compliance/ processed appropriately as and Legal, if needed
Reputational Transactional Digital Strategic, TL-DW17 Mechanisms
are not in place or L, M, H (Business) Wallets Operational,
effective in ensuring subsequent (DW) Financial, Digital Wallet
transactions are Compliance/ triggered and processed by Legal,
authorized participants and Reputational appropriately as and if
needed Transactional Digital Strategic, TL-DW18 Monitoring
meclianisms are not L, M, H (Business) Wallets Operational, in
place for Digital Wallets, (DW) Financial, which can lead to
non-detection Compliance/ of Digital Wallets not Legal, performing
as intended in the Reputational environment Transactional Digital
Strategic, TL-DW19 Monitoring mechanisms are L, M, H (Business)
Wallets Operational, not in place for Digital Wallets, (DW)
Financial, which can create a risk of Compliance/ impaired network
performance Legal, or latency Reputational Transactional Digital
Strategic, TL-DW20 Mechanisms are not in place L, M, H (Business)
Wallets Operational, to monitor Digital Wallet (DW) Financial,
transactions and ensure Compliance/ transactions are executed
Legal, per defined terms Reputational Transactional Digital
Strategic, TL-DW21 Monitoring mechanisms are L, M, H (Business)
Wallets Operational, not in place for Digital Wallets, (DW)
Financial, which can create a risk of the Compliance/ Digital
Wallet not being retired Legal, appropriately if necessary
Reputational Transactional Digital Strategic, TL-DW22 Monitoring
mechanisms are L, M, H (Business) Wallets Operational, not in place
for Digital Wallets, (DW) Financial, which can create a risk of the
Compliance/ Digital Wallet being utilized, Legal, modified, or
changed by Reputational unauthorized participants Transactional
Digital Strategic, TL-DW23 Digital Wallet privacy is not L, M, H
(Business) Wallets Operational, maintained throughout the (DW)
Financial, Digital Wallet lifecycle, Compliance/ creating the risk
of private Legal, information being divulged, Reputational shared,
or disseminated Transactional Digital Strategic, TL-DW24 Interfaces
are not configured L, M, H (Business) Wallets Operational, to
ensure all process data (DW) Financial, transmissions within the
Compliance/ blockchain are complete, Legal, accurate, and secure
Reputational Transactional Digital Strategic, TL-DW25 Interfaces
are not configured L, M, H (Business) Wallets Operational, to
ensure all process data (DW) Financial, transmissions to off-chain
Compliance/ platforms or systems are Legal, complete, accurate, and
secure Reputational Transactional Digital Strategic, TL-DW26
Mechanisms are not in place L, M, H (Business) Wallets Operational,
or effective in ensuring Digital (DW) Financial, Wallets are
configured with Compliance/ appropriate transaction Legal,
thresholds to prevent failed Reputational detection of transferred
funds Transactional Digital Strategic, TL-DW27 Security mechanisms
are not L, M, H (Business) Wallets Operational, in place for
Digital Wallets, (DW) Financial, compromising private keys or
Compliance/ PKIs, which may result in Legal, breaches of Digital
Wallet security or risk of unauthorized access to assets stored on
the wallet platform Transactional Digital Strategic, TL-DW28 The
organization's legacy L, M, H (Business) Wallets Operational,
system accounts are not linked (DW) Financial, with PKIs or DLTs
associated Compliance/ with the Digital Wallet, causing Legal, lack
of operational alignment Reputational across the organization
Transactional Clearing Strategic, TL-CS1 Movement of underlying
asset L, M, H (Business) and Operational, or currency is not
synchronized Settle- Financial, with books of records. ment
Compliance/ Legal, Reputational Transactional Buisness Strategic,
TL-BU1 Transactions are not approved. L, M, H (Business) Use case
Operational, transactions Financial, Compliance/ Legal,
Reputational Transactional Buisness Strategic, TL-BU2 Transactions
are not processed L, M, H (Business) Use case Operational,
accurately, completely or within transactions Financial, approved
guidelines. Compliance/ Legal, Reputational
TABLE-US-00020 TABLE 18 In-scope/ Out-of- Scope (TBD--As Risk per
Category Domain Control/Test Objective Control Description
engagement) Transactional Smart Control(s) is in place to ensure
correct Inquire management of the In-scope (Business) Contracts
template is used for SC execution. control activities that are (SC)
in place to meet applicable risks and relevant control objectives.
Transactional Smart Control(s) is in place to ensure that required
Inquire management of the In-scope (Business) Contracts information
or standard terms and conditions control activities that are (SC)
are included in the SC before execution. in place to meet
applicable risks and relevant control objectives. Transactional
Smart Control(s) is in place to ensure that required Inquire
management of the In-scope (Business) Contracts andcorrect
participants associated with control activities that are (SC) the
SC before execution. in place to meet applicable risks and relevant
control objectives. Transactional Smart Control(s) is in place to
ensure that SC is Inquire management of the In-scope (Business)
Contracts reviewed, appraised, and approved by control activities
that are (SC) appropriate participants. in place to meet applicable
risks and relevant control objectives. Transactional Smart
Control(s) is in place to ensure that SC is Inquire management of
the In-scope (Business) Contracts executed after terms and
conditions are control activities that are (SC) met by all
participants. in place to meet applicable risks and relevant
control objectives. Transactional Smart Control(s) is in place to
ensure that required Inquire management of the In-scope (Business)
Contracts events (e.g. invoicing, payments, change or control
activities that are (SC) ownership) are initiated and completed in
place to meet applicable successfully during or after SC execution.
risks and relevant control Upon consensus, smart contracts auto-
objectives. matically executes the exchange of position and cash in
a complete, accurate and timely manner. Transactional Digital
Control(s) is in place to ensure that DAs are Inquire management of
the In-scope (Business) Assets classified and created correctly and
control activities that are (DA) successfully for transactional
level in place to meet applicable processing. risks and relevant
control objectives. Digital Control(s) is in place to ensure that
DA Inquire management of the In-scope Assets ownership is
transferred to the right/correct control activities that are (DA)
participants in a timely manner. in place to meet applicable risks
and relevant control objectives. Transactional Digital Control(s)
is in place to ensure that DA is Inquire management of the In-scope
(Business) Assets managed and maintained (e.g. classification,
control activities that are (DA) valuation, and handovers)
appropriately in place to meet applicable throughout the lifecycle.
risks and relevant control objectives. Transactional Digital
Control(s) is in place to ensure that DA is Inquire management of
the In-scope (Business) Assets retired appropriately at the end of
the control activities that are (DA) lifecycle. in place to meet
applicable risks and relevant control objectives. Transactional
Digital Control(s) is in place to ensure that valid Inquire
management of the In-scope (Business) Currency participants are
on-boarded and assigned control activities that are (DC) with a
digital wallet for DC transactions. in place to meet applicable
risks and relevant control objectives. Transactional Digital
Control(s) is in place to ensure that a payor Inquire management of
the In-scope (Business) Currency account balance is checked and
verified to control activities that are (DC) validate that
sufficient DC is available before in place to meet applicable the
transaction is processed or completed. risks and relevant control
objectives. Transactional Digital Control(s) is in place to ensure
that DC-in Inquire management of the In-scope (Business) Currency
(Cash-in) requests are processed completely control activities that
are (DC) and accurately. in place to meet applicable risks and
relevant control objectives. Transactional Digital Control(s) is in
place to ensure that DC-out Inquire management of the In-scope
(Business) Currency (Cash-out) requests are processed completely
control activities that are (DC) and accurately. in place to meet
applicable risks and relevant control objectives. Transactional
Digital Control(s) is in place to ensure that a Inquire management
of the In-scope (Business) Currency duplicate DC transactions are
not processed. control activities that are (DC) in place to meet
applicable risks and relevant control objectives. Transactional
Digital Control(s) is in place to ensure that a DC Inquire
management of the In-scope (Business) Currency transactions are
approved appropriately for control activities that are (DC)
processing. in place to meet applicable risks and relevant control
objectives. Transactional Digital Control(s) is in place to ensure
that a DC Inquire management of the In-scope (Business) Currency
transactions contain required information for control activities
that are (DC) processing. in place to meet applicable risks and
relevant control objectives. Transactional Digital Control(s) is in
place to ensure that a valid Inquire management of the In-scope
(Business) Currency unique address is generated and shared with
control activities that are (DC) appropriate participants in safe
and secure in place to meet applicable manner for DC transactions
processing. risks and relevant control objectives. Transactional
Digital Control(s) is in place to ensure that cancelled Inquire
management of the In-scope (Business) Currency and failed
transactions are monitored, control activities that are (DC)
processed and recorded in the books in place to meet applicable
accurately. risks and relevant control objectives. Transactional
Digital Control(s) is in place to ensure that DC is Inquire
management of the In-scope (Business) Currency moved from one
participant to the other (e.g. control activities that are (DC)
payee and payor) correctly and in a timely in place to meet
applicable manner. Also, the movement of DC is risks and relevant
control recorded in the books of records accurately. objectives.
Transactional Digital Control(s) is in place to ensure that DC is
Inquire management of the In-scope (Business) Currency evaluated
correctly relative to underlying control activities that are (DC)
asset or currency in a timely manner. in place to meet applicable
risks and relevant control objectives. Transactional Clearing
Control(s) is in place to ensure that books Inquire management of
the In-scope (Business) and of records are updated when the
underlying control activities that are Settlement asset or currency
is processed. Reconcil- in place to meet applicable iation and
verification between books of risks and relevant control records
and underlying asset or currency objectives. position is performed
to validate integrity, accuracy and completeness of transactional
and business information. Control(s) is in place to ensure that
trades/transactions processing meet the following financial
statements assertion requirements: 1--Rights and obligations
2--Completeness, accuracy, cutoff 3--Existence 4--Valuation
Transactional Business Control(s) is in place to ensure that
business Inquire management of the In-scope (Business) Use case
transactions are authorized and executed in control activities that
are transactions accordance with approved guidelines. in place to
meet applicable risks and relevant control objectives.
Transactional Business Control(s) is in place to ensure that
trades/ Inquire management of the In-scope (Business) Use case
transactions meet the following financial control activities that
are transactions statements assertion requirements: in place to
meet applicable 1--Rights and obligations risks and relevant
control 2--Completeness, accuracy, cutoff objectives. 3--Existence
4--Valuation
TABLE-US-00021 TABLE 19 Re- Test Type quest Risk (TBD--As List
Category Domain Test Procedure (#) per engagement) (#)
Transactional Smart Based on the inquiry of the Inquiry,
Inspection, (Business) Contracts management regarding the control
observation, and/or (SC) activities in place assessment Automated
results test procedures will be designed and data parameters will
be identified to configure and operationalize the Blockchain
Auditing software Transactional Smart Based on the inquiry of the
Inquiry, Inspection, (Business) Contracts management regarding the
control observation, and/or (SC) activities in place assessment
Automated results test procedures will be designed and data
parameters will be identified to configure and operationalize the
Blockchain Auditing software Transactional Smart Based on the
inquiry of the Inquiry, Inspection, (Business) Contracts management
regarding the control observation, and/or (SC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Smart Based on the
inquiry of the Inquiry, Inspection, (Business) Contracts management
regarding the control observation, and/or (SC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Smart Based on the
inquiry of the Inquiry, Inspection, (Business) Contracts management
regarding the control observation, and/or (SC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Smart Based on the
inquiry of the Inquiry, Inspection, (Business) Contracts management
regarding the control observation, and/or (SC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Digital Based on the
inquiry of the Inquiry, Inspection, (Business) Assets management
regarding the control observation, and/or (DA) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Digital Based on the inquiry of
the Inquiry, Inspection, Assets management regarding the control
observation, and/or (DA) activities in place assessment Automated
results test procedures will be designed and data parameters will
be identified to configure and operationalize the Blockchain
Auditing software Transactional Digital Based on the inquiry of the
Inquiry, Inspection, (Business) Assets management regarding the
control observation, and/or (DA) activities in place assessment
Automated results test procedures will be designed and data
parameters will be identified to configure and operationalize the
Blockchain Auditing software Transactional Digital Based on the
inquiry of the Inquiry, Inspection, (Business) Assets management
regarding the control observation, and/or (DA) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Digital Based on the
inquiry of the Inquiry, Inspection, (Business) Currency management
regarding the control observation, and/or (DC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Digital Based on the
inquiry of the Inquiry, Inspection, (Business) Currency management
regarding the control observation, and/or (DC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Digital Based on the
inquiry of the Inquiry, Inspection, (Business) Currency management
regarding the control observation, and/or (DC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Digital Based on the
inquiry of the Inquiry, Inspection, (Business) Currency management
regarding the control observation, and/or (DC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Digital Based on the
inquiry of the Inquiry, Inspection, (Business) Currency management
regarding the control observation, and/or (DC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Digital Based on the
inquiry of the Inquiry, Inspection, (Business) Currency management
regarding the control observation, and/or (DC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Digital Based on the
inquiry of the Inquiry, Inspection, (Business) Currency management
regarding the control observation, and/or (DC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Digital Based on the
inquiry of the Inquiry, Inspection, (Business) Currency management
regarding the control observation, and/or (DC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Digital Based on the
inquiry of the Inquiry, Inspection, (Business) Currency management
regarding the control observation, and/or (DC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Digital Based on the
inquiry of the Inquiry, Inspection, (Business) Currency management
regarding the control observation, and/or (DC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Digital Based on the
inquiry of the Inquiry, Inspection, (Business) Currency management
regarding the control observation, and/or (DC) activities in place
assessment Automated results test procedures will be designed and
data parameters will be identified to configure and operationalize
the Blockchain Auditing software Transactional Clearing Based on
the inquiry of the Inquiry, Inspection, (Business) and management
regarding the control observation, and/or Settle- activities in
place assessment Automated ment results test procedures will be
designed and data parameters will be identified to configure and
operationalize the Blockchain Auditing software Transactional
Business Based on the inquiry of the Inquiry, Inspection,
(Business) Use case management regarding the control observation,
and/or transac- activities in place assessment Automated tions
results test procedures will be designed and data parameters will
be identified to configure and operationalize the Blockchain
Auditing software Transactional Business Based on the inquiry of
the Inquiry, Inspection, (Business) Use case management regarding
the control observation, and/or transac- activities in place
assessment Automated tions results test procedures will be designed
and data parameters will be identified to configure and
operationalize the Blockchain Auditing software
[0152] In one or more embodiments, the blockchain risk framework is
designed to produce testing procedures that align with a technology
stack associated with a blockchain. FIG. 5A illustrates a
correspondence between the testing procedures produced by a risk
framework and a technology stack of a blockchain system according
to examples of the disclosure. In FIG. 5A, a block chain use-case
technology stack can include multiple technology stacks that are
integrated together to form the overall blockchain computing
system. For instance in the example of FIG. 6, a block-chain
use-case technology stack 600 can include an application layer 502,
encryption (cryptography) layer 506, a permissioned or
unpermissioned network layer (i.e., operational layer) 508, a
shared data layer 510, a commercial API layer 512, and an overlay
network layer 514.
[0153] In one or more examples, an application layer 502 can
include decentralized applications (i.e., a digital application or
program) that can be run by many users or nodes on a decentralized
network with consensus and other trustless protocols. They can be
designed to avoid any single point of failure. The applications in
the application layer provide workflow and processing logic to
execute transactional activity using shared communications
protocols and interface methods used by hosts in a communications
network.
[0154] In one or more examples, an encryption (cryptography) layer
506 can include cryptography used to cipher (encrypt) and de-cipher
(decrypt) information by using a mathematical function or
algorithm. Encryption can refer to the process of transforming
information so it is unintelligible/inaccessible/unreadable to
anyone but the intended recipient. Decryption is the process of
transforming encrypted information so that it is
intelligible/accessible/readable again.
[0155] In one or more examples, a permissioned or unpermissioned
network layer 508 can refer to both permissioned networks and
unpermissioned networks. Unpermissioned networks can refer to an
open blockchain network that anyone can join and participate in.
The community operates and administers the blockchain, and one or
more participants can provide consensus. Any user can join a
permissionless network, i.e., exchanging digital currency on a
public currency exchange. A permissioned network refers to a
blockchain model that requires permission to join, read, write to,
operate and administer. Multiple participants administer the
blockchain under consortium or group leadership. There may be
restrictions on how participants can contribute to the system state
or consensus of transactions. In one or more examples network layer
508 can also include private blockchains. In a private blockchain,
only a centralized entity or single participant has permission to
write to the blockchain. Platform architects can decide how to
assign permissions.
[0156] In one or more examples, shared data layer 510 can include
organized collections of data that are stored and accessed
electronically. In one or more example a commercial API layer 512
can include elements dealing with an interface in software that can
act as a shared boundary across which two or more separate
components of a computer system exchange information. The exchange
can be between software, computer hardware, peripheral devices,
humans and combinations of these. Finally, in one or more examples,
an overlay network layer 514 includes different types of LAN and
WAN networks that are used to access the blockchain system. The
network layer provides the means of transferring variable-length
network packets from a source to a destination host via one or more
networks.
[0157] One or more of the risk categories described above can
correspond to one or more layers of the stack 500. For instance, in
the example of FIG. 5A, transaction layer risks 518 can correspond
to the application layer 502 of the stack 500. This can mean that
test procedures created in response to the "transactional layer"
risk framework can create test procedures that validate the
application layer of the blockchain use-case stack 500. Likewise,
blockchain architecture layer risks 514 can generate test
procedures that test and validate the decentralized protocols layer
504, and the encryption layer 506. The operation layer risks 520
can generate tests that can validate and test permissioned network
layer 508. Finally the infrastructure layer risks 516 of the risk
framework can create test procedures that can validate and test
shared data layer 510, commercial API layer 512, and overlay
network 514.
[0158] FIG. 5B illustrates sub-categories corresponding to each
risk framework category according to examples of the disclosure. As
illustrated in FIG. 5B, each category of risk can include one or
more subcategories. For instance, the governance and oversight risk
category 530 can include one or more sub-categories including (but
not limited to): business objectives, program sponsorship,
leadership commitment, MIS and metrics, program management,
operational and capital expenditure oversight, and project
management. The cyber security risk category 530 can include one or
more sub-categories including (but not limited to): cloud security,
data security, data privacy, penetration testing, programming
security, network security, patch vulnerability, threat detection,
and threat response. The infrastructure risk category 534 can
include one or more sub-categories including (but not limited to):
servers and databases configuration, ITGCs, business continuity and
disaster recovery, and IT asset management. The transactional layer
risk category 536 can include one or more sub-categories including
(but not limited to): smart contracts, digital assets, digital
currency, cleaning and settlement, business use and case
transactions. The operation layer risk category 538 can include one
or more sub-categories including (but not limited to): permissioned
network management, participant over boarding and off-boarding,
application layer, blockchain consensus program management, and
integration with off-blockchain systems and processes. Finally the
blockchain architecture risk category 540 can include one or more
sub-categories including (but not limited to): blockchain platform
and protocol configuration, hardware security modules, signature
management, cryptography, scalability, and availability.
[0159] In some embodiments, the results (i.e. testing procedures
and parameters) of an assessment performed using the blockchain
risk framework can be used to consolidate the audit and compliance
activities into categories by nature of activity at the transaction
layer and embed them into an validating software/tool. By drawing
data from the underlying blockchain ledger as well as from other up
and down stream systems affecting the use case, any and all
necessary audit or assurance based procedures can be fully automate
and active transparency for them on a real time basis (or some
other cadence if preferred) can be provided to the
practitioner.
[0160] As illustrated in the discussion above, the risk framework
can provide a user interface that translates a user's blockchain
auditing preferences into tangible tests and procedures that are
then used to perform real-time continuous monitoring of the block
chain system. FIG. 6 illustrates an exemplary process for
generating blockchain test procedures according to examples of the
disclosure. The process 600 described with respect to FIG. 6 can be
performed on a computing system that includes a display and devices
that are configured to accept input from a user such as a keyboard,
touchpad, mouse, etc.
[0161] The process can begin at step 602, wherein the user is
presented with the risk framework and is prompted by the risk
framework to specify a risk level associated with each risk
category and sub-category as described above. Once the user
specifies the risk levels, the process can move to step 604 wherein
the user can be presented with a series of controls of the
blockchain that relate to the risks identified in step 602 (as
described above). When presented with the series of controls, the
user can then be prompted by the risk framework to input which
controls are to be in-scope of the assessment, and which ones are
to be considered out of scope as described above.
[0162] Once the user indicates which controls are in scope versus
out of scope at step 604, the process can move to step 606, wherein
the risk framework generates one or more test procedures based on
the user's inputs into the risk framework. Once the tests are
generated at step 606, the process can move to step 608 wherein the
test procedures are transmitted to an external user. In one or more
examples, transmitting the test procedures can include generating a
planning file that can be used by a validation software (like the
one described with respect to FIG. 4) to perform real-time and
continuous validation of a blockchain.
[0163] FIG. 7 illustrates an example of a computing device in
accordance with one embodiment. Device 700 can be a host computer
connected to a network. Device 700 can be a client computer or a
server. As shown in FIG. 7, device 700 can be any suitable type of
microprocessor-based device, such as a personal computer,
workstation, server, or handheld computing device (portable
electronic device) such as a phone or tablet. The device can
include, for example, one or more of processor 710, input device
720, output device 730, storage 740, and communication device 760.
Input device 720 and output device 730 can generally correspond to
those described above and can either be connectable or integrated
with the computer.
[0164] Input device 720 can be any suitable device that provides
input, such as a touch screen, keyboard or keypad, mouse, or
voice-recognition device. Output device 730 can be any suitable
device that provides output, such as a touch screen, haptics
device, or speaker.
[0165] Storage 740 can be any suitable device that provides
storage, such as an electrical, magnetic, or optical memory,
including a RAM, cache, hard drive, or removable storage disk.
Communication device 760 can include any suitable device capable of
transmitting and receiving signals over a network, such as a
network interface chip or device. The components of the computer
can be connected in any suitable manner, such as via a physical bus
or wirelessly.
[0166] Software 750, which can be stored in storage 740 and
executed by processor 710, can include, for example, the
programming that embodies the functionality of the present
disclosure (e.g., as embodied in the devices as described
above).
[0167] Software 750 can also be stored and/or transported within
any non-transitory computer-readable storage medium for use by or
in connection with an instruction execution system, apparatus, or
device, such as those described above, that can fetch instructions
associated with the software from the instruction execution system,
apparatus, or device and execute the instructions. In the context
of this disclosure, a computer-readable storage medium can be any
medium, such as storage 740, that can contain or store programming
for use by or in connection with an instruction execution system,
apparatus, or device.
[0168] Software 750 can also be propagated within any transport
medium for use by or in connection with an instruction execution
system, apparatus, or device, such as those described above, that
can fetch instructions associated with the software from the
instruction execution system, apparatus, or device and execute the
instructions. In the context of this disclosure, a transport medium
can be any medium that can communicate, propagate, or transport
programming for use by or in connection with an instruction
execution system, apparatus, or device. The transport readable
medium can include, but is not limited to, an electronic, magnetic,
optical, electromagnetic, or infrared wired or wireless propagation
medium.
[0169] Device 700 may be connected to a network, which can be any
suitable type of interconnected communication system. The network
can implement any suitable communications protocol and can be
secured by any suitable security protocol. The network can comprise
network links of any suitable arrangement that can implement the
transmission and reception of network signals, such as wireless
network connections, T1 or T3 lines, cable networks, DSL, or
telephone lines.
[0170] Device 700 can implement any operating system suitable for
operating on the network. Software 750 can be written in any
suitable programming language, such as C, C++, Java, or Python. In
various embodiments, application software embodying the
functionality of the present disclosure can be deployed in
different configurations, such as in a client/server arrangement or
through a Web browser as a Web-based application or Web service,
for example.
[0171] The foregoing description, for purpose of explanation, has
been described with reference to specific embodiments. However, the
illustrative discussions above are not intended to be exhaustive or
to limit the disclosure to the precise forms disclosed. Many
modifications and variations are possible in view of the above
teachings. The embodiments were chosen and described in order to
best explain the principles of the techniques and their practical
applications. Others skilled in the art are thereby enabled to best
utilize the techniques and various embodiments with various
modifications as are suited to the particular use contemplated.
[0172] Although the disclosure and examples have been fully
described with reference to the accompanying figures, it is to be
noted that various changes and modifications will become apparent
to those skilled in the art. Such changes and modifications are to
be understood as being included within the scope of the disclosure
and examples as defined by the claims.
[0173] This application discloses several numerical ranges in the
text and figures. The numerical ranges disclosed inherently support
any rage or value within the disclosed numerical ranges, including
the endpoints, even though a precise range limitation is not stated
verbatim in the specification because this disclosure can be
practiced throughout the disclosed numerical ranges.
[0174] The above description is presented to enable a person
skilled in the art to make and use the disclosure and is provided
in the context of a particular application and its requirements.
Various modifications to the preferred embodiments will be readily
apparent to those skilled in the art, and the generic principles
defined herein may be applied to other embodiments and applications
without departing from the spirit and scope of the disclosure.
Thus, this disclosure is not intended to be limited to the
embodiments shown, but is to be accorded the widest scope
consistent with the principles and features disclosed herein.
Finally, the entire disclosure of the patents and publications
referred in this application are hereby incorporated herein by
reference.
* * * * *