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_b:start [2022/05/16 18:21] nick ↷ Page moved from cbdc:public:04_doc:20_comments:brp:q13:sb_01:prt_b:start to cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_b:start |
cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_b:start [2022/06/17 19:12] (current) terrance |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== b) Cyber Resiliency ====== | ====== b) Cyber Resiliency ====== | ||
| - | [[cbdc:public: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.b) Cyber Resiliency | ||
| + | ">Provide Feedback</a></b> | ||
| + | </html> | ||
| + | </WRAP> | | ||
| ===== Overview ===== | ===== Overview ===== | ||
| - | [[cbdc:public:04_doc:20_comments:brp:q13:sb_01:prt_b:start| Return to Top]] | + | [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_b:start| Return to Top]] |
| **Cyber Resiliency** is tied to the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security | Securability]] of the system. Securability is not a single "thing" that can be added to a system. To be truly secure, the entire [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:e:e2esolution | End-to-End Solution (E2ES) ]] needs to be secure and needs to be considered during the entire [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:syslifecycle| System Lifecycle.]]. As shown in Figure {{ref>layerSecure}}, a layered approach is used to help isolate the security needs. Each layer represents a portion of the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:infotech | Information Technology (IT) ]] stack, including the people who use and have access to the IT stack. | **Cyber Resiliency** is tied to the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security | Securability]] of the system. Securability is not a single "thing" that can be added to a system. To be truly secure, the entire [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:e:e2esolution | End-to-End Solution (E2ES) ]] needs to be secure and needs to be considered during the entire [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:syslifecycle| System Lifecycle.]]. As shown in Figure {{ref>layerSecure}}, a layered approach is used to help isolate the security needs. Each layer represents a portion of the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:infotech | Information Technology (IT) ]] stack, including the people who use and have access to the IT stack. | ||
| <figure layerSecure> | <figure layerSecure> | ||
| - | {{ :cbdc:private:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:layers_of_security.png?275 |}} | + | {{ cbdc:04_doc:20_comments:brp:q13:sb_01:layers_of_security.png?275 |}} |
| <caption>The layers of security.</caption> | <caption>The layers of security.</caption> | ||
| </figure> | </figure> | ||
| - | In many ways, **Cyber Resiliency** is the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security | Security non-functional]] requirement in [[cbdc:public:04_doc:20_comments:brp:q13:sb_01:prt_a:start| Operational Resiliency ]]. | + | In many ways, **Cyber Resiliency** is the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security | Security non-functional]] requirement in [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_a:start| Operational Resiliency ]]. |
| The **Security non-Functional Requirement** includes the following sub-requirements. | The **Security non-Functional Requirement** includes the following sub-requirements. | ||
| Line 21: | Line 28: | ||
| |< 100% 20% >| | |< 100% 20% >| | ||
| ^ [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security:confidentiality | Confidentiality ]] | <WRAP> | ^ [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security:confidentiality | Confidentiality ]] | <WRAP> | ||
| - | [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:confidentiality| Confidentiality]] is usually covered by the use of a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:confidentialityagreement | Confidentiality Agreement]] or [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:n:nda | Non-Disclosure Agreement (NDA)]], which defines a set of rules or a promise limiting access or places restrictions on certain types of information. Areas that have legal agreements covering confidentiality are: | + | [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:confidentiality| Confidentiality]] is usually covered by using a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:confidentialityagreement | Confidentiality Agreement]] or [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:n:nda | Non-Disclosure Agreement (NDA)]], which defines a set of rules or a promise limiting access or places restrictions on certain types of information. Areas that have legal agreements covering confidentiality are: |
| : 1. Legal Confidentiality | : 1. Legal Confidentiality | ||
| Line 50: | Line 57: | ||
| Accessed 14 August 2020, | Accessed 14 August 2020, | ||
| [[https://csrc.nist.gov/glossary/term/authenticity | Authenticity]] | [[https://csrc.nist.gov/glossary/term/authenticity | Authenticity]] | ||
| - | )). The process of authenticating a source starts when an [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:e:entity|entity]] (i.e., user, remote process, intelligent agent, etc.) attempts to access resources on a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:computerplaform | Computer Platform]]. The entity proves their identity in order to gain access rights. For example, traditionally when logging into a computer, users use [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sfa | Single-Factor Authentication (SFA) ]], providing a ''username'' and ''password'' to confirm their identity and allow [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:authentication|authentication]] for future access to resources. However, the ''username'' and ''password'' login combination is no longer considered secure enough, especially if the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:securityculture | Security Culture]] is poor. As a consequence, many systems have added [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:t:2fa | Two-Factor Authentication (2FA) ]] that require [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:biometrics | Biometrics]] (i.e., facial recognition, fingerprints, etc.) or [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:o:otp | One-Time PIN (OTP) ]]. These 2FA methods generally require the user to be physically present to successfully login. | + | )). The process of authenticating a source starts when an [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:e:entity|entity]] (i.e., user, remote process, intelligent agent, etc.) attempts to access resources on a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:computerplaform | Computer Platform]]. The entity proves its identity in order to gain access rights. For example, traditionally when logging into a computer, users use [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sfa | Single-Factor Authentication (SFA) ]], providing a ''username'' and ''password'' to confirm their identity and allow [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:authentication|authentication]] for future access to resources. However, the ''username'' and ''password'' login combination is no longer considered secure enough, especially if the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:securityculture | Security Culture]] is poor. As a consequence, many systems have added [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:t:2fa | Two-Factor Authentication (2FA) ]] that require [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:biometrics | Biometrics]] (i.e., facial recognition, fingerprints, etc.) or [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:o:otp | One-Time PIN (OTP) ]]. These 2FA methods generally require the user to be physically present to successfully log in. |
| </WRAP>| | </WRAP>| | ||
| ^ [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security:accountability | Accountability ]] | <WRAP> | ^ [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security:accountability | Accountability ]] | <WRAP> | ||
| - | [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:accountability | Accountability]] is the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:principle|principle]] of holding an individual entrusted to safeguard and control [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:k:key|key]] components of a system or program (i.e., equipment, keying material, and information) answerable to proper authority for the loss or misuse of that component.(( | + | [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:accountability | Accountability]] is the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:principle|principle]] of holding an individual entrusted to safeguard and control [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:k:key|key]] components of a system or program (i.e., equipment, keying material, and information) answerable to proper authority for the loss or misuse of that component. (( |
| Accountability, | Accountability, | ||
| __Computer Security Resource Center (CSRC)__ | __Computer Security Resource Center (CSRC)__ | ||
| Line 63: | Line 70: | ||
| Accessed 15 August 2020, | Accessed 15 August 2020, | ||
| [[https://iso25000.com/index.php/en/iso-25000-standards/iso-25010?limit=3&start=6]] | [[https://iso25000.com/index.php/en/iso-25000-standards/iso-25010?limit=3&start=6]] | ||
| - | )) requiring the actions of an [[https://www.omgwiki.org/dido/doku.php?id=[dido:public:ra:xapend:xapend.a_glossary:e:entity|entity]] to be traced uniquely to that entity. Accountability directly supports [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security:nonrepudiability | Non-Repudiation]]. It also provides deterrence, helps with fault isolation, and is useful in intrusion detection and prevention. In many cases, it is a key source of the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:e:evidence|evidence]] used in an [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:aar | After Action Review (AAR)]] and can ultimately, if needed, support legal actions. | + | )) requiring the actions of an [[https://www.omgwiki.org/dido/doku.php?id=[dido:public:ra:xapend:xapend.a_glossary:e:entity|entity]] to be traced uniquely to that entity. Accountability directly supports [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc:25_security:nonrepudiability | Non-Repudiation]]. It also provides deterrence, helps with fault isolation, and is useful in intrusion detection and prevention. In many cases, it is a key source of the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:e:evidence|evidence]] used in an [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:aar | After Action Review (AAR)]] and can ultimately, if needed, support legal actions. |
| </WRAP>| | </WRAP>| | ||
| </table> | </table> | ||
| - | 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]] in order to refine the definitions and expectations of Cyber Resiliency. See [[cbdc:public:04_doc:15_common:05_stakeholder:start| CBDC Stakeholders]] for a more detailed discussion. | + | 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]] in order to refine the definitions and expectations of Cyber Resiliency. See [[cbdc:public:cbdc_omg:04_doc:15_common:05_stakeholder:start| CBDC Stakeholders]] for a more detailed discussion. |
| ===== Guidelines for Developing Cyber-Resilient Systems ===== | ===== Guidelines for Developing Cyber-Resilient Systems ===== | ||
| - | [[cbdc:public:04_doc:20_comments:brp:q13:sb_01:prt_b:start| Return to Top]] | + | [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:sb_01:prt_b:start| Return to Top]] |
| - | An important first step is to follow the NIST Special Publication SP 800-16 volume 2 guidelines for developing cyber-resilient systems.(( | + | An important first step is 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, | Ron Ross, Victoria Pillitteri, Richard Graubart, Deborah Bodeau, Rosalie McQuaid, | ||
| __Developing Cyber-Resilient Systems: A Systems Security Engineering Approach__, | __Developing Cyber-Resilient Systems: A Systems Security Engineering Approach__, | ||
| Line 80: | Line 87: | ||
| Accessed: 11 April 2022, | Accessed: 11 April 2022, | ||
| [[https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v2r1.pdf]] | [[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 stakeholder 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. | + | )). 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 stakeholder 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 resistant. |
| SP 800-16 provides a framework for conducting cyber resiliency engineering. It starts with defining and setting the goals, objectives, techniques, implementation | SP 800-16 provides a framework for conducting cyber resiliency engineering. It starts with defining and setting the goals, objectives, techniques, implementation | ||
| Line 141: | Line 148: | ||
| Once the Systems Engineering is completed, a design can be achieved to foster cyber resiliency. | Once the Systems Engineering is completed, a design can be achieved to foster cyber resiliency. | ||
| - | <color blue><todo @nick>Suggest adding major defs of terms in Table 1 and 2 into Glossary - per Steve McL</todo></color> | ||
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||