Security Concepts and Capabilities

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 • Middleware Security • 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