Security Concepts and Capabilities CSE 4095 5810 Prof.

Security Concepts and Capabilities CSE 4095 5810 Prof.

Security Concepts and Capabilities CSE 4095 5810 Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-1155 Storrs, CT 06269-1155 [email protected] http://www.engr.uconn.edu/~steve (860) 486 - 4818 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. Security_BG-1 Motivation: Recall Project Architecture Providers

Patients EMR CSE 4095 5810 Where areWeb-Based the Security + HL7) Issues Portal(XML and Concerns? Open Source DB (XML or MySQL) Consider Components of Architecture Feedback Repository Clinical Researchers Education Materials

Security_BG-2 Motivation: Security Issues? Patients CSE 4095 5810 Patient GUI Providers for RN vs. MD FHIR https https html Web Server Encryption Firewall Appl Server Web - Control Services Clinical

Researchers Appl. Control Methods Encryption Secure Communication Web Content DB Server Encryption GUI Look and Feel Security_BG-3 Overview CSE 4095 5810

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 Security_BG-4 Motivation: General Concepts CSE 4095 5810

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 Security_BG-5 Motivation: Type of Security Issues CSE 4095 5810

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 Security_BG-6 Glossary of Protection and Security Terms CSE 4095 5810

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. Security_BG-7 Glossary of Protection and Security Terms CSE 4095 5810

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 Security_BG-8 Glossary of Protection and Security Terms CSE 4095 5810

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.) Security_BG-9 Glossary of Protection and Security Terms CSE 4095 5810

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 Security_BG-10 Glossary of Protection and Security Terms CSE 4095 5810 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 Security_BG-11 Glossary of Protection and Security Terms CSE 4095 5810

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 Security_BG-12 Glossary of Protection and Security Terms CSE 4095 5810

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 Security_BG-13 Policy & Mechanism CSE 4095 5810

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 Security_BG-14 Authentication CSE 4095 5810 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 Cant? DB Authentication Uncontrolled Access (Select, Modify, etc.) Can be Limited (Authorized) requiring Authentication Security_BG-15 Authorization CSE 4095 5810

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? Security_BG-16 User Authentication

CSE 4095 5810 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 EMRs Treating Accident Victim? Past Invasion of Engineering Computing yppasswd File Stolen/Decrypted S. Demurjians Sun Workstation Corrupted Security_BG-17 Network Authentication

CSE 4095 5810 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 Security_BG-18 Core Security Capabilities of Java

CSE 4095 5810 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 Security_BG-19 Core Security Capabilities of Java

CSE 4095 5810 Class Loader - Only Load Correct Classes Bytecode Verifier - Classes in Correct Format Both Dont care Where the Code is from (compiled from Java or another PL just is it correct) Security Manager - Untrusted Classes Cant 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 Security_BG-20

Recall Java Bytecode Verification: CSE 4095 5810 Security_BG-21 Digital Signatures and JAR Files CSE 4095 5810 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 Security_BG-22 Available Access Control Approaches CSE 4095 5810 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 Security_BG-23 What are Key Access Control Concepts? CSE 4095 5810 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 Security_BG-24 Mandatory Access Control CSE 4095 5810 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 Security_BG-25 Mandatory Security Mechanism CSE 4095 5810 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 Security_BG-26 Operations CSE 4095 5810

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 Security_BG-27 Mandatory Security Mechanism CSE 4095 5810 Restriction (Axiom 1): No Subject S Can Read an Object O if the Objects

Security Classification is Higher Than the Subjects Security Clearance S Can Read O iff Clearance(S) Classification(O) No Subject May Write an Object that has Lower Security Class than the Subjects 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 of Clearance Dominating Classification Security_BG-28 Other Axioms CSE 4095 5810

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 Security_BG-29 Mandatory Security Mechanism CSE 4095 5810

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 Objects Security Classification is Higher Than the Subjects 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 TS S User (S) C U Read Down Security_BG-30 Mandatory Security Mechanism CSE

4095 5810 Simple Integrity Property (Write DownNo Write Up) A Subject May Write an Object only if that Object is at or Below the Subjects 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! TS S User (S) C U Write Down Security_BG-31

Mandatory Security Mechanism CSE 4095 5810 Liberal * Property (Write UpNo Write Down) No Subject May Write an Object that has Lower Security Class than the Subjects 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 TS S C

U Write Up User (S) Security_BG-32 Mandatory Security Mechanism CSE 4095 5810 Strict * Property (Read/Write Equal) A Subject May Only Read/Write an Object that has the Exact Same Security Class than the Subjects Security Clearance S Can Read/Write O iff Clearance(S) = Classification(O) This Limits Information Flow to within a Level TS S C U

Read Equal Write Equal User (S) Security_BG-33 Using the Properties CSE 4095 5810 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 Security_BG-34

A Classic Example CSE 4095 5810 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 User (S) TS S Read Down C

U Write Up Security_BG-35 Other Axioms CSE 4095 5810 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: 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 Security_BG-36 Illustrating MAC CSE 4095 5810 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 Security_BG-37 Illustrating MAC CSE

4095 5810 Whenever a User Attempts to Access a Table, the Table is Filtered According to Us Clearance First Set are for a User at Confidential Level Second Set is For a User at Unclassified Level Security_BG-38 Lattice-based Access Control (LBAC) CSE 4095 5810 Parent of MAC Work of Denning (Denning, 1976) on LBAC defines set of security classes SC (analogous to security classifications) organized into a universally bounded lattice defines a partial order across the set SC Security_BG-39

Lattice-based Access Control (LBAC) CSE 4095 5810 Work of Sandhu (Sandhu, 1993) enhanced Denning (a) showing a simple high/low levels; Figure 3 (b) has intermediate set of levels the flow can go from L to H thru one of those levels (c) the classic MLS/military case of a linear lattice (d) A is employee information, B is medical information with the lowest level null, the first level is either A or B, with the combined information {A, B} at the top level (e) A, B, and C are employee, medical, and educational information, where A and B have two upper bounds {A,B} and {A,B,C} with {A,B} least upper bound Security_BG-40 Lattice-based Access Control (LBAC)

CSE 4095 5810 A more complex version of (e) (f) fails as a lattice since missing low and high levels and the upper bounds of A and B are incompatible lattice in (g) solves these problems (f) (g) Security_BG-41 Lattice Suitable for Healthcare CSE 4095 5810

