CSE 590 SO, Winter 2005Computer security: Legal and

technical perspectives

University of WashingtonComputer Science and Engineeing

Presentation: Keunwoo Lee

Pick up readings by door.

Outline

• Administrative info

• What are we doing here?

• What is security?

• Why is software insecure?

Administrative info (1)

URL: http://www.cs.washington.edu/590soHas link to wiki, where most info resides

Sign up for mailing list; instructions will be posted to wiki

Course organizers:Keunwoo Lee (me; klee@cs) Ben Dugan (brd@u)Caroline Benner (cmbenner@u)

Faculty sponsor: Ed Lazowska (lazowska@cs)

Administrative info (2)

For those unfamiliar with CSE 590 format:• Small, discussion-oriented seminars• Mostly student-led discussions• Credit structure:

– 1 credit: do readings, come to class, discuss

– 2 credits: present at least once during quarter

– 3 credits: talk to us

– Default is credit/no credit; contact us for graded option

What are we doing here?

• Today’s computer systems are too vulnerable to common attacks, given the value of the things we do with themRecent study: unpatched Windows machine will be

attacked and “owned” by a cracker within 20 min. of being plugged into the Internet

• CS research has been working on the software quality problem for decades

• Software producers almost never use best practices in design and implementation

Lessig’s dot

individual

Lessig’s dot

individualarchitecture

market

law

norms

Lessig’s dot

individualarchitecture

market

law

norms

Lessig’s dot

software producerarchitecture

market

law

norms

Just the beginning…

• soctech@cs: interest group in CSE• Center for Internet Studies• Technology and Law Society at Law School

• Longer-term goal:– create ongoing interdisciplinary dialogue among these

groups, and others– Future seminar subjects open: ideas welcome– Join the soctech@cs mailing list! (info on wiki)

Course organization

3 weeks: CS introduction (Keunwoo)

2 weeks: law introduction (Ben)

5 weeks: focus on specific topics

Warnings• My personal qualifications are minimal• Subjects covered in the first 5 weeks will be

extremely elementary to many of youHowever, you still have a role to play:

• Fact check me (and Ben)• Debug our explanations• Correct our POV

• When we say something that you don’t understand, you must speak up

• We will probably spend some time fumbling around and learning to talk to each other

On the bright side…

• Bruce Schneier: “Anyone can learn to think about security.”

• Ed Felten: Don’t get discouraged if interdisciplinary collaboration takes a while to get rolling

Topics/presenters

Presenters

8 Feb: Vendor liability Ben? Prof. Winn?

15 Feb: Certification processes __________

22 Feb: Security in the real world Ira?

1 Mar: Criminal law approaches __________

8 Mar: Public policy approaches __________

Volunteers to be “stenographers”: ______________________________________________

Overview of next 3 weeks

Rest of today: Security and computing intro– Reading: Lessig ch. 7

11 Jan: Security aspects of current computing technologyreadings:– Parnas “Software Aspects of Strategic Defense Systems”, CACM 28(12),

Dec. 1985– Schneier chapters 8-10, 13

18 Jan: Technical measures for improving software quality/security (reading tbd)

see wiki for further details on reading

What is security?

Trustworthiness: A user of the system has a justifiable and true belief that the system will act as the user intends it to act, within a known margin of risk.(adapted from David Dill’s definition of trustworthy voting)

Security: trustworthiness in the face of attacks by a malicious, intelligent adversary

Observations

Security can only be evaluated relative to:– a set of attacks and adversaries (threat model)– a quantitative measure of acceptable risk

Security is a property of a whole system, not points in the systemCorollary: “security is a process, not a product”

(Schneier)

Caveat

We plan to focus this seminar on one aspect of computer system security:

the fact that the software on individual computers can be compromised remotely

This omits a large part of the picture, but it’s a necessary evil

Compromised software

To be useful, a program must perform actions on some resource at the request of a user

programusers inputsresources

actions

A program can be compromised if, under any combination of inputs and internal memory states, it can ever take an action that causes harm to the resources with which it interacts

memoryworld

Fundamental obstacles

Why can’t things be perfect?

• Specification/understanding problem

• Complexity

• Undecidability

Why aren’t things “good enough” in practice?

• Ultimately: cost

Specification/understanding

What is “harm” to a protected resource?– Generically, breaches of integrity, confidentiality, and

access; but hard to enumerate all specifics for system and every subpart

– Hard to be sure that specification is adequate and correct

Understanding of system designers may differ from understanding of users

Complexity outstrips brute force

• Modern PCs have on the order of 100 billion bits of storage– Individual programs are smaller, but still have

tens of millions of instructions

• Inputs can be of unbounded size• It is not feasible to use brute-force

approaches to check a program for all inputs under all possible states of storage

Undecidability defeats smarts

• Why not use something smarter than brute force testing of all possible states+inputs?

• Unfortunately, a fundamental result in theoretical CS states that no automated procedure can determine, for every program, the truth or falsehood of a nontrivial property of its behavior, except by running it

Nevertheless, there is hope

• We can’t capture user intention perfectly, but we can write and test rigorous specifications

• We can’t prove whether a property holds for every program by automated techniques; but– We can sometimes design by hand an individual program/system

that has a desirable property– We can devise automated technologies that determine whether

some programs satisfy desirable properties

However, these measures still have costs, which grow with the size of the program

More on this in upcoming weeks

Next 2 weeks

1. An overview of current computing technology, from a security perspective

2. Overview of technical measures that improve computer security