Security models for medical and genetic information Eduardo B.

Security models for medical and genetic information Eduardo B. Fernandez, María M. Larrondo Petrie, Tami Sorgente, Alvaro Escobar, and Andrei Bretan

Medical information Patient information is very sensitive; its misuse could seriously affect the life of the patient In the past this information was kept in paper in doctors’ offices and hospitals Most medical information now is being put online and accessible from the Internet There is more information available, e.g., genetic information

Security problems There are many benefits by having information online but also new threats Access to patients’ records is now possible from remote locations, illegal access also! Access to many patients’ records makes blackmail, spam, and theft identity more lucrative We need new access control models

General policies for the model Need-to-know, provide only information needed to perform their job Users are defined by their roles but individual access is also needed Emphasis on privacy Closed system

Specific policies Specific access constraints for each role Patients consent to use of their records and and are notified of their use A record custodian is responsible for use of record Records must be accessible for specific time periods Need to override rights in exceptional situations

Specific Policies II Records of patients with genetic or infectious diseases need to be linked to other medical records e.g. relatives Each patient has one or more medical records seen as one Logical Record Need for aggregate types of access which do not reveal the individuals’ medical data

Requirements for model Administration of security—Custodians and traditional administrators Attribute and credential-based authorization —Users unknown in advance Exceptional access modes—need to override predefined authorization Delegation of rights—Provisions for delegation

More requirements Temporal restrictions—Time-dependent access Use of XML—Need to control access to XML documents Multimedia objects—Units of access can be text, images, audio Inference—Control of basic inferencial associations

Even more requirements Expression encryption needs—When Transferring documents Coordinated authentication and authorization Coordination of architectural levels Consideration of web standards Compliance with health records laws

Medical information Medical information is collected from the moment a person is born until her death Presently there is not one medical record for each individual kept in a central registry Each clinician or consortium keeps their own records Information is passed through referrals and discharge letters

Privacy of Patients Since 400 B.C., and the Hippocratic oath, patient privacy has been an important part of physician’s code of conduct Now, many insurers, attorneys and government agencies employ individuals not subject to medical ethics codes

Medical information Protection The use of medical information of each individual is complex and fragmented Several countries have provided guidelines for medical information protection

Patient data protection laws The UK had a law in 1996 Germany, France, Iceland, and others already have laws In the US we have now HIPAA, not as effective as the British laws

HIPAA in the United States Healthcare providers must ensure the integrity, confidentiality, and availability of electronic protected health information (PHI) is protected PHI is broad and includes any identifiable health or mental information related to an individual

Bioinformatics Application of computer technology to the management of biological information. Science of developing computer databases and algorithms to facilitate and expedite biological research. Genomics is a perfect example. Biological information must be protected from misuse.

Bioinformatics & Security Approaches Use alias to replace the individual’s true identity. Use passwords and encryption for access to or transfer of files, using a secure shell protocol. Chemical encoding into the genetic material. Digital Certificate and Public Key Infrastructure for individual user’s identification.

Access control models There are several models for access control to information The most common are: multilevel, Access matrix, and Role-Based Access Control These are general models, independent of the application However, the model must fit the application or it will not be used

Some XML Security Standards Signed Document Markup Language (SDML) Key Management Specification (XKMS) Security Assertion Markup Language (SAML) Extensible Access Control Markup Language (XACML)

MemberOf Group * User * MemberOf * * * * 1 AuthorizationRule * Role * * Composite Simple Role Role Activated Right From Subset * WorksOn * Session AdminRole AdminRight ProtectionObject

Some policies for medical information Patients can see their records, consent to their use, must be informed of their use A doctor or other medical employee is responsible for use of record (custodian) Records of patients with genetic or infectious diseases must be related One or more medical records per patient

MedicalRelation role Doctor 1 Custodian InChargeOf * * MedicalRecord role Patient * 1.* read modify 1 Right read authorizeUse informPatient for own Record

An Analysis Pattern for Patient Treatment Requirements A Patient Treatment Pattern describes the treatment or stay history of a patient in a hospital. The hospital may be a member of a medical consortium. Each patient has a medical history which contains insurance information and a record of all treatments within the medical consortium. Each patient has a primary physician, an employee of the hospital. Upon admission the patient is created as new or information is updated from previous visit(s). A treatment history is created for each patient admitted and updated throughout the patient’s stay. Inpatients are assigned a room, nurse team and consulting doctors.

Patient Record Patient MedicalHistory 1 name address patient number insurance treatment history * Outpatient specialty Inpatient TreatmentHistory medications procedures Figure 1 Class Diagram for Patient Record

