This is an old revision of the document!
The biggest Risks to the CBDC is the related to the Information Technology(IT) infrastructure for the CBDC and the need to ensure the CBDC meets the quality expectations of the U.S. Federal Reserve and the public. For example, the White Paper Desirements
B0020 is about establishing maintaining public confidence as a priorityB0027 and B0050 are about establishing a priority on safe and trusted central bank moneyR0011 is concerned about loss, theft, and fraudThese are unique problems to The Federal Reserve or to U.S. CBDC. These problems have been addressed by standards aimed at minimizing risk to projects heavily dependent on Software:
See the the OMG DIDO-RA section on:
The difference between Specification and Standard is a specification is an explicit set of requirements to be satisfied by a material, product, or service. A Standard is a principle or example or measure used for comparison.
A Specification are statements detailing requirements of a system or product that should or must* be satisfied depending on the regulatory or contractual context. The Specification includes work products such as the definition of Protocols, Application Programming Interfaces (API) or the definition of processes. A Standard is a specification established by institutions such as Standards Developing Organization (SDO) or a Voluntary Standards Consensus Body (VSCB). Standards can be classified as Technical or de facto Standards.
==== ISO, IEC, IEEE Standards ====
Return to Top
The purpose of ISO/IEC 25000 is to provide a general overview of SQuaRE contents, common reference models and definitions, as well as, the relationship among the documents, and allow users of the Guide to gain a good understanding of how to use this series of standards. It also contains an explanation of the transition process between the old ISO/IEC 9126 and the newer ISO/IEC 14598 series and SQuaRE.
<figure>
<caption>Quality Characteristics and Measures Specifications</caption>
</figure>
* ISO 9001:2015 Quality management
* ISO/IEC/IEEE 90003:2018 Software engineering – Guidelines for the application of ISO 9001:2015 to computer software
* ISO/IEC/IEEE 25000:2014 SQuaRE -- Guide to SQuaRE
* ISO/IEC 25001:2014 SQuaRE -- Planning and Management
* ISO/IEC 25010:2011 SQuaRE -- System and Software Quality Models
* ISO/IEC 25012:2008 SQuaRE -- Data Quality Model
* ISO/IEC 25020:2007 SQuaRE -- Measurement Reference Model and Guide
* ISO/IEC 25021:2012 SQuaRE -- Quality Measure Elements
* ISO/IEC 25022:2016 SQuaRE -- Measurement of Quality in Use
* ISO/IEC 25023:2016 SQuaRE -- Measurement of System and Software Product Quality
* ISO/IEC 25024:2015 SQuaRE -- Measurement of Data Quality
* ISO/IEC 25030:2007 SQuaRE -- Quality Requirements
* ISO/IEC 25040:2011 SQuaRE -- Evaluation Process
* ISO/IEC 25041:2012 SQuaRE -- Evaluation Guide for Developers, Acquirers and Independent Evaluators
* ISO/IEC 25045:2010 SQuaRE -- Evaluation Module for Recoverability
* ISO/IEC/IEEE 15288:2015 Systems and software engineering -- System life cycle processes
==== Object Management Group (OMG) Standards and Consortium for Information & Software Quality (CISQ) ====
Return to Top
The Consortium for Information & Software Quality (CISQ) develops international standards to automate the measurement of software from source code. Industry needs standard, low-cost, automated measures for evaluating software size and structural quality that can be used to control the quality, cost, and risk of software produced internally or by third parties.
Automation is critical because manual review is infeasible for large multi‐layer, multi‐language, multi‐platform systems. Additionally, DevOps greatly speeds up the deployment of applications, some changing on a daily or even hourly basis, which may result in unintended vulnerabilities without review.
* OMG: Automated Source Code CISQ Maintainability Measure (ASCMM)
* OMG: Automated Source Code CISQ Measures (ASCQM)
* OMG: Automated Source Code CISQ Performance Efficiency Measure (ASCPEM)
* OMG: Automated Source Code CISQ Reliability Measure (ASCRM)
* OMG: Automated Source Code CISQ Security Measure (ASCSM)
* OMG: CISQ Automated Enhancement Points (AEP)
* OMG: CISQ Automated Function Points (AFP)
* OMG: CISQ Automated Technical Debt Measure (ATDM)
The Case Management Model and Notation (CMMN) specification defines a common meta-model and notation for modeling and graphically expressing a Case, as well as an interchange format for exchanging Case models among different tools. The specification is intended to capture the common elements that Case management products use, while also taking into account current research contributions to Case management. It is to case management products what the OMG Business Process Model and Notation (BPMN) specification is to business process management products. This specification is intended to be consistent with and complementary to BPMN.
* OMG: Case Management Model and Notation (CMMN)
The Structured Assurance Case Metamodel (SACM) specification defines a metamodel for representing structured assurance cases. An Assurance Case is a set of auditable claims, arguments, and evidence created to support the claim that a defined system/service will satisfy the particular requirements. An Assurance Case is a document that facilitates information exchange between various system stakeholder such as suppliers and acquirers, and between the operator and regulator, where the knowledge related to the safety and security of the system is communicated in a clear and defendable way. Each assurance case should communicate the scope of the system, the operational context, the claims, the safety and/or security arguments, along with the corresponding evidence.
* OMG: Structured Assurance Case Metamodel (SACM)
The Test Information Interchange Format (TestIF) goal is to achieve a specification that defines the format for the exchange of test information among tools, applications, and systems that utilize it. The term “test information” is deliberately vague, because it includes the concepts of tests (test cases), test results, test scripts, test procedures, and other items that are normally documented as part of a software test effort. The long term goal is to standardize the exchange of all test related artifacts produced or consumed as part of the testing process,
* OMG: Test Information Interchange Format (TestIF)
==== State of Data ====
Return to Top
Data can exist in many states depending on how it is being used. The risks and concerns about Data in each of its different states are also important. Often, the primary focus for understanding data is to concentrate on Data-at-Rest . Even though data tends to remain relatively static, it can change over time. In the past, there was little concern for Data-in-Motion , which can have serious effects on Reliability, Maintainability, and Availability (RAM), as well as, Securability and can leave a system vulnerable to breaches. With the advent of HTTPS, these vulnerabilities are mitigated. The latest issue has become the need to secure Data-in-Use. A recent WhatsApp data breach1) found that switching data between image filters could cause memory corruption followed by a crash that left data exposed.
Figure ##REF:DataStateFigure## graphically represents the different Data States within a system. Most systems are now able to handle Data-in-Motion and Data-at-Rest issues but have traditionally relied on physical security to protect Data-in-Use.
<figure DataStateFigure>
<caption>The various States of Data</caption>
</figure>
Table ##REF:dataStateTable## provides a quick overview of the various data states. These data states are described in detail in the OMG DIDO-RA.
<table dataStateTable>
<caption>Data can exist in the following different states</caption>
|< 100% 20% >|
^ Data-at-Rest |
Data-at-Rest refers to all data in computer storage. It excludes data while it is moving across or within a network, and it excludes data that is temporarily residing in computer memory.
| ^ Data-in-Motion |
Data-in-Motion , also referred to as Data in Transit or Data in Flight, is a Digital Asset transmitted between locations (i.e., between computers or computer components). Data-In-Motion also describes data within Random Access Memory (RAM).
| ^ Data-in-Use |
Data-in-Use covers data being processed (i.e., updated, processed, erased, accessed or read) by a system. Data-In-Use is not passively stored, but is actively moving through parts of a Computing Platform (i.e., Central Processing Unit (CPU), Dynamic Random Access Memory (DRAM),, Data Bus, etc.). Data-In-Use is one of three states of digital data – the other states are Data-at-Rest and Data-in-Motion.
| </table> ===== Examples ===== Return to Top Some “desirements” in the Money and Payments: The U.S. Dollar in the Age of Digital Transformation White Paper and relating to Operational or Cyber Risks are summarized in the White Paper Analysis done by the Object Management Group and listed in Table ##REF:opCyberRiskReq##. <table opCyberRiskReq> <caption>List of Operational or Cyber Risks Desirements identified in the White Paper</caption> |< 100% 20% →| ^ Category ^ Desirements ^ ^ Benefits | B0020, B0027, B0048, B0050, B0053, B0054 | ^ Policy Considerations | P0012, P0017, P0020, P0021, P0025, P0027, P0028 | ^ Risks | R0011 | ^ Design | D0015, D0016, D0017 | </table> ===== Discussion of Examples ===== Return to Top Table ##REF:opCyberRiskReqComment## comments on those “desirements” identified by the White Paper and the OMG's White Paper Analysis relating to Central Bank Digital Currency (CBDC) Operational or Cyber Risks. See: Table 5 in Section 4.1 Stakeholders. <table opCyberRiskReqComment> <caption>List of “desirements” that allude to stakeholders</caption> |< 100% 5% 45% 50%→| ^ Desirement No. ^ Desirement Text ^ Comment ^ ^ B0020 ^ Maintain public confidence by not requiring mechanisms, such as deposit insurance |
This is highly dependent on the Currency Model used for the CBDC. If it is Digital Cash Model then the need for deposit money is nil, since there are no deposits (i.s., just like there is no insurance on U.S. Dollars).
However, if it is based on a Digital Account Model, then by definition there are accounts, and by experience, deposit insurance is required to stabilize (See: R0012) the assets stored in those accounts. Deposit insurance provides three important benefits to the economy:2)
B0007, B0019, B0027, B0050)R0009, R0012)R0001, R0003, R0018)| ^ B0027 ^ Maintain the centrality of safe and trusted central bank money |
Safety and trust are both about perceived risk.
Therefore, the key is to manage risk, which is the probability or threat of damage, injury, liability, loss, or any other negative occurrence caused by external or internal vulnerabilities, and that may be avoided through preemptive action.
The goal of Systems Engineering is to manage risk, including the risk of not delivering what the customer wants and needs, the risk of late delivery, the risk of excess cost, and the risk of negative unintended consequences. One measure of the utility of Systems Engineering activities is the degree to which such risk is reduced. Conversely, a measure of acceptability of the absence of a System Engineering activity is the level of excess risk incurred as a result.
| ^ B0048 ^ Provide a secure way for people to save |
In the U.S., savings accounts are a safe place since deposits (with limits) are guaranteed by Federal Deposit Insurance Corporation (FDIC) or the National Credit Union Administration (NCUA).
Additionally, Certificates of Deposit (CDs) and U.S. government securities are also considered safe savings places. Both of these options offer some return on money. However, money safety is often associated with a high degree of liquidity, and relatively low fees.
| ^ B0050 ^ Extend Public Access to Safe Central Bank Money |
P0018P0019| ^ B0053 ^ Provide resiliency to threats to existing payment services—including:
|
| ^ B0054 ^ Attract risk-averse users to CBDC |
The term Risk-Averse describes the investor who chooses the preservation of capital over the potential for a higher-than-average return. In investing, risk equals price volatility. A volatile investment can make you rich or devour your savings. A conservative investment will grow slowly and steadily over time. https://www.investopedia.com/terms/r/riskaverse.asp
| ^ P0012 ^ The firms that operate interbank payment services are subject to federal supervision |
See the detailed discussion in section 4.5 National Security Considerations.
| ^ P0017 ^ The PWG report recommends CBDC complement existing authorities regarding:
|
See:
| ^ P0020 ^ The private sector would offer accounts or digital wallets to facilitate the management of CBDC holdings and payments |
Although the private sector is more than willing to take on this role, without some assurance that the wallets cannot be hacked and any losses will be covered by insurance, achievement of this desirement will probably have limited success.
Hacks and data breaches happen almost daily. Cryptocurrency exchange hacks are particularly damaging because it affects thousands of users and involves the loss of funds. 4).
in 2019, there was a hack of a South Korean exchange that suffered a \$51 million dollar breach. The stolen crypto has been on the move. It is moving between wallets, although it is unclear what purpose this will serve.
At the current time, it is easy for exchanges or wallets to make lots of claims about security, but until there is a detailed assurance claim model to substantiate the claims, the promises are hollow.
See:
| ^ P0021 ^ The intermediaries would operate in an open market for CBDC services |
The lion's share of U.S. CBDC intermediaries will be building, delivering, and offering the services of software applications. This is not unlike the current situation in the smartphone world. However, the intermediary's applications will have to run not just on the smartphones, but also on personal computers, servers, and mainframes. The Federal Reserve and a U.S. CBDC must be able to achieve and retain the confidence of consumers that these applications are sufficiently robust and provide reliable security to hold their vital assets.
Therefore, there is a need for a U.S. CBDC “application store” to act as a web portal through which end users can access, download and install U.S. CBDC-approved software applications that rigorous Assurance Case Models with which the quality and security of these applications is validated.
See:
| ^ P0025 ^ CBDC intermediary would need to verify the identity of a person accessing CBDC |
| ^ P0027 ^ CBDC a risk-free asset |
The risk-free rate of return is the theoretical rate of return of an investment with zero risk. The risk-free rate represents the interest an investor would expect from an absolutely risk-free investment over a specified period of time.
The so-called “real” risk-free rate can be calculated by subtracting the current inflation rate from the yield of the Treasury bond matching your investment duration. https://www.investopedia.com/terms/r/risk-freerate.asp
| ^ P0028 ^ Require significant international coordination to address issues such as:
|
| ^ R0011 ^ Increased Risk to consumer's vulnerability to:
|
If the U.S. CBDC avoids most of the safeguards built into the current U.S. financial system, then there is an increased risk of loss, theft, and fraud. Most of the laws and regulations outlined in section 4.5 National Security Considerations have evolved over time in response to consumer demand for protection. Although it seems appealing, more efficient, and even “modern”, consumers should demand the same level of protection from a U.S.-based CBDC.
According to Ryan Browne of CNBC7)
| ^ D0015 ^ Design should include any dedicated infrastructure required to provide resilience to threats such as operational disruptions and cybersecurity risks |
In order to protect data during all aspects of data handling and processing, there will most likely need to be new network hardware, computer processors, and even new encryption algorithms based on Quantum Computing's ability to crack encryption.
See:
| ^ D0016 ^ Design should include offline capabilities to help with the operational resilience of the payment system |
| ^ D0017 ^ Design should include digital payments in areas suffering from large disruption, such as natural disasters |
|
| B = Benefit Considerations |||
| P = Policy Considerations |||
| R = Risk Considerations |||
| D = Design Considerations |||
</table>
[nick]Need to explain difference between "specification" and "standard" better. Should be included in Glossary. Suggests that perhaps the term "specification standard" would be better given that the government tends to treat 'standards' and 'specifications' as equivalent. (from Steve McL)
[nick]Suggestion to add glossary items from Table 1 should be ignored given that these terms are defined in the DIDO RA glossary and a link is provided to it. In fact, the rule should be that if a term is already linked to a glossary item in the DIDO RA, there is no need to clutter up the Glossary for this report with them. (From Steve McL)
~~DISCUSSION:on|Outstanding Issues~~
~~DISCUSSION:off~~