This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: CS 161 Computer Security Spring 2010 Paxson/Wagner Notes 1/27 Principles for Secure Systems Here are some general principles for secure system design. 1 • Security is economics. No system is completely, 100% secure against all attacks. Rather, systems may only need to resist a certain level of attack. There is no point buying a $10,000 firewall to protect $1,000 worth of trade secrets. Also, it is often helpful to quantify the level of effort that an attacker would need to expend to break the system. Adi Shamir once wrote, “There are no secure systems, only degrees of insecurity.” A lot of the science of computer security comes in measuring the degree of insecurity. Analogy: Safes come with a rating of their level of security. For instance, a consumer-grade safe might indicate that it will resist attack for up to 5 minutes by anyone without tools. A high-end safe might be rated TL-30: it is secure against a burglar with safecracking tools and limited to 30 minutes access to the safe. (With such a safe, we know that we need to hire security guards who are able to respond to any intrusion within 30 minutes.) A corollary of this principle is you should focus your energy on securing the weakest links. Security is like a chain: it is only as secure as the weakest link. Attackers follow the path of least resistance, and they will attack the system at its weakest point. There is no sense putting an expensive high-end deadbolt on a screen door; an attacker isn’t going to bother trying to pick the lock when he can just rip out the screen and step through. • Least privilege. Give a program the set of access privileges that it legitimately needs to do its job—but nothing more. Try to minimize how much privilege you give each program and system component. Least privilege is an enormously powerful approach. It doesn’t reduce the probability of failure, but it can reduce the expected cost of failures. The less privilege that a program has, the less harm it can do if it goes awry or runs amok. You can think of this as the computer-age version of the shipbuilder’s notion of “watertight compartments”: even if one compartment is breached, we want to minimize the damage to the integrity of the rest of the system. For instance, the principle of least privilege can help reduce the damage caused by buffer overruns. If a program is compromised by a buffer overrun attack, then it will probably be completely taken over by an intruder, and the intruder will gain all the privileges the program had. Thus, the fewer privileges that a program has, the less harm is done if it should someday be penetrated by a buffer overrun attack. Example: How does Unix do, in terms of least privilege? Answer: Pretty lousy. Every program gets all the privileges of the user that invokes it. For instance, if I run a editor to edit a single file, the editor receives all the privileges of my user account, including the powers to read, modify, or delete all my 1 Many of them are due to Saltzer and Schroeder, who wrote a classic paper in the 1970s with advice on this topic....
View Full Document
- Spring '08
- Computer Security, administrator, Secure Systems