EoP Threat Suits - R (Repudiation)

Repudiation (R) is the third suit of threats in the STRIDE threat enumeration.

Repudiation describes any threat that allows an attacker to deny that they have taken an action that your application allowed. Repudiation is a complex and confusing threat, requiring that an action which has occurred can be denied by the user who caused it. Because it’s confusing and complex, the characters on the cards are capital letter “R”s with filled in loops. Bold faced lie-Rs, if you like.

Repudiation threats are generally countered through quality implementations of Logging, Integrity protection and Authorisation.

Another successful way to mitigate repudiation is to not care about who did what - this only works if you can accept that your application may engage in multiple actions without your being able to determine who caused those actions, or whether they truly occurred. Ignoring repudiation and hoping that attackers will voluntarily provide identifying information or proof of purchase is not a valid mitigation strategy.

The cards in the Repudiation suit are as follows

Repudiation Suit
Value	Threat	Example / Mitigation
2	An attacker can pass data through the log to attack a log reader, and there’s no documentation of what sorts of validation are done	Example: Mitigation:
3	A low privilege attacker can read interesting security information in the logs	Example: Mitigation:
4	An attacker can alter digital signatures because the digital signature system you’re implementing is weak, or uses MACs where it should use a signature	Example: Mitigation:
5	An attacker can alter log messages on a network because they lack strong integrity controls	Example: Mitigation:
6	An attacker can create a log entry without a timestamp (or no log entry is timestamped)	Example: Mitigation:
7	An attacker can make the logs wrap around and lose data	Example: Mitigation:
8	An attacker can make a log lose or confuse security information	Example: Mitigation:
9	An attacker can use a shared key to authenticate as different principals, confusing the information in the logs	Example: Mitigation:
10	An attacker can get arbitrary data into logs from unauthenticated (or weakly authenticated) outsiders without validation	Example: Mitigation:
J	An attacker can edit logs and there’s no way to tell (perhaps because there’s no heartbeat option for the logging system)	Example: Mitigation:
Q	An attacker can say “I didn’t do that,” and you’d have no way to prove them wrong	Example: Mitigation:
K	The system has no logs	Example: Mitigation:
A	You’ve invented a new Repudiation attack	Example: Mitigation:

[When completed, each card description above will link to a copy of the card, along with examples of the threat and some specific mitigation steps. Point to Patterns & Practices documents, excerpts from Writing Secure Code, etc, where possible. Emphasise that the information is already out there, so that dev teams widen their horizons.]