Product lattice combines ordered security levels (i.e., TS, S, C, U) with 8 different categories of data (A, K, L, Q, W, X, Y, Z) A user would be assigned a given level and Associated category There may be different categories at different levels S has only W, L, and A categories combined into S-LW TS has all 8 categories combined in different ways up through the lattice. Security_BG-42 Proposed set of Levels for Healthcare CSE 4095

5810 Security_BG-43 Proposed levels for healthcare lattice CSE 4095 5810 Basic Information contains data that is freely available to anyone: Basic demographic city and state of residence and surveillance data (0-DM) General health condition (0-C) Fitness data (0-FT) such as date, time, type, and duration of activity, etc. Security_BG-44 Proposed levels for healthcare lattice CSE 4095 5810

Medical History Data contains data that has some restrictions: Detailed demographic data as patient name, address, day/month of birth, weight, height, next of kin, medical record ID of the patient, surveillance data (1-DM) Sensitive patient-collected fitness data; history of the patient and his/her family, immunizations (1-MHx, 1-FHx, 1-IM respectively) Separate mental health history of the patient (1-MH-Hx) Security_BG-45 Proposed levels for healthcare lattice CSE 4095 5810 Summary Clinical Data contains clinical data including Prescription (2-Rx) and OTC medications (2-OTC), allergies (2-ALL) Medical diagnoses and problem list that includes the provider name and ID and surveillance data (2-Dx) Plan for treatment or other related instructions (2-PL),

For mental health, separate medical diagnoses Problem list (2-MH-Dx) and plan for treatment or other related instructions (2-MH-PL) Security_BG-46 Proposed levels for healthcare lattice CSE 4095 5810 Detailed Clinical Data contains Reports on imaging studies (CT Scans, MRIs, X-Rays, etc.) (3-RP) images from the studies (3-IM) Detailed info on a medical visit (encounter notes, 3-EN), Laboratory tests ordered, dates, results, surveillance data (3-LB) Info on mental health encounters (no psychotherapy notes) (3-MH-EN) and surveillance data (3-SR) Clinical data (e.g., heart rate, blood oxygen level, blood pressure, etc.) from fitness devices (3-FT) Security_BG-47 Proposed levels for healthcare lattice

CSE 4095 5810 Sensitive Clinical Data sensitive information on a patient that is used by medical specialists including Data on genetics (4-G), substance abuse (4-SA) Mental health psychotherapy notes (4-MH) Reproductive health (4-RH), and domestic violence (4-DV) Security_BG-48 Proposed set of Levels for Healthcare CSE 4095 5810 SR surviellenc e Security_BG-49 One Possible Lattice CSE

4095 5810 Level 4: 1-FT 1-DM 1-MHx 1-FHx 1-IM 1-MH-Hx; 2-Rx 2-OTC 2-ALL 2-Dx 2-PL 2-MH-Dx 2-MH-PL; 3-RP 3-IM 3-EN 3-LB 3-FT 3-SR; 4-SA 4-G 4-MH 4-RH 4-DV 4-MH-RH-DV 4-G 4-SA 4-MH 4-RH 4-DV Level 4 3-RP-IM 3-RP 2-Rx-OTC 2-Rx 3-EN 3-LB

3-IM 3-FT 3-MH-EN 3-SR 2-ALL-Dx-PL Level 3 2-OTC 2-ALL 2-Dx 2-MH-Dx 2-PL 2-MH-PL 1-FT-DM 1-MHx-FHx-IM Level 2

1-DM 1-MHx 1-FHx 1-IM 1-MH-Hx 1-FT Level 1 Level 0 0-FT 0-DM 0-C Security_BG-50 Explaining the Lattice: Levels 0 and 1 CSE 4095 5810

All information in level 0 is public and freely available. Administrative users (office staff) would have access to All level 0 Subset oflevel 1: 1-FT, 1-DM, 1-MHx, 1-FHx, 1IM Security_BG-51 Explaining the Lattice: Level 2 CSE 4095 5810 Stakeholders that are clinical staff (RN, LPN, etc.) for a given patient would have access to All levels 0 and 1 Subset of level 2: 2-Rx, 2-OTC, 2-ALL, 2-Dx & 2PL Security_BG-52 Explaining the Lattice: Level 3 CSE

4095 5810 Stakeholders that are part of the medical provider team (MDs) for a given patient, would have access to All of levels 0, 1, and 2 Subset of level 3: 3-RP, 3-IM, 3-EN, 3-LB, 3-FT, and 3-SR Security_BG-53 Explaining the Lattice: Level 4 CSE 4095 5810 A specialist medical provider would have one or more of: 4-SA, 4-G, 4-MH, 4-RH, and 4-DV. In this last category, specific information filtered by specialist: Protect mental health information: Eliminate 4-MH Protect HIV information: Eliminate 4-RH Protect Genetic information: Eliminate 4-G Protect Substance Abuse information: Eliminate 4-SA

Security_BG-54 Summary Interpreting the Lattice CSE 4095 5810 All information in level 0 is public and freely available. Administrative users (office staff) would have access to all level 0 & level 1 including 1-FT, 1-DM, 1-MHx, 1-FHx, 1-IM Stakeholders that are clinical staff (RN, LPN, etc.) for a given patient would have access to levels 0 and 1, as well as 2-Rx, 2OTC, 2-ALL, 2-Dx, and 2-PL. Stakeholders that are part of the medical provider team (MDs) for a given patient, would have access to levels 0, 1, and 2, as well as 3-RP, 3-IM, 3-EN, 3-LB, 3-FT, and 3-SR. A specialist medical provider would have one or more of: 4-SA,

4-G, 4-MH, 4-RH, and 4-DV. In this last category, specific information filtered by specialist: Protect mental health information: Eliminate 4-MH Protect HIV information: Eliminate 4-RH Protect Genetic information: Eliminate 4-G Protect Substance Abuse information: Eliminate 4-SA Security_BG-55 Interpreting the Lattice CSE 4095 5810 The different mental health information categories that exist from Level 1 to 4 This provides the ability to tailor access to sensitive mental health information for different stakeholders. A psychiatrist would have access to all mental health categories: 1-MH-Hx

2-MH-Dx 2-MH-PL 3-MH-EN 4-MH This subdivision allows some of the mental health information on lower levels to be available to stakeholders that need access to lower level mental health such as 1-MH-Hx and 2-MH-Dx but would be not be allowed access to other levels Security_BG-56 Disease Surveillance Scenario CSE 4095 5810 Collection of emergency room and other data on patients Data collected on reportable diseases or conditions Collected for local, State and Federal public health agencies This is called disease surveillance

