Outline for March 8, 1999
- Greetings and felicitations!
- Should have homework 1 and 2 back, along with project parts 1 and 2 (if you
handed them in)?
- Penetration Exercises
- MTS
- Burroughs
- Vulnerabilities Databases
- Federated or centralized?
- What should they contain?
- Use: basis forFlaw Hypothesis step of FHM
- Use: basis for testing classification schemes
- Exploit Databases
- Federated or centralized?
- Difference between them and vulnerabilities databases
- Use: analysis of detritus
- Avoiding Vulnerabilities
- Good programming design (eight rules follow; Saltzer and Schroeder)
- Good implementation practise (more next week)
- Principles of Secure Design
- Refer to both designing secure systems and securing existing systems
- Speaks to limiting damage
- Principle of Least Privilege
- Give process only those privileges it needs
- Discuss use of roles; examples of systems which violate this (vanilla UNIX)
and which maintain this (Secure Xenix)
- Examples in programming (making things setuid to root unnecessarily,
limiting protection domain; modularity, robust programming)
- Example attacks (misuse of privileges, etc.)
- Principle of Fail-Safe Defaults
- Default is to deny
- Example of violation: su program
- Principle of Economy of Mechanism
- KISS principle
- Enables quick, easy verification
- Example of complexity: sendmail
- Principle of Complete Mediation
- All accesses must be checked
- Forces system-wide view of controls
- Sources of requests must be identified correatly
- Source of problems: caching (because it may not reflect the state of the
system correctly); examples are race conditions, DNS poisoning
- Principle of Open Design
- Designs are open so everyone can examine them and know the limits of the
security provided
- Does not apply to cryptographic keys
- Acceptance of reality: they can get this info anyway
- Principle of Separation of Privilege
- Require multiple conditions to be satisfied before granting
permission/access/etc.
- Advantage: 2 accidents/errors/etc. must happen together to trigger
failure
- Principle of Least Common Mechanism
- Minimize sharing
- New service: in kernel or as a library routine? Latter is better, as each
user gets their own copy
- Principle of Psychological Acceptability
- Willingness to use the mechanisms
- Understanding model
- Matching user's goal
- Auditing
- Goals: reconstruction or deduction?
- Relationship to security policy
- Application logs
- System logs
- Example analysis technique
- GOAL methodology
- Do it on local file accesses
- Problems
- Log size
- Impact on system services
- Correllation of disparate logs
You can get this document in
ASCII text,
Framemaker+SGML version 5.5,
PDF (for Acrobat 3.0 or later),
or
Postscript.
Send email to
cs253@csif.cs.ucdavis.edu.
Department of Computer Science
University of California at Davis
Davis, CA 95616-8562
Page last modified on 3/15/99