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 • 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. MLS in HL7 • Part of the Vocabulary of HL7, Specifically in the Definition of Confidentiality Labels: • L – low, M – moderate, N – normal, R – restricted, V – very restricted, U – unrestricted • HL7 Version 3 - Value sets using code system: Confidentiality • http://www.hl7.org/documentcenter/public_temp_5969D197-1C23-BA17-0C1ADD88E2E4CEBD/standards/vocabulary/vocabulary_tables/infrastructure/vocabulary/vs_Confidentiality.html • http://www.hl7.org/documentcenter/public_temp_F7525D5D-1C23-BA17-0C9A9B2F4EEFA395/standards/vocabulary/vocabulary_tables/infrastructure/vocabulary/Confidentiality.html#L • Access Control for Document Using HL7 Identifies Issues Related to PHI • Guide to the HL7 Health care Privacy and Security Classification System (HCS) May 2013 HL7 Informative Guidance Release 2 • https://www.hl7.org/documentcenter/public_temp_57724ED9-1C23-BA17-0CB16856B7F6E33F/wg/secure/3.%20HCS%20Guide%20Final%202013%200322%20JMD.pdf

40. Confidentially

41. Health Classification System – Policy Considerations • Unmasked PHI (meaning PHI that makes patient data visible) is allowed to be utilized by • clinical decision support system of a HIT • or some other system (e.g., drug-drug interaction checking in a EMR) • Objective: inform a non-authorized stakeholder that a patient may be in danger of an interaction or adverse event. • In certain situations, defined security policies that exist related to a patient’s PHI can be automatically overridden • Accomplished through a process termed Security policies “break the glass access” which could be utilized in an emergent situation • Ex. scene of an accident on in an ER).

42. Health Classification System – Policy Considerations • If patients own of their medical/health/fitness data, then in some situations, patients can allow medical providers to access masked PHI. • This permission when given is termed a “shared secret” • Essentially shares a patient’s decryption key with their permission. • Careful balance between masking & redacting. • Releasing masked PHI allows a medical provider to see all of the information in order to make an informed decision regarding a patient’s care with all available information. • Redaction has one main problem, the removal of information (e.g., a medication allergy) that could not only impact patient care in an emergent situation, but may also be never recoverable.

43. Health Classification System (HCS) in HL7 • An EHR is Capable of: • Disaggregating health information into clinical data elements, which are the most granular level of clinically relevant information, • Retrieving clinical attributes about • the patient, clinical information category • provenance such as information source and encoding clinical vocabulary, • Applying clinical attributes as metadata tags on clinical data elements to generate clinical facts in accordance with clinical rules.

44. Health Classification System in HL7 • Notes: • Clinical facts have no intrinsic security or privacy value. • The sensitivity of a clinical fact is determined by matching clinical attributes with the criteria for governance under privacy policies, including patient consent directives. • Security labels can convey the relative risk associated with disclosure of clinical information based upon standardized security and privacy vocabularies applied to a HCS • Nothing in the application of sensitivity labels prevents the appropriate disclosure of information affecting patient safety.

45. Access Control Model • Uses Classifications and Clearances as Discussed • For example, if the clinical fact is tagged with security label field values for sensitivity = HIV, then access is permitted only if the user possesses a security clearance that includes the corresponding HIV clearance

46. Applying Clinical and Security Labels • Security policy/privacy Rules dynamic and depend on the Clinical Facts and Factors such as: • patient consent directives • purpose of use of the information • environmental constraints • the identity and roles of the requestor • various policies for use and re-disclosure of the information by the recipient Cannot be known or predicted in advance • Cannot be known or predicted in advance

47. Applying Clinical and Security Labels • Issues to be Addressed include: • Maintaining static tagging of security and privacy labels for individual clinical facts may be problematic, inefficient or impossible • Tags and rules for any particular access present variability that cannot generally be assessed until runtime • Security and privacy tagging is best done at runtime when access control variables are avaialbe that tell • whom, why, where, and what type of information are known and can be resolved

48. Applying Clinical and Security Labels • Issues to be Addressed include: • Security and privacy tagging is applied to the aggregated EHR response to a query for information based • upon rules, policies, and obligations in effect at the time of release, • Preservation of the tagging, handling caveats (including obligations), and information provenance becomes the responsibility of the recipient if subsequent reuse or disclosure to additional parties is contemplated • Security labels allow for the management and enforcement of inter-enterprise privacy policies

49. Proposed Work Defines Classifications • Three categories are: • Normal (N), Restricted (R), and Very Restricted (VR) • Sub-categories in the figure

50. Interpreting Sub-Categories • Two Step Authorization Process • Authorize to a Category • Identify Which Sub-categories Can be Assigned • For N – there is no second Step – User Limited to N • For R • User can be Authorized to A, B, and/or AB • User can access all Data Items in N • For VR • User can be Authorized to C, AC, BC, and/or ABC • User can access all Data Items in N and R