An Introduction to Computer System Security

1. An Introduction to Computer System Security CS-502 Operating Systems (Notes taken from guest CS-502 lecture by Bob Strong, April 4, 2005) CS502 Spring 2006

2. 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 CS502 Spring 2006

3. Reading Material • Tanenbaum, Chapter 9 • Security and threats • Viruses • How to write and detect! • Protection – implementation of security • Silbershatz, Chapters 14-15 • Protection • Security CS502 Spring 2006

4. Part 1: OS Issues • Why “Security”? …and Security principles • Authorization and the Access Control Policy • User Authentication CS502 Spring 2006

5. Fundamental Goals for Computer Security • Data Confidentiality • Data Integrity • System Availability • Related issue – Privacy • A legal and ethic question • Implemented by Confidentiality goal CS502 Spring 2006

6. In Business Terms Asset Threat Cost Risk CS502 Spring 2006

7. 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? CS502 Spring 2006

8. 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? CS502 Spring 2006

9. 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 CS502 Spring 2006

10. 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! CS502 Spring 2006

11. Textbook 2D Matrix • Columns are access control lists (ACLs) • Associated with each object • Rows are capabilities • Associated with each user or each domain CS502 Spring 2006

12. 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 CS502 Spring 2006

13. 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 CS502 Spring 2006

14. 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…) CS502 Spring 2006

15. …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. CS502 Spring 2006

16. 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 CS502 Spring 2006

17. 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! CS502 Spring 2006

18. “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 CS502 Spring 2006

19. 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! CS502 Spring 2006

20. 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…) CS502 Spring 2006

21. 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 CS502 Spring 2006

22. 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 CS502 Spring 2006

23. 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) CS502 Spring 2006

24. The Challenge/Response Protocol Mary Art Hello, I’m Art Decrypt This {R}P R Hello Art! How can I help you? CS502 Spring 2006

25. 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. CS502 Spring 2006

26. 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 CS502 Spring 2006

27. 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 CS502 Spring 2006

28. 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 ... Systems and Networks Are Not Different CS502 Spring 2006

29. 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! CS502 Spring 2006

30. Break CS502 Spring 2006

31. Part 2: Human and Application Issues • What are we defending against…and why? • Weaknesses and Responses • Technical • Human • Things to think about... CS502 Spring 2006

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

33. 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” CS502 Spring 2006

34. 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 CS502 Spring 2006

35. 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 CS502 Spring 2006

36. 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! CS502 Spring 2006

37. 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. CS502 Spring 2006

38. 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?” CS502 Spring 2006

39. Social Engineering (2) From: 3dksobinsky@zoom-internet.net Sent: Sunday, March 26, 2006 8:10 AM To: rmstronger@charter.net Subject: Re: Approved Please read the attached file. CS502 Spring 2006

40. 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, process Patrick McBride CS502 Spring 2006

41. 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 CS502 Spring 2006

42. 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 CS502 Spring 2006

43. Policy Models (2) • Win200X • 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 CS502 Spring 2006

44. 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 CS502 Spring 2006

45. 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 CS502 Spring 2006

46. 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) CS502 Spring 2006

47. 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 CS502 Spring 2006

48. 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! CS502 Spring 2006

49. Break CS502 Spring 2006

50. Part 3: Fun with Cryptography • What is cryptography about? • General Principles of Cryptography • Basic Protocols • Single-key cryptography • Public-key cryptography • An example... CS502 Spring 2006