Today s Topics. HIPAA Security Rule. HIPAA Data Protection. Administrative Safeguards. Administrative Safeguards

Size: px

Start display at page:

Download "Today s Topics. HIPAA Security Rule. HIPAA Data Protection. Administrative Safeguards. Administrative Safeguards"

Cathleen Potter
5 years ago
Views:

1 Today s Topics Data Privacy in Biomedicine Lecture 3: ccess Control and EMs Security ule Pillars of Security ccess Control ole Engineering Bradley Malin, PhD (b.malin@vanderbilt.edu) Professor of Biomedical Informatics, Biostatistics, & Computer Science Vanderbilt University January 14, Bradley Malin 2 HIP Data Protection PIVCY ULE (2002) Dept of Health & Human Services. Standards for privacy of individually identifiable health information; Final ule. Federal egister. 45 CF: Pt 160 and 164. SECUITY ULE (2003) Dept of Health & Human Services. Standards for the Protection of Electronic Health Information; Final ule. Federal egister. 45 CF: Pt 164. HIP Security ule dministrative Safeguards Physical Safeguards Technical Safeguards Organizational equirements In general: Security ule preempts contrary state law Security ule details: Bradley Malin Bradley Malin 4 dministrative Safeguards Standards Implementation Specification equired vs. ddressable Security Management Process ssigned Security esponsibility Workforce Security Information ccess Management Security wareness & Training isk nalysis isk Management Sanction Policy Information System ctivity eview uthorization and/or Supervision Workforce Clearance Procedure Termination Procedures Isolating Healthcare Clearinghouse Function ccess uthorization ccess Establishment and Modification Security eminders Protection from Malicious Software Log-in Monitoring Security Incident Procedures esponse and eporting Contingency Plan Data Backup Plan Disaster ecovery Plan dministrative Safeguards Standards Implementation Specification equired vs. ddressable Contingency Plan Evaluation Business ssociate Contracts & Other rrangements Data Backup Plan Disaster ecovery Plan Emergency Mode Operation Plan Written Contract or Other greement Emergency Mode Operation 2019 Bradley Plan Malin Bradley Malin 6 1

2 Physical Safeguards Technical Safeguards Standards Implementation Specification equired vs. ddressable Contingency Operations Facility Security Plan Facility ccess Controls ccess Control and Validation Procedures Maintenance ecords Workstation Use Workstation Security Disposal Media euse Device & Media Controls ccountability Data Backup & Storage Standards Implementation Specification equired vs. ddressable Unique User Identification Emergency ccess Procedure ccess Control utomatic Logoff Encryption and Decryption udit Controls Integrity Mechanism to uthenticate ephi Person or Entity uthentication Integrity Controls Transmission Security Encryption 2019 Bradley Malin Bradley Malin 8 Three Pillars of Security Least Privilege User should be provided with no more privileges than are necessary to perform their job Least Privilege Separation of Duties Data bstraction 2019 Bradley Malin Bradley Malin 10 Separation of Duties Data bstraction equirement for multiple types of individuals to complete a task Permissions are related to the type of data being handled 2019 Bradley Malin Bradley Malin 12 2

3 ccess Control What to Control? Subjects S (or Users) Objects O (or Patients) ights ead from ecord Issue Order Could specialize to type of information demographics diagnoses treatments Write to ecord equest Consult Subjects & Principals One-to-many mapping of subjects to principals Intention is to ensure accountability for one s actions Dr. X X.Physician X.Supervisor X.Teacher 2019 Bradley Malin Bradley Malin 14 Many Variations ccess Matrix (M) Mandatory ccess Control (MC) Discretionary ccess Control (DC) ole-based ccess Control (BC) Task-Based ccess Control (TBC) Team-Based ccess Control (TeBC) bstraction of ccess Control (Lampson 1971) right is a relation for subjects and objects r(s,o) el Specification of which rights can be invoked by which subject for which object B. Lampson. Protection. Proc. 5 th Princeton Conference on Information Sciences and Systems. 1971: Bradley Malin Bradley Malin 16 ccess Matrix How to Use an ccess Matrix Object Subject B C Dr. D -X WX WX Nurse E -X WX -X Biller F r(dr. D, C) = {, W, X} Can allow for dynamic protections Operations for assignment & revocation of rights Can permit special rights: Ownership of object Copy of object Control of rights modification for object 2019 Bradley Malin Bradley Malin 18 3

