Differences

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

--- cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:start [2022/04/12 01:16]
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 =====
-[[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 =====
-[[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:
-  * [[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]]
-Within the context of CBDC, [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:o:operational_resilience | Operational Resilience]] neds to address a few things and is not something that can be added on or bolted onto an existing systems, it must be //baked in// so to speak. This means that for something that is new, like the CBDC, it starts with spcifying the requirements, both [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:n:nonfuncreq | non-Functional]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:f:funcreq | Functional Rerquirements]].
-Operational Resiliency also means that once the CBDC is up and opertional, it needs to respond to internal issues requiring continuous monitoring and adaptation of the CBDC to ensure it continues to has Operational Resiliency and also that it able to evolve to live way beyond any existing software or harward component that comprises the CBDC.
-Operational Resiliency also means that it must continue to adapt to the surround situations (i.e., hostile cyber threats, physical threats like hurricanes, earthquakes, and fire) and evolving national and geopollitical situations. The current Ukraine-Russian conflict is an example.
-In other words, Operational Resiliency for the CBDC is not a done and dusted sort of problem. It is a continuous process that covers the entire [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:4_data_tax:05_lifecycle:start | lifecyle]] of the CBDC or followon efforts.
-A key aspect of Operational Resiliency is to develop //"what-if"// scenarios to validate the resilence of the system against the functional and non-Functional requirements. Some possible scenarios might be:
-  * What if there is an upgrade to an Operating System?
-  * What if a key component of the CBDC system is obsolete and no longer available?
-  * What if there is a network outage in the NE U.S?
-  * What if there is a network failure crossing the Atlantic?
-  * What if there is a personel breach of security?
-  * What if there is a compromise in the data access?
-  * What if there is a 10-fold demand for access to CBDC infrastructure?
-  * What id the the value of the U.S. Dollar goes up or down against the rest of the world currencies?
-  * What happens if there is a war?
-A well-defined Resilience Plan addressing the specific Functional and non-Functional requirements is essential. Trying to reverse engineer what these requirements are from an existing system adds a lot of risk and indicates that the system is not designed but is the result of Organic Development((
-**Organic Development** is the internal growth based on adjusting and adapting to the situations at hand. For example, new information systems might evolve incrementally based on user feedback rather than starting anew with a system from a third party.
-)). While this make sense for products that have a short life span and are not [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:missioncritical | Mission Critical]], it is not going to:
-  * Instill the confidence (i.e., **''B0020''**)
-  * Preserve the dominant role of the U.S. Dollar (i.e., **''B0036''**)
-  * Provide braod support from CBDC Stakeholders (i.e., **''B0006''**)
-  * Provide trusted central bank money (i.e., **''B0027''**).
-The following is an outline from the OMG's DIDO-RA for [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc | non-Functional Requirements]] and should be reviewed and assessed for applicability to the CBDC.
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:10_portability      | Portability]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:10_portability:01_adapt | Adaptability]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:10_portability:04_install | Installability]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:10_portability:06_replace | Replaceability]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:14_reliability      | Reliability]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:14_reliability:01_matuity | Maturity ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:14_reliability:02_availability | Availability ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:14_reliability:04_faulttolerance | Fault Tolerance ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:14_reliability:12_recoverability | Recoverability ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:20_maintainability  | Maintainability]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modularity | Modularity ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:20_maintainability:reuseability | Reusability ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:20_maintainability:analysability | Analysability ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modifiability | Modifiability ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:20_maintainability:testabilityTestability ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security         | Security]]
-    * [[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 ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:28_manageability    | Manageability]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:28_manageability:02_types | Types of Manageability Functions ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:28_manageability:04_costs | Manageability Costs]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:28_manageability:06_system | System Manageability Issues]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:28_manageability:08_software | Software Manageability Issues]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:30_usability        | Usability ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:30_usability:effectiveness | Effectiveness Metrics]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:30_usability:efficiency | Efficiency Metrics]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:30_usability:satisfaction | Attitude / Satisfaction Metrics]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:40_performance      | Performance ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:40_performance:01_platform | Platform Performance ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:40_performance:02_application | Application Performance ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:40_performance:04_nework | Network Performance ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:05_interoperability | Interoperability ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:08_elasticity       | Elasticity ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:16_scalability      | Scalability ]]
-In many ways, Operational Resiliency is a high level view of the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:1_func | Functional Requirements]] for the CBDC.
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:1_func:platform | Platforms ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:1_func:platform:hw_arch | Hardware Platform ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:1_func:platform:os_arch | Operating System Platform]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:1_func:platform:sw_arch | Runtime Platforms ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:1_func:platform:net_arch | Network Platforms ]]
-    * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:1_func:platform:virtnodes | Virtualized Nodes ]]
-  * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:1_func:access | Access Control ]]
-[[https://www.logicgate.com/blog/what-is-operational-resilience/ | What is Operational Resilience?]]
-Take These 3 Steps to Build Operational Resilience
-**Take a holistic view of organizational risk.** Consider internal and external factors that impact your organization including business lines, assets, systems, processes, third parties, and people. Building a resilient operation means seeing the interconnection and interdependence of risk throughout the organization. Effective enterprise risk management systems must look across divisions and operations to holistically assess and account for potential threats.
-**Design systems that take a comprehensive approach to risk assessment. **This starts with translating risk into a language that everyone at the firm understands. Having a common vernacular permits a more comprehensive analysis and documentation of potential risks throughout the organization. It also allows for a more robust discussion around risk and return as organizations consider how to adapt to changing conditions. Moreover, a shared language permits greater collaboration and cooperation, both critical to building a deeper understanding of the interdependence of risk in the organization and building operational resilience.
-**Assess for critical points of failure to inform robust processes, ensure systems capabilities, and cultivate adaptable practices.** Although no market disruption or business interruption is the same, much can be learned from each. Knowing where the key risks lie across the organization and proactively implementing potential workarounds can help organizations better adapt to evolving conditions. The key is having robust systems and flexible processes, as well as cultivating a collaborative and resilient culture.
-[[https://www.logicgate.com/blog/5-ways-to-strengthen-operational-resilience-in-the-financial-services-sector/ | 5 Ways to Strengthen Operational Resilience in the Financial Services Sector]]
-For any financial services company, big or small, failure is not an option. Financial services play a critical, foundational role in almost every sector of the economy, and robust customer service is expected through technology failures, market disruption, systemic risk events, natural disasters, and even pandemics.
-Companies that can deliver robust services through unexpected disruptions are considered operationally resilient. The critical importance of operational resilience in financial services is evidenced by the flurry of guidance from global financial regulators detailing expectations and mandating best practices on how providers and supporting infrastructure can improve their operational resilience.
-Operational resilience, as defined by the Federal Reserve Board (FRB), is the ability to deliver operations, including critical operations and core business lines, through disruption from any hazard. Last October, the FRB, in partnership with the Office of the Comptroller of the Currency, and the Federal Deposit Insurance Corporation, issued an interagency paper on Sound Practices to Strengthen Operational Resilience. This guidance, specifically written for banks and savings and loan companies with at least $100 billion in assets, can be adapted and applied to financial services companies of any size.
-In short, operational resilience is built through “effective operational risk management combined with sufficient financial and operational resources to prepare, adapt, withstand, and recover from disruptions.” More than business continuity, which is focused on uninterrupted operations, operational resilience considers how to best adapt a firm’s operations to deliver services through any disruption.
-. Establish Effective Governance
-Effective governance at the board and senior management level is critical to strengthening operational resilience. A strong risk management culture—the foundation of operational resilience—can only happen when there is top-down, organizational commitment. Board and executive responsibilities lay the groundwork and accountability for an operationally resilient mindset and commitment to supporting practices throughout the organization.
-. Identify Critical Assets
-Disruption, by its nature, is unpredictable. Operational resilience is not about identifying and measuring risks and uncertainty, as the impact of evolving technology and market changes can rarely be predicted. It is instead a framework for protecting the core business.
-The identification of critical assets and functions and core business lines should be done with the intention of protecting those assets and operations regardless of the source of disruption. Whether impacted by an unexpected technology failure, pandemic, cybersecurity incident, or any other cause, an operationally resilient firm will have the policies, procedures, and practices in place to guide them through any disruption.
-To do this in a systematic way, the board must determine and approve the risk appetite and risk tolerance for operational disruption, both at the enterprise level and for critical operations and core business lines. These explicit board parameters for the firm’s acceptable level of risk from operational disruption can guide effective decision-making, appropriate investment in resilient systems and controls, and a consistent firm-wide approach to operational risk management.
-. Consider Key Dependencies and Interconnections
-After identifying the core business lines and critical assets and functions, consider the key personnel, technology, processes, data, and physical infrastructure facilities required to protect them. Understanding those inputs and mapping out the dependency and interconnection of those assets on other internal functions, external parameters, or third parties will support a robust plan for business continuity and operational resilience.
-Managing third-party risk is critical for operational resilience given the growing dependence on third parties to maintain specific functions and services of core business lines. This risk must also be accounted for within the approved risk tolerance.
-An understanding of the entire picture is necessary for recovery planning and the buildout of appropriate redundancies and alternate availability of essential resources, personnel, technology capability, and, if necessary, physical infrastructure. Recovery planning should also be consistent with existing risk management practices to ensure that there are no gaps in providing service or meeting regulatory requirements.
-. Proactively Review and Audit Plans
-Operational resilience is a dynamic process requiring periodic review, testing, and auditing. As systems and processes evolve, so should your plans. Regularly employing an internal or external audit function to assess the design and effectiveness of operational resilience efforts will help to keep your plans relevant, identify shortcomings due to process or policy changes, and support a firm-wide culture of risk management and operational resilience.
-As new infrastructure and technology is adopted, your plans should be revisited and tested. Any digital transformation efforts should include planning for and adoption of policies to address digital risk, such as disruption due to an internal failure, cybersecurity incident, or processing error.
-Consistent testing of your operational resilience plans, including dependencies and interconnections, will prepare your firm to pivot and adapt quickly through a disruption.
-. Form a Collaborative Approach to Operational Risk Management
-An operational risk management function is responsible for determining and managing exposure related to internal processes, people, and systems as well as external threats and third parties. However, they cannot do this in a silo. Effective operational risk management requires a collaborative approach between senior management, business units, the operational risk management function or designees, and the internal or external audit function.
-A cross-functional approach supports effective identification, mitigation, and resolution of operational risk, including technology and third-party risk, within the risk appetite and risk tolerance defined by the board while collaboration ensures a consistent, firm-wide approach and commitment to 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>

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

User Tools

Site Tools

Differences

Page Tools