DOC PREVIEW
Berkeley COMPSCI 161 - Principles and Design Patterns for Secure Systems

This preview shows page 1-2-3-4 out of 13 pages.

Save
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Paxson Spring 2011 CS 161 Computer Security 1 27 Principles and Design Patterns for Secure Systems In this set of notes we look at ways of building secure systems The same ideas also allow us to examine existing systems to understand their security properties 1 General Principles We ll being with 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 consumergrade 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 attackers aren t going to bother trying to pick the lock when they 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 becomes subverted You can think of this 1 Many of these principles are due to Saltzer and Schroeder who wrote a classic paper in the 1970s with advice on this topic 1 27 CS 161 Spring 2011 Material courtesy Prof David Wagner 1 of 13 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 files That s much more than is needed strictly speaking the editor probably only needs access to the file being edited to get the job done Example How is Windows in terms of least privilege Answer Just as lousy Arguably worse because many users run under an Administrator account and many Windows programs require that you be Administrator to run them In this case every program receives total power over the whole computer Folks on the Microsoft security team have recognized the risks inherent in this and are taking many steps to warn people away from running with Administrator privileges so things are getting better in this respect Use fail safe defaults Use default deny polices Start by denying all access then allow only that which has been explicitly permitted Ensure that if the security mechanisms fail or crash they will default to secure behavior not to insecure behavior Example A packet filter is a router If it fails no packets will be routed Thus a packet filter fails safe This is good for security It would be much more dangerous if it had fail open behavior since then all an attacker would need to do is wait for the packet filter to crash or induce a crash and then the fort is wide open Example Long ago SunOS machines used to ship with in their etc hosts equiv which allowed anyone with root access on any machine on the Internet to log into your machine as root Irix machines used to ship with xhost in their X Windows configuration files by default These instances violate of the principle of fail safe defaults since the machines came with an out of the box configuration that was insecure by default Separation of responsibility Split up privilege so no one person or program has complete power Require more than one party to approve before access is granted Examples In a nuclear missile silo two launch officers must agree before the missile 1 27 CS 161 Spring 2011 Material courtesy Prof David Wagner 2 of 13 can be launched Example In a movie theater you pay the teller and get a ticket stub then when you enter the movie theater a separate employee tears your ticket in half and collects one half of it putting it into a lockbox Why bother giving you a ticket that 10 feet later is going to be collected from you One answer is that this helps prevent insider fraud Tellers are low paid employees and they might be tempted to under charge a friend or to over charge a stranger and pocket the difference The presence of two employees helps keep them both honest since at the end of the day the manager can reconcile the number of ticket stubs collected against the amount of cash collected and detect some common shenanigans Example In many companies purchases over a certain amount must be approved both by the requesting employee and by a separate purchasing office This control helps prevent fraud since it is less likely that both will collude and since it is unlikely that the purchasing office will have any conflict of interest in the choice of vendor Defense in depth This is a closely related principle There s a saying that you can recognize a security guru who is particularly cautious if you see someone wearing both a belt and a set of suspenders What better way to


View Full Document

Berkeley COMPSCI 161 - Principles and Design Patterns for Secure Systems

Documents in this Course
Rootkits

Rootkits

11 pages

Load more
Download Principles and Design Patterns for Secure Systems
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Principles and Design Patterns for Secure Systems and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Principles and Design Patterns for Secure Systems and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?