Transcript on the medical security proposal

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
*
*
Right
Composite
Simple
Role
Role
Activated
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 *
1..* read
modify
1
<<role>>
Patient
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
MedicalHistory
Patient
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
*
Hospital
create
update
<<role>>
GovernmentAuditor
name
address
Right
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
Draft 1993
Common Criteria
1989
German Criteria
French Criteria
ITSEC
1991
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/i
ndex.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