вход по аккаунту

код для вставкиСкачать
HIPAA Security and Privacy
Katharine Chang
Ashlesha Joshi
EECS 598-2
19 April 2004
HIPAA Overview
• HIPAA has a number of goals for
improving access to and delivery of health
insurance and health care
• It includes requirements for the security
and privacy of protected health information
• Electronic PHI is of particular concern
A Sampling of HIPAA Security
• A covered entity must…
– Implement technical policies and procedures
for electronic information systems that
maintain EPHI to allow access only to those
persons or software programs that have been
granted access rights
– Implement policies and procedures to protect
EPHI from improper alteration or destruction
– etc.
• To formalize a relevant subset of HIPAA
and investigate whether it can be
expressed by existing security models
• To consider possible design alternatives
for systems that need to comply with
• To investigate how to automate the
auditing process
HIPAA Principles
1. (Access control) For each patient there must exist an
access control list of healthcare professionals who may
read the patient's records and create new records. The
system shall prevent anyone not on the patient's access
control list from accessing the records in any way,
subject to the exception of Principle 3.
2. (Patient access) Every patient shall have read only
access to his or her own information.
3. (Emergency access) In case of an emergency, any
healthcare professional can access any patient's PHI.
HIPAA Principles (cont.)
4. (ACL management) One healthcare professional on
each patient's ACL shall be designated the administrator
of the ACL. Only this person may modify the ACL.
5. (Authentication) The identity of anyone seeking access
to PHI must be verified.
6. (Integrity) Unauthorized modification or deletion of PHI
shall be prevented.
7. (Audit control) All accesses to PHI shall be logged with
the subject’s name, date, and time. All modifications to
each patient's access control list should also be logged.
HIPAA Principles (cont.)
8. (Transmission security) Unauthorized access to
PHI being sent over a network shall be
9. (Enforcement) Computer systems that handle
PHI shall have a subsystem that enforces the
above principles in an effective way. Its
effectiveness shall be subject to evaluation by
independent experts.
Relation With Other Models
• No clear correspondence with BLP, Biba, or
Chinese Wall models
• Clark-Wilson model
– CDIs (Constrained Data Items)
• Medical records and access control lists
– TPs (Transformation Procedures)
• Requests to read, insert or modify patient information and
their access control lists
– IVPs (Integrity Verification Procedures)
• Verifier model
– Certification rule 4
• Audit trail
Prototype Design
• We designed a prototype system that
allows doctors, nurses, and patients to do
read, modify, and insert of patient
information and medical records as
permitted by HIPAA
Design Overview
Server machine
Client machine
How Design Relates to Principles
• KeyNote
Access control
Patient access
ACL management
• Server
Emergency access
ACL management
• Encryption between
client and server
– Transmission security
• Audit Trail (log)
– Audit control
• Verifier
– Enforcement
Design Decisions
• Client and server application – Java
– Multithreading
– Access to database using JDBC
– Platform independent
• Three-tier model
Server maintains control over access and updates
Simplifies the deployment of applications
Performance advantage
• Application-specific security policies and
credentials are expressed using a general
purpose framework
• Compliance checker determines whether a
given action requested by a given principal
complies with security policies
Our Use of KeyNote
• Every user has a public/private key pair
• Security official
– Responsible for entering policies
– Policies allow each patient’s administrator doctor full
access to the patient’s information
• Administrator doctor
– May enter credentials (i.e., signed assertions)
allowing other doctors/nurses read and write access
to his/her patients’ information
• Policies and credentials are stored in a database
Example Policy
keynote-version: 2
comment: doc1 is the administrator doctor
for pat1
authorizer: "POLICY"
licensees: "DSA:abcd123456" # doc1's pub key
conditions: app_domain == "HIPAA" &&
patient_id == "pat1" &&
(requested_act == "READ" ||
requested_act == "MODIFY") &&
(data == "patients_info" ||
data == "access_control")
-> "true";
Another Example Policy
keynote-version: 2
comment: doc1 is granting read and insert
access to doc2 for pat1's
patients_record and referral
authorizer: "DSA:abcd123456" # doc1's pub key
licensees: "DSA:dead1357" # doc2's public key
conditions: app_domain == "HIPAA" &&
patient_id == "pat1" &&
(requested_act == "READ" ||
requested_act == "INSERT") &&
(data == "patients_record" ||
data == "referral") -> "true";
signature: "DSA-SHA1:1f4C539B02"
# signed by doc1 with his private key
What KeyNote Doesn’t Do
• Emergency access
– Would be possible to handle in KeyNote, but
would require an assertion that lists every
doctor and nurse as licensees to access any
patient’s information
• Restricting the type of credentials that
each administrator doctor may add
– We don’t want administrator doctors
delegating the right to change patients’ ACL
Verifier Application
• Also a Java application
• Retrieves log records
• Checks logged events vs. new or old
• Could catch violations due to bugs in
server application
• If there was an error in the policy, can
check if old events comply with corrected
Evaluation: Advantages
• Three-tier model for better security and
• Use Java for client and server application
• KeyNote for access control
• Unified logging mechanism for PHI
accesses and policy updates
• Verifier automates the auditing process
Evaluation: Disadvantages
• Large number of assertions
– Might not be scalable
• Security official might be a single point of failure
• Signing the assertions might be inconvenient for
administrator doctors
• Server application being compromised could be
• So could administrator doctors' private keys
being stolen
Future Work
• Evaluate how to make the access control
more scalable
• Extend model to other user types such as
insurance companies and researchers
• Extend verifier application to flag
suspicious access patterns
Questions or Comments?
Пожаловаться на содержимое документа