CS-3013 & CS-502, Summer 2006 Computer System Security1 An Introduction to Computer System Security...

CS-3013 & CS-502, Summer 2006

Computer System Security 1

An Introduction to Computer System Security

(Notes taken from CS-502 guest lecture by

Bob Strong, April 4, 2005)

CS-3013 & CS-502, Summer 2006


Outline

• A few principles about security• The relationship between OS services

and their implementation, and system and data security

• The importance of the human side of the problem

• A little fun with cryptography

CS-3013 & CS-502, Summer 2006


Reading Material

• Tanenbaum, Chapter 9– Security and threats– Viruses

• How to write and detect!

– Protection – implementation of security

• Silbershatz, Chapters 14-15– Protection– Security

CS-3013 & CS-502, Summer 2006


Part 1: OS Issues

• Why “Security”? …and Security principles

• Authorization and the Access Control Policy

• User Authentication

CS-3013 & CS-502, Summer 2006


Fundamental Goals for Computer Security

• Data Confidentiality

• Data Integrity

• System Availability

• Related issue – Privacy• A legal and ethic question• Implemented by Confidentiality goal

CS-3013 & CS-502, Summer 2006


In Business Terms

Asset

Threat Cost

Risk

CS-3013 & CS-502, Summer 2006


Threat Analysis

• What are we trying to protect? (and why?)• What are the vulnerabilities of those

assets?• Who might exploit a vulnerability?

– Either on purpose or by accident

• How can we prevent a specific threat?• How much is it worth to us to prevent it?• How much will it cost to prevent it?

CS-3013 & CS-502, Summer 2006


Threat Analysis (2)

• An Example: OCTAVE– Operationally Critical Threat And

Vulnerability Evaluation• http://www.cert.org/octave• CERT (Computer Emergency Response Team)

– OCTAVE is a business-focused process

• Example:– How much effort should I spend protecting my company’s web site?

http://www.cert.org/octave

CS-3013 & CS-502, Summer 2006


The Core Technical Problem

• Controlling access to machine and data resources

• Controlling the way access rights are passed from holder to holder

• person to person• program to program

• Preventing maliciousness and errors from subverting the controls

CS-3013 & CS-502, Summer 2006


Access Rights

• In general case, need triplet for every possible combination of right, protected asset, and potential user (U, A, R)

• …and some entity must be responsible for checking and enforcing any limitation...

• The 3-D matrix is hard to manage…We need a simpler approach!

CS-3013 & CS-502, Summer 2006


Textbook 2D Matrix

file1 file 2 file 3 device domain

User/Domain 1 r rx rwx – enter

User/Domain 2 r x rx rwx –

User/Domain 3 rw – – – –

…

• Columns are access control lists (ACLs)• Associated with each object

• Rows are capabilities• Associated with each user or each domain

CS-3013 & CS-502, Summer 2006


What about efficiency?

• At run-time…– What does the OS know about the user?– What does the OS know about the

resources?

• What is the cost of checking and enforcing?– Access to the data– Cost of searching for a match

CS-3013 & CS-502, Summer 2006


ACLs vs. Capabilities

• Focus on resources – the Access Control List– Good if resources greatly outnumber users– Can be implemented so that minimal

information caching is needed– Good when the user who creates a resource has

authority over it

• Focus on users – the Capability System– Good if users greatly outnumber resources– Lots of information caching is needed– Good when a system manager has control over

all resources

CS-3013 & CS-502, Summer 2006


We need both …

• ACLs for files and other proliferating resources

• Capabilities for major system functions

• The common OSs offer BOTH– Linux emphasizes an ACL model

• provides good control over files and resources that are file-like

– Win200x emphasizes Capabilities• provides good control over access to system functions

(e.g. creating a new user, or doing a system backup…)

CS-3013 & CS-502, Summer 2006


…and good management, too!

• What do we need to know to set up a new user or to change their rights?

• …to set up a new resource or to change the rights of its users?

• …Who has the right to set/change access rights?

• No OS allows you to implement all the possible policies easily.

CS-3013 & CS-502, Summer 2006


