# 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 terrorism. - **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. ### Assumptions 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. ### Assets 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. ## Exercises * 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?