1 / 92

Security Concepts and Capabilities

Security Concepts and Capabilities. The majority of these slides represent material that has been accumulated from various sources over the years. A portion these slides are being used with the permission of Dr. Ling Lui, Associate Professor, College of Computing, Georgia Tech.

Download Presentation

Security Concepts and Capabilities

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. Security Concepts and Capabilities • The majority of these slides represent material that has been accumulated from various sources over the years. • A portion these slides are being used with the permission of Dr. Ling Lui, Associate Professor, College of Computing, Georgia Tech. Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-1155 Storrs, CT 06269-1155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818

  2. Motivation: Recall Project Architecture Providers Patients EMR Web-Based Portal(XML + HL7) Open Source DB (XML or MySQL) Where are the Security Issues and Concerns? Consider Components of Architecture… Feedback Repository Education Materials Clinical Researchers

  3. Motivation: Security Issues? Patients XML Patient GUI for RN vs. MD Encryption https Providers html Web - Control Services Appl. – Control Methods Clinical Researchers Encryption Secure Communication Web Content Encryption GUI Look and Feel Web Server https Firewall Appl Server DB Server

  4. Overview • Objective: Cover the wide range of Background Concepts and Security Ideas • Motivation: Importance, Concepts, and Issues • Glossary of Security Terms • Security Policy, Authentication, and Authorization • Security in Java • Access Control • Mandatory Access Control (MAC) • Discretionary Access Control (DAC) • Role-Based Access Control (RBAC) • DB Security, Cryptography, Security in Statistical DB • Web Based Security • Concluding Remarks

  5. Motivation: General Concepts • Authentication • Proving you are who you are • Signing a Message • Is Client who s/he Says they are? • Authorization • Granting/Denying Access • Revoking Access • Does Client have Permission to do what s/he Wants? • Encryption • Establishing Communications Such that No One but Receiver will Get the Content of the Message • Symmetric Encryption and Public Key Encryption

  6. Motivation: Type of Security Issues • Legal and Ethical Issues • Information that Must be Protected • Information that Must be Accessible • HIPPA vs. Emergent Health Situations • Policy Issues • Who Can See What Information When? • Applications Limits w.r.t. Data vs. Users? • System Level Enforcement • What is Provided by the DBMS? Programming Language? OS? Application? Web Server? Client? • How Do All of the Pieces Interact? • Multiple Security Levels/Organizational Enforcement • Mapping Security to Organizational Hierarchy • Protecting Information in Organization

  7. Glossary of Protection and Security Terms • Principal • Entity (Person/Process/etc.) to Which Authorizations are Granted • Can be a User, User Group, Program, Client, etc. • Also Known as Subject • Protected Object • Known Object whose Internal Structure is Inaccessible Except by Protection System • The Unit of Protection • For Our Purposes: • Table, Column, Tuple • Data and Meta-Data Glossary from: Saltzer and Schroeder, “The Protection of Information in Computer Systems”, Proc. of IEEE, Vol. 63, No. 9, September 1975.

  8. Glossary of Protection and Security Terms • Access Control List • List of Principals (User, User Group, Process, …) Authorized to have Access to Some Object • For Every Object, Maintain Authorized Principals • Easily Implemented in Algorithm/Typically in OS • Authenticate • Verify Identity of Principal Making Request • In OS - Equivalent to Logging on (ID, Password) • May be More Complicated Based on Security Needs • Authorize • Grant Principal Access to Objects • Granularity Ranges from Fine to Coarse • Application Directed

  9. Glossary of Protection and Security Terms • Capability • Unforgeable Ticket as Proof of Authorization of Presenter (Principal) to Access Named Object • Ticket or Certificate Must be Presented at Each Access • Capability List • List of Protected Objects which Likewise List Authorized Principles • Used in Conjunction with Tickets for Authorization • Certify • Verify Accuracy, Correctness, & Completeness of Security/Protection Mechanism • Critical for Select Domains (DoD, Banking, etc.)

  10. Glossary of Protection and Security Terms • Confinement • Restricting What a Process Can Do to with Authorized Objects • Similar in Concept to Sandbox of Java • Domain • Objects Currently Accessed by Principal • (De)Encryption • De(Encoding) of Data According to Transformation Key for Transmission/Storage • Reciprocal Activity - Many Different Options • Grant • Authorize Access to Objects by Principals • Who Can do What When

  11. Glossary of Protection and Security Terms • Password • Encrypted Character String to Authenticate Identity of Individual • Critical to Encrypt Also from Client to Login Server • Client Types in Plain Text that is Encrypted • Encrypted login Travels of Network • Decrypted at Login Server and Verified • Permission • Form of Allowed Access to Object (R, W, RW) • Level of Access is System Dependent • Unix File System has: • r, w, x for User, Group, and Other

  12. Glossary of Protection and Security Terms • Privacy • Ability to Decide Whether, When, and to Whom Information is Released • Is Anyone Intercepting Client/Server Communications? • Propagation • Principal Passing on Authorization to Object to Another Principal • Current Term Today is “Delegation” • Principal Must be Authorized to Delegate Privileges to Another Principal • Enforcement Mechanism • Centralized and Distributed “Code” • Enforces Security Policy at Runtime

  13. Glossary of Protection and Security Terms • Protection & Security • Mechanisms and Techniques to Control Access to Information by Executing Programs • Enforcement Mechanism, Cryptography Algorithms, Database Security, etc. • Revoke • Remove Previously Authorized Access from Principals • Security Tools Must Promote Grant, Revoke, and Authorize in a Dynamic Setting • Ticket-Oriented • Each Principal Maintains List of Unforgeable Tickets Denoting Objects have been Authorized • Works with Capability Lists

  14. Policy & Mechanism • Security Policy Defines Rules for Authorizing Access to Computer and Resources • Who are Users? What are DB Items? What DB Items are Available to Each User? Etc… • For PHR – Patient Defines Policy • Protection Mechanisms Authenticate • Access to DB Items, File and Memory Protection • What is the Granularity of Access? • A Security Policy is an Organizations Strategy to Authorize Access to the DBMS DB Items • Each Policy is Application Dependent • Range from Full to Limited Access • Security Transcends DB as a Separate Research and Realization for All Types of Systems/Applications

  15. Authentication • User/Process Authentication • Is this User/Client Who It Claims to Be? • Passwords • More Sophisticated Mechanisms • Need for Re-authentication • Authentication in Networks • Is this Computer Who It Claims to Be? • File Downloading and Transferring • Obtaining Network Services • What is Java Promise? What Does Java Guarantee re. Applets? What can Application do that Applet Can’t? • DB Authentication • Uncontrolled Access (Select, Modify, etc.) Can be Limited (Authorized) requiring Authentication

  16. Authorization • Ability of Principals to Use Machines, Objects, Resources, etc. • Security Policy Defines Capabilities of Each Principal Against Objects, Resources, etc. • Authorization Mechanism Enforces Policy at Runtime • External Authorization • User Attempts to Access Computer • Authenticate Identify and Verify Authorizations • Internal Authorization • Can Process Access a Specific Resource? • Database Authorization • What Can Each User Do Against the DB? Select, Insert, Update, Delete? • Are Users Limited to Subsets of Tuples by Value?

  17. User Authentication • Combination of User ID and Password Universal for Access to Computers • However, Cannot Prevent … • Guessing of Passwords • Stolen and Decrypted Passwords • Masquerading of Intended User • Is User Who they are Supposed to be? • What Extra Information Can User be Asked to Supply? • What About Life Critical Situations – EMR’s Treating Accident Victim? • Past Invasion of Engineering Computing • yppasswd File Stolen/Decrypted • S. Demurjian’s Sun Workstation Corrupted

  18. Network Authentication • Computers Must Interact with One Another • Classic Example, Transmitting E-Mail Msgs. • Does Transferring Computer have Right to Store a File on Another Computer? • What About PHR Data Routed from Web to Application to DB to EMR? • Where is the Control? https? Encryption? • Guarantee Unencrypted Data not Stored on the Way? • Viruses: Passive Penetrating Entity • Software Module Hidden in Another Module • When Container Executed, Virus Can Penetrate and Wreak Havoc • Worms: Active Penetrating Entity • Actively Seeks to Invade Machine

  19. Core Security Capabilities of Java • Sandbox and Applet Level Security • Downloaded Applets are Confined in a Targeted Portion of System During Execution • Execution of Untrusted Code in Trusted Way • What is Sandbox? • Area of Web-Browser Dedicated to Applet • Applet Limited to Sandbox to Prohibit Access to Local Machine/Environment • Utilizes Class Loader, Bytecode Verifier, and Security Manager • Three Components Maintain System Integrity • How Does this Occur? • Why is this Relevant for BMI Applications? • Pervasive Usage of Applets and Client Java Code

  20. Core Security Capabilities of Java • Class Loader - Only Load Correct Classes • Bytecode Verifier - Classes in Correct Format • Both Don’t care Where the Code is from (compiled from Java or another PL – just is it correct) • Security Manager - Untrusted Classes Can’t Execute Dangerous Instructions nor Access Protected System Resources • Role of Security Managers • Enforces Boundaries of Sandbox • All Java Classes ask Manager for Permission to Perform Certain Operations • Implements/Imposes Appl. Security Policy • Java Interface Class Implementable by Users • Integrated with Exception Handling of Java

  21. Recall Java Bytecode Verification:

  22. Digital Signatures and JAR Files • When Can Applets Become Applications? • Trusted Publisher (Originator of Applet) • Signed Applet is Authenticated • Java Security Manager May Allow Applet out of Sandbox to be Application • How is Information Transmitted and Exchanged? • JAR: Archived (Compressed) Files • Bundling of Code/Data into Java Archive • Associated Digital Signature for Verification • Transmission via Object Serialization • Again, for BMI • Web Applications to PCs, PDAs, and Cells • Pervasiveness of Technology and Potential for Misuse and Information Release

  23. Available Access Control Approaches • Mandatory Access Control (MAC) • Bell/Lapadula Security Model • Security Classification Levels for Data Items • Access Based on Security Clearance of User • Role Based Access Control (RBAC) • Govern Access to Information based on Role • Users can Play Different Roles at Different Times Responsibilities of Users Guiding Factor • Facilitate User Interactions while Simultaneously Protecting Sensitive Data • Discretionary Access Control (DAC) • Richer Set of Access Modes - Govern Access to Information based on User Id • Discretionary Rules on Access Privileges • Focused on Application Needs/Requirements

  24. What are Key Access Control Concepts? • Assurance • Are the Security Privileges for Each User Adequate to Support their Activities? • Do the Security Privileges for Each User Meet but Not Exceed their Capabilities? • Consistency • Are the Defined Security Privileges for Each User Internally Consistent? • Least-Privilege Principle: Just Enough Access • Are the Defined Security Privileges for Related Users Globally Consistent? • Mutual-Exclusion: Read for Some-Write for Others

  25. Mandatory Access Control • Bell-Lapadula Model [1976] • An Extension of the Access Matrix Model • The Model is Based on Subject-Object Paradigm • Subjects: Active Elements • Objects: Passive Elements • Four Access Modes/Categories • Executable by Subjects on Objects • Read-only or Read • Append (Write without Read) • Execute (Executes an Object/program) • Read-Write or Write

  26. Mandatory Security Mechanism • Typical Security Classification Levels for Subjects/programs and Objects/resources • Top Secret (TS) and Secret (S) • Confidential (C) and Unclassified (U) • Rules: • TS is the Highest and U is the Lowest Level • TS > S > C > U • Security Levels: • C1 is Security Clearance Given to User U1 • C2 is Security Classification Given to Object O1 • U1 can Access O1 iff C1  C2 • This is Referred to as the Domination of U1 Over O1

  27. Operations • Get access • Initiate access to object in the given mode • Release access • Terminate access previously started by get • Given access • grant an access mode on an object to a subject • Rescind access • Revoke access previously granted with the “give” operation • Create object • An object may be inactive or active; this takes an inactive object and adds to the object hierarchy • Delete object • Deactivates an active object • Change subject security level • Change object security level

  28. Mandatory Security Mechanism • Restriction (Axiom 1): • No Subject S Can Read an Object O if the Object’s Security Classification is Higher Than the Subject’s Security Clearance • S Can Read O iff Clearance(S)  Classification(O) • No Subject May Write an Object that has Lower Security Class than the Subject’s Security Clearance • S Can Write O iff Clearance(S)  Classification(O) • This Prevents Information Flow from Higher Classification to Lower Classification Levels • Depending on the Desired MAC, Different Axioms Can be Employed that Satisfy Different Criteria ofClearance Dominating Classification

  29. Other Axioms • Simple Security (SS) Property • Subject S may have Read(Write) Access to Object O iff Clearance of S Dominates the Classification of O • Star (*) Property • A Subject Can Only Read Objects at or Above their Level • A Subject Can Only Write Objects at or Below their Level • Tranquility Principle • No Subject Can Modify Classification of Active Object

  30. Mandatory Security Mechanism TS S C U • There are Numerous Security Properties Regarding the Ability of a Subject S to Read (Write) an Object O • These Properties Control the flow of Information from Users to the Objects that they are allowed to Access • Simple Security Property (Read Down – No Read Up) • No Subject S Can Read an Object O if the Object’s Security Classification is Higher Than the Subject’s Security Clearance • S Can Read O iff Clearance(S)  Classification(O) • This Insures that a Subject S cannot Read Information Above his/her Security Level User (S) Read Down

  31. Mandatory Security Mechanism TS S C U • Simple Integrity Property (Write Down–No Write Up) • A Subject May Write an Object only if that Object is at or Below the Subject’s Security Clearance • S Can Write O iff Clearance(S) ≥ Classification(O) • This Allows the Potential of Information Flow from Higher Classification to Lower Classification Levels • This Prevents the Ability of a Subject S to Corrupt Data above its Security Level • Security Designer Must Choose their Poison! User (S) Write Down

  32. Mandatory Security Mechanism TS S C U • Liberal * Property (Write Up–No Write Down) • No Subject May Write an Object that has Lower Security Class than the Subject’s Security Clearance • S Can Write O iff Clearance(S)  Classification(O) • This Prevents Information Flow from Higher Classification to Lower Classification Levels • Such an Attempt can be Overt or Unintentional • Likewise, this Allows a Subject to Corrupt Information above its Level Write Up User (S)

  33. Mandatory Security Mechanism TS S C U • Strict * Property (Read/Write Equal) • A Subject May Only Read/Write an Object that has the Exact Same Security Class than the Subject’s Security Clearance • S Can Read/Write O iff Clearance(S) = Classification(O) • This Limits Information Flow to within a Level Read Equal Write Equal User (S)

  34. Using the Properties • Security Policy is Typically a Combination of one Read and one Write Property • Simple Security + Simple Integrity • Simple Security + Strict * (Write) • Simple Security + Liberal * • Strict * (Read) + Simple Integrity • Strict * (Read) + Strict * (Write) • Strict * (Read) + Liberal * • Objective: Security Engineer Must Choose the Most Appropriate Combination for their Application

  35. A Classic Example TS S C U • Simple Security for Reads • See Information at User Clearance Level and Lower (Less Secure) • No Chance of Viewing TS Information • Liberal * for Writes • Write Information at User Clearance Level and Above (More Secure) • No Chance of Releasing “S” Data to Lower Levels Read Down User (S) Write Up

  36. Other Axioms • Discretionary Property (DS-property) • Every Current Access Must Be Present in the Access Matrix • For All Subjects S, Objects O, and the Access Mode M: <S,o,m>  B  M  M[s,o] • Non-Accessibility of Inactive Objects • A Subject Cannot Read the Contents of an Inactive Object • Rewriting of Inactive Objects • A Newly Activated Object is Assigned to an Initial State Independent of the Previous Activation of the Object

  37. Illustrating MAC • Consider the EMPLOYEE Table Below with Two Instances • Notice Classifications on Each Tuple (TC) • Notice Classifications on Each Attribute Value • Interpretation: • Limit Who Can See Each Tuple and Values • Focus on User Clearance w.r.t. Classifications

  38. Illustrating MAC • Whenever a User Attempts to Access a Table, the Table is Filtered According to U’s Clearance • First Set are for a User at Confidential Level • Second Set is For a User at Unclassified Level

  39. Security in Software Applications • Extensive Published Research (Demurjian, et al) in Last Ten Years for DAC/RBAC for OO • Efforts in • Automatically Generatable and Reusable Enforcement Mechanisms • MAC/DAC/RBAC within Distributed Setting • Premise: • Customizable Public Interface of Class • Access to Public Interface is Variable and Based on User Needs and Responsibilities • Only Give Exactly What’s Needed and No More • Please see:www.engr.uconn.edu/~steve/DSEC/desc.html

  40. What is Role Based Access Control (RBAC)? • Most OO Programming and Database Languages have a Single Public Interface that is Shared by All Users of OT/Class • Consequently, Public Interface Often Union of all Possible Methods Required by All Likely Users • Discretionary Access Control: • Occurs at Type-Level • Different Portions of Public Interface Available to Different Users at Different Times Depending on User-Roles • Promote Potential Public Interface

  41. Motivating Security for OO Paradigm • OO Paradigm Provides Minimal Support via Public Interface and Private Implementation • Public Interface Represents UNION of all Possible Privileges Needed by All Potential Users • A Method in the Public Interface for One Specific User Available to ALL Users • Can Access to Public Interface be Customized? • Can Individuals have Particular Access to Specific Subsets of Public Interface? • Can Access be Based on (Potentially) Dynamic User Roles? • Can Code be Automatically Generated to Implement an Enforcement Mechanism? • Role of OO Paradigm in Support a Generic, Evolvable, Reusable Enforcement Mechanism?

  42. Why is RBAC Needed? • In Health Care, different professionals (e.g., Nurses vs. Physicians vs. Administrators, etc.) Require Select Access to Sensitive Patient Data • Suppose we have a Patient Access Client • Lois playing the Nurse Role would be Allowed to Enter Patient History, Record Vital Signs, etc. • Steve playing M.D. Role would be Allowed to do all of a Nurse plus Write Orders, Enter Scripts, etc. • Vicky playing Admin Role would be Allowed to Enter Demographic/Insurance Info. • Role Dictates Client Behavior

  43. Why is RBAC Needed? • Many Situations When Application Library Designer (SWE) Could Utilize More Fine-Grained Control to Access of Public Interface • Tradeoff Between Developers and End-Users • SWEs Have Different Roles Based on Their Responsibilities Related to Cooperative Design on an Application • SWEs Should Only See Those Portions of the Application That They Need to See or That They Will Be Responsible for Implementing • End-users Must Be Limited in Their Interactions and Access Depending on Their Roles

  44. Examples of Why RBAC is Needed • In HTSS, the public interface for Items has methods that read (for Scanner, I-Controller) and modify instances (only for I-Controller) • Read Methods Targeted for Certain System Functions (e.g., Scan Item) • Update Methods Targeted for Others (e.g., as Item is Scanned, Decrement Inventory Amount) • In HCA, different health care professionals (e.g., Nurses vs. Physicians vs. Administrators, etc.) require select access to sensitive patient data • Physician’s Write Scripts • Nurses Enter Patient Data (Vitals + History) • All Access Shared Medical Record • Access is Limited Based on Role

  45. RBAC for OO public class PatientRecord { private: Data/Methods as Needed; public: write_medical_history(); write_prescription(); get_medical_history(); get_diagnosis(); set_payment_mode(); etc… For MDs Only For MDs and Nurses For Admitting • Public Interface is Union of All Privileges for All Potential Users No Explicit way to Prohibit Access • Customizable Public Interface of Class • Access to Public Interface is Variable and Based on User Needs and Responsibilities • Only Give Exactly What’s Needed and No More

  46. Sample RBAC Hierarchy for HCA Users Medical_Staff Support_Staff Etc. Nurse Physcian Technician UR:Lab UR:Pharmacy UR:Radiology UR:Private UR:Attending UR:Education UR:Staff_RN UR:Director UR:Discharge_Plng UR:Manager

  47. Sample RBAC Hierarchy for University Users / \ +---+ +-----+ / \ non-academic-staff academic-staff / \ \ / \ \.... / \ \ / \ purchasing campus-police ... dept-staff registrar-staff ... / \ ... ... / \ grade-recording transcript-issuing

  48. Sample RBAC Hierarchy for Portal Users Medical_Staff Patients Etc. Clinical Researcher Basic User Provider UR: Nurse UR: OccTher UR: Physician UR: etc… UR: ForumLeader UR: BasicPHR UR: DataAnalyst UR: EdMaterials UR: Poster

  49. NIST RBAC Standard • http://csrc.nist.gov/groups/SNS/rbac/ • Formalized in 1992 (Ferraiolo and Kuhn) • Based on Work by Sandhu, et al. • Lot’s of Health Care Related Case Studies:http://csrc.nist.gov/groups/SNS/rbac/case_studies.html • Please Visit the Site … • May be Applicable Applications …. • Briefly, Let’s Review …

  50. RBAC Model Variants • http://csrc.nist.gov/groups/SNS/rbac/documents/towards-std.pdf • Transition from Essential Features to Complex Model

More Related