This information is used for disease surveillance of influenza, tick-borne diseases, etc. Allows public health officials and epidemiologists to track incidence, prevalence, and trends Of diseases Contained in 3-LB of Lattice TEST/24, RSLT/25 Contained in 3-SR of Lattice: RDAT/1, RNAM/2, RCON/3, FAC/7, FADR/8, FSTAT/9 Contained in 2Dx of Lattice PROV/4, PTYP/5, PRID/6, ODAT/22, COND/23 Contained in 1-DM of Lattice NAM/10, PADR/12, MDOB/17, MRN/19, KINM/20, KINP/21 Contained in 0-DM of Lattice PSTAT/11, PZIP/13, SEX/14, RACE/15, YOB/16, ETHN/18 General public would have access to 0-DM Local Health Department would have access to all data categories CDC & State Health Department would have access to 0-DM, and surveillance data in 2-Dx, 3-SR, and 3-LB (but not 1-DM) Security_BG-57

CSE 4095 5810 Description Name Level Value 1. Date of report RDAT 0 day/month/year 2. Name of reporter RNAM 2 [First name, Middle Name, Last Name] 3. Reporter Contact info RCON 2 [Address & Phone] 4. Care provider PROV 2 [First name, Middle Name, Last Name] 5. Care provider type PTYP 2 [physician/nurse/other] 6. Care provider ID PRID 2 [National Provider ID] 7. Care Facility FAC 2 [Facility name]

8. Facility Contact FADR 2 [Facility address & phone] 9. Facility State FSTAT 0 [two letter state code] 10. Patient Name NAM 3 [First name, Middle Name, Last Name] 11. Patient State PSTAT 0 [two letter state code] 12. Patient Address PADR 2 [Street, City] 13. Patient Zip PZIP 1 [Zip code 5 digit] 14. Patient Gender SEX 1 [code] 15. Patient Race RACE 1 [code] 16. Year of Birth YOB 0 [year] 17. Month, Day of Birth MDOB 3 [month, day] 18. Patient Ethnicity

ETHN 1 [code] 19. Patient Record Number MRN 3 [alphanumeric, variable length] 20. Next of Kin Name KINM 3 [First name, Middle Name, Last Name] 21. Next of Kin Phone KINP 3 [phone number] 22. Date of onset ODAT 0 day/month/year 23. Condition COND 0 [disease code ICD-10] 24. Test ordered TEST 1 [LOINC code] 25. Test result RSLT 1 [text] Security_BG-58 Medical Fitness Scenario CSE 4095 5810

Data obtained from the patient usingfitness or medical device, such as a glucose meter, pulse oximeter, or heart monitor. Devices collect data and communicate via a mobile device so that it can be inserted into the EHR of Fitness date on next slide are mapped as follows into the categories of the lattice : Contained in 3-FT lattice - Detailed Clinical Data Contained in 1-FT lattice - Basic Demographic Data Contained in 0-FT lattice - Basic Information From a stakeholder perspective, the general public would have access to the category 0-FT, health researchers would have access to the category 1-FT health researchers with special permission would have access to the category 3-FT Security_BG-59 CSE 4095

5810 Description Name Level Value 1. Date DAT 0 date 2. Time start STIM 0 time 3. Time end (optional) ETIM 0 time 4. Type of activity TYP 0 code 5. Intensity of activity LEV 0 code 6. Duration of activity DUR 0 time interval 7. Heart rate HR 1 number

8. GPS location GPS 3 GPS coordinates 9. Blood oxygen level O2 1 percent saturation 10. Steps taken STEP 0 number 11. Distance traveled DIST 0 distance 12. Light level LITE 1 number 13. Person name NAM 3 name 14. Person address ADDR 3 address 15. Person City CITY 2 city 16. Person State STAT 0 2-digit state code

17. Person Zip code ZIP 2 zip code (5 digit) 18. Home GPS location HGPS 3 GPS coordinates 19. Device used DEV 1 code 20. Data entry type ENT 0 code (measured vs. entered) 21. Person weight WT 3 number 22. Person height HT 3 weight 23. Person gender SEX 1 height 24. Person YOB YOB 1 year 25. Systolic blood pressure SBP 2 number

26. Diastolic blood pressure DBP 1 number Security_BG-60 Medical Provider Office Staff Scenario CSE 4095 5810 This scenario involves using the lattice to control access to information by office staff Limited to select categories of Lattice in Levels 0 and 1. Office staff would have access to All basic information in Level 0: demographics (0-DM), general health condition (0-C), and fitness (0-FT). Level 1 access would be restricted to 1-DM for: detailed demographic data on the patient name, address, day/month of birth, weight, height, next of kin, medical record ID, any patient-collected fitness data, etc.

A new point could be created in the lattice of Figure 9 for Office Staff that contains: 0-FT-DM-C/1-DM Security_BG-61 Medical Provider Scenario CSE 4095 5810 A medical provider (e.g., physician, nurse practitioner, nurse, etc.) Access to all non-mental health categories in Levels 0 through 3 in Lattice 0-FT, 0-DM, 0-C 1-FT, 1-DM, 1-MHx, 1-FHx, 1-IM 2-Rx, 2-OTC, 2-ALL, 2-Dx, 2-PL 3-RP, 3-IM, 3-EN, 3-LB, 3-FT Medical specialists in genetics, substance abuse, reproductive health, or domestic violence have access to all, supplemented

by 4-G, 4-SA, 4-RH, or 4-DV category, respectively Security_BG-62 Mental Health Scenario CSE 4095 5810 Mental health provider needs to send data to non-mental health medical provider Information stored on a patient would have different sensitivity levels. Data for a patient may range from Level 4-MH (e.g., the psychotherapy notes) Level 3-MH-EN mental health encounter summaries) Level 2-MH-Rx (mental health medications) and mental health diagnoses (2-MH-Dx)/plan (2-MH-PL) Level 1 all categories (e.g., non-demographic health information such as age, weight, height, vital signs,

medications for other conditions, non-mental health conditions, etc.) Level 0 all categories (e.g., demographic and identification) Transmitting this needs careful consideration Security_BG-63 MLS in HL7 CSE 4095 5810 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-BA170C1ADD88E2E4CEBD/standards/vocabulary/vocabulary_tables/