Enforcing Access Control

• User level privileges must always be less than OS privileges!– For example, a user should not be allowed to

grab exclusive control of a critical device– or write to OS memory space

• …and the user cannot be allowed to raise his privilege level!

• The OS must enforce it…and the user must not be able to bypass the controls

• In most modern operating systems, the code which manages the resource enforces the policy

CS-3013 & CS-502, Summer 2006


Requirements: System Call Code

• No user can interrupt it while it is running

• No user can feed it data to make it – violate access control policies– stop serving other users

• No user can replace or alter any system call code

• No user can add functionality to the OS!• Data must NEVER be treated as code!

CS-3013 & CS-502, Summer 2006


“Yeah, but …”

• No user can interrupt it while it is running• Windows, Linux routinely interrupt system calls

• No user can feed it data to make it – violate access control policies– stop serving other users

• No user can replace or alter any system call code

• Except your average virus

• No user can add functionality to the OS!• Except dynamically loaded device drivers

• Data must NEVER be treated as code!• “One man’s code is another man’s data” A. Perlis

CS-3013 & CS-502, Summer 2006


Saltzer-Schroeder Guidelines

• System design should be public• Default should be no access• Check current authority – no caching!• Least privilege possible for processes• Protection mechanism should be

– Simple, uniform, built into lowest layers of system

• Psychologically acceptable

• KISS!

CS-3013 & CS-502, Summer 2006


Authentication

• How does the machine know who it is talking to???

• Who do I SAY that I am?

• How can I verify that?• Something I know (that nobody else should

know)• Something I have (that nobody else should have)• Something I am (that nobody else should be…)

CS-3013 & CS-502, Summer 2006


Threats against authentication

I want to pretend to be you:• I can steal your password

– the sticky on your monitor or the list in your desk drawer

– by monitoring your communications or looking over your shoulder

• I can guess your password (particularly useful if I can also guess your user name)

• I can get between you and the system you are talking to

CS-3013 & CS-502, Summer 2006


The Trouble with Passwords

• They are given away• They are too easy to guess• They are used too often • There are too many of them• They are used in too many places

CS-3013 & CS-502, Summer 2006


Some ways around the problem

• Better passwords– longer– larger character set– more random in nature/encrypted

• Used less often– changed frequently, one system per

password– challenge/response – use only once (p.

599)

CS-3013 & CS-502, Summer 2006


The Challenge/Response Protocol

Art MaryHello, I’m Art

Decrypt This {R}P

R

Hello Art! How can I help you?

CS-3013 & CS-502, Summer 2006


Threat: Steal passwords from the system

• Don’t keep them in an obvious place• Encrypt them so that the version the

system sees is not the same as the one the user enters or the version on the wire.

CS-3013 & CS-502, Summer 2006


Too many passwords to remember?

• Third-party authentication– Get someone to vouch for you

• The basics: “This guy says you know him..”

“Yes, I trust him, so you should too..”

• Kerberos – Certificate-based authentication within a trust community

CS-3013 & CS-502, Summer 2006


What is in a certificate?

• Who issued it• When was it issued• For what purpose was it issued• For what time frame is it valid• (possibly other application-specific

data)• A “signature” that proves it has not

been forged

CS-3013 & CS-502, Summer 2006


Systems and Networks Are Not Different

• Same basic rules about code behavior apply

• Same authentication rules apply

• The same security principles apply

• Same Coding Rules Apply To: – An application– Code which

manages incoming messages

– Code which imposes access controls on a network

– ...

CS-3013 & CS-502, Summer 2006


The Principles

• Understand what you are trying to protect

• Understand the threat(s) you are trying to protect against– Also, costs and risks

• Be prepared to establish trust by telling people how you do it

• Assume that the bad guys are at least as clever as you are!

CS-3013 & CS-502, Summer 2006


Break

CS-3013 & CS-502, Summer 2006


Part 2: Human and Application Issues

• What are we defending against…and why?

• Weaknesses and Responses– Technical– Human

• Things to think about...

CS-3013 & CS-502, Summer 2006


Reading Assignment

