All you need to know about STRIDE - Repudiation Threat

STRIDE is a security threat model, developed by Microsoft that categorize the security threat associated with the computer. It consists of six different threat categories which are:
  1. Spoofing
  2. Tampering
  3. Repudiation
  4. Information Disclosure
  5. Denial of Service
  6. Elevation of Privilege
This article is all about the Repudiation Threat only. Subsequent articles will cover details on remaining techniques.
 
Microsoft STRIDE model defines Repudiation as the ability of users (legitimate or otherwise) to deny that they performed specific actions or transactions. Without adequate auditing, repudiation attacks are difficult to prove.
 
Such attacks happen when an application or system lacks necessary controls to properly track and log user’s action, hence permitting manipulation or forging the identification of new actions. 
 
Imagine a scenario where a transaction between two entities viz., a bank and its customer happens, a post which the customer denies withdrawing the cash from the bank. The customer might claim that he had nothing to do with the withdrawal of the cash and bank should compensate for that amount. This is a simple case of repudiation where one party involved, denies that he has actually performed specific transactions.
 
A repudiation threat involves carrying out a transaction in such a way that there is no proof after the fact of the principals involved in the transaction. 
 
This is a threat that might lead to financial losses, legal implications, and lawsuits if not solved by appropriate and legitimate proof. Hence, repudiation has to be dealt with utmost care in all online/ offline transactions.
 

Non-Repudiation

Non-repudiation refers to the ability of a system to counter repudiation threats. For example, a user who purchases an item might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user has received the package.
 
Scenario
 
As shown in the below process, the billing details of a patient are calculated in the billing module and the billing receipts/files are uploaded into the File server using an Upload API. Let us look at the repudiation threats generated by the tool for the interaction between the Upload API client and the File server component.                                                          
 

Potential Threats

  • Potential Weak Protections for Audit Data: Consider what happens when the audit mechanism comes under attack, including attempts to destroy the logs or attack log analysis programs.
    Remediation suggestion: Ensure access to the log is strictly monitored and a mechanism to control read and write separately.
     
  • Insufficient Auditing: Does the log capture enough data to understand what happened in the past? Do your logs capture enough data to understand an incident after the fact? Is such capture lightweight enough to be left on all the time? Do you have enough data to deal with repudiation claims?
    Remediation suggestion: Make sure you log sufficient and appropriate data to handle a repudiation claims. Ensure privacy of the data is also accounted for while auditing.
     
  • Data Logs from an Unknown Source or lower trusted subjects: Do you accept logs from unknown or weakly authenticated users or systems? Is anyone other outside of the highest trust level allowed to log?
    Remediation suggestion: Identify and authenticate the source of the logs before accepting them and only allow trusted code to log.

Counter Measures

Following countermeasures can be applied in order to overcome above Repudiation threat,
 
  • Strong Authentication
  • Use the logging features to keep an audit trail of any activity on the server
  • Usage of Digital Signatures - when a document or message needs to be non-reputable and especially when such document/message may have come from an intermediate entity (e.g. aggregated across multiple users by a 3rd party) or through non-secure channels (no login, email or pen drive) etc.
“Threat model – Repudiation play a vital role in the process of building a secure system. So keep proof and be secure.”
 
Authored By - Deepti Nayak
TCS Enterprise Security and Risk Management
Rate this article: 
Average: 3.2 (6 votes)
Article category: