Differences

This shows you the differences between two versions of the page.

--- cbdc:public:cbdc_omg:04_doc:20_comments:brp:q11:start [2022/04/24 15:28]
nick [8. Risk of Business Processes Being Hacked]
+++ cbdc:public:cbdc_omg:04_doc:20_comments:brp:q11:start [2022/06/17 18:59] (current)
terrance
@@ Line 1: / Line 1: @@
-====== Question: 11. TBD Are there additional ways to manage potential risks associated with CBDC that were not raised in this paper? ======
+====== Question: 11. Are there additional ways to manage potential risks associated with CBDC that were not raised in this paper? ======
-[[cbdc:private:cbdc_omg:04_doc:20_comments:brp:start| Return to CBDC Benefits, Risks, and Policy Considerations ]]
+|< 100% >|
+| [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:start| Return to CBDC Benefits, Risks, and Policy Considerations ]]  |  <WRAP>
+<html><b>
+<a href="mailto:[email protected]?Subject=OMG's CBDC WG Response:
+Question: 11. Are there additional ways to manage potential risks associated with CBDC that were not raised in this paper?
+">Provide Feedback</a></b>
+</html>
+</WRAP>  |
 ===== Question =====
-[[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q11:start| Return to Top]]
+[[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q11:start| Return to Top]]
 **Are there additional ways to manage potential risks associated with CBDC that were not raised in this paper?**
 ===== Answer =====
-[[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q11:start| Return to Top]]
+[[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q11:start| Return to Top]]
 By all descriptions, the U.S. CBDC is primarily a large [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sos | System-of-Systems (SoS)]] or even an SoS of SoSs. Some of these would ideally already exist and some will need to be created. The new systems are predominately a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:software | Software (SW)]] effort. Yes, there will be some specialized [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:h:hardware | Hardware(HW) ]] required, but the primary focus appears to be Software (including [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:cots | Commercial-Off-The-Shelf (COTS)]], [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:g:gots | Government Off-The-Shelf (GOTS)]], or [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:mots | Modified Off-The-Shelf (MOTS)]]. This software will ultimately need to be  [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:28_manageability:04_costs | Managed ]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modifiability | Modified]].
