Midterm• Mark out of: 92• Average: 63.6, Median: 652Design PrinciplesCS498IASpring 20073Reading Material• Chapter 13 Computer Security: Art andScience4Overview• Simplicity− Less to go wrong− Fewer possible inconsistencies− Easy to understand• Restriction− Minimize access− Inhibit communicationSaltzer and Schroeder 755Economy of Mechanism• Keep the design as simple and small aspossible• Simpler means less can go wrong− And when errors occur, they are easier tounderstand and fix• Interfaces and interactionsExample: Voting Software• Diebold Accuvote TS− 31,000 lines of C++• PRUI (Yee et al)− < 300 lines of Python− http://zesty.ca/voting/• Which one would you trust?Example: Star Wars8Fail-Safe Defaults• Base access decisions on permission ratherthan exclusion• Burden of proof is on the principal seekingpermission• If the protection system fails, then legitimateaccess is denied but illegitimate access isalso deniedExamples• Remove illegal characters:illegal_chars = “,;/\\!”str = [c for c in input if c not inillegal_chars]• Better:legal_chars = “abcdefg…”str = [c for c in input if c in legal_chars]• Other examples?10Complete Mediation• Every access to every object must bechecked for authority• Usually done once, on first action− UNIX: access checked on open, not checkedthereafter• If permissions change after, may getunauthorized access• Proposals to gain performance byremembering the result of an authority checkshould be examined skepticallyExample: Star Wars12Open Design• The design should not be secret− Design / code should be available for publicreview− Easier to achieve assurance• The mechanisms should not depend on theignorance of potential attackers, but rather onthe possession of specific, more easilyprotected, keys or passwords.− Kerckhoffs’ principle: do not depend on thesecrecy of something you cannot changeExample: GSM security• Algorithms designed in secret− A3/A8: reverse engineered (‘98), broken 3 hourslater− A5/2: reverse engineered (‘99), broken 5 hourslater− A5/1: reverse engineered (‘99), broken 1 yearlaterExample: Star Wars15Separation of Privilege• Where feasible, a protection mechanism thatrequires two keys to unlock it is more robustand flexible than one that allows access tothe presenter of only a single key.• Require multiple conditions to grant privilege− Separation of duty− Defence in depthExample: root / admin account• Most operating systems use admin account• Any privileged action requires adminprivileges− All-or-nothing access17Least Privilege• Every program and every user of the systemshould operate using the least set ofprivileges necessary to complete the job• A subject should be given only thoseprivileges necessary to complete its task− Function, not identity, controls− Rights added as needed, discarded after use− Minimal protection domainExamples• Military: need-to-know− BLP/Biba compartments• PitBull: proxy privilege− A new process defines subset of parent’s privilegethat it needs to use• Others?19Least Common Mechanism• Minimize the amount of mechanism common tomore than one user and depended on by all users− Every shared mechanism (especially one involving sharedvariables) represents a potential information path betweenusers− Further, any mechanism serving all users must be certifiedto the satisfaction of every user, a job presumably harderthan satisfying only one or a few users.• Is this a good principle?− Shared mechanisms can have higher assurance than non-shared ones20Psychological Acceptability• It is essential that the human interface bedesigned for ease of use so that usersroutinely and automatically accept theprotection mechanisms correctly• Security mechanisms should not add todifficulty of accessing resource− Hide complexity introduced by securitymechanisms− Ease of installation, configuration, use− Human factors critical hereExample: Voting systems22Key Points• Principles of secure design underlie allsecurity-related mechanisms• Require:− Good understanding of goal of mechanism andenvironment in which it is to be used− Careful analysis and design− Careful
View Full Document