Differences

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

--- cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start [2022/05/17 14:47]
nick
+++ cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start [2022/06/17 19:15] (current)
terrance
@@ Line 3: / Line 3: @@
 | [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:start| Return to Question 13]]  |  <WRAP>
 <html><b>
-<a href="mailto:[email protected]?Subject=OMG CBDC Response:
+<a href="mailto:[email protected]?Subject=OMG's CBDC WG Response:
 .2. What operational or cyber risks might be unavoidable?
 ">Provide Feedback</a></b>
@@ Line 13: / Line 13: @@
-The biggest [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:risk | Risks]] to the CBDC is the related to the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:infotech | 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
+The biggest [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:risk | Risks]] to the CBDC is related to the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:infotech | 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 priority
@@ Line 19: / Line 19: @@
   * **''R0011''** is concerned about loss, theft, and fraud
-These 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:
+These are unique problems for 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:
@@ Line 32: / Line 32: @@
 The difference between [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:specification | Specification ]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:standard | 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 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:specification | 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 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:standard | Standard]] is a specification established by institutions such as [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sdo | Standards Developing Organization (SDO)]] or a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:v:vcsb | Voluntary Standards Consensus Body (VSCB)]]. Standards can be classified as [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech | Technical]] or //[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:defact | de facto]]// Standards.
+A [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:specification | Specification ]] are statements detailing the 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 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:standard | Standard]] is a specification established by institutions such as [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sdo | Standards Developing Organization (SDO)]] or a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:v:vcsb | Voluntary Standards Consensus Body (VSCB)]]. Standards can be classified as [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech | Technical]] or //[[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:defact | de facto]]// Standards.
 ==== ISO, IEC, IEEE Standards ====
 [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start| 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.
+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>
-{{  :cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:qualitycharacteristicmeasures.png?700  |}}
+{{  cbdc:04_doc:20_comments:brp:q13:sb_02:qualitycharacteristicmeasures.png?700  |}}
 <caption>Quality Characteristics and Measures Specifications</caption>
 </figure>
@@ Line 64: / Line 64: @@
 [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start| 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.
+The Consortium for Information & Software Quality (CISQ) develops international standards to automate the measurement of software from source code. The 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, [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:devops |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.
+Automation is critical because the manual review is infeasible for large multi‐layer, multi‐language, multi‐platform systems. Additionally, [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:devops |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.
   * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:acsmm                        | OMG: Automated Source Code CISQ Maintainability Measure (ASCMM) ]]
@@ Line 81: / Line 81: @@
   * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:cmmn                         | 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.
+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 stakeholders 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.
   * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:sacm                         | 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,
+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,
   * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:testif                       | OMG: Test Information Interchange Format (TestIF)]]
@@ Line 104: / Line 104: @@
 <figure DataStateFigure>
-{{  :cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:datastateflow.png?700 |}}
+{{  cbdc:04_doc:20_comments:brp:q13:sb_02:datastateflow.png?700 |}}
 <caption>The various States of Data</caption>
 </figure>
@@ Line 127: / Line 127: @@
 [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
-Some "desirements" in the [[https://www.federalreserve.gov/publications/files/money-and-payments-20220120.pdf | 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 [[cbdc:public:cbdc_omg:04_doc:12_summary:start| White Paper Analysis]] done by the [[https://www.omg.org/ | Object Management Group ]] and listed in Table {{ref>opCyberRiskReq}}.
+Some "desirements" in the [[https://www.federalreserve.gov/publications/files/money-and-payments-20220120.pdf | 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 [[cbdc:public:cbdc_omg:04_doc:12_summary:start| White Paper Analysis]] done by the [[https://www.omg.org/ | Object Management Group's ]] CBDC WG and listed in Table {{ref>opCyberRiskReq}}.
 <table opCyberRiskReq>
@@ Line 142: / Line 142: @@
 [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_02:start| Return to Top]]
-Table {{ref>opCyberRiskReqComment}} comments on those "desirements" identified by the [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:15_summary:start&do=edit | White Paper]] and the [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:15_summary:start | OMG's White Paper Analysis]] relating to [[cbdc:public:cbdc_omg:8_append:20_glossary:cbdc]] Operational or Cyber Risks. See: Table [[https://www.omgwiki.org/CBDC/doku.php?id=cbdc:private:cbdc_omg:04_doc:15_common:05_stakeholder:start#stakeholderReq | 5]] in Section [[cbdc:public:cbdc_omg:04_doc:15_common:05_stakeholder:start]].
+Table {{ref>opCyberRiskReqComment}} comments on those "desirements" identified by the [[https://www.federalreserve.gov/publications/files/money-and-payments-20220120.pdf | White Paper]] and the [[cbdc:public:cbdc_omg:15_summary:start | OMG's CBDC WG White Paper Analysis]] relating to [[cbdc:public:cbdc_omg:8_append:20_glossary:cbdc]] Operational or Cyber Risks. See: Table [[cbdc:public:cbdc_omg:04_doc:15_common:05_stakeholder:start#stakeholderReq | 5]] in Section [[cbdc:public:cbdc_omg:04_doc:15_common:05_stakeholder:start]].
 <table opCyberRiskReqComment>
@@ Line 173: / Line 173: @@
 Therefore, the key is to manage [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:risk | 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 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:se | 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.
+The goal of [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:se | Systems Engineering]] is to manage the 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.
 </WRAP>|
 ^ B0048 ^ Provide a secure way for people to save |<WRAP>
@@ Line 219: / Line 219: @@
   : // Cryptocurrency exchanges come and go, and it’s almost inevitable that an exchange will get hacked at one point or another. While cryptocurrencies themselves are very secure, exchanges can be affected by a variety of vulnerabilities, making them a prime target for malicious actors.//
-  : //State of the industry – February 2020: As it stands, 2019 saw a record number of twelve crypto exchanges being hacked. That being said, across the board the amounts of crypto stolen were worth less. In total, **\$292,665,886 worth of cryptocurrency and 510,000 user logins were stolen from crypto exchanges in 2019**.//
+  : //State of the industry – February 2020: As it stands, 2019 saw a record number of twelve crypto exchanges being hacked. That being said, across the board the amounts of crypto stolen were worthless. In total, **\$292,665,886 worth of cryptocurrency and 510,000 user logins were stolen from crypto exchanges in 2019**.//
   : //One would hope that as time goes on cryptocurrency exchanges would become more secure. The unfortunate reality is that more exchanges are hacked every year. As cryptocurrency and exchanges remain largely unregulated, it is unclear who has jurisdiction over cryptocurrency markets.//
@@ Line 234: / Line 234: @@
 </WRAP>|
 ^ P0021 ^ The intermediaries would operate in an open market for CBDC services |<WRAP>
-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.
+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 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.
+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 are validated.
 See:
@@ Line 333: / Line 333: @@
 | **''D''** = [[cbdc:public:cbdc_omg:04_doc:12_summary:start#design| Design Considerations]] |||
 </table>
-<color blue><todo @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)</todo></color>
-<color blue><todo @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)</todo></color>
 /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

User Tools

Site Tools

Differences

Page Tools