Nonrepudiation Requirements

Definition

A nonrepudiation requirement is any security requirement that specifies a required amount of the security quality subfactor nonrepudiation.

Objectives

The typical objectives of a nonrepudiation requirement are to:

• Ensure that adequate tamper-proof records are kept to prevent parties to interactions from denying that they have taken place.
• Minimize any potential future legal and liability problems that might result from someone disputing one of their interactions.

Measurements

Nonrepudiation requirements are typically specified in terms of the following measurements:

• Maximum percentage of transactions repudiated.

Examples

General Examples

The following are typical examples of nonrepudiation requirements:

• “The application shall make and store tamper-proof records of the following information about each order received from a customer and each invoice sent to a customer:
  • The contents of the order or invoice.
  • The date and time that the order or invoice was sent.
  • The date and time that the order or invoice was received.
  • The identity of the customer.”

Specific Examples

The following are examples of nonrepudiation requirements from the Global Personal Marketplace (GPM) system, a global Web-based marketplace bringing together private individuals and small companies to buy and sell all manner of items:

• Accountant:
  • Accountant Updates Fee Schedule— “A minimum of 99.999% of the time that an accountant updates the fee schedule, the GPM shall make and store a tamper-proof record including the following information:
    • Accountant name and identifier
    • Date and time
    • Updated fees information (fee type, original value, and new value)”
• Buyer:
  • Buyer Registers Feedback About Seller— “A minimum of 99.999% of the time that a buyer registers feedback about a seller, the GPM shall make and store a tamper-proof record including the following information:
    • Buyer name and identifier
    • Date and time
    • Feedback information (i.e., seller, sale, sale type, sale date, feedback comments)”

Guidelines

The following guidelines have been found to be useful when producing nonrepudiation requirements:

• The scope of a nonrepudiation requirement can be:
  • A business enterprise
  • An application
  • A component
  • A center
• Nonrepudiation requirements can be identified and specified in term of the following:
  
  

  Component of Requirement	Possibile Values
  Actor Repudiating Transaction	TBD
  Transaction Repudiated	TBD
  State	Normal Processing Degraded Mode Under Attack
  Measurement	Maximum percentage of transactions repudiated

  
  
• Nonrepudiation requirements primarily deal with ensuring that adequate tamper-proof records are kept. It is not sufficient to merely make records; these records must be:
  • Complete.
  • Tamper-proof.
• Nonrepudiation requirements typically involve the storage of a significant amount of information about each interaction including:
  • The authenticated identity of all parties involved in the transaction.
  • The date and time that the interaction was sent, received, and acknowledged (if relevant).
  • The significant information that is passed during the interaction.
• Although nonrepudiation requirements may ensure that a record is kept of the fact that the receiver received the message from the sender, these requirements may (or may not) require that the receiver has both read and understood the message (e.g., by requiring an explicit acknowledgement).
• Nonrepudiation requirements are based on, can be specified in reference to, and should not redundantly specify:
  • Functional requirements specifying mandatory interactions.
  • Data requirements specifying the data that is stored and passed with these interactions. Note that nonrepudiation requirements may add making the stored data tamperproof.
  • Auditability requirements specifying the data that is required for auditing purposes.
• Use misuse cases to perform security threat analysis and security use cases to analyze and specify security requirements.
• Nonrepudiation requirements should not be specified in terms of the types of security architecture mechanisms that are typically used to implement them.