1 / 41

Some Aspects of Security in a Multiprogramming Environment

Some Aspects of Security in a Multiprogramming Environment. ECEN5043 University of Colorado. Favorite sentence in the chapter:. “If prevented from picking easy ones (passwords), they will forget them and start writing them down on sticky notes attached to their monitors ...”

ashling
Download Presentation

Some Aspects of Security in a Multiprogramming Environment

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Some Aspects of Security in a Multiprogramming Environment ECEN5043 University of Colorado

  2. Favorite sentence in the chapter: “If prevented from picking easy ones (passwords), they will forget them and start writing them down on sticky notes attached to their monitors ...” Been there. Done that. :-)) The above problem will also occur if one is required to change passwords too frequently. (Now how would I know that?!?!) ECEN5043 University of Colorado -- Security

  3. Overview • What we won’t cover • Basic Concepts • Topics about Security strongly related to multiprogram systems • Review of cryptography • Process communication • The opportunity of design ECEN5043 University of Colorado -- Security

  4. I. What we won’t cover from the chapter • Spy vs. Spy -- virus/antivirus, point/counterpoint • Attacks from inside – except that we will cover: • design principles • programming habits that make it harder to be attacked successfully • User authentication using physical objects or biometrics • Worst security weakness is not addressed in this chapter and most other books on security. ECEN5043 University of Colorado -- Security

  5. II. Basic Concepts • Security -- making sure that files are not read or modified by unauthorized persons/programs • includes technical, administrative, legal, social, psychological and political issues • Protection mechanisms • The various means used to ensure security • by the operating system • by some other avenue in the absence of an o.s. • in your cell phone, for example • company procedures ECEN5043 University of Colorado -- Security

  6. Basic Concepts : types of threats • Data confidentiality • having secret or confidential data remain so • defining and enforcing who can see what – authorization • authentication– you are who you say you are (still) • identity – I am who I say I am (still) • Data integrity – “the data is what it was” • Unauthorized user or program cannot modify data without owner’s permission • Changing, removing, or adding • System availability • No one can disturb system to make it unusable F. Non-repudiation ECEN5043 University of Colorado -- Security

  7. Review of terms: types of intruders • Passive -- read files without authorization • Active -- malicious, unauthorized changes • Casual prying • Snooping by insiders -- personal challenge to break security (also by former insiders) • Financial gain -- theft, blackmail • Espionage -- commercial or military • Virusor worm-- program, not a direct person, (usually) trying to do (usually) general damage via replication ECEN5043 University of Colorado -- Security

  8. Basic Concepts: Accidental loss • Accidental loss includes loss of data and/or programs due to • weather, wars, pestilence • hardware or software errors • crash and leave data exposed • corrupt data • human blunder ECEN5043 University of Colorado -- Security

  9. Basic Concepts: cryptography • Plaintext -- your original • Ciphertext -- encrypted text that can only be decrypted (deciphered) by authorized people • Security by obscurity -- trying to keep the encryption and decryption algorithms secret • Keys -- parameters to the algorithms that encode and decode ECEN5043 University of Colorado -- Security

  10. III.Security Topics & Multiprogram Systems • Avoiding Accidental Loss • Where’s the security related work? • Requirements and design process • Programming habits • Authentication IV. Basic cryptography • Name usage and notation • Digital signatures V. Process Communication VI. Considerations of design details • Protection mechanisms ECEN5043 University of Colorado -- Security

  11. III.A. Avoiding Accidental Loss 1. Unintentional loss, not by malicious means 2. Text says “Most of these” can be dealt with by maintaining adequate backups • Backups won’t help certain kinds of data loss such as ...? ECEN5043 University of Colorado -- Security

  12. Where’s the security work? • COMET process • Requirements engineering activities • Analysis activities – develop analysis model • Develop design model • Design overall architecture • Initial performance analysis • Component design – Concurrent portion • Performance analysis – refine • Component design – Passive portion • Detailed software design for each subsystem • Refine performance model and analyze ECEN5043 University of Colorado -- Security

  13. Where’s the security related activity? (#1) • Requirements engineering activities • Use case model • Relationships between use cases • Package use cases to group large functional areas • Use case narrative descriptions • System test plan • Use Case analysis, part 1 • “Run” tests against use cases ECEN5043 University of Colorado -- Security

  14. Where’s the security related work? (#2) • Analysis activities – develop analysis model • Develop domain model • Develop system context model • Develop entity classes static model • Class dictionary • Apply object structuring criteria to structure the system • Classes and objects • Determine high-level subsystems • Add new classes to class dictionary ECEN5043 University of Colorado -- Security

  15. Where’s the security related work? (#3) • Analysis activities, continued • Develop dynamic model: for each use case, • Determine which objects participate in the use case • Develop object interaction diagram (sequence or collaboration) • analyze sequence of interactions • analyze information passed between objects • Develop statecharts for state-dependent objects • verify events and actions are consistent with input/output messages of the state-dependent object executing the statechart ECEN5043 University of Colorado -- Security

  16. Where’s the security related work? (#4) • Develop design model • Synthesize what you’ve done so far ... produce initial software architecture • Synthesize partial use case based statecharts for a particular object into a complete statechart for that object • Synthesize a collaboration model from the use case based individual collaboration models • Synthesize a static model – class diagram ECEN5043 University of Colorado -- Security

  17. Where’s the security related work? (#5) • Design overall architecture • Structure into subsystems using criteria • Define subsystem interfaces • Develop synthesized collaboration diagram for each subsystem • Develop high-level collaboration diagram for whole system • (Design distributed component-based architecture) • Performance analysis ECEN5043 University of Colorado -- Security

  18. Where’s the security related work? (#6) • Component design – Concurrent portion • design the concurrent task architecture for each subsystem • apply task structuring criteria • define tasks and their interfaces • modify synthesized coll. diag. by adding concurrency information • document task behavior specs • Performance engineering analysis (more) • RMA • Performance model refinement ECEN5043 University of Colorado -- Security

  19. Where’s the security related work? (#7) • Component design – Passive portion • Within each subsystem, define the passive classes • Class interfaces including all operations • Inheritance hierarchies • Design database, if any, and its wrapper classes • Develop class interface specification • Detailed software design for each subsystem • Internals of composite tasks • Details of task synchronization mechanisms • Connector classes that encapsulate inter-task comm • Internal event sequencing logic • Refine performance model and analyze • Write code ECEN5043 University of Colorado -- Security

  20. III. Security Topics & Multiprogram Systems • Avoiding Accidental Loss • Where’s the security related work? • Requirements and design process • Programming habits • Authentication IV. Review of basic cryptography • Name usage and notation • Digital signatures V. Process Communication VI. Considerations of design details • Protection mechanisms ECEN5043 University of Colorado -- Security

  21. III. B. “Programming” habits • Array bounds checking • Hazop-type review: explicitly check the length of all user-supplied strings before stuffing them into fixed-length buffers • Efficient? (No measurable impact on performance if the code is not accessed frequently) • Worth it? Probably. Depends on requirements for security -- whether stated or not. • Forging pointers – Smart Pointer Pattern ECEN5043 University of Colorado -- Security

  22. III. B. Programming habits (bad habits) • Circumvention of access restrictions on private class members • Type casting -- implicitly or explicitly • Stack class checks for stack overflow or underflow (similar to array bounds checking) • System calls with insufficient return error code checks ECEN5043 University of Colorado -- Security

  23. III. Security Topics & Multiprogram Systems • Avoiding Accidental Loss • Where’s the security related work? • Requirements and design process • Programming habits • Authentication IV. Review of basic cryptography • Name usage and notation • Digital signatures V. Process Communication VI. Considerations of design details • Protection mechanisms ECEN5043 University of Colorado -- Security

  24. III. C. Authentication – Secure Login • Was initially absent and became important in successive generations of mainframes, minicomputers, personal computers, embedded systems • Section 9.3.1 discusses • easy to crack many login name/password combos, especially with the aid of automation • lunacy of publicly readable password files • Therefore, if programs communicate by password, what can you conclude? ECEN5043 University of Colorado -- Security

  25. Suggested approaches re logins & passwords • Don’t store the password; transform it first. • Store a one-way transformation • When password is provided by would-be user/process, transform it in the same way and look for match • Don’t store the transformed password; salt it. • append an n-bit random number called the salt with each password. (This changes when the pswd does.) • concatenate password and the salt, transform that • Store the salted, transformed password in an unreadable file that can be accessed by a slow program ECEN5043 University of Colorado -- Security

  26. III. Security Topics & Multiprogram Systems • Avoiding Accidental Loss • Where’s the security related work? • Requirements and design process • Programming habits • Authentication IV. Review of basic cryptography • Name usage and notation • Digital signatures V. Process Communication VI. Considerations of design details • Protection mechanisms ECEN5043 University of Colorado -- Security

  27. IV. Review of Basic Cryptography • Cryptography tradition -- “What’s in a name?” • There is a tradition to use certain names to indicate certain roles in security scenarios. • Alice • Bob • Carol • Dave • Eve –an eavesdropper • Mallory (or Mal) –a malicious attacker • Sara or Sue –a server ECEN5043 University of Colorado -- Security

  28. Cryptography notation • Plaintext, ciphertext, keys, encryption, decryption • C = E(P, KE) How would you read that? • P = D(C, KD) • KA • Kab • Kapriv and Kbpub • E(Kab,M) • {M} Kab • Sometimes the subscripts are written without using subscript format. • A obtains Kbpub • A:B keyname, {Kab} Kbpub • B decrypts with Kbpriv • Now A and B can use Kab ECEN5043 University of Colorado -- Security

  29. Keys A. Secret key: both sender and receiver must know the shared secret key B. Public-key: “public” means “published” • distinct keys used for encryption and decryption • given a well-chosen encryption key, it is nearly impossible to discover the corresponding decryption key • the encryption key is public and uses easy operation • sender sends message encrypted with receiver’s public key; only the receiver can decrypt it ECEN5043 University of Colorado -- Security

  30. Digital Signatures • To encrypt and decrypt an entire message may be too time-consuming and unnecessary. (The decryption algorithm is usually much more difficult than the encryption one.) • Or: may want to enforce non-repudiation • Hash a document -- result is a single fixed-length number • Alice “decrypts” the number with Alice’s private key, appends to original plaintext document, and sends to Bob. • Bob hashes the plaintext document again. • Bob applies Alice’s public key to the appended number (see why it has to be fixed length?) • Result should be the original hash result -- why? ECEN5043 University of Colorado -- Security

  31. Requirements for digital signatures to work • Must use algorithms for which E(D(x)) = x, not just that D(E(x)) = x , • That is, D and E must be commutative • Receiver must know sender’s public key • May need way to distribute public keys such that they cannot be altered -- certificate • Consider a multi-program system in which you don’t want one of the programs to be impersonated and have Mallory (the program) send bogus messages ECEN5043 University of Colorado -- Security

  32. III. Security Topics & Multiprogram Systems • Avoiding Accidental Loss • Where’s the security related work? • Requirements and design process • Programming habits • Authentication IV. Review of basic cryptography • Name usage and notation • Digital signatures V. Process Communication VI. Considerations of design details • Protection mechanisms ECEN5043 University of Colorado -- Security

  33. V. Process Communication • Authentication • Digital signatures • User interface design issues • Example: user choices appear in lists rather than free-form typing of strings -- can’t overflow parameter buffer or stack • Checking input w.r.t. bounds & buffer over / underflow (filter methods; even in design by contract) • Protection Mechanisms -- See Section 9.6 in chapter • Is writing to and reading from a shared data file safer than passing parameters? ECEN5043 University of Colorado -- Security

  34. III. Security Topics & Multiprogram Systems • Avoiding Accidental Loss • Where’s the security related work? • Requirements and design process • Programming habits • Authentication IV. Review of basic cryptography • Name usage and notation • Digital signatures V. Process Communication VI. Considerations of design details • Protection mechanisms ECEN5043 University of Colorado -- Security

  35. The Considerations of Design Details • How much security is your responsibility rather than the o.s.’s (if it exists)? • Erase pages, disk space, tape, etc. before allocating them (Note: there is erase and there is erase) • Design the system calls so as not to be confused by unreasonable parameters; design code to deal with any possible return code (including those not yet defined). • Ensure a killed password check is not considered a successful one – defaults to failure ECEN5043 University of Colorado -- Security

  36. The Considerations of Design Details -- cont. • Don’t put operating system structures in user space -- e.g. structure containing file name and parameters is passed to the system; system updates the structure while accessing the file • Do not insert trap doors for testing or debugging convenience -- they will be found by the wrong people some day (your ex-employees, for example) • Make the design public; make it as simple as possible • Make the default “no access” -- e.g. killed password check • Check for current authority ECEN5043 University of Colorado -- Security

  37. The Considerations of Design -- cont. • Give each process the least privilege possible • Build protection mechanism into lowest layers of the system -- make it simple and uniform • Conduct design reviews with an eye to security from the outset • Choose what is psychologically acceptable* • Design strong boundaries between kernel and user mode, if possible • Separate login passwords for users from that of system administrator ECEN5043 University of Colorado -- Security

  38. The Considerations of Design -- cont. • System design that bases updates over the web is risky • Do not require customers to update via attachments to email • Consider redundant file copies for verification • In multiprogram system, do not require one program to execute a program passed to it or found in a directory without authentication • If designing whole environment, allow selectively write-protected areas • If providing a security warning to the user, consider having it make sense to the user (just a suggestion!) ECEN5043 University of Colorado -- Security

  39. VI. The Considerations of Design -- cont. • If product uses imported applet-like code, • sandbox • run interpreted code, checking for problems • only accept code from trusted sources • verified by digital signature • Some combination -- see Notes for VI.M. • When product will run in existing environment, MUST understand how the system keeps track of which object belongs to which domain and what actions are permitted (access control). • Else, must design that, simply and uniformly • Resist the urge to provide multiple ways to do the same thing ECEN5043 University of Colorado -- Security

  40. The Considerations of Design Details -- cont. Z. Resist the urge to add unnecessary features for stupid reasons -- like this one. :-)) ECEN5043 University of Colorado -- Security

  41. References • Hassan Gomaa, Designing Concurrent, Distributed, and Real-Time Applications with UML, Addison-Wesley, 2000, ISBN 0-201-65793-7 • Andrew S. Tanenbaum, Modern Operating Systems, Prentice Hall, 2001, ISBN 0-13-031358-0. ECEN5043 University of Colorado -- Security

More Related