CS363

1. Week 9- Monday CS363

2. Last time • What did we talk about last time? • Theoretical limits of access control • Security design principles • Least privilege • Fail-safe defaults • Economy of mechanism • Complete mediation • Open design • Separation of privilege • Least common mechanism • Psychological acceptability • OS security features

3. Questions?

4. Project 2

5. Assignment 3

6. Security Presentation Claire Chambless

7. OS Assurance

8. Common OS Security Flaws • User interaction is problematic because input is often not under the direct control of the OS • Hardware can vary, and it is hard to check all software drivers • Sometimes security measure are bypassed for efficiency • Ambiguity in access policy • Incomplete mediation • Generality • Customizability leads to unpredictable configurations or special modules that need high privilege access • Time-of-check to time-of-use issues

9. Assurance • There are many methods to provide assurance that a system has few vulnerabilities: • Testing • Penetration testing • Formal verification • Validation • Open source model

10. Testing • We discussed testing briefly before • It has problems: • Testing can find problems, but it can’t find the lack of problems • Testing takes time and effort because the number of states a program can undergo is exponential in its length • Black box testing cannot be guaranteed to be complete • Code introduced into a program to test it can change its behavior • Complex systems can have errors that are difficult to reproduce • It is still the most common form of assurance

11. Penetration Testing • Penetration testing (or tiger team analysis or ethical hacking) is a kind of testing where experts try to use every trick they can to break a system • It is an art requiring creativity and a science requiring deep technical knowledge • It is not a panacea, but there is money to be made as a penetration tester

12. Formal verification • It is possible to prove that some programs do specific things • You start with a set of preconditions • You transform those conditions with each operation • You can then guarantee that, with the initial preconditions, certain postconditions will be met • Using this precondition/postcondition approach to formally describe programming languages is called Hoare semantics • Proving things about complex programs is hard and requires automated use of programs called theorem provers

13. Validation • Validation is checking the design against the requirements • Verification is checking the implementation against the design • OS validation is often done in the following ways: • Requirements checking • Design and code reviews • System testing

14. Open source systems • In open source systems, the software is freely available for public use and criticism • In most cases, anyone sufficiently skilled can even add their own code to the systems • They are popular • Microsoft CEO Steve Ballmer said in 2008 that 60% of the web servers in the world run Linux • The open source security advantage is that a huge number of people can look for flaws • The open source security disadvantage is the same • Research suggests that a product being open source or closed source is not the key determiner of security

15. System Evaluation

16. Evaluation criteria • Governments have established criteria for software security evaluation • These include: • U.S. Orange Book Evaluation • ITSEC • U.S. Combined Federal Criteria • Common Criteria

17. U.S. Orange Book Evaluation • In the 1970’s, the DoD defined the Trusted Computer System Evaluation Criteria (TCSEC) known as the Orange Book standard • It had assurance levels ranging from D to A1

18. Other countries • The Germans created Green Book criteria • Quality levels Q0 through Q7, similar to Orange Book assurance levels • Functionality levels F1 through F10 for different program needs (e.g., high integrity or high availability) • The British system provided a structure for developers to make demonstrable claims about their products • Canada, Australia, and France had other criteria

19. ITSEC • The ITSEC (Information Technology Security Evaluation Criteria) came out in 1991 as an effort to unify the European models • It focuses on effectiveness, similar to the U.S. assurance levels • It also requires that a product has a target of evaluation, the kind of security being judged

20. U.S. Combined Federal Criteria • NIST and the NSA came up with U.S.Combined Federal Criteria which introduced the following ideas: • Protection profile: what kind of protection and how much is needed for a particular kind of application • Security target: How a particular product maps to a protection profile

21. Common Criteria • The U.S. Combined Federal Criteria were never formally adopted • Instead, researchers combined its ideas with ITSEC to created a world criteria called the Common Criteria • It created families of functionality and assurance and created components for each family

22. Evaluation criteriacriteria • A number of important features are important for the development of security criteria • Extensibility • Granularity • Speed • Thoroughness • Objectivity • Portability • Consistency • Compatibility • Exportability

23. Lessons from criteria • The original TCSEC came out of the U.S. DoD • It focused on military and national defense threats • Because of its age, it had little connection to networking • Other evaluation criteria were mostly created by governments • The most highly evaluated products have never been widely used by consumers • Some vendors have succeeded in getting low level evaluations • Many use an emphatic assertion (claiming high security with no real evaluation) instead • What will the future be?

24. Database Background

25. What is a database? • You guys probably know more about databases than I do • A database is a collection of data and a set of rules to organize the data by relationships • A database administrator makes the rules and controls access • A database management system (DBMS) is the program through which the user interacts with the database

26. Database components • Almost all modern databases use the relational database model • The fundamental unit of organization is a table • An older format for databases was hierarchical, like a tree • A table consists of records • A record consists fields or elements, which are each a specific item of data

27. Schemas • The tables in a database are usually related to each other in some way • The logical structure of a database is called a schema • A user may only see part of it, called a subschema • An attribute is the name of a column • A relation is a set of columns

28. Queries • A query is the name of a command given to a database by a user • Queries can: • Retrieve • Modify • Add • Delete • Most databases allow commands to be issued through a variant of SQL

29. Query example • Table CLIENTS • Query: SELECT * FROM CLIENTS WHERE FIRST="BEN" OR CITY="CHICAGO" • Result

30. Database advantages • Databases have many advantages: • Shared access for many users • Minimal redundancy so that space is used efficiently • Data integrity with rules that protect relationships • Controlled access with authorized users • Databases have also been heavily optimized for speed • Users don’t need to know anything about the actual physical layout of the database on disk

31. Database Security Requirements

32. Database security requirements • Because they are a central part of modern business, several aspects of database security are crucial: • Physical database integrity • Logical database integrity • Element integrity • Access control • User authentication • Availability

33. Database integrity • Physical database integrity • What happens in a power failure? • Disk drives fail all the time • Regular backups are necessary • Google and Amazon offer distributed database services • Transaction logs should be kept

34. Element integrity • The integrity of an individual element is its correctness or accuracy • Field checks make sure that data values fall within appropriate ranges or have the right types • Usually these checks are done as data is being entered • Access control is key • Partly to protect data from malicious users • Partly to avoid situations where two users update information at the same time, leading to inconsistency • A change log keeps track of all changes, allowing for an undo of mistaken updates

35. Auditability • Like with OS logs, we want to be able to keep track of who has accessed the database • Similarly, the log can become very long • Should we record when a user has indirectly accessed a value through a SELECT statement? • This is called the pass-through problem

36. Access control and authentication • Managing access control for a database is very difficult • Many systems allow for very fine-grained control • But some human has to assign all the privileges • Worse, giving a person access to some data but not others might not be enough • Some queries can leak information about hidden data • Getting this data is called inference • Most DBMS systems are separate from the OS • Since there is no trusted path, the DBMS must do its own authentication

37. Availability • Availability is another challenge for a DBMS • Since these systems make the world work, everyone notices when they go down • If a field is not available to user A while user B is editing it, user A may have to wait an unacceptable amount of time • To avoid inference, data that should be publicly known might be unreasonably hidden • CIA all come together in DBMS

38. Upcoming

39. Next time… • Database reliability and integrity • Ted Bushongpresents

40. Reminders • Read Sections 6.3 and 6.4 • Keep working on Project 2 • Due Friday