Security Concepts and Capabilities

Security Concepts and Capabilities
Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-1155 Storrs, CT (860) 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.

Motivation: Recall Project Architecture
Patients Providers 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

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

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

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

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 Legal and ethical issues regarding to the right to access certain information Policy issues at governmental, institutional or corporate level System related issues such as the system levels at which various security functions should be enforced The need in some organizations to identify multiple security levels and to characterize the data and users based on the classifications

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.

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

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.)

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

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

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

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

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

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

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?

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

Network Authentication
Computers Must Interact with One Another Classic Example, Transmitting 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

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

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

Recall Java Bytecode Verification:

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

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

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

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 Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

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

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

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 of Clearance Dominating Classification

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 Star (*) property An untrusted subject may have append access to an object if the security level if the object dominates the security of the subject. An untrusted subject may have write access to an object if only the security level of the object is equal to the current security level of the subject. Discretionary property (ds-property) Every current access must be present in the access matrix That is, a subject can excerise only accesses for which it has the necessary authorization. A system state satisfies the discretionary property if an only if 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.

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 TS S C U User (S) Read Down

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! TS S C U User (S) Write Down

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 TS S C U Write Up User (S)

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 TS S C U Read Equal Write Equal User (S)

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

A Classic Example 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) TS S C U Write Up

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 Star (*) property An untrusted subject may have append access to an object if the security level if the object dominates the security of the subject. An untrusted subject may have write access to an object if only the security level of the object is equal to the current security level of the subject. Discretionary property (ds-property) Every current access must be present in the access matrix That is, a subject can excerise only accesses for which it has the necessary authorization. A system state satisfies the discretionary property if an only if 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.

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

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

Lattice-based Access Control (LBAC)
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 Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

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 Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

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 Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write (f) (g)

Lattice Suitable for Healthcare
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. Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

Proposed set of Levels for Healthcare

Proposed levels for healthcare lattice
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. Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

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) Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

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) Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

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) Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

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) Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

Proposed set of Levels for Healthcare
SR surviellence

One Possible Lattice

Explaining the Lattice: Levels 0 and 1
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, 1-IM

Explaining the Lattice: Level 2
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 & 2-PL

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

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

Summary Interpreting the Lattice
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, 2-OTC, 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

Interpreting the Lattice
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

Disease Surveillance Scenario
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 2–Dx 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) Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

Description Name Level Value
1. Date of report RDAT day/month/year 2. Name of reporter RNAM [First name, Middle Name, Last Name] 3. Reporter Contact info RCON [Address & Phone] 4. Care provider PROV [First name, Middle Name, Last Name] 5. Care provider type PTYP [physician/nurse/other] 6. Care provider ID PRID [National Provider ID] 7. Care Facility FAC [Facility name] 8. Facility Contact FADR [Facility address & phone] 9. Facility State FSTAT [two letter state code] 10. Patient Name NAM [First name, Middle Name, Last Name] 11. Patient State PSTAT [two letter state code] 12. Patient Address PADR [Street, City] 13. Patient Zip PZIP [Zip code – 5 digit] 14. Patient Gender SEX [code] 15. Patient Race RACE [code] 16. Year of Birth YOB [year] 17. Month, Day of Birth MDOB [month, day] 18. Patient Ethnicity ETHN [code] 19. Patient Record Number MRN [alphanumeric, variable length] 20. Next of Kin Name KINM [First name, Middle Name, Last Name] 21. Next of Kin Phone KINP 3 [phone number] 22. Date of onset ODAT day/month/year 23. Condition COND [disease code – ICD-10] 24. Test ordered TEST [LOINC code] 25. Test result RSLT 1 [text]

Medical Fitness Scenario
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 Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