4 Views on the Matrix ccess Control List (CL) For a single object Indicates which subject can invoke which right Subject Object Dr. D, X Nurse E, X Biller F Views on the Matrix Capability List For a single subject Indicates which rights can be invoked by the subject across objects which right Object Subject B C Dr. D, X, W, X, W, X 2019 Bradley Malin Bradley Malin 20 ccess Matrix (M) Many Variations Mandatory ccess Control (MC) Discretionary ccess Control (DC) ole-based ccess Control (BC) Task-Based ccess Control (TBC) Team-Based ccess Control (TeBC) Mandatory vs. Discretionary Mandatory access controls (MC) restrict the access of subjects to objects on the basis of security labels Discretionary access controls (DC) permits access rights to be propagated from one subject to another Possession of an access right by a subject is sufficient to allow access to the object 2019 Bradley Malin Bradley Malin 22 Take a Step Back ights (or Permission) ssignment 2019 Bradley Malin Bradley Malin 24 4

5 ights (or Permission) ssignment Delegation 2019 Bradley Malin Bradley Malin 26 Delegation Delegation 2019 Bradley Malin Bradley Malin 28 User-Permission elation via Transitivity Many Variations ccess Matrix (M) Mandatory ccess Control (MC) Discretionary ccess Control (DC) ole-based ccess Control (BC) Task-Based ccess Control (TBC) Team-Based ccess Control (TeBC) 2019 Bradley Malin Bradley Malin 30 5

6 Many Potential ssignments ole-based ccess Control (BC) ole 1 ole 2 ole k 2019 Bradley Malin Bradley Malin 32 Can Map oles to Permissions Can Map Users to oles ole 1 ole 1 ole 2 ole 2 ole k ole k 2019 Bradley Malin Bradley Malin 34 Users can Have Multiple oles! ole 1 Formal BC System Defined over the following principals U: user set : role set P: permission set S: session set (not always used) elations ole 2 U U (which users belong to which roles) P P (which permissions belong to which roles) Note: Permissions are positive (not negative) statements Functions ole k user: S U (e.g., session s i belongs to user u j ) roles: S 2 (mapping of each session to set of roles) 2019 Bradley Malin Bradley Malin 36 6

Core BC Framework Decomposition of oles into Entities & ctions Users U oles P Operations Objects Permissions Sessions Notice: permissions are often partitioned into Operations & Objects D.

7 Core BC Framework Decomposition of oles into Entities & ctions Users U oles P Operations Objects Permissions Sessions Notice: permissions are often partitioned into Operations & Objects D. Ferraiolo, et al. CM Transactions on Information and System Security. 2001; 4(3): Bradley Malin 37 B. Blobel, et al. Modelling privilege management and access control. International Journal of Medical Informatics. 2006; 75: Bradley Malin 38 Does BC Help? BC in Practice Various database management systems (DBMS)* ole 1 ole 2 ole k Enterprise Security Management Take a look at the IBM Security Identity Governance and Intelligence (IGI) Various operating systems use BC in a limited way (think groups and rights) *C. amaswamy and. Sandhu. ole-based access control features in commercial database management systems. National Institutes of Standards and Technologies Bradley Malin Bradley Malin 40 Family of BC Models BC 3 (Hierarchies & Constraints) BC 1 (ole Hierarchies) BC 2 (Constraints) BC 0 (User-ole & ole-permission elations) Hierarchies in BC 1 Defined over (U,, P, S, P, U) H (partial order on the set ) x y implies role x can dominate role y x y implies role x can be dominated by role y roles: S 2, such that: roles(s i ) {r ( r r) [user(s i ),r ] U} s i has permissions r roles(si ) {p ( r r) [p,r ] P} Sometimes called General Hierarchical BC 2019 Bradley Malin Bradley Malin 42 7

