The GBA is developing the Blockchain Maturity Model (BMM) and we need your input.
We are currently working on the section of the model related to security. Below is an extract of the model and we ask you to read it and provide your feedback in the form below.
The purpose of the model is to provide a set of criteria for any blockchain solution. The BMM forms the basic layer of criteria. GBA Working Groups are also developing supplemental criteria that is domain-specific. For example:
The BMM has two types of requirements and expectations for assessment. They are Generic requirements and domain-specific requirements. Generic requirements refer to the set of elements that a blockchain solution should have for it to be a reliable solution. Domain-specific is a set of elements that are necessary for the application of blockchain technology for specific domains.
For a solution to be reliable for use by organizations, it must be capable of meeting requirements and expectations in the following Elements:
- Identity Management
Within each element, there are five levels. The five levels relate to degrees of reliability and dependability for the given element or domain-specific element. The five levels are:
|Level 1: Feasible||Suitable to assess readiness for research funding|
|Level 2: Functional||Suitable to assess functional readiness for proof-of-concept deployment|
|Level 3: Operational||Suitable to assess if a solution is ready for operational deployment – Documenting and recording|
|Level 4: Scalable||Suitable to assess scalability for enterprise-level deployment|
|Level 5: Sustainable||Suitable to assess sustainability for global-level deployment.|
To be assessed at any level, all expectations of that level, and below must be met for all of the capabilities.
The goal of security in a blockchain solution is to provide assurance that adequate controls address and mitigate the security risks of its key components, composed of nodes, consensus mechanisms, infrastructure/network, system, and smart contracts.
The table below describes the requirements associated with each level. The subparagraphs below the table provide the expectations and outcomes for each level depicted in the table.
|Level 1: Feasible||Security objectives and controls for confidentiality, integrity, availability. and partition tolerance is defined for each component of the blockchain solution. Project Charter for Security shall be demonstrated.|
|Level 2: Functional||Security objectives and controls are defined and documented for each component of the blockchain solution.|
A risk assessment methodology and plan is established.
|Level 3: Operational||Security objectives and controls are defined, documented, and tested for each component of the blockchain solution.|
A risk assessment is conducted, documented, and implementing the controls and document the residual risks.
|Level 4: Scalable||Security objectives and controls are defined, documented, and tested for each component of the blockchain solution. A technical vulnerability assessment is conducted, and mitigating controls are implemented at the enterprise level.|
|Level 5: Maintainable||Security objectives and controls are defined, documented, and tested for each component of the blockchain solution. A technical vulnerability assessment is conducted, and mitigating controls are implemented at the global level.|