Introduction to Security

All satisfied with their seats? O.K. No talking, no smoking, no knitting, no newspaper reading, no sleeping, and for God's sake take notes. —Vladimir Nabokov

November 2, 1988: Robert Tappan Morris, Jr. released the "great worm." (His dad, Bob Morris, was chief scientist at NSA's National Computer Security Center.) This was the first worm; the first malware to get media attention; and the first conviction under the Computer Fraud and Abuse Act. Morris was 23 years old, and a first year grad student at Cornell. (He released the worm from MIT, though.) He later claimed the worm's purpose was to measure size of Internet, but the immediate effect was denial of service (DoS). The Internet "came apart" as hosts were overloaded by invisible processes. System admins had to disconnect from the network to isolate their systems from infection. The US GAO later estimated the cost of recovery was somewhere in $100k to $10m. Morris was tried in US District Court. His sentence: 3 years probation, 400 hours community service, and a $13k fine. In 1999, he received a PhD from Harvard. And now he's a professor at MIT.

June 1, 2012: The New York Times reports that the US and Israel created Stuxnet, the first (publicly known) cyberweapon. Its provenance was initially unknown. The weapon first infects Windows systems, then subsequently infects an industrial control device, causing it to vary the frequency of its motor and do physical harm. But, the weapon hides that frequency change from the device's monitoring system, so that the harm won't be noticed until it's too late. The purpose of the weapon seemed to be destruction of centrifuges in Iranian uranium enrichment facilities.

Today, security is

• hard: we don't (fully) know how to accomplish it,
• interesting: involves lots of cool ideas, and
• important: society depends on computers, hence their security.

That's what makes this such a fun field of study.

Defining security

A computer system is secure when it

• does what it should
• and nothing more.

A security policy stipulates what should and should not be done. Policies can be long English documents, mathematical axioms, etc. But almost everyone agrees that security policies are formulated in terms of three basic kinds of security properties: confidentiality, integrity, and availability.

Confidentiality:

Protection of assets from unauthorized disclosure. Assets could be information, or resources. Disclosure must be to someone; that might be a person, a program, another computer system, etc. To generalize those entities, define a principal to be any entity that can take actions. So, confidentiality is about which principals are allowed to learn what. Secrecy is synonymous with confidentiality.

• e.g., keep contents of file from being read. (Access control.)
• e.g., keep value of variable secret. That's harder: pub := 0; if (sec = 1) { pub := 1; } (Information flow.)
• e.g., keep behavior of system secret. Even harder: suppose system load goes up when system is processing secret information. Anyone on system can observe load. (Covert channel.)
• e.g., keep information about an individual secret. Hard these days with lots of databases. Can be linked against one another, new information extracted. Gender, DOB, ZIP uniquely identify about 99% of people in Cambridge, MA. (Database privacy.)

Privacy is the confidentiality of identifying information about individuals, which could be people, organizations, etc. Sometimes privacy is construed as legal right. Don't say "keep information private" unless you really mean that the information is about an individual and is identifying. (All your vocabulary are belong to us.)

Integrity:

Protection of assets from unauthorized modification. I.e., what changes are allowed to system and its environment. Changes can include initial sources, hence provenance. The environment can include outputs.

• e.g., output is correct according to a mathematical specification.
• e.g., no exceptions are thrown.
• e.g., resource consumption is bounded.
• e.g., only certain principals are allowed to write a file. (Access control.)
• e.g., data are not corrupted or tainted by downloaded programs. (Information flow.)

Availability:

Protections of assets from loss of use. Denial of service (DoS) attacks typically cause violations of availability properties.

• e.g., system must accept inputs periodically (OS doesn't terminate)
• e.g., produce output by specified time (program terminates)
• e.g., process requests fairly (order received, priority, etc.)

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 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.

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.

This recognition that there is no such thing as "perfect security" leads us to reflect on the goals we are attempting to achieve in security:

• Prevention. We can attempt to build systems that are completely free of vulnerabilities, hence all attacks are prevented. This goal is laudable, and we'll discuss many techniques in this course related to achieving prevention. We should recognize, however, that we are unlikely ever to achieve absolute security, and even approaching it is likely to incur significant expense.
• Risk Management. We can attempt to ensure that investment in security reduces the expected harm from attacks. Given that our resources are limited, this goal is sensible. We would need to determine the probabilities that vulnerabilities can be exploited, the costs of countermeasures that would control those vulnerabilities, and the cost of harm that would be incurred from attacks. But determining the actual probabilities involved is difficult—we don't have enough information about likelihoods and costs.
• Deterrence through Accountability. We can attempt to legally prosecute the attackers. To do so, we would need to attribute attacks to the humans who perpetrate them. There are significant technical and legal challenges to implementing this goal: How do we attribute attacks? How do we prosecute attacks across legal boundaries? How do we balance attribution with privacy?
• Cybersecurity as a Public Good. We can attempt to treat security similar to how we treat public health. We can educate the public about it, disseminate treatments (such as vaccines), and track outbreaks. This goal was articulated recently [Mulligan and Schneider 2011].