Patient Treatment with HIPAA Security standards General requirements of Health Insurance Portability and Accountability Act (HIPAA) security standards: 1. Ensure the confidentiality, integrity and availability of all electronic protected health information the hospital creates, receives, maintains or transmits. 2. Protect against any reasonably anticipated threats or hazards to the security or integrity of such information. 3. Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under the privacy regulations. 4. Ensure compliance of this subpart by the hospital workforce.

Patient Treatment with Authorization The Role Based Access Control model will be used to assign rights to the users according to their roles in patient treatment. admit a new patient extend admit a patient patient admit an inpatient admissions clerk admit an outpatient nurse treat a patient doctor discharge a patient include close a patient administrative clerk

Patient Treatment with Authorization TreatmentHistory * medications procedures update Consortium 1 MedicalHistory insurance treatmentHistory name main location Patient name patient number role GovernmentAuditor * Hospital create update Right name address governmentAudit * Employee name ss number address Right hospitalAudit Right Right treatPatient closePatient billPatient Right Right admitPatient treatPatient dischargePatient role HospitalAuditor role . AdministrativeClerk role Doctor specialty role Nurse specialty role . AdmissionsClerk

Outline of Proposed Research The main objective of this project is to develop security models for specialized applications requiring a high level of security with an emphasis on privacy Specifically, we propose to develop an authorization model for medical and genetic information

Research Approach Analyze interactions of systems and users with a patient record system Interview healthcare professionals Define threats and incorporate countermeasures Develop patterns to define the complete model and subsets of the model

Research Approach (cont.) Develop a protection profile that could help to develop secure access systems Validate the model by testing in real health environment Develop a secure methodology to build and configure system used for this type of application

Extensions of the Model Financial systems require investor consent before disclosing his investments Eduacation, law enforcement, and banking have several similar requirements Pharmaceutical companies in search of experimental drug testing subjects inviting a patient to participate without accessing their identity until the patient accepts

Evaluation Plan 8 measures of success for evaluation of the model Common Criteria Protection Profile for systems that access, store, or interact with medical data Sources for Common Criteria: [NIST, 2003] “Common Criteria for IT Security Evaluation: Common Language to Express Common Needs”, Computer Security Resource Center (CSRC), National Institute of Standards and Technology, created 12 November 2002, last updated 19 May 2003, http://csrc.nist.gov/cc/ “Common Criteria for Information Technology Security Evaluation, User Guide, CESG, UK and NIST, USA, Syntegra, October 2999. [Towns and Britton, 1999] Towns, M. and K. BrittonProterction Profile Development Workshop: Student Handbook, Ver. 2.0, NIAP/NIST, 2000. [Grainger 2000] Granger, G. Common Criteria Tools, Mitretek Systems, May 25, 2000.

Common Criteria: What is it? Common Criteria (CC) – catalog of criteria and a framework for organizing a subset of the criteria into security specification Who uses it: Developers Accreditors Approvers Product Vendors Common Criteria Consumers Certifiers Evaluators

Common Criteria International Standard Orange Book (TCSEC) 1985 Canadian Criteria CTCPEC) 1993 Federal Criteria (FC) UK Confidence Levels 1989 German Criteria French Criteria Draft 1993 ITSEC 1991 Common Criteria V 1.0 1996 V 2.0 1998 V 2.1 1999 ISO International Standard 15408 1999

Common Criteria Protection Profile Common Criteria Protection Profile (CC PP) – an implementation independent statement of security requirements that is shown to address threats that exist in a specified environment A PP is appropiate when – Consumer group wishes to specify security requirements for an application type (e.g., electronic funds transfer) – Government wishes to specify security requirements for a class of security products (e.g., firewalls) – An organization wishes to purchase an IT system to address its security requirements (e.g., patient records for a hospital)

Contents of a Protection Profile PP Introduction – PP Identification – PP Overview Target of Evalustion (TOE) TOE Security Environment – Assumptions – Threats – Organizational security policies Security Objectives – Security objectives for the TOE – Security objectives for the environment IT Security Requirements – TOE Security Requirements Security functional req. Security assurance req. – Sec. reqs. for IT environment PP Application Notes Rationales – Security objectives rationale – Security requirements rational

Registered Protection Profiles Sets of registered Protection Profiles exist at the following locations: – http://www.radium.ncsc.mil/tpep/protection profiles/ index.html – http://www.cesg.gov.uk/cchtml/ippr/list by type.html – http://csrc.nist.gov/cc/pp/pplist.htm – (currently being updated so I could not look up the list to see if it including what we are trying to propose) – http://www.scssi.gouv.fr/present/si/ccsti/pp.html