8 Several Notes on oles oles are a partial order, which means eflexive (r r) Transitive (x y y z x z) ntisymmetric (negated transpose of relation) If (a,b) and (b,a), then a = b If (a,b) and a b, then (b,a) must not hold true Permissions propagate from subordinates (below) to superior roles (above) Inverted Tree Main Hospital Chief of Staff Medical Center Director Children s Hospital Chief of Staff Can leverage hierarchical nature of organizations to more effectively manage roles General Practitioner Billing ssistant Nurse Laboratory Technician Pediatrician Pediatric Nurse Natural way of reflecting authority, responsibility and competency 2019 Bradley Malin Bradley Malin 44 ED Physician ED Nurse Tree OBGYN Phsyician OBGYN Nurse Lattice ED Chief Chief of Staff OBGYN Chief Emergency Department (ED) Staff Obstetrics and Gynecology (OBGYN) Staff ED Physician ED Nurse OBGYN Phsyician OBGYN Nurse Hospital Staff ED Staff OBGYN Staff 2019 Bradley Malin 45 Hospital Staff 2019 Bradley Malin 46 BC 1 Framework ole Hierarchy Constraints in BC 2 Users U oles P Operations Objects estrictions on permissible components of BC 0 Sessions Permissions The hierarchy amends only the roles, user-role relation (U), and rolepermission relation (P) function that returns acceptable or not acceptable with respect to any assertion Can be applied to elations: U, P Functions: user, roles Example: mutually exclusive roles D. Ferraiolo, et al. CM Transactions on Information and System Security. 2001; 4(3): Bradley Malin Bradley Malin 48 8

9 BC 2 Framework BC 3 Users U oles P Operations Objects Combines hierarchies and constraints Permissions Sessions Constraints Ex: Limited Hierarchical BC Limit on ordering (or design) of hierarchy Constraints can sit anywhere in the system, but are usually left out of permissions D. Ferraiolo, et al. CM Transactions on Information and System Security. 2001; 4(3): Ex: Cardinality Constraints Limit on the number of roles per user Testing a constraint may requires deduction 2019 Bradley Malin Bradley Malin 50 Speaking of BC Speaking of BC The goal is to simplify security administration There are certain expectations 1. Users change more frequently than roles 2. Number of roles << Number of users The goal is to simplify security administration There are certain expectations 1. Users change more frequently than roles 2. Number of roles << Number of users verage Task Time in Minutes Non-BC Systems 12.4 ssign Privileges to New Users verage Task Time in Minutes Non-BC Systems 12.4 ssign Privileges to New Users BC Systems 6.9 Difference 5.5 G. Tassey. The economic impact of role-based access control. NIST eport G. Tassey. The economic impact of role-based access control. NIST eport Bradley Malin Bradley Malin 52 Speaking of BC Speaking of BC The goal is to simplify security administration There are certain expectations 1. Users change more frequently than roles 2. Number of roles << Number of users The goal is to simplify security administration There are certain expectations 1. Users change more frequently than roles 2. Number of roles << Number of users verage Task Time in Minutes ssign Privileges to New Users Non-BC Systems BC Systems Difference Change Users Privileges verage Task Time in Minutes ssign Privileges to New Users Change Users Privileges Non-BC Systems BC Systems Difference Establish New Privileges for Users G. Tassey. The economic impact of role-based access control. NIST eport G. Tassey. The economic impact of role-based access control. NIST eport Bradley Malin Bradley Malin 54 9