• Ken Thompson, “Reflections on Trusting Trust,” Communications of ACM, vol.27, #8, August 1984, pp. 761-763.– The very first virus.

CS-3013 & CS-502, Summer 2006


How do these attacks work?

• Messages that attack mail readers or browsers

• Denial of service attacks against a web server

• Password crackers• Viruses, Trojan Horses, other

“malware”

CS-3013 & CS-502, Summer 2006


The concept of a “Vulnerability”

• Buffer overflow• Protocol/bandwidth interactions

– Protocol elements which do no work

• “execute this” messages– The special case of “mobile agents”

• Human user vulnerabilities– eMail worms– Phishing

CS-3013 & CS-502, Summer 2006


Another Principle

• There is a never-ending war going on between the “black hats” and the rest of us.

• For every asset, there is at least one vulnerability

• For every protective measure we add, “they” will find another vulnerability

CS-3013 & CS-502, Summer 2006


Yet Another Principle

• There is no such thing as a bullet-proof barrier

• Every level of the system and network deserves an independent threat evaluation and appropriate protection

• Only a multi-layered approach has a chance of success!

CS-3013 & CS-502, Summer 2006


Actual Losses:

• Approximately 70% are due to user error

• More than half of the remainder are caused by insiders

• “Social Engineering” accounts for more loss than technical attacks.

CS-3013 & CS-502, Summer 2006


What is “Social Engineering”?

“Hello. This is Dr. Burnett of the cardiology department at the Conquest Hospital in Hastings. Your patient, Sam Simmonds has just been admitted here unconscious. He has an unusual ventricular arrhythmia. Can you tell me if there is anything relevant in his record?”

CS-3013 & CS-502, Summer 2006


Social Engineering (2)

From: [email protected]: Sunday, March 26, 2006 8:10 AMTo: [email protected]: Re: Approved

Please read the attached file.

CS-3013 & CS-502, Summer 2006


Computerworld 3/19/04

• 10 cents on risk assessment• 15 cents on policy• 40 cents on awareness and

employee education• 20 cents on technology• 15 cents on process, process,

processPatrick McBride

CS-3013 & CS-502, Summer 2006


What is a “Security Policy?”

• What rights MAY a user have? – Define the maximum!

• What rights can a user pass on?• How can a user acquire additional

rights?

• Linux/Unix: -rwxr-xr-- /foo -rw--w---- /bar

CS-3013 & CS-502, Summer 2006


Policy Models (1)

A “Policy Model” is a framework for creating a specific policy for a specific organization

• Linux/Unix– Users, groups, everybody– “owner” (or “…”) controls grant of rights– Rights based on UID, GID – Focus on files– Process has rights of parent

• can change GID or drop rights

CS-3013 & CS-502, Summer 2006


Policy Models (2)

• Win2000/XP– Users and groups– Groups may be members of groups– Rights are the combined rights of all

groups of which the user is a direct or indirect member

– Administrator controls everything • can grant any right

– The default is strong control over admin functions and little control over files

CS-3013 & CS-502, Summer 2006


Policy Models (3)

• Typical Business– Managers can (usually) grant rights to their staff– Information is visible to people above in the

organization – Managers do not have authority to grant access

downward for some classes of information– Overall control is maintained by restricting

access to applications rather than to data– databases have their own distinct access controls

CS-3013 & CS-502, Summer 2006


Policy Models (4)

• The Military Mind– Access rights are granted only by a

higher authority– Access is broken into two models

• need-to-know (usually organizational with upward visibility)

• item-by-item (classification may occur in advance of creation or after)

– Creator may be denied access to own work– Some weird anomalies

CS-3013 & CS-502, Summer 2006


Policy Models (5)

• The BMA (British Medical Assoc.) model (1995)– Each medical record has an access control list– Access may be granted to a new clinician by the

subject or the primary clinician– Patient must be notified of all ACL changes, and

may revoke access– Deletions are not allowed– All access must be logged and auditable– Information may be aggregated from A into B

only if ACL(A) is a superset of ACL(B)• Reference

Anderson, Ross, “An Update on the BMA Security Policy,” 1996. (.pdf)

