DOC PREVIEW
U of I CS 498 - Design Principles

This preview shows page 1-2-21-22 out of 22 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 22 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

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

U of I CS 498 - Design Principles

Documents in this Course
Lecture 5

Lecture 5

13 pages

LECTURE

LECTURE

39 pages

Assurance

Assurance

44 pages

LECTURE

LECTURE

36 pages

Pthreads

Pthreads

29 pages

Load more
Download Design Principles
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Design Principles and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Design Principles 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?