• 400 likes • 515 Views
Week 9 - Monday. CS363. 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
E N D
Week 9- Monday CS363
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
Security Presentation Claire Chambless
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
Assurance • There are many methods to provide assurance that a system has few vulnerabilities: • Testing • Penetration testing • Formal verification • Validation • Open source model
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
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
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
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
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
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
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
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
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
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
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
Evaluation criteriacriteria • A number of important features are important for the development of security criteria • Extensibility • Granularity • Speed • Thoroughness • Objectivity • Portability • Consistency • Compatibility • Exportability
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?
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
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
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
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
Query example • Table CLIENTS • Query: SELECT * FROM CLIENTS WHERE FIRST="BEN" OR CITY="CHICAGO" • Result
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
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
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
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
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
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
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
Next time… • Database reliability and integrity • Ted Bushongpresents
Reminders • Read Sections 6.3 and 6.4 • Keep working on Project 2 • Due Friday