infrastructure/vocabulary/vs_Confidentiality.html http://www.hl7.org/documentcenter/public_temp_F7525D5D-1C23-BA170C9A9B2F4EEFA395/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-BA170CB16856B7F6E33F/wg/secure/3.%20HCS%20Guide%20Final %202013%200322%20JMD.pdf Security_BG-64 Confidentially U unrestricted This indicates that the information is not classified as sensitive. CSE 4095 L low 5810 M moderate Examples: I ncludes publicly available information, e.g., business name, phone, email or physical address.

The information requires protection to maintain low sensitivity. Examples: I ncludes anonymized, pseudonymized, or non-personally identifiable information such as HI PAA limited data sets. Low information might need to be accessed by a wide range of administrative staffto manage the subject of care's access to health services. This is moderately sensitive information, which presents moderate risk of harm if disclosed without authorization. Examples: I ncludes allergies of non-sensitive nature used inform food service; health information a patient authorizes to be used for marketing, released to a bank for a health credit card or savings account; or information in personal health record systems that are not governed under health privacy laws. Less sensitive information might need to be accessed by a wider range of personnel not all of whom are actively caring for the patient (e.g. radiology staff) . N normal This information is typical, non-stigmatizing health information, which presents typical risk of harm if disclosed without authorization. Examples: I n the US, this includes what HI PAA identifies as the minimum necessary protected health information (PHI ) given a covered purpose of use (treatment, payment, or operations). I ncludes typical, non-stigmatizing health information disclosed in an application for health, workers compensation, disability, or life insurance. Default for normal clinical care access (i.e. most clinical staffdirectly caring for the patient should be able to access nearly all of the EHR). Maps to normal confidentiality for trea tment information but not to ancillary care, payment and operations. R restricted This is highly sensitive, potentially stigmatizing information, which presents a high risk to the information subject if disclosed without authorization. Examples: I n the US, this includes what HI PAA identifies as the minimum necessary protected health information (PHI ) given a covered purpose of use (treatment, payment, or operations). I ncludes typical, non-stigmatizing health information

disclosed in an application for health, workers compensation, disability, or life insurance. Default for normal clinical care access (i.e. most clinical staffdirectly caring for the patient should be able to access nearly all of the EHR). V very restricted This information is extremely sensitive and likely stigmatizing health information that presents a very high risk if disclosed without authorization. This information must be kept in the highest confidence. Examples: I ncludes information about a victim of abuse, patient requested information sensitivity, and taboo subjects relating to health status that must be discussed with the patient by an attending provider before sharing with the patient. May also include information held under legal lock or attorney-client privilege. May not disclose this information except as directed by the information custodian, who may be the information subject. Security_BG-65 Health Classification System Policy Considerations CSE 4095 5810 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 patients 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). Security_BG-66 Health Classification System Policy Considerations CSE 4095 5810 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 patients 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 patients 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. Security_BG-67 Health Classification System (HCS) in HL7 CSE 4095 5810 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. Security_BG-68 Health Classification System in HL7 CSE 4095 5810 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. Security_BG-69 Access Control Model CSE 4095 5810 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 Security_BG-70 Applying Clinical and Security Labels CSE 4095 5810 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 Security_BG-71 Applying Clinical and Security Labels

CSE 4095 5810 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 Security_BG-72 Applying Clinical and Security Labels CSE 4095 5810

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 Security_BG-73 Proposed Work Defines Classifications CSE 4095 5810

Three categories are: Normal (N), Restricted (R), and Very Restricted (VR) Sub-categories in the figure Security_BG-74 Interpreting Sub-Categories CSE 4095 5810 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 Security_BG-75 Interpreting Sub-Categories CSE 4095 5810 Essentially a lattice is formed with: N < R < VR N is its own sensitivity level R has three sensitivity levels (A, B, and AB) VR has four sensitivity levels (C, AB, BC, ABC) Each Clinical Fact/Portion of a Patients PHI will be Assigned N, R.A, R.B, R.AB, VR.C, VR.AB, VR.BC or VR.ABC Is this Versatile Enough? Does PHI need finer grained Sensitivities? Security_BG-76

Recall Data Items from Paper CSE 4095 5810 Are 8 Levels of Sensitivity Enough to Classify Data and Make Available to Diverse set of Stakeholders? Recipient Primary physicians (current) Mental health providers Pharmacists Government agencies Health insurance companies Specialized physicians involved in care Nurses and assistant medical staff Alternative-medicine therapists Administrative personnel Researchers Home-care and rehabilitation providers Physician (not treating you) Family and close social network Emergency medicine providers Description

Generalists Psychiatrists or counselors (Intentionally blank) State health department, court system (Intentionally blank) Cardiologist, endocrinologist, allergist (Intentionally blank) Acupuncture, massage, herbal therapy Front desk, scheduling, billing Education, medical or pharmaceutical Nursing care, physical/occupational therapists (Intentionally blank) Spouse, close family members or friends Emergency care physicians, paramedics Data Item Contact information and demographics Information relevant to current condition Medications Recent test results Past medical history (unrelated) History of substance abuse* Mental health information* Sexual health information* Records relating to domestic violence* Reproductive health records*

Genetic information* Description Address, telephone number, race Illness, symptoms, hospitalization Prescribed and over-the-counter medicines Pulse, blood pressure, weight, height Previous injuries or illnesses Records of drug or alcohol abuse, treatment Psychiatric diagnosis, suicide attempts STDs including HIV, sexual orientation Fear of partner, suspicious physical injury Infertility, abortions or miscarriages, adoption Paternity testing, genetic tests Security_BG-77 HCS Operational Model CSE 4095 5810 Security_BG-78 Manage Information at Multiple Levels CSE 4095

5810 Security_BG-79 Applying Clinical Labels CSE 4095 5810 Establishes clinical vocabularies to be used for tagging Defines rules for tagging clinical elements Provisions Clinical Label Services Retrieves clinical elements and their clinical attributes Tags Creates clinical facts by application of clinical attributes (standard metadata) to clinical elements by a clinical rule Stores clinical facts in EHR repository. Security_BG-80

Access Control at Runtime CSE 4095 5810 ACS must establish that the request itself and requestors attributes meets acceptance parameter If not, the query is rejected and an appropriate negative response returned Following this first pass, the request is forwarded to the EHR which returns the initial response to Security Labeling Service labels the EHR response content applies masking/redaction and obligation rules Security_BG-81 eXtensible Access Control Markup Language CSE 4095 5810

