cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a: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:sb_01:prt_a:start [2022/05/08 21:19] nick ↷ Page moved and renamed from cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a to cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a:start |
cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a:start [2022/06/17 19:11] (current) terrance |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== a) Operational Resiliency ====== | ====== a) Operational Resiliency ====== | ||
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:start | Return to Question 13-1 ]] | + | |< 100% >| |
| + | | [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:start| Return to Question 13-1 ]] | <WRAP> | ||
| + | <html><b> | ||
| + | <a href="mailto:[email protected]?Subject=OMG's CBDC WG Response: | ||
| + | 13.1.a) Operational Resiliency | ||
| + | ">Provide Feedback</a></b> | ||
| + | </html> | ||
| + | </WRAP> | | ||
| ===== Overview ===== | ===== Overview ===== | ||
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a | Return to Top]] | + | [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a:start| 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]] needs to address things which can not be added on //post facto// or //"bolted on"// easily after the CBDC is deployed. In other words, it must be //"baked in"// so to speak. This means that for something new, like the CBDC, it starts with specifying 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 Requirements]]. The specification of requirements needs to be done as soon as possible. Granted, the system must be agile and adapt to unforeseen changes in the deployment environment, [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:t:threat | threats]], | 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]] needs to address things which can not be added on //post facto// or //"bolted on"// easily after the CBDC is deployed. In other words, it must be //"baked in"// so to speak. This means that for something new, like the CBDC, it starts with specifying 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 Requirements]]. The specification of requirements needs to be done as soon as possible. Granted, the system must be agile and adapt to unforeseen changes in the deployment environment, [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:t:threat | threats]], | ||
| - | [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:e:exploit | exploits]], etc. However, if these are not specified as requirements, the impact of these changes can be extraordinary. For example, tying functionality to a specific [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:o:os | Operating System(OS)]] or version of an OS rather than using standard, more portable alternatives (i.e., Windows 7 or Windows 10 versus POSIX). Relying on Operating System [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:u:unix_domain_scoket&s[]=socket | sockets]] versus higher abstraction layers such as OMG's [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dds | DDS]]. | + | [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:e:exploit | exploits]], etc. However, there is a fine line between being "agile" and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:scope_creep | Scope Creep]]. Agile should not be defining or redefining major functional or non-function requirements, but rather defining or refining Software Requirements such as Business Requirements, User Requirements. Granted, some functional and non-functional can evolve over time, but usually as a result of a discovery process conducted during [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtd_e | Research Development Test & Evaluation]] phases of a project, not during the production of a deployable system. Sometimes a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:proof_or_concept | Proof-of-Concept]] or Prototype Model(( |
| - | + | The prototyping model is a software development model in which a prototype is built, tested, and reworked until an acceptable prototype is achieved. It also creates a base to produce the final system or software. It works best in scenarios where the project’s requirements are not known in detail. It is an iterative, trial and error method that takes place between developer and client. | |
| - | <color blue><todo @nick> need to fix. Each of the previous two sentences don't include anything that states the consequences of "relying on" xyz. Is the second sentence being offered as a way to mitigate the negative consequences of relying on the OS or version thereof?? Or another example of a bad thing to do? URGENT .. and if this wording appears elsewhere in the doc (think it does) fix it there too.</todo></color> | + | Matthew Martin, |
| + | __Prototyping Model in Software Engineering: Methodology, Process, Approach__, | ||
| + | Guru99, | ||
| + | 5 March 2022, | ||
| + | Accessed: 17 May 2022, | ||
| + | [[https://www.guru99.com/software-engineering-prototyping-model.html]] | ||
| + | )). The Prototype model can work in areas such as Web Development, but not in the development of [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:missioncritical | Mission Critical Systems]]. For Mission Critical Systems, the prototype is used as "throwaway" code used to capture and refine more formalized requirements. | ||
| Operational Resiliency also means once the CBDC is up and operational, it needs to respond to internal issues requiring continuous monitoring and adaptation of the CBDC in order to ensure it continues to have Operational Resiliency and that it can evolve and live beyond any existing software or hardware component that comprises the CBDC. In the U.S. Navy, this is referred to as "reboot the Navy" In other words, it is not possible to reboot all the systems on a ship or within a fleet at the same time and still maintain operational purpose. Likewise, in distributed systems, it is not possible to update all the parts at one time; sometimes older parts may take years to update. Also, see the OMG DIDO-RA sections on: | Operational Resiliency also means once the CBDC is up and operational, it needs to respond to internal issues requiring continuous monitoring and adaptation of the CBDC in order to ensure it continues to have Operational Resiliency and that it can evolve and live beyond any existing software or hardware component that comprises the CBDC. In the U.S. Navy, this is referred to as "reboot the Navy" In other words, it is not possible to reboot all the systems on a ship or within a fleet at the same time and still maintain operational purpose. Likewise, in distributed systems, it is not possible to update all the parts at one time; sometimes older parts may take years to update. Also, see the OMG DIDO-RA sections on: | ||
| Line 22: | Line 35: | ||
| ===== Understanding the "What ifs" ===== | ===== Understanding the "What ifs" ===== | ||
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a | Return to Top]] | + | [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a:start| Return to Top]] |
| A key aspect of obtaining **Operational Resiliency** is to develop //"what-if"// scenarios to validate the resilience of the system against functional and non-Functional requirements. Some possible scenarios might be: | A key aspect of obtaining **Operational Resiliency** is to develop //"what-if"// scenarios to validate the resilience of the system against functional and non-Functional requirements. Some possible scenarios might be: | ||
| Line 30: | Line 43: | ||
| * What if there is a network outage in the NE U.S.? | * 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 network failure crossing the Atlantic? | ||
| - | * What if there is a personnel breach of security? | + | * What if there is a breach of security from personnel? |
| * What if there is a compromise in the data access? | * What if there is a compromise in the data access? | ||
| * What if there is a 10-fold demand for access to CBDC infrastructure? | * What if there is a 10-fold demand for access to CBDC infrastructure? | ||
| Line 36: | Line 49: | ||
| * What happens if there is a war? | * What happens if there is a war? | ||
| - | <color blue><todo @nick>"Personnel"? Or "Personal"? How about simply "breach security"?</todo></color> | + | A well-defined Resilience Plan addressing the specific Functional and non-Functional requirements is essential. Trying to reverse engineer these requirements from an existing system adds a lot of risks and indicates the system is not designed but the result of Organic Development(( |
| - | + | ||
| - | A well-defined Resilience Plan addressing the specific Functional and non-Functional requirements is essential. Trying to reverse engineer these requirements from an existing system adds a lot of risk and indicates the system is not designed but 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. | **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 makes sense for products with 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: | + | )). While this makes sense for products with a short life span and is 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 confidence (i.e., **''B0020''**) | * Instill confidence (i.e., **''B0020''**) | ||
| Line 48: | Line 59: | ||
| ===== Understanding the Requirements ===== | ===== Understanding the Requirements ===== | ||
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a | Return to Top]] | + | [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a:start| Return to Top]] |
| 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. In essence, each of the **non-functional** requirements should be considered carefully and tailored to the needs of the Federal Reserve and the CBDC. | 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. In essence, each of the **non-functional** requirements should be considered carefully and tailored to the needs of the Federal Reserve and the CBDC. | ||
| Line 103: | Line 114: | ||
| ===== Steps to Achieving Operational Resilience ===== | ===== Steps to Achieving Operational Resilience ===== | ||
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a | Return to Top]] | + | [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a:start| Return to Top]] |
| The following is an excerpt is from a blog from Matt Kunkel on //"What is Operational Resilience?"//(( | The following is an excerpt is from a blog from Matt Kunkel on //"What is Operational Resilience?"//(( | ||
| Line 115: | Line 126: | ||
| - //**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.// | - //**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.// | + | - //**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 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 returns 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.// | - //**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.// | ||
| ===== Strengthing Operational Resilience ===== | ===== Strengthing Operational Resilience ===== | ||
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a | Return to Top]] | + | [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a:start| Return to Top]] |
| Another blog post from Dominick Campagna defines five ways to strengthen **Operational Resilience** in the Financial Services Sector(( | Another blog post from Dominick Campagna defines five ways to strengthen **Operational Resilience** in the Financial Services Sector(( | ||
| Line 139: | Line 150: | ||
| <table fiveways> | <table fiveways> | ||
| - | <caption>5 Ways to Strengthen Operational Resilience in the Financial Services Sector.(( | + | <caption>5 Ways to Strengthen Operational Resilience in the Financial Services Sector. (( |
| Dominick Campagna, | Dominick Campagna, | ||
| __5 Ways to Strengthen Operational Resilience in the Financial Services Sector__, | __5 Ways to Strengthen Operational Resilience in the Financial Services Sector__, | ||
| Line 150: | Line 161: | ||
| ^ Step ^ Description of Activities ^ | ^ Step ^ Description of Activities ^ | ||
| ^ 1. Establish Effective Governance | <WRAP> | ^ 1. Establish Effective Governance | <WRAP> | ||
| - | 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. | + | Effective governance at the board and senior management level are 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. |
| </WRAP>| | </WRAP>| | ||
| ^2. Identify Critical Assets | <WRAP> | ^2. Identify Critical Assets | <WRAP> | ||
| 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. | 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. | + | 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, and the operationally resilient firm will have the policies, procedures, and practices in place to guide them through any disruption. |
| To do this systematically, 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. | To do this systematically, 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. | ||
| Line 164: | Line 175: | ||
| 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. | 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 build out 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. | + | An understanding of the entire picture is necessary for recovery planning and the build-out 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. |
| </WRAP>| | </WRAP>| | ||
| Line 170: | Line 181: | ||
| 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. | 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. | + | As new infrastructure and technology are adopted, your plans should be revisited and tested. Any digital transformation efforts should include planning for and adopting policies to address digital risks, 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. | + | Consistent testing of your operational resilience plans, including dependencies and interconnections, will prepare your firm to pivot and adapt quickly to a disruption. |
| </WRAP>| | </WRAP>| | ||
cbdc/public/cbdc_omg/04_doc/20_comments/brp/q13/sb_01/prt_a/start.1652059191.txt.gz · Last modified: 2022/05/08 21:19 by nick