Description Name Level Value
1. Date DAT date 2. Time start STIM 0 time 3. Time end (optional) ETIM 0 time 4. Type of activity TYP code 5. Intensity of activity LEV code 6. Duration of activity DUR time interval 7. Heart rate HR number 8. GPS location GPS GPS coordinates 9. Blood oxygen level O percent saturation 10. Steps taken STEP number 11. Distance traveled DIST distance 12. Light level LITE number 13. Person name NAM name 14. Person address ADDR address 15. Person City CITY city 16. Person State STAT 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 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

Medical Provider Office Staff Scenario
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 Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

Medical Provider Scenario
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 Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

Mental Health Scenario
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 Bell-Lapadula Model [1976] An extension of the access matrix model oriented to the definition of the security requirements in complex systems where the system elements can be classified. The model is based on subject-object paradigm Subjects are active elements that can execute actions Objects are passive elements that contain information Model considers four access modes executable by subjects on objects: Read-only or Read Append (write without read) Execute (executes an object/program) Read-Write or Write

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 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

Confidentially

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).

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.

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.

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.

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

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

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

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

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

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

Interpreting Sub-Categories
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 Patient’s 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?

Recall Data Items from Paper
Are 8 Levels of Sensitivity Enough to Classify Data and Make Available to Diverse set of Stakeholders?

HCS Operational Model

Manage Information at Multiple Levels

Applying Clinical Labels
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.

Access Control at Runtime
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

eXtensible Access Control Markup Language
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 Rule Subject Action Resource Rule Combination Algorithm Policy Combination Algorithm

Security Labeling via NIST Standards

Labeling Clinical Facts – Consider Data

Apply Security Labels

Sample Labels

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

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

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

RBAC Model Variants Transition from Essential Features to Complex Model

Level 1 and Level 2 Level 1: Three States and UA/PA
Level 2: Add in Role Hierarchy Look on R State

Example Role Hierarchies

Level 3 and Level 4 Level 3: Constrained RBAC – with Separation of Duty Constraints (SOD) Level 4: Sessions of Users and Roles

Constrained RBAC – with SOD

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

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

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

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

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

Sample RBAC Hierarchy for HCA
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:Discharge_Plng UR:Manager

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

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

Discretionary Access Control
Grant Privileges to Users, Including the Capabilities to Access Specific Data Items in a Specific Mode Available in Most Commercial DBMSs Aspects of DAC User’s Identity Predefined Discretionary “Rules” Defined by the Security Administrator Focus on Two Variants of this Model Access Matrix Model Lampson’s Protection System Role Delegation and Delegation Authority Detail DAC in SQL2

What is Role Delegation?
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 …

Why is Role Delegation Important?
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?

What Can be Delegated? 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

Delegation/Pass on Delegation Authorities
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

Example - Role Delegation
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]]

Example - Role Delegation
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]]

Role Delegation Revocation Rules
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).

Role Delegation Revocation Rules
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.

Monotonicity and Permanence
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

Totality and Administration
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, Agent-directed) is when Control is with the Security Officer

Revocation Definition: Cascading Revocation Refers to the Indirect Revocation of All DUs When the OU Revokes Delegation or Administration Revokes the OU’s 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

Database Security Approach
Software Engineers can Write Complex Programs Limited by Intellectual Capabilities DB Designer Must Create Protection Scheme that Can’t 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 Organization’s Admin. Policy

Database Security 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” - Can’t Change the Med By Law - Protect the Script per Patient (MD/Insurance) Access Control is Mechanism to Prevent Unauthorized Access to Databases A=(smith, insert), (mary, update) A’=(mary, update) C’=Book, Publisher C=Science Book, US Publisher

Database Security 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) Database Administrator (DBA) has the privileged commands to perform the following functions on databases (apply to all data models and all types of DBMSs) Account Creation: creating accounts, set passwords Privilege granting: granting certain privileges to certain accounts Privilege revocation: canceling (revoking) certain privileges Security level assignments: assign appropriate security level to user accounts

DAC in SQL2 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

Privileges in SQL 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

