cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:start [2022/04/11 19:09] nick |
cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:start [2022/06/17 19:10] (current) terrance |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Question: 13. TBD How could a CBDC be designed to foster operational and cyber resiliency? What operational or cyber risks might be unavoidable? ====== | + | ====== Question: 13. How could a CBDC be designed to foster operational and cyber resiliency? What operational or cyber risks might be unavoidable? ====== |
| - | [[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: 13. How could a CBDC be designed to foster operational and cyber resiliency? What operational or cyber risks might be unavoidable? | ||
| + | ">Provide Feedback</a></b> | ||
| + | </html> | ||
| + | </WRAP> | | ||
| ===== Question ===== | ===== Question ===== | ||
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13| Return to Top]] | + | [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:start| Return to Top]] |
| - | - [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13#how_could_a_cbdc_be_designed_to_foster_operational_and_cyber_resiliency | How could a CBDC be designed to foster operational and cyber resiliency?]] | + | This question is actually a compound question. Each question is answered independently: |
| - | - [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13#what_operational_or_cyber_risks_might_be_unavoidable | What operational or cyber risks might be unavoidable?]] | + | |
| + | - [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:start#how_could_a_cbdc_be_designed_to_foster_operational_and_cyber_resiliency| How could a CBDC be designed to foster operational and cyber resiliency?]] | ||
| + | - [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:start#what_operational_or_cyber_risks_might_be_unavoidable| What operational or cyber risks might be unavoidable?]] | ||
| ===== Answer ===== | ===== Answer ===== | ||
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13| Return to Top]] | + | [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:start| Return to Top]] |
| In order to answer this compound question, each part of the question is answered separately: | In order to answer this compound question, each part of the question is answered separately: | ||
| - | * [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13#how_could_a_cbdc_be_designed_to_foster_operational_and_cyber_resiliency | 1. How could a CBDC be designed to foster operational and cyber resiliency? ]] | + | <nspages -tree -r -exclude -subns -pagesInNs -h1 -textNs=""> |
| - | * [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13#what_operational_or_cyber_risks_might_be_unavoidable | 2. What operational or cyber risks might be unavoidable?]] | + | |
| - | + | ||
| - | ==== 1. How could a CBDC be designed to foster operational and cyber resiliency? ==== | + | |
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13| Return to Top]] | + | |
| - | + | ||
| - | Although Cyber Resiliency is affected by the Operational Resiliency of the system as a whole, the two topics need to be treated separately. Therefore, the question has been subdivided into two questions: | + | |
| - | + | ||
| - | : a) [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13#a_operational_resiliency | Operational Resiliency ]] | + | |
| - | : b) [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13#b_cyber_resiliency | Cyber Resiliency ]] | + | |
| - | + | ||
| - | === a) Operational Resiliency === | + | |
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13| Return to Top]] | + | |
| - | + | ||
| - | [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:o:operational_resilience | Operational Resilience]] | + | |
| - | + | ||
| - | === b) Cyber Resiliency === | + | |
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13| Return to Top]] | + | |
| - | + | ||
| - | The first step in designing for [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:cyber_resiliency | Cyber Resiliency]] is to begin with a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:se | Systems Engineering]] approach and to survey CBDC [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:stakeholder | Stakeholders]] to refine the definitions and expectations of Cyber Resiliency. See [[cbdc:private:cbdc_omg:04_doc:15_common:05_stakeholder:start | CBDC Stakeholders]] for a more detailed discussion. | + | |
| - | + | ||
| - | + | ||
| - | An important first step needs to be to follow the NIST Special Publication SP 800-16 volume 2 guidelines for developing cyber-resilient systems.(( | + | |
| - | Ron Ross, Victoria Pillitteri, Richard Graubart, Deborah Bodeau, Rosalie McQuaid, | + | |
| - | __Developing Cyber-Resilient Systems: A Systems Security Engineering Approach__, | + | |
| - | National Institute for Standards and Technology (NIST), | + | |
| - | NIST Special Publication 800-160, Volume 2, Revision 1, | + | |
| - | December 2021, | + | |
| - | Accessed: 11 April 2022, | + | |
| - | [[https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v2r1.pdf]] | + | |
| - | )). Skipping this step and going right to design and implementation often ends with the problem space (i.e., CBDC) being defined by the product(s) it chooses to use rather than by the stakeholders requirements. A product based solution can work, but it often misses many key requirements important to the stakeholders. For example, the design must be [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:q:quantum_computing | Quantum Computing]] "safe" or resistent. | + | |
| - | + | ||
| - | SP 800-16 provides a framework for conducting cyber resiliency engineering. It starts with defining and setting the goals, objectives, techniques, implementation | + | |
| - | approaches, design principles. Table {{ref>cyberResil}} summarizes the definition and purpose of each construct, and how each construct is applied at the system level. **Note:** The framework is applicable to levels beyond the system level (e.g., mission or business function level, organizational level, or sector level). | + | |
| - | + | ||
| - | <table cyberResil> | + | |
| - | <caption>Cyber Resiliency Constructs(( | + | |
| - | Ron Ross, Victoria Pillitteri, Richard Graubart, Deborah Bodeau, Rosalie McQuaid, | + | |
| - | __Developing Cyber-Resilient Systems: A Systems Security Engineering Approach__, | + | |
| - | National Institute for Standards and Technology (NIST), | + | |
| - | NIST Special Publication 800-160, Volume 2, Revision 1, | + | |
| - | December 2021, | + | |
| - | Accessed: 11 April 2022, | + | |
| - | [[https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v2r1.pdf]] | + | |
| - | ))</caption> | + | |
| - | |< 100% 15% >| | + | |
| - | ^ Construct ^ Definition, Purpose, and Application at the System Level | | + | |
| - | ^ **Goal** | <WRAP> | + | |
| - | A high-level statement supporting (or focusing on) one aspect (i.e., anticipate, withstand, recover, adapt) in the definition of cyber resiliency. | + | |
| - | + | ||
| - | : **Purpose:** Align the definition of cyber resiliency with definitions of other types of resilience. | + | |
| - | + | ||
| - | : **Application:** Can be used to express high-level stakeholder concerns, goals, or priorities. | + | |
| - | </WRAP>| | + | |
| - | ^ **Objective** | <WRAP> | + | |
| - | A high-level statement (designed to be restated in system-specific and stakeholder-specific terms) of what a system must achieve in its operational environment and throughout its life cycle to meet stakeholder needs for mission assurance and resilient security. The objectives are more specific than goals and more relatable to threats. | + | |
| - | + | ||
| - | : **Purpose:** Enable stakeholders and systems engineers to reach a common understanding of cyber resiliency concerns and priorities; facilitate the definition of metrics or [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:moe | Measures of Effectiveness (MoEs)]]. | + | |
| - | + | ||
| - | : **Application:** Used in scoring methods or summaries of analyses (e.g., cyber resiliency posture assessments). | + | |
| - | </WRAP>| | + | |
| - | ^ Sub-Objective | <WRAP> | + | |
| - | A statement, subsidiary to a cyber resiliency objective, that emphasizes different aspects of | + | |
| - | that objective or identifies methods to achieve that objective. | + | |
| - | + | ||
| - | : **Purpose:** Serve as a step in the hierarchical refinement of an objective into activities or capabilities for which performance measures can be defined. | + | |
| - | + | ||
| - | : **Application:** Used in scoring methods or analyses; may be reflected in system functional requirements. | + | |
| - | </WRAP>| | + | |
| - | ^ <WRAP> | + | |
| - | Activity\\ | + | |
| - | or\\ | + | |
| - | Capability</WRAP> | <WRAP> | + | |
| - | A statement of a capability or action that supports the achievement of a sub-objective and, | + | |
| - | hence, an objective. | + | |
| - | + | ||
| - | : **Purpose:** Facilitate the definition of metrics or [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:moe | MoE]]. While a representative set of activities or capabilities have been identified in [Bodeau18b], these are intended solely as a starting point for selection, tailoring, and prioritization. | + | |
| - | + | ||
| - | : **Application:** Used in scoring methods or analyses; reflected in system functional requirements. | + | |
| - | </WRAP>| | + | |
| - | ^ **Strategic Design Principle** | <WRAP> | + | |
| - | A high-level statement that reflects an aspect of the risk management strategy that informs | + | |
| - | systems security engineering practices for an organization, mission, or system. | + | |
| - | + | ||
| - | : **Purpose:** Guide and inform engineering analyses and risk analyses throughout the system life cycle. Highlight different structural design principles, cyber resiliency techniques, and implementation approaches. | + | |
| - | + | ||
| - | : **Application:** Included, cited, or restated in system non-functional requirements (e.g., requirements in a Statement of Work [SOW] for analyses or documentation). | + | |
| - | </WRAP>| | + | |
| - | </table> | + | |
| - | + | ||
| - | Once the Systems Engineering is completed, a design can be made to foster cyber resiliency. | + | |
| - | + | ||
| - | ==== 2. What operational or cyber risks might be unavoidable? ==== | + | |
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13| Return to Top]] | + | |
| - | + | ||
| - | + | ||
| - | ===== References ===== | + | |
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13| Return to Top]] | + | |
| - | + | ||
| - | <table> | + | |
| - | <caption>Guiding Document Specifics</caption> | + | |
| - | ^ Source | [[https://www.federalreserve.gov/publications/files/money-and-payments-20220120.pdf | Money and Payments: The U.S. Dollar in the Age of Digital Transformation]] | | + | |
| - | ^ Published Date: | January 2022 | | + | |
| - | ^ Requestor | Board of Governors, [[https://www.federalreserve.gov/aboutthefed.htm | The Federal Reserve System]] | | + | |
| - | ^ Area | Research and Analysis | | + | |
| - | </table> | + | |
cbdc/public/cbdc_omg/04_doc/20_comments/brp/q13/start.1649718549.txt.gz · Last modified: 2022/04/11 19:09 by nick
