The present disclosure relates generally to validation of distributed data storage systems, such as, for example, blockchain-based data storage systems.
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.
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.
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.
As shown in
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.
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.
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.
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.
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.
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.
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.
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.
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
In some embodiments of the method, the validity test is selected based on the risk categories.
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.
In some embodiments of the method, the one or more data activities comprise storing one or more data in the data block.
In some embodiments of the method, the performing the validity test comprises performing the validity test continuously on the stored one or more data.
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.
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.
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.
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.
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
In some embodiments of the system, the validity test is selected based on the risk categories.
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.
In some embodiments of the system, the one or more data activities comprises storing one or more data in the data block.
In some embodiments of the system, the validity test is performed continuously on the stored one or more data.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Peripheral devices may include any type of computer support device that adds additional functionality to the computer system.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
In one or more embodiments, the validation system created by the process described with respect to
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.
Planning Phase: In some embodiments, steps 302, 304, and 306 of
Fieldwork Phase: In some embodiments, step 308 and 310 of
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.
Reporting Phase: In some embodiments, step 310 of
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.
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).
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.
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).
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.).
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).
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.).
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
To illustrate the functionality of the components contained within system 400, a description of the data flow in the architecture of
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:
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.).
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.).
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.
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.
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.
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.
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.
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.
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.
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.
Referring back to
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.
In some embodiments, determining the acceptance criteria (may be referred to as assurance threshold formula) may include the five steps discussed below.
1—Purpose (P1)—Gain an understanding of the blockchain use case, business purpose, and the resultant effect on the risks and control objectives.
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.
3—Risks (Rs)—Assess the blockchain architecture variant and identify applicable control objectives using the blockchain risk framework.
4—Stakeholder (Sr)—Identify assurance related stakeholders, determine and inventory their expectations and needs for reporting purposes.
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.
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
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.
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.
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.
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.
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.
Some examples of stakeholders provided below:
Risk Categories:
In Some Embodiments, Some Examples of Risk Categories and their relevant domains are provided in Table 1.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
Number | Date | Country | |
---|---|---|---|
62579093 | Oct 2017 | US | |
62579095 | Oct 2017 | US |