Slide #13-1Design PrinciplesCS498SHFall 2006Based on slides provided by Matt Bishop for use with Computer Security: Art and ScienceSlide #13-2Reading Material•Chapter 13 Computer Security: Art and ScienceSlide #13-3Overview•Simplicity–Less to go wrong–Fewer possible inconsistencies–Easy to understand•Restriction–Minimize access–Inhibit communicationSaltzer and Schroeder 75Slide #13-4Economy of Mechanism•Keep the design as simple and small as possible•Simpler means less can go wrong–And when errors occur, they are easier to understand and fix•Interfaces and interactionsSlide #13-5Fail-Safe Defaults•Base access decisions on permission rather than exclusion•Burden of proof is on the principal seeking permission•If the protection system fails, then legitimate access is denied but illegitimate access is also deniedSlide #13-6Complete Mediation•Every access to every object must be checked for authority•Usually done once, on first action–UNIX: access checked on open, not checked thereafter•If permissions change after, may get unauthorized access•Proposals to gain performance by remembering the result of an authority check should be examined skepticallySlide #13-7Open Design•The design should not be secret•Do 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 keysSlide #13-8Separation of Privilege•Where feasible, a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key.•Require multiple conditions to grant privilege–Separation of duty–Defense in depthSlide #13-9Least Privilege•Every program and every user of the system should operate using the least set of privileges necessary to complete the job•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 domainSlide #13-10Least Common Mechanism•Minimize the amount of mechanism common to more than one user and depended on by all users•Mechanisms should not be shared–Information can flow along shared channels–Covert channels•Isolation–Virtual machines–SandboxesSlide #13-11Psychological Acceptability•It is essential that the human interface be designed for ease of use so that users routinely and automatically accept the protection mechanisms correctly•Security mechanisms should not add to difficulty of accessing resource–Hide complexity introduced by security mechanisms–Ease of installation, configuration, use–Human factors critical hereSlide #13-12Examine Scenarios•Paper overheadSlide #13-13Key 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
View Full Document
Unlocking...