1.2 The Internet Threat Model

The first thing that we need to do is define our threat model. A threat model describes resources we expect the attacker to have available and what attacks the attacker can be expected to mount. Nearly every security system is vulnerable to some threat or another. To see this, imagine that you keep your papers in a completely unbreakable safe. That's all well and good, but if someone has planted a video camera in your office they can see your confidential information whenever you take it out to use it, so the safe hasn't bought you that much.

Therefore, when we define a threat model, we're concerned not only with defining what attacks we are going to worry about but also those we're not going to worry about. Failure to take this important step typically leads to complete deadlock as designers try to figure out how to counter every possible threat. What's important is to figure out which threats are realistic and which ones we can hope to counter with the tools available.

Designers of Internet security protocols typically share a more or less common threat model. First, it's assumed that the actual end systems that the protocol is being executed on are secure. Protecting against attacks where one of the end systems is under the control of the attacker is extraordinarily difficult, if not impossible. This assumption comes with two caveats. First, compromise of any single end system shouldn't break security for everyone. There should be no single point of failure. For instance, if an attacker breaks system A, then all communications between B and C should be safe. If we must have a single point of failure it must be possible to harden it against attack. Second, attackers may control systems that attempt to pose as legitimate end systems. All we're assuming is that users can expect that their own machines haven't been compromised.

Other than that, we assume that the attacker has more or less complete control of the communications channel between any two machines. He can certainly inject packets into the network with arbitrary address information, both for the sender and the receiver, and can read any packet that is on the network and remove any packet he chooses. Any packet you send might be modified in transit. An attack that depends on the attacker writing data to the network is known as an active attack. An attack that merely involves reading the data off the network is known as a passive attack.

An obvious corollary of the assumption that the attacker can modify traffic is that the attacker can shut down all communications between any pair of machines simply by removing all relevant packets. This is one form of denial-of-service attack. Another form would be to force you to use up enormous CPU resources responding to connections. Conventionally, protocol designers don't worry about denial-of-service attacks not because these attacks aren't important but because they're extraordinarily difficult to prevent.

One of the most important functions of a threat model is to arrange that security doesn't become more expensive than it is worth. Security measures should be employed only up to the point where the cost to implement them doesn't exceed the expected risk. Failure to make this judgement correctly can easily lead to a situation where no risk is judged acceptable, and thus no acceptable system can be designed.

Part of the risk calculation is the effort required by the attacker to mount a given attack, and cost generally increases with each attack prevented. No security system is resistant to every attack. The function of a security model is to allow designers to determine which attacks are worthwhile to prevent.

However, accurately estimating how much security you need requires accurately estimating the attacker's capabilities. If an attack that was originally considered impractical is discovered to be simple, then there is a window of vulnerability while people adjust their security models and implementations to compensate.