# Beyond Attacks
*Attacks* are the sexy side of security. When hackers perpetrate cool
attacks, we hear about it in the news. (Unless it's covered up by
business or government.) But if you want to build secure systems, you need to
begin thinking beyond attacks. Attacks are perpetrated by *threats* that
inflict *harm* by exploiting a *vulnerability*. Vulnerabilities are
controlled by *countermeasures*.
- **Harm:** A negative consequence to a system asset, possibly
involving loss or damage to value.
- **Threat:** A principal or environment that has the potential to
cause harm to assets of a system. A human threat is an *adversary*
or *attacker*, who must be motivated and capable to be successful.
Adversaries range in scope from individuals to organized groups to
nations, and their motivations range from curiosity to crime to
- **Vulnerability:** An unintended aspect of a system, be it design,
implementation, or configuration, that can cause the system to do
something it shouldn't, or fail to do something it should.
- **Attack:** The act of causing harm by exploiting a vulnerability.
- **Countermeasure:** A defense that protects against attacks by
neutralizing either the threat or vulnerability involved.
Countermeasures might attempt to prevent, deter, deflect, mitigate,
or detect attacks, or recover from them.
Every system is built on assumptions—about timing, kinds of failures,
message delivery, formats of inputs, execution environment, etc. *Buffer
overflows*, which have long been one of the most prevalent
vulnerabilities, involve an assumption about input sizes. Violate that
assumption, the system does the wrong thing.
**ASSUMPTIONS are VULNERABILITIES.** We can't live with 'em, we can't
live without 'em.
One very important kind of assumption is **trust**. When a system is
*trusted*, we assume the system satisfies a particular security policy.
(It might not, in which case, we have vulnerabilities.) When a system is
*trustworthy*, we have evidence that the system really does satisfy a
policy. Much of this class is devoted to techniques for transforming
trusted systems into trustworthy systems.
In theory, vulnerabilities needn't all be found or repaired. Some aren't
exploitable (e.g., a component fails to do bounds checking, but the
component in front of it does). Some aren't exploitable by threats of
concern (e.g., the attack would require too many resources). But in
practice, ignoring vulnerabilities is a risky business. Too many get
passed off as "no one could ever exploit that", only to have a
successful attack perpetrated in the future.
The need for security arises when a system involves *assets* that can be
harmed by threats. Assets can include
- physical objects, such as printed money, and
- intangible objects, such as bank account balances.
Most computer systems deal in one main kind of asset: information. The
machines themselves might be an asset, as well as any peripherals (such
as smartcards), backup drives, etc. Note that people are not usually
considered assets in computer systems, because the system can't directly
protect or control them.
The key characteristic of assets is that they have *value* to
*stakeholders* in the system. An asset has *direct* value if damage
affects the value of the asset itself. An asset has *indirect* value if
damage affects something else—for example, reputation. Printed money has
both direct and indirect value to a bank. A bank robbery harms the bank
both through the loss of revenue (it no longer has money to lend) and
through the loss of reputation (if the robbery is made public).
Assets and stakeholders are intrinsically related. An object isn't an
asset unless some stakeholder values it. Likewise, a principal isn't a
stakeholder unless it values some object in the system. Although an
attacker might value objects, we don't consider a generic "attacker" to
be a stakeholder. However, legitimate stakeholders (e.g., disgruntled
employees) might try to attack the system themselves.
* List several harms that could come to a student if their Student Center
account were compromised. Identify each as C, I, or A.
Repeat this, but for your CMS account.
* Invent three different kinds of adversaries who might attack [www.cornell.edu]().
What are their motives and capabilities?
* Superman is vulnerable to [kryptonite](https://en.wikipedia.org/wiki/Kryptonite).
Suggest imaginative countermeasures to prevent, deter, deflect, mitigate,
or detect kryptonite-based attacks.
* What assets are associated with your Facebook account from your perspective?
From Facebook's perspective?
* A prominent public figure has their Wikipedia page vandalized and wishes
to sue the vandal in court. What technical challenges might be involved
in establishing the identity of the vandal?