This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
dido:public:ra:1.4_req:2_nonfunc:25_security:nonrepudiability [2020/11/11 01:27] nick created |
dido:public:ra:1.4_req:2_nonfunc:25_security:nonrepudiability [2021/07/30 12:23] (current) murphy [About] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== 2.2.4.3 Non-Repudiation ====== | + | ====== 4.3.4.3 Non-Repudiation ====== |
| - | [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional:20_maintainability| Return to Securability]] | + | [[dido:public:ra:1.4_req:2_nonfunc:25_security | Return to Securability ]] |
| ===== About ===== | ===== About ===== | ||
| - | [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional:25_security:nonrepudiability| Return to Top]] | + | [[dido:public:ra:xapend:xapend.a_glossary:n:nonrepudiation]] (( |
| - | + | ||
| - | [[ddsf:private:cookbook:06_append:glossary:n:nonrepudiation]] (( | + | |
| Non-Repudiation, | Non-Repudiation, | ||
| __Computer Security Resource Center (CSRC)__ | __Computer Security Resource Center (CSRC)__ | ||
| Line 12: | Line 10: | ||
| )) means that it is not possible to repudiate (i.e., deny) that an action has been taken. For example, the signed contract witnessed by two people could not be repudiated. In other words, the contract now has Non-Repudiation. | )) means that it is not possible to repudiate (i.e., deny) that an action has been taken. For example, the signed contract witnessed by two people could not be repudiated. In other words, the contract now has Non-Repudiation. | ||
| - | Non-Repudiation is about providing assurance using [[ddsf:private:cookbook:06_append:glossary:e:evidence|evidence]] that an action has been done. For example, a data sender is provided evidence (i.e., proof) of delivery while the receiver is provided evidence (i.e., proof) of the sender's identity. As a consequence, neither the sender or the receiver can deny having processed the data. | + | Non-Repudiation is about providing [[dido:public:ra:xapend:xapend.a_glossary:a:assurance|assurance]] using [[dido:public:ra:xapend:xapend.a_glossary:e:evidence|evidence]] that an action has been done. For example, a data sender is provided evidence (i.e., proof) of delivery while the receiver is provided evidence (i.e., proof) of the sender's identity. As a consequence, neither the sender or the receiver can deny having processed the data. |
| - | Non-Repudiation applies to more than just sending data between two parties. It can be applied to any action or activity. For example, by digitally signing an email, the receiver has evidence (i.e., proof) that the email is from the [[ddsf:private:cookbook:06_append:glossary:e:entity|entity]] that signed the email. In other words, it is not possible to repudiate that the email came from the entity that digitally signed the email. Another example is the use of identities in configuration management systems. The change (i.e., transformation) was recorded in a log along with the identity of the individual that made the change. In this way, all changes made to the configuration have Non-Repudiation.(( | + | Non-Repudiation applies to more than just sending data between two parties. It can be applied to any action or activity. For example, by digitally signing an email, the receiver has evidence (i.e., proof) that the email is from the [[dido:public:ra:xapend:xapend.a_glossary:e:entity|entity]] that signed the email. In other words, it is not possible to repudiate that the email came from the entity that digitally signed the email. Another example is the use of identities in [[dido:public:ra:xapend:xapend.a_glossary:c:cm|configuration management]] systems. The change (i.e., transformation) was recorded in a log along with the identity of the individual that made the change. In this way, all changes made to the configuration have Non-Repudiation.(( |
| Evan Wheeler, | Evan Wheeler, | ||
| __Security Risk Management__, | __Security Risk Management__, | ||
| Line 23: | Line 21: | ||
| - | There is a lot of overlap in Non-Repudiation and [[ddsf:private:cookbook:06_append:glossary:a:accesscontrol]]. During access to a controlled resource, the identity of the entity trying to access the resource is verified against an [[ddsf:private:cookbook:06_append:glossary:a:acl]]. When access is allowed or denied, an entry is made into a log. Once the entry is made, the access has Non-Repudiation. In other words, once an [[ddsf:private:cookbook:06_append:glossary:a:accesscontrolfunction]] is executed, there is generally sufficient evidence to for Non-Repudiation of access to the controlled resource. | + | There is a lot of overlap in Non-Repudiation and [[dido:public:ra:xapend:xapend.a_glossary:a:accesscontrol]]. During access to a controlled resource, the identity of the entity trying to access the resource is verified against an [[dido:public:ra:xapend:xapend.a_glossary:a:acl]]. When access is allowed or denied, an entry is made into a log. Once the entry is made, the access has Non-Repudiation. In other words, once an [[dido:public:ra:xapend:xapend.a_glossary:a:accesscontrolfunction]] is executed, there is generally sufficient evidence to for Non-Repudiation of access to the controlled resource. |
| + | ===== DIDO Specifics ===== | ||
| + | [[dido:public:ra:1.4_req:2_nonfunc:25_security:nonrepudiability| Return to Top]] | ||
| - | ===== DDS Specifics ===== | + | : <wrap hi><color red> To be added/expanded in future revisions of the DIDO RA </color></wrap> |
| - | [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional:25_security:nonrepudiability| Return to Top]] | + | |
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||