The OMG's CBDC WG members recommend the Federal Reserve define a task to ensure that Security is baked into the U.S. CBDC rather than trying to post facto add it later (i.e bolted-on).
Also see the answers to:
Cryptocurrency skirts near the edges of illegal, illicit, or shady interactions and transactions. The Chainalysis Team recently published their 2021 findings1) which highlights some security issues associated with the unregulated or poorly regulated Cryptocurrency realm. The following is an excerpt from the report:
Therefore, security needs to be “baked into” the CBDC from the onset and can not be an afterthought; however, it is hard to balance the tightrope between the need for Privacy and the need for Security. This difficulty in achieving a balance has been captured in Desirement
|R0014||Risk of not achieving an appropriate balance between safeguarding the privacy rights of consumers and affording the transparency necessary to deter criminal activity|
Regardless of which model ( Digital Accounts, Stablecoins, Digital Cash) is used for the CBDC, the Object Management Group's CBDC WG recommends that the Federal Reserve consider Seurity of the system from the earliest phases of the U.S. CBDC. This means having the Non-Functional requirement of Security be well defined and formal.
One way to accomplish this is through the use of a Model-Based Systems Engineering (MBSE) and Unified Architecture Framework (UAF) to model all aspects of the CBDC before it is built. Since the requirements for the security of the system are a moving, ever-changing target, this does not mean that every security issue must be fully understood or specified before work can begin. It means that at every step, the Security question needs to be raised. The CBDC is a complex issue that, once released, could have a life expectancy of many, many years. Only through extensive Systems Analysis, Engineering, and Design will the CBDC have the stability it needs to instill confidence in the public.
During system development, MBSE and UAF models of the system are used along with Use Scenarios and Use Cases to flush out potential problems. This means thinking about all aspects of the State of Data throughout its lifecycle. The OMG DIDO-RA has detailed discussions of the various states of data and how it relates to a distributed system.
Figure 1 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.
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-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.
|Statement No.||Page No.||Statement|
|B0004||2||Protect consumer privacy|
|B0005||2||Protect against criminal activity|
|B0053||20|| Provide resiliency to threats to existing payment services—including:
|R0011||11|| Increased Risk to consumer's vulnerability to:
|D0015||20||Design should include any dedicated infrastructure required to provide a resilience to threats such as operational disruptions and cybersecurity risks|
|D0016||20||Design should include offline capabilities to help with operational resilience of the payment system|
|D0017||20||Design should include digital payments in areas suffering from large disruption, such as natural disasters|