10 Speaking of BC The goal is to simplify security administration There are certain expectations 1. Users change more frequently than roles 2. Number of roles << Number of users verage Task Time in Minutes ssign Privileges to New Users Change Users Privileges Establish New Privileges for Users Non-BC Systems BC Systems Difference Terminate Privileges ole Engineering Implicit assumptions of BC are roles exist (!) roles accurately reflect activities, functions, and responsibilities in the organization ole definition is a requirements engineering process ole engineering should address all aspects of BC 3 (according to Coyne) ole engineering dovetails with other requirements engineering efforts to identify user roles, which serve as a basis for the design of User Interfaces System Functions G. Tassey. The economic impact of role-based access control. NIST eport Bradley Malin 55 Coyne, E. J. ole engineering. In Proceedings of the First CM Workshop on ole-based ccess Control Bradley Malin 56 ole Engineering - Challenge ole Engineering Process NIST identified role engineering as the most costly and time consuming aspect of BC execution even for BC 0 ole specification can take up to 3 4 months to establish consensus Top-Down D E C O M P O S I T I O N oles Jobs Workpatterns Tasks Permissions C O M P O S I T I O N Bottom-Up G. Tassey. The economic impact of role-based access control. NIST eport Bradley Malin 57 Top-down is more efficient, but may not be feasible in legacy systems Bradley Malin 58 ole Engineering - Challenge NIST identified role engineering as the costliest and time consuming aspect of BC execution even for BC 0 ole specification can take up to 3 4 months to establish consensus Many organizations continue to rely on traditional (pre- BC) management schemas (e.g., MC, DC, etc.) G. Tassey. The economic impact of role-based access control. NIST eport Bradley Malin 59 Directionality in ole Engineering Top-down pproach oles are identified by carefully analyzing and decomposing business processes into smaller functional units Functional units are then associated with permissions With >10 4 users, >10 6 authorizations difficult task Ignores existing permissions Bottom-up pproach permissions are aggregated into roles Lends itself for automation Hybrid pproaches (How to meet in the middle?) This remains an open research problem* *See.. Colantonio, et al. new role mining framework to elicit business roles and to mitigate enterprise risk. Decision Support Systems. 2011; 50: Bradley Malin 60 10

Exceptions can be Granted But they are discouraged can lead to managerial problems May be better off constructing a new role or augmenting an existing role In are Cases Break the Glass user may not

11 Exceptions can be Granted But they are discouraged can lead to managerial problems May be better off constructing a new role or augmenting an existing role In are Cases Break the Glass user may not have sufficient access rights to perform job This model allows users to temporarily escalate privilege ccess is logged and reviewed by administrator May require user to specify reason for access 2019 Bradley Malin Bradley Malin 62 are Cases? Central Norway Health egion enabled break the glass (2006) each beyond your access level if you provide documentation 53,650 of 99,352 patients had their glass broken 5,310 of 12,258 users broke the glass Over 295,000 logged breakage events in one month ole Users Invoked Glass Breaks in Past Month Nurse % Doctor % Health Secretary % Physiotherapist % Psychologist % Many Variations ccess Matrix Model (MM) ole-based ccess Control (BC) Discretionary ccess Control (DC) Mandatory ccess Control (MC) Task-Based ccess Control (TBC) Team-Based ccess Control (TeBC) L. østad and Ø. Nytrø. ccess control and integration of health care systems: an experience report and future challenges. Proceedings of the 2 nd International Conference on vailability, eliability and Security (ES). 2007: Bradley Malin Bradley Malin 64 NO CLSS ON MONDY Task-Based ccess Control Extends the (User, object) relational model to include Task Contextual Information Dynamic in nature and can facilitate workflows But the state-space can be huuuuge Bradley Malin Bradley Malin 66 11

12 Many Variations ccess Matrix Model (MM) ole-based ccess Control (BC) Discretionary ccess Control (DC) Mandatory ccess Control (MC) Task-Based ccess Control (TBC) Beyond the Course Team-Based ccess Control (TeBC) 2019 Bradley Malin 67 12

1 Security 101 for Covered Entities

1 Security 101 for Covered Entities HIPAA SERIES Topics 1. 101 for Covered Entities 2. Standards - Administrative Safeguards 3. Standards - Physical Safeguards 4. Standards - Technical Safeguards 5. Standards - Organizational, Policies &