Repudiation (STRIDE)

Question

What is repudiation? How does logging, for example, mitigate this threat?

Answer

Repudiation is the denial by one of the entities involved in a communication of having participated in all or part of the communication.³ Without adequate auditing, repudiation attacks are difficult to prove.¹

A repudiation attack may be performed by either a legitimate or illegitimate user who denies sending particular data or performing a particular action.

There are generally two types of mitigations, depending on the type potential threat:

Non-repudiation of origin ensures that the originator of information cannot successfully deny having sent the information (and variations thereof).
Non-repudiation of receipt ensures that the recipient of information cannot successfully deny receiving the information (and variations thereof).

Mitigations for Specific Threats

What is the threat when an external entity denies receiving data?
- Summary: Repudiation types of threats occur when an attacker or actor can perform an action with an application that is not attributable, in this case an external model element on the other side of the trust boundary may claim that it did not receive data.
- Recommendations: Recommended mitigations include for example your application as the sender using logging or auditing to record the source, time, and summary of the sent data, to ensure that the recipient of information cannot successfully deny receiving the information. Additionally it is recommended that the sender also authenticates the receiver to ensure communication with the correct receiver. Please ensure the audit comment refers to the correct sender for the receiver and interaction indicated in the identified threat.
What is the threat when an external entity denies writing data?
- Summary: Repudiation types of threats occur when an attacker or actor can perform an action with an application that is not attributable, in this case a data store model element on the other side of the trust boundary may claim that it did not write received data.
- Recommendations: The extent to which this potential threat can be mitigated by your application is to at least ensure that the recipient of information cannot successfully deny receiving the information. Please see “What is the threat when an external entity denies receiving data?” for more information for those recommended mitigations.
What is the threat of potential repudiation by an element within the trust boundary?
- Summary: Repudiation types of threats occur when your application attempts to perform an action that is not attributable, in this case your application claims that it did not receive data sent by a model element outside of the trust boundary.
- Recommendations: This potential threat is a false positive. For example “Controller claims that it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.” In this example, the Controller is part of a notional custom-developed application. As such, the Controller is presenting the threat that the tools is reporting, the logging mitigation should belong in the source outside the trust boundary. Auditing should be performed as described here.
What is the threat of lower trusted subject updates logs or data logs from an unknown source?
- Summary: If access to log files is not restricted properly, or the data sent to log files is not properly sanitized and validated, the log files may be maliciously manipulated or forged so that wrong data is logged to the log files. The identification of who performed actions in the system may be disguised or general data sent to the log files may be changed. As a result, the data stored in log files can be considered invalid or misleading.[5]
- Recommendations: Controls should be implemented that properly track and log users’ actions, with access to log files restricted per least privilege. Ensure that users have no control over how the source of actions, events or data modified in the application is logged. All data from external sources should be properly validated and sanitized prior to writing it to log files.
What is the threat of Insufficient Auditing?
- Summary: Auditing is the monitoring and recording of selected user actions. It can be based on individual actions, such as the type of action executed, or on combinations of factors that can include user name, application, time, and so on. Security policies can trigger auditing when specified data objects are accessed or altered, including the contents within a specified object. Auditing is typically used to:[6]
  - Enable future accountability for current actions taken by the application in behalf of a user
  - Deter users (or others) from inappropriate actions based on that accountability Investigate suspicious activity
    - For example, if a user is deleting data, then the security administrator might decide to audit all connections to the database and all successful and unsuccessful deletions of data from the database.
  - Notify an auditor that an unauthorized user is manipulating or deleting data and that the user has more privileges than expected which can lead to reassessing user authorizations
  - Monitor and gather data about specific user activities Detect problems with an authorization or access control implementation
  - When insufficient data is recorded or logged so that the above actions cannot be adequately performed, then the auditing is insufficient.
- Recommendations: Ensure that sufficient and appropriate data is logged to handle any repudiation claims. Ensure privacy of the data is also accounted for while auditing. An audit and/or privacy expert should be consulted to ensure all needed data is logged and protected appropriately.
What is the threat of potential weak protections for audit data?
- Summary: The mechanisms for creating, maintaining and analyzing audit data stored in log files must be protected. An attacker may try to destroy the log files themselves, data within the logs, or attempt to insert scripts that subvert programs that analyze the logs. Protection must be provided that provides assurance that the audit data has not been tampered or modified and that the confidentiality of the audit data is preserved.
- Recommendations: To provide assurance that audit data is only viewed by authorized users and cannot be untraceably modified, consider encrypting, signing, or encrypting and signing the data. Also implement directory and file system level access control mechanisms on audit files, or access restrictions on audit data stored in a database. Any data programmatically inserted into audit logs must be validated to ensure it contains no scripts or characters that can maliciously modify the content of the logs (e.g. CR/LF).

Repudiation (STRIDE)

Question

Answer

Mitigations for Specific Threats

References