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