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:q11:04_risks [2022/04/27 14:36] terrance |
cbdc:public:cbdc_omg:04_doc:20_comments:brp:q11:04_risks [2022/06/17 19:04] (current) terrance |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== 4. Risk Due to lack of Broad, Wide Ranging Security Planning ====== | + | ====== 4. Risk Due to lack of Broad, Wide-Ranging Security Planning ====== |
| - | [[cbdc:private:cbdc_omg:04_doc:20_comments:brp:q11:start | Return to Question 11]] | + | |< 100% >| |
| + | | [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q11:start| Return to Question 11]] | <WRAP> | ||
| + | <html><b> | ||
| + | <a href="mailto:[email protected]?Subject=OMG's CBDC WG Response: | ||
| + | 11.4. Risk Due to lack of Broad, Wide Ranging Security Planning | ||
| + | ">Provide Feedback</a></b> | ||
| + | </html> | ||
| + | </WRAP> | | ||
| An important way to make sure the Security Planning is adequate is to design it into the U.S. CBDC from the onset, especially if the U.S. CBDC adopts the use of Distributed Technologies currently in wide use in cryptocurrencies. First, it is important to detail what needs to be secure and why. See Table {{ref>datatypeSecurity}}. | An important way to make sure the Security Planning is adequate is to design it into the U.S. CBDC from the onset, especially if the U.S. CBDC adopts the use of Distributed Technologies currently in wide use in cryptocurrencies. First, it is important to detail what needs to be secure and why. See Table {{ref>datatypeSecurity}}. | ||
| Line 15: | Line 22: | ||
| </table> | </table> | ||
| - | All too often, projects try to "bolt-on" security after products are built. When building something as essential and critical to the U.S. as a new financial mechanism such, ie., the CBDC, it is essential to think about it at every stage of the development, starting at the specification of requirements and at each layer of securability. See Figure {{ref>layerSecDarw}} and Table {{ref>layerSec}} | + | All too often, projects try to "bolt-on" security after products are built. When building something as essential and critical to the U.S. as a new financial mechanism such, ie., as the CBDC, it is essential to think about it at every stage of development, starting at the specification of requirements and at each layer of securability. See Figure {{ref>layerSecDarw}} and Table {{ref>layerSec}} |
| Securability is also a layered stack. At each layer, there are different steps that need to be taken to secure the system. For example, **Culture Security** it may just mean having employees hold a security clearance and/or take Drug Tests. For **Physical Security** it may mean having a locked facility to house the computers and network devices. Data Security might be software and cultural procedures such as encrypting all data stored in a disk drive and using software to access the data. | Securability is also a layered stack. At each layer, there are different steps that need to be taken to secure the system. For example, **Culture Security** it may just mean having employees hold a security clearance and/or take Drug Tests. For **Physical Security** it may mean having a locked facility to house the computers and network devices. Data Security might be software and cultural procedures such as encrypting all data stored in a disk drive and using software to access the data. | ||
| <figure layerSecDarw> | <figure layerSecDarw> | ||
| - | {{ :cbdc:private:cbdc_omg:04_doc:15_common:48_natsec:layers_of_security.png?300 |}} | + | {{ cbdc:04_doc:15_common:48_natsec:layers_of_security.png?275 |}} |
| <caption>The layers of Security.</caption> | <caption>The layers of Security.</caption> | ||
| </figure> | </figure> | ||
| Line 34: | Line 41: | ||
| </table> | </table> | ||
| - | <color blue><todo @nick>how to address McL's comment about highlighting the IEF? Think it could have a role to play but is this the place to bring it out? Is there some other place in this document where it could be mentioned? Or is it sufficient to point at the DIDO RA for a citation about the IEF? </todo></color> | + | The OMG's CBDC WG members recommend a close look at the Reference Architecture (RA) defined by [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:ief | Information Exchange Framework (IEF)]]. |
| + | |||
| + | The IEF RA is primarily targeting operational environments that require the ability and capacity to share information within and beyond organizational boundaries (public and private sectors) and are challenged by rapid, unpredictable changes in operational contexts (e.g., threat, risk, roles & responsibilities, scale, scope, and severity). The IEF RA is targeted towards the following areas: | ||
| + | |||
| + | * Military (coalition and Civilian-Military) operations | ||
| + | * National Security | ||
| + | * Public Safety | ||
| + | * Crisis Management | ||
| + | * Border Security | ||
| + | * Emergency Management | ||
| + | * Peace Keeping | ||
| + | * Humanitarian Assistance | ||
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||