http://web.cs.wpi.edu/~cs502/s06/Papers/Anderson,%20BMA%20Security%20Policy.pdf

http://web.cs.wpi.edu/~cs502/s06/Papers/Anderson,%20BMA%20Security%20Policy.pdf

CS-3013 & CS-502, Summer 2006


Policy Models (6)

• The HIPAA model (1998)– The patient controls the right to access

“personally identifiable health information”– Access is granted to any clinician or facility

staff participating in the care of the patient– Patient must be notified of all breaches– Deletions are not allowed– All access must be logged and auditable– Privileges may be revoked

CS-3013 & CS-502, Summer 2006


More Principles

• Think about Assets, Threats and Vulnerabilities FIRST

• Find an appropriate (and minimally complex) Policy Model

• Match your OS capabilities to the policy model as best you can

• Train staff to recognize social engineering!

• Train staff to make a habit out of the policy!

CS-3013 & CS-502, Summer 2006


Break

CS-3013 & CS-502, Summer 2006


Part 3: Fun with Cryptography

• What is cryptography about?• General Principles of Cryptography• Basic Protocols

– Single-key cryptography– Public-key cryptography

• An example...

CS-3013 & CS-502, Summer 2006


Principles

• Cryptography is about the exchange of messages

• The key to success is that all parties to an exchange trust that the system will both protect them from threats and accurately convey their message

• TRUST is essential

CS-3013 & CS-502, Summer 2006


Therefore

• Algorithms must be public and verifiable

• We need to be able to estimate the risk of compromise

• The solution must practical for its users, and impractical for an attacker to break

CS-3013 & CS-502, Summer 2006


Guidelines

• Cryptography is always based on algorithms which are orders of magnitude easier to compute in the forward (normal) direction than in the reverse (attack) direction.

• The attacker’s problem is never harder than trying all possible keys

• The more material the attacker has the easier his task

CS-3013 & CS-502, Summer 2006


Example

• What is 314159265358979 314159265358979?

vs.

• What are prime factors of3912571506419387090594828508241?

CS-3013 & CS-502, Summer 2006


Time marches on…

• We must assume that there will be improvements in computational power, mathematics and algorithms.– Messages which hang around get less

secure with time!

• Increases in computing power help the good guys and HURT the bad guys for new and short-lived messages

CS-3013 & CS-502, Summer 2006


Caveat

• We cannot mathematically PROVE that the inverse operations are really as hard as they seem to be…It is all relative…

The Fundamental Tenet of Cryptography:If lots of smart people have failed

to solve a problem, it won’t be solved (soon)

CS-3013 & CS-502, Summer 2006


Secret key cryptography

f (T,K) g (C,K)Cleartext Cleartext

K K

CyphertextT TC

CS-3013 & CS-502, Summer 2006


Secret Key Methods

• DES (56 bit key)• IDEA (128 bit key)

• http://www.mediacrypt.com/community/index.asp

• Triple DES (three 56 bit keys)• AES

– From NIST, 2000– choice of key sizes up to 256 bits and more– Commercial implementations available

http://www.mediacrypt.com/community/index.asp

http://www.mediacrypt.com/community/index.asp

CS-3013 & CS-502, Summer 2006


Diffie – Hellman

Alice Agree on p,g Bob

choose random A choose random BTA = gA mod p

TB = gB mod p

compute (TB)A compute (TA)B

Shared secret key is gAB mod p

CS-3013 & CS-502, Summer 2006


D–H Problems

• Not in itself an encryption method – we must still do a secret key encryption

• Subject to a “man in the middle” attack(Alice thinks she is talking to Bob, but actually Trudy is intercepting all of the messages and substitution her own)

CS-3013 & CS-502, Summer 2006


RSA Public key cryptography

f () f ()Cleartext Cleartext

Key #1 Key #2

Cyphertext

Key #1 can be either a Public Key or a Private Key.Key #2 is then the corresponding Private Key or Public Key.

T C T

CS-3013 & CS-502, Summer 2006


RSA Public Key Cryptography