Example Schema Consider Two Database Tables: EMPLOYEE DEPARTMENT
(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

SQL Examples 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 Example 1 He wants only to grant U1 the right to create base relations Example 2 Suppose that U1 wants to grant U2 the privilege to insert and delete tuples in both relations. However, U1 does not want U2 to be able to propagate these privileges to additional accounts. Example 3: Suppose U1 wants to allow U3 to retrieve information from either of the two tables and also to be able to propagate the SELECT privilege to other accounts: Example 4 Now U3 can grant the SELECT privilege on the EMPLOYEE relation to U4 by:

SQL Examples 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! Example 1 He wants only to grant U1 the right to create base relations Example 2 Suppose that U1 wants to grant U2 the privilege to insert and delete tuples in both relations. However, U1 does not want U2 to be able to propagate these privileges to additional accounts. Example 3: Suppose U1 wants to allow U3 to retrieve information from either of the two tables and also to be able to propagate the SELECT privilege to other accounts: Example 4 Now U3 can grant the SELECT privilege on the EMPLOYEE relation to U4 by:

SQL Examples 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; Suppose that U1 wants to give back to U3 a limited capability to SELECT from the EMPLOYEE relation. And he wants to allow U3 to be able to propagate the privilege. The limitation is to retrieve only the NAME, BDAT and ADDRESS atteributes and only for tuples with DNO = 5; Supppse that after the view is created, U1 can grant SELECT on the view U3_EMP to U3 as follows: Suppose U1 wants to allow U4 to update only the SALARY attribute of EMPLOYEE, U1 can issue the following command:

Cryptography 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

More on Cryptography plaintext plaintext Ke Kd C = EKe(plaintext)
Encrypt Decrypt Invader Side information plaintext

Cryptographic Systems
Modern Systems Conventional or Symmetric Systems Ke and Kd are essentially the same Private Key Public Key Ke and Kd are private Ke is public Kd is private

Statistical Database Security
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: 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 Person(name, ssn, income, address,city, state, zip, sex, last_degree)

Example of Statistical DB
Consider Q1 and Q2: 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 Mary’s Income Q1: find the total number of women who have ph.D. and live in Calgary, Alberta. Q1: find the average income 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”; select AVG(income) from Person where last_degree = “ph.D.” and sex = “F” and city = “Calgary” and state = “Alberta”;

Example Two of Statistical DB
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: Since Connie Knows her Own Income, by Calculating Q4 - (Q3 - Connie’s Income), She Determinds Mary’s Income select SUM(income) from Person where last_degree = “ph.D.” and sex = “F” and city = “Calgary” and state = “Alberta”; and name <> “Mary” select SUM(income) from Person where last_degree = “ph.D.” and sex = “F” and city = “Calgary” and state = “Alberta” and name <> “Connie”;

Statistical Database Security
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!

Web Based Security What are the Issues and Concerns in Web-Based Security? See: Partitions Security into: Client Side Security Server Side Security CGI Scripts Protecting Confidential Documents Denial of Service Attacks We’ll Briefly Review all, but Concentrate on those Most Apropos to BMI and Associated Web-Based Applications (e.g., Team Project)

General Web Security Issues
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?

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

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

Benefits for Written Security Policy
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.

Issues of Client Side Security
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?

Issues of Client Side Security
Q9 What is ActiveX? Does it pose any risks? Q10 Do "Cookies" Pose any Security Risks? Q11 I hear there's an 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?

Issues of Protecting Confidential Documents
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?

Web Services Security Predominately Achieved via SOAP Messaging See: 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:

Concluding Remarks 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 Today’s World Integral Part of Everyday Life - Some Key Concerns Confidentiality of an Individuals Data – PHR/EMR Identity Theft Protecting National Infrastructure

Security Concepts and Capabilities

Similar presentations

Presentation on theme: "Security Concepts and Capabilities"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Security Concepts and Capabilities

Similar presentations

Presentation on theme: "Security Concepts and Capabilities"— Presentation transcript:

Similar presentations

About project

Feedback