1. June 1, 2004©2002-2004 Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-1 Chapter 13: Design Principles Overview Principles –Least Privilege –Fail-Safe Defaults –Economy of Mechanism –Complete Mediation –Open Design –Separation of Privilege –Least Common Mechanism –Psychological Acceptability

2. June 1, 2004©2002-2004 Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-2 Overview Simplicity –Less to go wrong –Fewer possible inconsistencies –Easy to understand Restriction –Minimize access –Inhibit communication

3. June 1, 2004©2002-2004 Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-3 Examples The program sendmail –reads configuration data from a binary file –It is generated by compiling a text file –3 interfaces: edit the text file, compile the file, read the binary file by sendmail –May be different assumptions! Examples: Prisoners communications

4. June 1, 2004©2002-2004 Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-4 Least Privilege A subject should be given only those privileges necessary to complete its task –Function, not identity, controls –Rights added as needed, discarded after use –Minimal protection domain –Example: in UNIX, root can do every thing! user who creates system backups can also delete files!

5. June 1, 2004©2002-2004 Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-5 Fail-Safe Defaults Default action is to deny access If action fails, system as secure as when action began

6. June 1, 2004©2002-2004 Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-6 Economy of Mechanism Keep it as simple as possible –KISS Principle Simpler means less can go wrong –And when errors occur, they are easier to understand and fix –testing process is less complex Interfaces and interactions –Example: finger protocol

7. June 1, 2004©2002-2004 Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-7 Complete Mediation Check every access Usually done once, on first action –UNIX: access checked on open, not checked thereafter If permissions change after, may get unauthorized access

8. June 1, 2004©2002-2004 Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-8 Open Design Security should not depend on secrecy of design or implementation –Popularly misunderstood to mean that source code should be public –“Security through obscurity” –Does not apply to information such as passwords or cryptographic keys

9. June 1, 2004©2002-2004 Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-9 Separation of Privilege Require multiple conditions to grant privilege –Separation of duty: if two or more steps are required to perform a critical function, at least two different people should perform the steps –Defense in depth

10. June 1, 2004©2002-2004 Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-10 Least Common Mechanism Mechanisms should not be shared –Information can flow along shared channels –Covert channels Isolation –Virtual machines –Sandboxes

11. June 1, 2004©2002-2004 Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-11 Psychological Acceptability Security mechanisms should not add to difficulty of accessing resource –Hide complexity introduced by security mechanisms –Ease of installation, configuration, use –Human factors critical here

12. June 1, 2004©2002-2004 Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-12 Key Points Principles of secure design underlie all security-related mechanisms Require: –Good understanding of goal of mechanism and environment in which it is to be used –Careful analysis and design –Careful implementation