• Rivest, Shamir and Adelman (1978)• I can send messages that only you

can read• I can verify that you and only you

could have sent a message• I can use a trusted authority to

distribute my public key – The trusted authority is for your benefit!

CS-3013 & CS-502, Summer 2006


RSA Details

• We will use the same operation to encrypt and decrypt

• To encrypt, we will use “e” as a key, to decrypt we will use “d” as a key

• e and d are inverses with respect to the chosen algorithm

CS-3013 & CS-502, Summer 2006


RSA Details

• Choose n as the product of two large primes– Finding the factors of a large number is

mathematically difficult– Finding primes is also difficult

• Choose e to be a (fairly small) prime and compute d from e and the factors of n

• THROW AWAY THE FACTORS OF n!• Publish two numbers, e (public key) and

n

CS-3013 & CS-502, Summer 2006


RSA Details

• Encryption: Cyphertext = (Cleartext)e mod n• Decryption: Cleartext = (Cyphertext)d mod n

• Typical d will be on the order of 500 to 700 bits

• The cost of the algorithm is between 1 and 2 the size of n, – Each operation is a giant shift and add (multiply

by a power of 2)

CS-3013 & CS-502, Summer 2006


RSA Problems

• It is much more costly than typical secret-key methods – Use RSA to hide (i.e., encrypt) a secret key, – Encrypt the message with the secret key

and append/prefix the encrypted key

• Requires a “Public Key Infrastructure” for effective key generation and distribution– Chain of trust thing again!

CS-3013 & CS-502, Summer 2006


Message Digests (aka Digital Signatures)

• A message digest is a non-reversable algorithm which reduces a message to a fixed-length “summary”

• The summary has the property that a change to the original will produce a new summary

• The probability that the new summary is the same as the old should be 1/(size of digest)

• Tanenbaum, p. 590 (§9.2.4)

CS-3013 & CS-502, Summer 2006


Message Digests (2)

• There are several good (but possibly no perfect) message digest algorithms

• MD5 is probably the most common one in use – 128 bit digest

• has known weaknesses

• SHA-1 – 160 bit digest (current best choice)

• [Another product of NIST]

CS-3013 & CS-502, Summer 2006


Resources

• Network World Security Newsletter– http://www.nwsubscribe.com– Practical advice, not a virus alert newsletter. Especially good

for the links to other security resources at the bottom of each article

• CERT Coordination Center at CMU– http://www.cert.org

• News about system threats, including viruses and other problems. Source for OCTAVE papers and process

• Norton AntiVirus Site (Symantec)– http://securityresponse.symantec.com/avcenter/

• McAfee Security (Network Associates)– http://us.mcafee.com/virusinfo/

http://www.nwsubscribe.com/

http://www.cert.org/

http://securityresponse.symantec.com/avcenter/

http://us.mcafee.com/virusinfo/

CS-3013 & CS-502, Summer 2006


Textbooks

Network Security: C. Kaufman, R. Perlman, M. Speciner, Prentice Hall (2002)– A practical but rigorous presentation of network security

issues and techniques with emphasis on cryptographic solutions

Security Engineering: R. Anderson, Wiley (2001)– Focused on learning from past mistakes in security

system design.– Excellent discussion of policies and policy models.– See author’s web site (www.ross-anderson.com) if you

are interested in current research.

http://www.ross-anderson.com/

CS-3013 & CS-502, Summer 2006


Other Books

Real World Linux Security: R. Toxen, Prentice Hall (2003)– An excellent read. Lists hundreds of vulnerabilities and

what to do about them. Valuable for non Linux users too.

Windows 2003 Security Bible: B. Rampling, Wiley (2003) – Good example of a how-to book. Specific to WIN2003

The Art of Deception: K. Mitnick, Wiley (2002)– Mitnick is one of the most famous social engineers. – Must-read for those involved in broad security planning,

and fun for everyone.

CS-3013 & CS-502, Summer 2006 Computer System Security1 An Introduction to Computer System Security...

Documents

Transcript of CS-3013 & CS-502, Summer 2006 Computer System Security1 An Introduction to Computer System Security...