Notes for January 7, 1998

  1. Greetings and Felicitations
    1. Go through handouts
    2. Reading: Pfleeger, pp. 1-18, 286-287, 467-471, 494-517; Garfinkel & Spafford, pp. 23-45, 779-798
  2. Puzzle of the day
    1. Key point: policy vs. mechanism, with a sidebar on intent
  3. How do you design a security policy? [Pfleeger, pp. 1-18]
    1. Risk analysis
    2. Analysis of other factors:
    3. Procedures
  4. Risk analysis [Pfleeger, pp. 467-471; Garfinkel & Spafford, pp. 23-45]
    1. What are the threats?
    2. How likely are they to arise?
    3. How can they best be dealt with?
  5. Analysis of other factors [Pfleeger, pp. 494-517; Garfinkel & Spafford, pp. 779-798]]
    1. What else affects the policy (federal or state law, needs, etc.)?
    2. Law: as above; discuss jurisdiction (federal or local), problems (illiteracy of authorities, etc.); chain of evidence
    3. Discuss cryptographic software controls (here, France, etc.)
  6. Procedures
    1. What procedures need to be put in place, and how will they affect security?
  7. Human Factors
    1. Principle of Psychological Acceptability (note: illegal violates this)
    2. Principle of common sense (it's not common; more when we discuss robust programming)
  8. Design Principles [Pfleeger, pp. 286-287]
    1. Principle of Psychological Acceptability
    2. Principle of Least Privilege
    3. Principle of Fail-Safe Defaults
    4. Principle of Economy of Mechanism (KISS principle, redone)
[ ended here ]
    1. Principle of Complete Mediation
    2. Principle of Separation of Privilege
    3. Principle of Least Common Mechanism
    4. Principle of Open Design


You can also see this document in its native format, in Postscript, in PDF, or in ASCII text.
Send email to [email protected]. Department of Computer Science
University of California at Davis
Davis, CA 95616-8562


Page last modified on 1/15/98