-==== 1. Risk of a Software Crisis ====
+The following is a list of potential risks not identified in the **White Paper**.
-[[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q11:start| Return to Top]]
-For these reasons, the [[https://www.omg.org/ | Object Management Group (OMG) ]] recommends the adoption of a systematic effort for the development of an SoS identified as a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:missioncritical | Mission-Critical SoS]]. The CBDC also has a potential [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:syslifecycle | System Lifcycle]] that spans decades at a minimum. __**The need for an SoS, long-lived, Mission-Critical System sets the stage for the biggest risks for the U.S. CBDC**__, the potential for a looming [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sw_crisis | Software Crisis]].
+<nspages -tree -r -exclude -subns -pagesInNs -h1 -textNs="">
-A **Software Crisis** occurs on projects for many reasons, but the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:infotech | Information Technology (IT)]] industry has focused on a shortlist, which is provided in summary form in Table {{ref>swCrisis}}. Any particular project suffering a **Software Crisis** may have any number of these issues and unfortunately, some projects might have all of these issues.
-<table swCrisis>
-<caption>Issues causing a Project to have a **Software Crisis**.</caption>
-  - Projects are running over budget
-  - Projects are running behind schedule
-  - Poor quality of the delivered software
-  - Poor definition of requirements
-  - Poor adherence to the requirements
-  - Poor management of the entire project throughout its lifecycle
-  - Poor communications between the Stakeholders, Systems Engineers, and Software Engineers
-  - Poor documentation of Policies and Procedures for the project
-  - Poor enforcement of Policies and Procedures for the project
-  - Poor training of Stakeholders, Systems Engineers, and Software Engineers on Policies and Procedures.
-  - Increase in System and Software complexity
-  - Increase in Software costs compared to Hardware
-</table>
-However, all is not lost for the CBDC. There is a way to prevent a future CNDC **Software Crisis** by applying sound [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:se | Systems Engineering]] practices throughout the CBDC lifecycle, starting immediately. The OMG has a rich history of working in Systems and Software Engineering. Table {{ref>omgStds}} provides a list of OMG standards covering [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sw_engineering | Systems Engineering]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sw_engineering | Software Engineering]].
-<table omgStds>
-<caption>The Object Management Group's list of System and Software Engineering Stadards.</caption>
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:bmn   | Business Motivation Model (BMM)]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:bpmn     | Business Process Model and Notation (BPMN) ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:cwm      | Common Warehouse Metamodel (CWM) ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:dol   | Distributed Ontology, Model, and Specification Language (DOL)]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:fibo  | Financial Industry Business Ontology (FIBO) ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:figi  | Financial Instrument Global Identifier (FIGI)]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:mof      | MetaObject Facility (MOF) ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:mbse     | Model Based Systems Engineering (MBSE) ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:mda      | Model Driven Architecture (MDA) ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:odm   | Ontology Definition Metamodel (ODM) ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:sbvr  | Semantics Of Business Vocabulary And Business Rules (SBVR) ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:sacm  | Structured Assurance Case Metamodel (SACM) ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sysml    | Systems Modeling Language (SysML) ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:uaf   | Unified Architecture Framework (UAF)]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:u:uml      | Unified Modeling Language (UML)]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:xmi   | XML Metadata Interchange (XMI) ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:iso:syseng | Systems and software engineering -- System life cycle processes]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:iso:square_measure_product | Measurement of System and Software Product Quality]]
-</table>
-The Systems Engineering process as described by the Department of Energy (DOE) is to develop, manage, and implement large programs ((
-National Academy of Sciences,
-__Systems Analysis and Systems Engineering in Environmental Remediation Programs at the Department of Energy Hanford Site__,
-National Research Council 1998.
-Systems Analysis and Systems Engineering in Environmental Remediation Programs at the Department of Energy Hanford Site.
-Washington, DC: The National Academies Press.
-[[https://doi.org/10.17226/6224]]
-)). The following is a modified version of the DOE process tweaked to differentiate the Water Fall Model versus the Agile Model.
-  - Orderly definition of the **System** through top-down development of **System Functions** and **System Requirements**. This is an iterative process with each iteration providing further decomposition of the System Level Requirments as needed. **Note:** These Systems-level definition iterations should not be confused with the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:agile | Agile Sprints]] used during development. See the OMG DIDO-RA section on [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:00_aboutreq:05_currstate | The Current State of DIDO Requirements]].
-  - Clear distinction between:
-    - External driven **System** requirements and constraints, which are by intent not easy to modify. In other words, the identification of System Functional and Non-Functional Requirements.
-    - Internal driven **Design** (i.e., implementation) requirements developed by the project, which are potentially modifiable and evolutionary with new requirements added as the system is developed. In other words, Derived Requirements.
-  - Top-down consideration and evaluation of alternative solutions and designs based on the System [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:1_func | Functional]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc | Non-Functional Requirements]]
-  - Completeness and traceability for the design of System Components and System Interfaces, for configuration and change control, and for the system verification and validation plan(s). In other words, the SoS must come together as a cohesive, solitary "thing". All the Systems within the SoS must have a single, cohesive, unified understanding of the other Systems within the SoS and must be able to use standardized Application Programming Interfaces (APIs).
-DOE goes on to describe the value of the Systems Engineering Process realization in a number of ways, including:
-  - Increased ability to estimate system life-cycle costs
-  - Reduced redesign due to consideration of the entire system throughout its development
-  - Increased ability to affect design changes and retrofits due to clear traceability of requirements, design features, and configuration control
-  - Increased probability of achieving the best technical design and operational concept through the iterative consideration of design alternatives, where **//best//** is defined through decision criteria such as cost, risk, and use. See the OMG DIDO-RA section on [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:3_assessment | Assessing Requirements]]
-Figure {{ref>sysProcOverview}} provides a simplified high-level processes flow for Systems Engineering. This process was developed by the U.S. Department of Energy and would have to be tailored to meet the needs of a U.S. CBDC. Basically, the System's process flow is captured in Table {ref>}}
-<figure sysProcOverview>
-{{  :cbdc:private:cbdc_omg:04_doc:20_comments:brp:q11:screen_shot_2022-04-22_at_3.52.14_pm.png?800  |}}
-<caption>Simplified high-level Systems Engineering Process as defined by the U.S. Department of Energy. </caption>
-</figure>
-<table sysProcSteps>
-<caption>The steps in the Simplified high-level Systems Engineering Process as defined by the U.S. Department of Energy</caption>
-  - A high-level statement of system needs. In this discussion, the Mission needs are referred to as "Desirements". The current "desirements" from the [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:15_summary:start | White Paper]] as identified by the [[https://www.omg.org/ | Object Management Group's ]] report called [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:15_summary:start | White Paper Analysis]] is a good starting point for these.
-  - The //"Mission Needs"// are analyzed and transformed into //"Mission Statements"// (i.e., Systems Requirements). For example, the **White Paper** desirement of:<WRAP>
-  The Federal Reserve does not intend to proceed with the issuance of a CBDC without clear
-  support from the Executive Branch, the Legislative Branch, and also ideally in the form
-  of a specific authorizing law
-</WRAP>would be transformed into:<WRAP>
-  U.S. CBDC shall be authorized by a specific U.S. Law
-  U.S. CBDC Authorizing Law shall be approved by the Legislative Branch
-  U.S. CBDC Authorizing Law shall be approved by the Executive Branch
-</WRAP>
-  - The //"Mission Statements"// are transformed into [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:1_func | Functional]] (i.e, performance, interfaces)and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc | Non-Functional]] Requirements (i.e., constraints), see OMG DIDO-RA [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:00_aboutreq:07_reqspec | Specifying Requirements]]. Also see the OMG DIDO-RA section on Testability and especially the subsection on [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:swassurance | Software Assurance (SwA)]]. If the requirements are not testable, then they serve little purpose.
-  - The //"Requirements"// are allocated to Systems, or components (i.e., elements) and added to a formal System Description and Systems Analysis. Table {{ref>reqDocTable}} captures the documents called out in the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:uaf | Unified Architecture Framework (UAF)]]. These documents can be tailored for the U.S. CBDC, but many of the documents are useful for [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:missioncritical | Mission Critical Systems. ]] <WRAP>
-<table reqDocTable>
-<caption>The kinds of documents that can be used to define the system.</caption>
-|< 100% 15% 5% >|
-^  Viewpoint  ^  Acronym  ^  Description |
-^ Architecture Management ^  Am  | Identifies the metadata and views required to develop a suitable architecture that is fit for its purpose.|
-^ Strategic     ^  St  | Capability management process. Describes the capability taxonomy, composition, dependencies, and evolution. |
-^ Operational   ^  Op  | Illustrates the Logical Architecture of the enterprise. Describes the requirements, operational behavior, structure, and exchanges required to support (exhibit) capabilities. Defines all operational elements in an implementation/solution-independent manner. |
-^ Services      ^  Sv  | The Service-Orientated View (SOV) is a description of services needed to directly support the operational domain as described in the Operational View. A service within MODAF is understood in its broadest sense, as a unit of work through which a provider provides a useful result to a consumer. DoDAF: The Service Views within the Services Viewpoint describe the design for service-based solutions to support operational development processes (JCIDS) and Defense Acquisition System or capability development within the Joint Capability Areas.|
-^ Personnel     ^  Ps  | Defines and explores organizational resource types. Shows the taxonomy of types of organizational resources as well as connections, interaction, and growth over time. |
-^ Resources     ^  Rs  | Captures a solution architecture consisting of resources, e.g., organizational, software, artifacts, capability configurations, and natural resources that implement the operational requirements. Further design of a resource is typically detailed in SysML or UML. |
-^ Security      ^  Sc  | Security assets and security enclaves. Defines the hierarchy of security assets and asset owners, security constraints (policy, laws, and guidance), and details where they are located (security enclaves). |
-^ Projects      ^  Pj  | Describes projects and project milestones, how those projects deliver capabilities, the organizations contributing to the projects, and dependencies between projects. |
-^ Standards     ^  Sd  | MODAF: Technical Standards Views are extended from the core DoDAF views to include non-technical standards such as operational doctrine, industry process standards, etc. DoDAF: The Standards Views within the Standards Viewpoint are the set of rules governing the arrangement, interaction, and interdependence of solution parts or elements. |
-^ Actual Resources ^  Ar  | The analysis, e.g., evaluation of different alternatives, what-if, trade-offs, V&V on the actual resource configurations. Illustrates the expected or achieved actual resource configurations.|
-^ Motivation   ^  Mv  | Captures motivational elements e.g., challenges, opportunities, and concerns, that pertain to enterprise transformation efforts, and different types of requirements, e.g., operational, services, personnel, resources, or security controls. |
-^ Taxonomy     ^  Tx  | Presents all the elements as a standalone structure. Presents all the elements as a specialization hierarchy, provides a text definition for each one and references the source of the element |
-^ Structure    ^ Sr   | Describes the breakdown of structural elements e.g., logical performers, systems, projects, etc. into their smaller parts |
-^ Connectivity ^  Cn  | Describes the connections, relationships, and interactions between the different elements. |
-^ Processes    ^  Pr  | Captures activity-based behavior and flows. It describes activities, their Inputs/Outputs, activity actions, and flows between them. |
-^ States       ^  St  | Captures state-based behavior of an element. It is a graphical representation of the states of a structural element and how it responds to various events and actions.|
-^ Sequences    ^  Sq  | Expresses a time-ordered examination of the exchanges as a result of a particular scenario. Provides a time-ordered examination of the exchanges between participating elements as a result of a particular scenario. |
-^ Information  ^  If  | Address the information perspective on operational, service, and resource architectures. Allows analysis of an architecture’s information and data definition aspect, without consideration of implementation-specific issues. |
-^ Constraints  ^  Ct  | Details the measurements that set performance requirements constraining capabilities. Also defines the rules governing behavior and structure.|
-^ Roadmap      ^  Rm  | Addresses how elements in the architecture change over time.|
-^ Traceability ^  Tr  | Describes the mapping between elements in the architecture. This can be between different viewpoints within domains as well as between domains. It can also be between structure and behaviors. |
-</table>
-</WRAP>
-  - Verification of the System is progressing according to plan. This is done through Test Inspection, Demonstrations, as well as Static and Dynamic Analysis of the System. Another major tool should be the use of Modeling and testing in Virtual Environments.
-  - Evaluation and Optimization occur before a release to the public. Based on the results of Trade Studies, risk analysis, performance, etc, the System Design Specifications can be updated, refined, or added to.
-</table>
-==== 2. Risk of Lack of Stakeholder Buy-In =====
-[[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q11:start| Return to Top]]
-A major risk confronting the U.S. CBDC is the lack of Stakeholders' "buy-in". The [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:stakeholder | Stakeholders]] for a U.S. CBDC is far beyond just the Federal Reserve. The definition is applied to the U.S. CBDC is a large and spreading network of other U.S. Government Departments and Agencies, the current financial institutions that participate in the U.S. Finacial system,  the U.S. Executive and Legislative Branches of the U.S. Government, international governments and institutions, the citizens and residents of the U.S, and for that matter, almost everyone on the planet since the U.S. Dollar is the dominate [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:reserve_currency | Reserve Currency]]. Obviously, it is not possible to invite everyone to sit down at a table and have discussions about a U.S. CBDC. Most people will rely on elected officials, government organizations, etc. to represent them.
-In the Object Management Group's (OMG's) response, we tried to help enumerate the U.S. CBDC in section [[cbdc:private:cbdc_omg:04_doc:15_common:05_stakeholder:start]]. Table {{ref>summaryStakeReg}} is a summary of the list identified so far that could be considered potential Stakeholder.
-<table summaryStakeReg>
-<caption>Summary of the estimated number of Government Stakeholders for the CBDC.</caption>
-|< 50% 30% 10% >|
-^  Potential Oversight Authorities  ^ No. of Stakeholders  |
-^ [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:04_doc:15_common:05_stakeholder:start#us_federal_government_oversight_authorities | U.S. Federal Government Oversight Authorities ]] |  14 |
-^ [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc_omg:04_doc:15_common:45_privacy:start#us_state_laws_and_regulations   | non-U.S. Federal Government Oversight Authorities  ]]  |  19 |
-^             Total ^  **33** |
-</table>
-Although a U.S. CBDC is something new, it will also be part of the U.S. monetary system that is already established. The U.S. population relies on the monetary system and has expressed its aspirations for the monetary system through laws and regulations already in effect to control the monetary system. These laws and regulations have evolved since the founding of the U.S. and are generally a response to negative impacts on the U.S. people. Therefore, a major way to include the people as Stakeholders is to follow the laws and regulations of the U.S. The same can be said for the potential international stakeholders who rely on international treaties and agreements between the U.S. and their countries.
-In the Object Management Group's (OMG's) response, we tried to enumerate the U.S. and U.S. State laws and regulations that are concerned with Privacy in section [[cbdc:private:cbdc_omg:04_doc:15_common:45_privacy:start]]. Table {{ref>summaryPrivReg}} is a summary of the list of Laws and Regulations identified so far for the U.S. and U.S. State laws covering Privacy.
-<table summaryPrivReg>
-<caption>Summary of the number of laws and regulations covering National Security Considerations.</caption>
-|< 40% 20% 10% >|
-^  U.S. Privacy Consideration  ^ No. of Laws and Regulations  |
-^ [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc_omg:04_doc:15_common:45_privacy:start#us_federal_laws_and_regulations | U.S. Federal Laws and Regulations ]] |  10 |
-^ [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc_omg:04_doc:15_common:45_privacy:start#us_state_laws_and_regulations   | U.S. State Laws and Regulations  ]]  |   6 |
-^             Total ^  **16** |
-</table>
-Here are some examples of "resistance" to a U.S. CBDC from potential stakeholders:
-  * WASHINGTON – Sen. Chuck Grassley (R-Iowa), a member and former chair of the Senate Finance Committee, and Sens. Ted Cruz (R-Texas) and Mike Braun (R-Ind.) have introduced new legislation to prohibit the Federal Reserve from issuing a central bank digital currency (CBDC) directly to individuals. Specifically, the legislation prohibits the Federal Reserve from developing a direct-to-consumer CBDC, which could potentially be used as a financial surveillance tool by the federal government – similar to what is currently happening in China. ((
-Chuck Grassley,
-News Release,
-March 2022,
-Accessed: 24 April 2022,
-[[https://www.grassley.senate.gov/news/news-releases/grassley-colleagues-introduce-bill-to-prohibit-unilateral-fed-control-of-a-us-digital-currency]]
-))
-  * People have a wide range of views when it comes to digital assets. On one hand, some proponents speak as if the technology is so radically and beneficially transformative that the government should step back completely and let innovation take its course. On the other hand, skeptics see limited, if any, value in this technology and associated products and advocate that the government take a much more restrictive approach. Such divergence of perspectives has often been associated with new and transformative technologies.((
-Janet Yellen,
-The U.S. Department of the Treasury,
-__Remarks from Secretary of the Treasury Janet L. Yellen on Digital Assets__,
-April 2022,
-Accessed: 24 April 2022,
-[[https://home.treasury.gov/news/press-releases/jy0706]]
-))
-==== 3. Risk due to Poor Community of Interest (CoI) Governance ====
-[[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q11:start| Return to Top]]
-Governance of a Community of Interest (CoI) just does not happen by chance. It must be a well-thought-out formal organization with strict Policies and Procedures in place to guarantee the whole community is represented and can help formulate the solution or in this case, solutions to solving the Communities problem (i.e., U.S. CBDC). Too often, the Governance is considered by using [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:o:oss | Open Source Software (OSS)]]. Although having OSS Projects can have an important role in the Governance of a project, it is primarily focused on the development of Software. Yes, the CBDC will be predominately software, but there is much more that needs to be governed than just software.
-<table>
-<caption>Examples of non-Software things the U.S. CBDC Community of Interest might need to control.</caption>
-For example,
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.3_gov:1_legaldocs | Legal Documents]] such as
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.3_gov:1_legaldocs:1_charter | Charters]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.3_gov:1_legaldocs:2_bylaws | By-Laws]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.3_gov:1_legaldocs:3_pp | Policies and Procedures (P&P)]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.3_gov:5_hg | Guides]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:se | System]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sw_engineering | Software Engineering]] documents such as
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req | Requirements]]
-      * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc | Non-Functional]]
-      * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:1_func | Functional]]
-    * Models
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:2_tech_views:1_core:1_interface | Interface Specifications]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:assurance| Assurance]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:sacm | Assurance Models]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.g_testing:start |Testing regime]]
-      - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:u:unittesting       | Unit Testing ]]
-      - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:integrationtesting | Integration Testing ]]
-      - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:e:end2endtest       | End-to-End Testing (E2E Testing)]]
-      - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:smoketesting      | Smoke Testing ]]
-      - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sanitytesting     | Sanity Testing ]]
-      - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:regressiontesting | Regression Testing]]
-      - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:acceptancetesting | Acceptance Testing ]]
-      - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:w:whiteboxtesting   | White Box Testing]]
-      - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:blackboxtesting   | Black Box Testing ]]
-      - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:interfacetesting  | Interface Testing ]]
-      - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:interoptesting    | Interoperabiloity Testing ]]
-      - Test Data
-      - Test Plans
-      - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:testif | Test Results ]]
-</table>
-In addition to all these requirements for Governance, the Governance Model itself must reflect the //"distributed nature"// of the participants in the CoI itself. So far, we have identified 33 different Oversight Authorities that could be part of the CoI (see Table {{ref>summaryStakeReg}}, and each one needs to be able to have a voice at the CoI forum or Consortium. See the OMG DIDO-RA discussion of [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.3_gov#governance | Governance]].
-The U.S. CBDC will most likely be a System-of-Systems (SoS) or even an SoS of other SoSs. This means that there probably needs to be a hierarchy of CoI not unlike that of the Federal Reserve itself. For example:
-  * The U.S. CBDC CoI might be an [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:1_stakeholder:4_ecosphere | Ecosphere]]
-  * The development of U.S. CBDC ATM equivalents might be an [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:1_stakeholder:3_ecosystem | Ecosystem]]
-    * The Development of a U.S. CBDC ATM machine itself might be a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:1_stakeholder:2_domain | Domain]]
-    * The Development of a U.S. CBDC ATM network might be a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:1_stakeholder:2_domain | Domain]]
-  * The Development of a Bridge between the ACH and the U.S. CBDC might be an [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:1_stakeholder:3_ecosystem | Ecosystem]]
-    * The Development of a U.S. CBDC Bridge Hardware might be a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:1_stakeholder:2_domain | Domain]]
-    * The Development of a U.S. CBDC Application Programming Interface (API) might be a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:1_stakeholder:2_domain | Domain]]
-<table coiTypes>
-<caption>Overview of the different kinds of Communities of Interest (CoIs)</caption>
-|< 100% 25% >|
-^  CoI Type  ^  Description  |
-^ Ecosphere Community ^ <WRAP>
-**Ecosphere Community** is the highest level [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:coi | Community of Interest (COI)]] that encapsulates DIDO Ecosystem Communities and DIDO Domain Communities. The Ecosphere usually provides high-level requirements and some funding for the administration of the other CoIs. The Ecosphere's role is to act as a coordinator of the Ecosystems and to provide a framework for all other CoIs to establish working agreements such as [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:moa | Memorandum of Agreement (MoA)]] or [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:mou | Memorandum of Understanding (MoU)]]. The Ecosphere is often the only CoI that is recognized as a Legal Entity with legally binding [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.3_gov:1_legaldocs:1_charter | Charter]], [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.3_gov:1_legaldocs:2_bylaws | Bylaws]] and official [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.3_gov:1_legaldocs:3_pp | Policies and Procedures]]. Often the Ecosphere control [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:intelp| Intellectual Property (IP) rights ]]  and allowable [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:copyright | Copyrights]] that are acceptable for the Ecosphere and the Domain.
-</WRAP>|
-^ Ecosystem Community ^ <WRAP>
-**Ecosystem Community** is the midlevel level [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:coi | Community of Interest (COI)]] that encapsulates [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dido_domain_community|Domain Communities]]. The Ecosystem has a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:charter | Sub-Charter]] approved by the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dido_ecosphere_community | Ecosphere CoI]]. The Ecosystem usually relies on the Ecosphere for [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:bylaw | By-Laws]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:p_p | Policy and Procedures (P&P)]]  but can provide addendums that do not conflict with the Ecosphere. The primary role of the Ecosystem is to coordinate the activities of the Domains which fall under its jurisdiction. As a general rule, the Ecosystem does not actually create anything but acts as the integrator and coordinator of all the Domains it is responsible for. The Ecosystem may have more restrictive [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:intelp | Intellectual Property (IP) ]] Rights than the Ecosphere. It can only subset the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:copyright | Copyrights]] allowed by the Ecosphere.
-The Ecosphere's role is to act as a coordinator of the Domains, however, one Ecosystem can also have a Sub-Ecosystem that it is responsible for. The Ecosystem can have its own [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.e_tools:bugtrack | bug tracking system]] that covers integration issues. The Ecosystem is responsible for all [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:integrationtesting|Integration Testing]].
-</WRAP>|
-^ Domain Community ^ <WRAP>
-**Domain Community** is the lowest level [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:coi | Community of Interest (COI)]]. The Domain has a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:charter | Sub-Charter]] approved by the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dido_ecosystem_community | Ecosystem Community]]. The Domain usually relies on the Ecosphere for [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:bylaw | By-Laws]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:p_p | Policies and Procedure (P&P)]] but can provide addendums that do not conflict with the Ecosphere. The primary role of the Domain is to produce a product that meets the Functional and Non-Functional Requirements of the Ecosystem and the Ecosphere. As a general rule, the Domain actually builds or deploys things to be integrated into the Ecosystem. The Domain may have more [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:intelp | Intellectual Property (IP)]] Rights than the Ecosystem. It can have a subset of the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:copyright | Copyrights]] allowed by the Ecosystem.
-The Domain's role is to build products as per the requirements and maintain products according to the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.e_tools:bugtrack | Bug Tracking System]]. The Domain is responsible for all testing at the Domain level (See: [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:20_maintainability:testability | Testability]]).
-</WRAP>|
-</table>
-  : **Note:** One way within the U.S. Government to create an Ecosphere, might be to use the [[cbdc:private:cbdc_omg:8_append:50_other:start |Other Transaction Authority provisions]] within the U.S. Code.
-==== 4. Risk due to lack of Broad, Wide Ranging Security Planning ====
-[[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q11:start| Return to Top]]
-An important way to make sure the Security Planning is adequate is to design it into the U.S. CBDC from the onset, especially if the U.S. CBDC adopts the use of Distributed Technologies currently in wide use in cryptocurrencies. First, it is important to detail what needs to be secure and why. See Table {{ref>datatypeSecurity}}.
-For a more detailed discussion, see the OMG DIDO-RA section on Non-Functional requirements for [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security |Securability]].
-<table datatypeSecurity>
-<caption>Main reasons why data needs to be secure.</caption>
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security:confidentiality    | Confidentiality]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security:04_data_integrity  | Data Integrity]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security:nonrepudiability   | Non-repudiation]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security:authenticity       | Authenticity]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security:accountability     | Accountability]]
-</table>
-All too often, projects try to "bolt-on" security after products are built. When building as essential and critical to the U.S. as a new financial mechanism such as CBDC, it is essential to think about it at every stage of the development, starting at the specification of requirements and at each layer of securability. See Figure {{ref>layerSecDarw}} and Table {{ref>layerSec}}
-Securability is also a layered stack. At each layer, there are different steps that need to be taken to secure the system. For example, **Culture Security** it may just mean having employees hold a security clearance and/or take Drug Tests. For **Physical Security** it may mean having a locked facility to house the computers and network devices. Data Security might be software and cultural procedures such as encrypting all data stored in a disk drive and using software to access the data.
-<figure layerSecDarw>
-{{  :cbdc:private:cbdc_omg:04_doc:15_common:48_natsec:layers_of_security.png?400  |}}
-<caption>The layers of Security.</caption>
-</figure>
-<table layerSec>
-<caption>The layers of Security.</caption>
-  - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:physicalsecurity    | Physical Security]]
-  - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:datasecurity        | Data Security]]
-  - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:n:networksecurity     | Network Security]]
-  - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:platformsecurity    | Platform Security]]
-  - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:applicationsecurity | Application Security]]
-  - [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:securityculture     | Culture Security]]
-</table>
-==== 5. Risk of Data being hacked due weak Security Infrasture ====
-[[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q11:start| Return to Top]]
-  : //When Senator Mark Warner (D-VA) questioned witness Dr. Neha Narula, Director of the Digital Currency Initiative at MIT, on security risks associated with cryptocurrencies, she responded that, with respect to ransomware attacks, the issue is that valuable data has not been properly secured, and suggested that a CBDC could have built-in safeguards. She also believed that open source software is critical for security.//((
-Buckley Firm,
-__Senate holds hearing on central bank digital currency__,
-June 2022,
-Accessed: 24 April 2022,
-[[https://buckleyfirm.com/blog/2021-06-16/senate-holds-hearing-central-bank-digital-currency]]
-))
-Data can exist in many states depending on how it is being used. Each of the different Data States poses its own risks of compromising data. The primary concern with data is that it compromises End User Privacy. See section [[cbdc:private:cbdc_omg:04_doc:15_common:45_privacy:start]].
-The risks and concerns about Data in each of the different states are also important. Often, the primary focus for understanding data is to concentrate on [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dataatrest | Data-at-Rest]]. Although this data is relatively static, it can change over time. In the past, there was little concern for [[https://www.omgwiki.org/dido/doku.php?id=[dido:public:ra:xapend:xapend.a_glossary:d:data_in_motion | Data-in-Motion ]], which can have serious effects on [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:ram |  Reliability, Maintainability, and Availability (RAM)]], as well as, [[https://www.omgwiki.org/dido/doku.php?id=[dido:public:ra:1.4_req:2_nonfunc:25_security | 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 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:data_in_use | Data-In-Use]]. A recent WhatsApp data breach ((
-Czarina Grace,
-__WhatsApp Data Breach 2021 Could Expose 2 Billion Users: Update Now on Android, iOS to Fix Security Risk__,
-iTechPpost,
-September 2021,
-Accessed 6 October 2021,
-[[https://www.itechpost.com/articles/106929/20210906/whatsapp-data-breach-2021-expose-2-billion-users-update-now.htm]]
-)) 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 the Data-in-Motion and the Data-at-Rest issues but have traditionally relied on physical security to protect Data-in-Use.
-<figure DataStateFigure>
-{{  :cbdc:private:cbdc_omg:04_doc:20_comments:brp:q11:data_states.png?600  |}}
-<caption>The Various States of Data.</caption>
-</figure>
-Any risk assessment must include the Security Infrasture and the state of data:
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dataatrest      | Data-at-Rest]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=[dido:public:ra:xapend:xapend.a_glossary:d:data_in_motion | Data-in-Motion ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:data_in_use     | Data-In-Use]]
-==== 6. Risk of Meta-Data being hacked due weak Security Infrasture ====
-[[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q11:start| Return to Top]]
-[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:metadata | Metadata]] is data about data. Although this data can provide specific insight into personal data such as [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:pii | Personal Identifiable Information (PII)]] (see [[cbdc:private:cbdc_omg:04_doc:15_common:45_privacy:start | Privacy Concerns]]), there is also a problem with hackers gaining access to Metadata.
-For example, knowing your name, address, phone number, and credit card details can be used to make illegal purchases in your name. This is a [[cbdc:private:cbdc_omg:04_doc:15_common:48_natsec:start | Criminal Activity]] in itself, but gaining information about your behavior and habits is a different kind of privacy violation. This information can be used to target you for advertisements or more nefariously specific scams. For instance, the metadata can now be used to determine that an individual is visiting a well-known cancer clinic and target the person for "miracle cures".
-Another example might be the discovery that a well-known founder and CEO of a publicly-traded company has visited the same well-known cancer clinic. This information is then used to in essence glean insider information about the company and make stock trades.
-The use of Metadata is the primary engine for companies such as Google, Facebook, Microsoft, Apple, etc. However, this is done using their own mechanism to collect the data and users sign their rights away with the Service Level Agreements (SLAs), etc they "sign" when they choose to use these products. It is another thing to use government-provided data.
-Therefore, Metadata not only contains Data about Data, but it can also contain information about the association of data elements together. Sometimes this activity is referred to as Triangulation.
-  : //**Metadata Triangulation** describes taking two pieces of metadata to infer a great deal more. Let me give you an example. You take a picture of something with your iPhone. That picture has both a date/time stamp and a GPS location tag. Two different pieces of information that, when combined, can lead to so much more. Some examples of information that can be inferred are://((
-Aaron Edell,
-__Coining a term: metadata triangulation__,
-February 2016,
-Accessed: 24 April 2022,
-[[https://www.linkedin.com/pulse/coining-term-metadata-triangulation-aaron-edell/]]
-))
-    * //The weather//
-    * //Top news stories (including the content of those stories)//
-    * //Local objects, buildings, structures, etc. //
-    * //Natural disasters//
-    * //Nearby housing prices//
-    * //Stock prices, economic conditions, inflation, etc. //
-    * //Flights overhead, traffic conditions//
-There is an assumption that Bitcoin transactions are anonymous, the reality is that they are anonymized. The following article by John Bohannon highlights the issue:((
-John Bohannon,
-__Why criminals can't hide behind Bitcoin - Even with cryptocurrency, investigators can follow the money__,
-Science,
-March 2016,
-Accessed: 24 April 2022,
-[[https://www.science.org/content/article/why-criminals-cant-hide-behind-bitcoin]]
-))
-  : //Bitcoin, the Internet currency beloved by computer scientists, libertarians, and criminals, is no longer invulnerable. As recently as 3 years ago, it seemed that anyone could buy or sell anything with Bitcoin and never be tracked, let alone busted if they broke the law. "It's totally anonymous," was how one commenter put it in Bitcoin's forums in June 2013. "The FBI does not have a prayer of a chance of finding out who is who."//
-  : // The Federal Bureau of Investigation (FBI) and other law enforcement begged to differ. Ross Ulbricht, the 31-year-old American who created Silk Road, a Bitcoin market facilitating the sale of \$1 billion in illegal drugs, was sentenced to life in prison in February 2015. In March, the assets of 28-year-old Czech national Tomáš Jiříkovský were seized; he's suspected of laundering \$40 million in stolen Bitcoins. Two more fell in September 2015: 33-year-old American Trendon Shavers pleaded guilty to running a \$150 million Ponzi scheme—the first Bitcoin securities fraud case—and 30-year-old Frenchman Mark Karpelès was arrested and charged with fraud and embezzlement of \$390 million from the now shuttered Bitcoin currency exchange Mt. Gox.//
-In this case, it was the "good guys" who used the Metadata, but this could also have been used for nefarious activities and a U.S. CBDC needs to protect this kind of data.
-==== 7. Risk of Business Processes Being Hacked ====
-[[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q11:start| Return to Top]]
-Some government business processes need to be kept confidential, secret, or even top-secret when it comes to trying to audit or discover illegal or criminal activities. The reason is that if the processes were made readily available to the public, then the business process can be "gamed" to avoid detection. In these situations, the government is involved in an "arms race" so to speak with those who want to avoid detection. The government business processes are continuously refined and honed to detect illegal or criminal activity, while the "bad guys" continuously test the system to find its weaknesses.
-As an example, the process of trying to "reverse engineer" the "rules" of a government business process for determining if an individual return gets audited run rampant when it comes to triggering an audit by the Internal Revenue Service (IRS).((
-Jacob Dayan,
-__IRS Audits: 10 Common Myths Debunked__,
-Accessed: 24 April 2022,
-[[https://articles.bplans.com/irs-audits-10-common-myths-debunked/]]
-))
-More and more government business processes are using Artificial Intelligence (AI) to aid in the flow of the business process. Many of these AI processes are data-driven either through parameters or by using learning datasets continuously refined based on previous runs through the process. This means that either the original parameters or the learning data sets are subject to hacking attempts.
-  : //Budget cuts and a significant drop in Special Agents that investigate criminal tax crimes have led the IRS to use Artificial Intelligence (AI) to uncover criminal tax activities. In a recent webcast hosted by the American Bar Association, the IRS revealed that research and investigative techniques that used to take weeks or months may now be accomplished in minutes with technology the IRS is rolling out to detect taxpayer noncompliance.//
-  : //These computer tools are able to detect fraud, identity theft, money laundering, and hidden assets that Revenue Agents and Special Agents typically look for manually. The speed and sophistication of these computer data-mining programs have greatly increased the IRS’ efficiency.//((
-Stahl Criminal Defense Lawyers,
-Accessed: 24 April 2022,
-[[https://stahlesq.com/irs-artificial-intelligence-detects-tax-evaders/]]
-))
-If the government business processes are hacked, then the ability for illegal or criminal activities to go undetected is advanced.
-Another problem would be if the government's business processes themselves were "hacked" to disable the government process or change the algorithms or parameters of the process to provide an unfair advantage. A simple example might be adding an exclusion for a certain individual within the process.
 /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

OMG Central Bank Digital Currency (OMG-CBDC) Working Group (WG) Wiki

User Tools

Site Tools

Differences

Page Tools