XACML schema Provides Several Structures and Elements to Represent Policies PolicySet, Policy, Rule PolicySets and Rules Combined by Policy/Rule Combination Algorithm Permit-overrides Deny-overrides First-applicable Only-one-applicable PolicySet Policy Combination Algorithm Policy Rule Combination Algorithm Rule Resource Subject Action

Security_BG-82 Security Labeling via NIST Standards CSE 4095 5810 Security_BG-83 Labeling Clinical Facts Consider Data CSE 4095 5810 Security_BG-84 Apply Security Labels CSE 4095 5810 Security_BG-85 Sample Labels CSE

4095 5810 Security_BG-86 Security in Software Applications CSE 4095 5810 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 Whats Needed and No More Please see: www.engr.uconn.edu/~steve/DSEC/desc.html Security_BG-87 What is Role Based Access Control (RBAC)? CSE 4095 5810 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

Security_BG-88 NIST RBAC Standard CSE 4095 5810 http://csrc.nist.gov/groups/SNS/rbac/ Formalized in 1992 (Ferraiolo and Kuhn) Based on Work by Sandhu, et al. Lots 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, Lets Review Security_BG-89

RBAC Model Variants CSE 4095 5810 http://csrc.nist.gov/groups/SNS/rbac/documents/towardsstd.pdf Transition from Essential Features to Complex Model Security_BG-90 Level 1 and Level 2 CSE 4095 5810 Level 1: Three States and UA/PA Level 2: Add in Role Hierarchy Look on R State

Security_BG-91 Example Role Hierarchies CSE 4095 5810 Security_BG-92 Level 3 and Level 4 CSE 4095 5810 Level 3: Constrained RBAC with Separation of Duty Constraints (SOD) Level 4: Sessions of Users and Roles Security_BG-93 Constrained RBAC with SOD CSE 4095

5810 Security_BG-94 Motivating Security for OO Paradigm CSE 4095 5810 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? Security_BG-95 Why is RBAC Needed? CSE 4095 5810 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 Security_BG-96

Why is RBAC Needed? CSE 4095 5810 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 Security_BG-97 Examples of Why RBAC is Needed CSE

4095 5810 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 Physicians Write Scripts Nurses Enter Patient Data (Vitals + History) All Access Shared Medical Record Access is Limited Based on Role Security_BG-98 RBAC for OO CSE 4095 5810

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 Whats Needed and No More public class PatientRecord { private: Data/Methods as Needed; public: write_medical_history(); write_prescription(); For MDs get_medical_history(); and Nurses get_diagnosis(); set_payment_mode(); etc For MDs Only For Admitting

Security_BG-99 Sample RBAC Hierarchy for HCA CSE 4095 5810 Users Medical_Staff Support_Staff Etc. Nurse Physcian Technician UR:Lab UR:Pharmacy UR:Radiology UR:Staff_RN UR:Education

UR:Private UR:Attending UR:Director UR:Manager UR:Discharge_Plng Security_BG-100 Sample RBAC Hierarchy for University CSE 4095 5810 Users / \ +---+ +-----+ / \ non-academic-staff academic-staff / \

\ / \ \.... / \ \ / \ purchasing campus-police ... dept-staff registrar-staff ... / \ ... ... / \ grade-recording transcript-issuing Security_BG-101 Sample RBAC Hierarchy for Portal CSE

4095 5810 Users Medical_Staff Patients Etc. Clinical Researcher Basic User Provider UR: Nurse UR: OccTher UR: Physician UR: etc UR: ForumLeader UR: BasicPHR UR: Poster UR: DataAnalyst

UR: EdMaterials Security_BG-102 Discretionary Access Control CSE 4095 5810 Discretionary Grant Privileges to Users, Including the Capabilities to Access Specific Data Items in a Specific Mode Available in Most Commercial DBMSs Aspects of DAC Users Identity Predefined Discretionary Rules Defined by the

Security Administrator Focus on Two Variants of this Model Access Matrix Model Lampsons Protection System Role Delegation and Delegation Authority Detail DAC in SQL2 Security_BG-103 What is Role Delegation? CSE 4095 5810 Role Delegation, a User-to-User Relationship, Allows an Original User (OU) to Transfer Responsibility for a Particular Role to a Delegated User (DU) Two Major Types of Delegation Administratively-directed Delegation has an Administrative Infrastructure Outside the Direct Control of a User Mediates Delegation

User-directed Delegation has an User (Playing a Role) Determining If and When to Delegate a Role to Another User In Both, Security Administrators Still Oversee Who Can Do What When w.r.t. Delegation Delegation Vital in Health Care: Provider on-Call, Emergent Situations, DCP Security_BG-104 Why is Role Delegation Important? CSE 4095 5810 Many Different Scenarios Under Which Privileges May Want to be Passed to Other Individuals Large organizations often require delegation to meet demands on individuals in specific roles for certain periods of time True in Many Different Sectors

Health Care Financial Services Engineering Academic Setting Key Issues: Who Controls Delegation to Whom? How are Delegation Requirements Enforced? Security_BG-105 What Can be Delegated? CSE 4095 5810 Authority to Do the Task, Carries the Least Responsibility Necessary to Execute the Task, but Does Mean the Delegated User Can Execute the

Delegated Task or Role. Responsibility to Do a Task Implies Accountability and a Vested Interest that a Task or Role Can Be Executed Properly. Duty to Perform a Task Implies that the Delegated User is Obligated to Execute the Given Task. Our Focus: Delegate Authority Only Security_BG-106 Delegation/Pass on Delegation Authorities CSE 4095 5810 When Establishing Privileges (by the Security Officer) there must be the Ability to Define: Delegation Authority (DA) Recall:Security Officer can Delegate a Role to User DA Means that the Security Officer Can Delegate the Authority to Delegate to another User Role Can be Delegated by one User to Another However, Delegation Authority Cannot

Pass-on Delegation Authority (PODA) PODA Augments DA to Allow the Delegation Authority to Also be Delegated as Part of the Delegation of a Role to a User Security_BG-107 Example - Role Delegation CSE 4095 5810 General DoBest Delegates his Role CDR_CR1 (Commander, Crisis 1) to Colonel DoGood with DA, where DoBest, CDR_CR1, and DoGood defined as: OU: [DoBest, [ct, ], T] UR: [CDR_CR1, [01dec00, 01dec01], T] UA: [DoBest, CDR_CR1, [01dec00, 01dec01]] DA: Yes PODA: Yes After Delegation: DU: [DoGood, [01dec00, 01jun01], T] UA: [DoGood, CDR_CR1, [01dec00, 01jun01]]

Security_BG-108 Example - Role Delegation CSE 4095 5810 Now, Colonel DoGood wishes to re-delegate CDR_CR1 to Major CanDoRight, which can be defined as: DU: [DoGood, [01dec00, 01jun01], T] UR: [CDR_CR1, [01dec00, 01dec01], T] UA: [DoGood, CDR_CR1, [01dec00, 01jun01]] DA: Yes PODA: No After Delegation: DU: [CanDoRight, [01jan01, 01feb01], T] UA: [CanDoRight, CDR_CR1, [01dec00, 01jun01]] Security_BG-109 Role Delegation Revocation Rules

CSE 4095 5810 User-to-User Delegation Authority Rule A User (OU or DU) Who is a Current Member of a Delegatable Role (DUR), Can Delegate that User Role to Any User that Meets the Prerequisite Conditions of the Role: DU Receiving the Role is Not a Member of the Role; OU or DU is Identified As Having Delegation Authority for the Role; DU Meets the Mandatory Access Control Constraints (MACC). Security_BG-110 Role Delegation Revocation Rules CSE 4095 5810 Delegation Revocation Authorization Rule:

An Original User Can Revoke Any Delegated User From a User Role in Which the OU Executed the Delegation. This is a Stricter Interpretation than [Zhan01], Which Allows Any OU of a Role Revocation Authority Over a DU in the Delegation Path. In Addition, a Security Administrator Can Revoke Any Delegation. Cascading Revocation Rule: Whenever an OU or DU in the delegation path is revoked, all DUs in the path are revoked. Security_BG-111 Monotonicity and Permanence CSE 4095 5810 Definition: Monotonicity Refers to the State of Control the OU Possesses After Role Delegation Monotonic Delegation Means That the OU Maintains Control of the Delegated Role

Non-monotonic Means That the OU Passes the Control of the Role to DU Definition: Permanence Refers to Delegation in Terms of Time Duration Permanent Delegation is When a DU Permanently Replaces the OU Temporary Delegation Has an Associated Time Limit With Each Role Security_BG-112 Totality and Administration CSE 4095 5810 Definition: Totality Refers to How Completely the Permissions Assigned to the Role Are Delegated Partial Delegation Refers to the Delegation of a Subset of the Permissions of the Role Total Delegation Refers to the Situation All of the Permissions of the Role Are Delegated Definition: Administration Refers to how Delegation will be Administered

User Directed is when the User Controls all Aspects of Delegation Administrator-Directed (Third party, Agentdirected) is when Control is with the Security Officer Security_BG-113 Revocation CSE 4095 5810 Definition: Cascading Revocation Refers to the Indirect Revocation of All DUs When the OU Revokes Delegation or Administration Revokes the OUs Delegated Role Definition: Grant-Dependency Revocation Refers to Who Has Authority to Revoke a DU Grant-Dependent Revocation Only Allow the OU to Revoke the Delegated Role Grant-Independent Revocation Allows Any Original Member of the DUR to Revoke a Delegated Role

Security_BG-114 Database Security Approach CSE 4095 5810 Software Engineers can Write Complex Programs Limited by Intellectual Capabilities DB Designer Must Create Protection Scheme that Cant be Bypassed by Current and Future Software Users and DB Initiators Users have Dedicated and Shared DB Items DB Items Shared by User Groups vs. DB Items Globally Shared Users Spawn Clients that Access DB Items Clients May be Local or Remote (on Another Machine Connected via Network) Protection System of DB Must Support Above According to Organizations Admin. Policy

Security_BG-115 Database Security CSE 4095 5810 Types of Security Database Security is Mainly Related with Access Rights to the Database Database Security Involves Issues Such as Governmental or Corporate Level of Policies Privacy and Confidentiality Requirements For Example - Consider a Medicine Prescription Physician or PA Only One Authorized to Write Drug, Dosage, Refills, Generic vs. Brand, etc. Pharmacist by Law Can Enter Script, Replace Brand with Generic, Alter Refills - Cant Change the Med By Law - Protect the Script per Patient (MD/Insurance) Access Control is Mechanism to Prevent Unauthorized

Access to Databases Security_BG-116 Database Security CSE 4095 5810 Database Administrator (DBA) has the Privileged Commands to Perform the Following on Databases Account Creation Privilege Granting Privilege Revocation Security Level Assignments Elements of the Security Model Subjects (Principals) Objects (Data) Access Methods (How to Use) Policies (Application Dictated) Authorizations (Who Can Do What) Authentication and Enforcement (Runtime) Security_BG-117

DAC in SQL2 CSE 4095 5810 SQL2 Uses the Concept of Authorization Identifier User Group (could be Single User) References a Set of User Accounts DBA Must Provide Selective Access by each User to Every Relation in the DB Based on Account Two Levels of Privilege Assignment Account Level - DBA Manages the Accounts for to Authorize Users to Different DBs Relation/Table Level - Controlling Access to Each Relation or View in a DB Objective Manage and Administer Design/Realize the Security Policy Security_BG-118

Privileges in SQL CSE 4095 5810 Allocated at a Relation Level SELECT Privilege Gives Account Retrieval Access MODIFY Privilege Gives Account Ability to Change the Database Subdivided into Insert, Update, and Delete Insert and Update can be Specialized on Different Attributes of Relation REFERENCES Privilege Gives Account the Ability re. Integrity Constraints Can be Restricted to Certain Attributes of Relation Commands to both GRANT and REVOKE are Supported

Security_BG-119 Example Schema CSE 4095 5810 Consider Two Database Tables: EMPLOYEE (NAME, SNN, BDATE, ADDRESS, SET, SALARY, DNO) DEPARTMENT (D#, DNAME, MGRSNN) Consider Four Accounts/Users: U1, U2, U3 and U4 Limit U1 to be Able to Create Schema In SQL GRANT CREATETAB TO U1;

In SQL2 CREATE SCHEMA EXAMPLE AUTHORIZATION U1; U1 Can Create Tables In Schema EXAMPLE Security_BG-120 SQL Examples CSE 4095 5810 Suppose U1 Wants to Grant U2 the Ability to Insert and Delete into EMPLOYEE and DEPARTMENT U1 Wants to Disallow Ability of U2 to Propagate (Delegate) Insert/Delete to Other Users GRANT INSERT, DELETE ON EMPLOYEE, DEPARTMENT TO U2; Suppose U1 Wants to Grant U3 the Ability to Select from EMPLOYEE and DEPARTMENT U1 Allows U3 to Propagate to Other Users

GRANT SELECT ON EMPLOYEE TO U3 WITH GRANT OPTION; Now, U3 can: GRANT SELECT ON EMPLOYEE TO U4; U4 Cannot Propagate/Delegate this Privilege Security_BG-121 SQL Examples CSE 4095 5810 Suppose U1 Wants to REVOKE U3 the Ability to Select from EMPLOYEE and DEPARTMENT REVOKE SELECT ON EMPLOYEE TO U3; Database Must Also Cascade this Revoke to U4 Since U3 No Longer has the Ability to Grant Cascading Revokes Can be Complicated as Privileges are Defined Consider 100 Users and DB with 20 Tables and Ability to Grant/Revoke Becomes Complex Consequently, Propagation/Delegation are Usually

Only Given Very Carefully Critical to Document Security Policy for Each Application! Security_BG-122 SQL Examples CSE 4095 5810 Suppose that U1 wants to Give Back to U3 a Limited Capability to SELECT from EMPLOYEE Also Allow U3 to be able to Propagate U1 First Creates a View create view U3_EMP as select NAME, BDATE, ADDRESS from EMPLOYEE where DNO = 5;

U1 Now Grants the View GRANT SELECT ON U3_EMP TO U3 WITH GRANT OPTION; U1 Can also Grant Limited Update GRANT UPDATE ON EMPLOYEE (SAL) TO U4; Security_BG-123 Cryptography CSE 4095 5810 Information can be Encoded Using a Key it is Written (or Transferred) -- Encryption Information is then Decoded Using a Key When it is Read (or Received) -- Decryption

Very Widely Used for Secure Network Transmission Mathematical Basis - Prime Number Generation encryption plaintext ciphertext decryption Security_BG-124 More on Cryptography CSE 4095 5810 plaintext plaintext Ke Encrypt Encrypt Side information

Kd C = EKe(plaintext) Invader Invader Decrypt Decrypt plaintext Security_BG-125 Cryptographic Systems CSE 4095 5810 Cryptographic Systems Modern Systems Conventional or Symmetric Systems Ke and Kd Private Key Public Key

are essentially the Ke and Kd Ke is public same are private Kd is private Security_BG-126 Statistical Database Security CSE 4095 5810 Statistical Databases are used to Produce Statistics on Various Populations Individual Information is Considered Confidential Users May be Allowed to Access Statistical Information on the Population, i.e., Applying Statistic Functions to a Population of Tuples Techniques for Protecting Privacy of Individual Information Solutions are Illustrated by Examples: Person(name, ssn, income, address,city,

state, zip, sex, last_degree) Suppose we are Allowed to Retrieve Only the Statistical Information Over this Relation by Using SUM, AVG, MIN, MAX, COUNT, Etc. Vital for Epidemiology and other Clinical Research Security_BG-127 Example of Statistical DB CSE 4095 5810 Consider Q1 and Q2: Q1: find the total number of women who have ph.D. and live in Calgary, Alberta. select COUNT(*) from Person where last_degree = ph.D. and

sex = F and city = Calgary and state = Alberta; Q1: find the average income of women who have ph.D. and live in Calgary, Alberta. select AVG(income) from Person where last_degree = ph.D. and sex = F and city = Calgary and state = Alberta; Suppose Mary Black is a Ph.D who Lives in Calgary and we want to know her Income, which is Prohibited If Query Q1 Returns One Tuple, then the Result of Q2 is the Income of Mary Otherwise we May Issue a Number of Subsequent Queries

Using MAX and MIN, we May Easily Obtain a Close Range of Marys Income Security_BG-128 Example Two of Statistical DB CSE 4095 5810 The Issue is that Even with Statistical DB Limits, it is Possible to Infer and Discern Confidential Info. Suppose the Query Writer (Connie) also Lives in Calgary and has a Ph.D. Consider Q3 (left) and Q4 (right) below: select from where and and and and

SUM(income) Person last_degree = ph.D. sex = F city = Calgary state = Alberta; name <> Mary select from where and and and and SUM(income) Person last_degree = ph.D. sex = F city = Calgary state = Alberta name <> Connie;

Since Connie Knows her Own Income, by Calculating Q4 - (Q3 - Connies Income), She Determinds Marys Income Security_BG-129 Statistical Database Security CSE 4095 5810 Thus, having Just Aggregate Operations Can Allow the Confidentiality of DB to be Breached A Number of Restrictions can be used to Reduce the Possibility of Deducing Individual Information from Statistical Queries: Statistical Queries are not Permitted if the Number of Tuples in the Population Specified by the Selection Condition Falls Below Some Threshold Restricting the Number of Tuples in the Intersection of Subsequent Query Results

Prohibiting Sequences of Queries that Refer Repeatedly to the Same Population of Tuples While these can help - it may Still Possible to Deduce Information and Breach Confidentiality! Security_BG-130 Web Based Security CSE 4095 5810 What are the Issues and Concerns in Web-Based Security? See: http://www.w3.org/Security/Faq/ Partitions Security into: Client Side Security Server Side Security CGI Scripts Protecting Confidential Documents Denial of Service Attacks Well Briefly Review all, but Concentrate on those

Most Apropos to BMI and Associated Web-Based Applications (e.g., Team Project) Security_BG-131 General Web Security Issues CSE 4095 5810 Bugs or Configuration Problems in Web Servers that allow Remote users able to: Steal Confidential Documents, Execute Commands on Servers, Break Into Servers, Launch DoS Browser-Side: Active-X or Applets Can Breach Privacy Misuse of Supplied Personal Info (App Side) Network Eavesdropping: Network on Browser Side

Network on Server Side End User ISP, Server ISP What is the Biggest Concern for BMI? Security_BG-132 General Web Security Issues CSE 4095 5810 Impact of OS on Web Security: Unix and NT Powerful and Full Featured have Many Potential Holes most Vulnerable Special Purpose Web Boxes less Vulnerable Bare-Bones Macintosh least Vulnerable Security of Web Server Software Programs Dependent on Services Offered Simple Server (Static files) Safer than Complex Server (CGI scripts, Server-Side Processing, etc.) All Security Servers have Holes!

Common Gateway Interface (CGI) Scripts are Major Source of Security Problems Issue Traced to Diligence in Writing Code as Opposed to Technology Itself Security_BG-133 General Web Security Issues CSE 4095 5810 General Security Precautions Laundry List Who is allowed to use the system When they are allowed to use it What they are allowed to do (different groups may be granted different levels of access) Procedures for granting access to the system Procedures for revoking access (e.G. When an employee leaves) What constitutes acceptable use of the system Remote and local login methods System monitoring procedures Protocols for responding to suspected security breaches Security_BG-134

Benefits for Written Security Policy CSE 4095 5810 You yourself will understand what is and is not permitted on the system. If you don't have a clear picture of what is permitted, you can never be sure when a violation has occurred. Others in your organization will understand what the security policy is. The written policy raises the level of security consciousness, and provides a focal point for discussion. The security policy serves as a requirements document against which technical solutions can be judged. This helps guard against the "buy first, ask questions later" syndrome. The policy may help bolster your legal case should

you ever need to prosecute for a security violation. Security_BG-135 Issues of Client Side Security CSE 4095 5810 Q1 How do I turn off the "You are submitting the contents of a form insecurely" message in Netscape? Should I worry about it? Q2 How secure is the encryption used by SSL? Q3 When I try to view a secure page, the browser complains that the site certificate doesn't match the server and asks me if I wish to continue. Should I? Q4 When I try to view a secure page, the browser complains that it doesn't recognize the authority that signed its certificate and asks me if I want to continue. Should I? Q5 How private are my requests for Web documents? Q6 What's the difference between Java and JavaScript? Q7 Are there any known security holes in Java? Q8 Are there any known security holes in JavaScript? Security_BG-136 Issues of Client Side Security

CSE 4095 5810 Q9 What is ActiveX? Does it pose any risks? Q10 Do "Cookies" Pose any Security Risks? Q11 I hear there's an e-mail message making the rounds that can trash my hard disk when I open it. Is this true? Q12 Can one Web site hijack another's content? Q13 Can my web browser reveal my LAN login name and password? Q14 Are there any known problems with Microsoft IE? Q15 Are there any known problems with Netscape Com.? Q16 Are there any known problems with Lynx for Unix? Q17 Is it a good idea to configure /bin/csh as a viewer for documents of type application/x-csh. Q18 Is there anything else I should keep in mind regarding external viewers? Security_BG-137 Issues of Protecting Confidential Documents CSE 4095 5810 Q1 What types of access restrictions are available?

Q2 How safe is restriction by IP address or domain name? Q3 How safe is restriction by user name and password? Q4 What is user verification? Q5 How do I restrict access to documents by the IP address or domain name of the remote browser? Q6 How do I add new users and passwords? Q7 Isn't there a CGI script to allow users to change their passwords online? Q9 How does encryption work? Q10 What are: SSL, SHTTP, Shen? Q11 Are there any "freeware" secure servers? Security_BG-138 Web Services Security CSE 4095 5810 Predominately Achieved via SOAP Messaging

See: http://www.oasis-open.org/specs/index.php#wssv1.0 Enhancements to SOAP Messaging for: Message Integrity Message Confidentiality Single Message Authentication General Purpose Mechanism for Associating Security Token with messages This is a Good Topic for Project 2 Web Services Security See also: http://www.ibm.com/developerworks/library/specification/ws-secure/ Security_BG-139 Concluding Remarks CSE 4095 5810 Security is Multi-Step, Multi-Discipline Process Definition of Security Requirements Realization of Security at Web, Application, and Database Levels

Integration of Security from Client to Web to Application to DB Rigorous Definition of Security Policy Dynamic Nature of Security Privileges Enforcement of Defined Privileges Across and within Multiple Tiers Overall, Security in Todays World Integral Part of Everyday Life - Some Key Concerns Confidentiality of an Individuals Data PHR/EMR Identity Theft Security_BG-140

Recently Viewed Presentations

  • 48x36_horizontal - West Virginia University

    48x36_horizontal - West Virginia University

    Poster Presentation Photo & Graphics Group Title of Poster Doctors, Researchers, PhDs, etc… Department , University of Maryland ABSTRACT: INTRODUCTION: Sdfkjsdfdfs alsefksdf dfgdf sdkfsdfgsdljslfsdfjsdfls fdgd dfkasdf ljsd fsdjfsdjlf sdk sk; dfk adkfsdkfsd;kfdkf s dskfasdklfsd ksdf ssd fsdkfsdk dfg as dfkUkdasf...
  • Project Management - Monitoring and Control

    Project Management - Monitoring and Control

    Project management process. Inspection process. Configuration management process. Change management process. Process management process. Will briefly look at these now. ... First proposed by Fagan in 70s. Earlier used for code, now used for all types of work products.
  • chapter

    chapter

    Chapter 10 Biomechanics of Physical Activity chapter 10 Biomechanics of Physical Activity Kathy Simpson What Is Biomechanics of Physical Activity? Biomechanics applies the mechanical principles of physics and engineering to the motion, structure, and functioning of all living systems.
  • Aucun titre de diapositive - economistesquebecois.com

    Aucun titre de diapositive - economistesquebecois.com

    Diane-Gabrielle Tremblay Professeure, Télé-université Titulaire de la chaire de recherche du Canada sur les enjeux socio-organisationnels de l 'économie du savoir
  • Synergy at the Interface International WaTER Conference ...

    Synergy at the Interface International WaTER Conference ...

    Peter Winch, Director, Social and Behavioral Interventions Program, Johns Hopkins Bloomberg School of Public Health - Behavior Change. Oral presentations and posters from experts around the world. Post-conference workshop on well drilling, biosand filters and eco-latrine construction.
  • Menu System - EV3 Lessons

    Menu System - EV3 Lessons

    What Role Does the VM Play. The VM sits between your programs and the operating system running on the EV3. Note that systems such ev3dev run their own updated Linux installation with their own drivers for the EV3 hardware (i.e....
  • THE RISKS OF LIFE Scams & Cons Video

    THE RISKS OF LIFE Scams & Cons Video

    THE RISKS OF LIFE Video Conference #3 Scams & Cons
  • F, t, and p Basic Statistics for Computer Scientists

    F, t, and p Basic Statistics for Computer Scientists

    F, t, and p Basic Statistics for Computer Scientists (aka knowing enough to be critical of user studies) April 4, 2002 Benjamin Lok User Studies Trying to identify phenomena or trends Hypothesis Blood pressure increases with age and weight Smoking...