HIPAA and HITECH Detailed Analysis

HIPAA is the Health Insurance Portability and Accountability Act. HITECH is the Health Information Technology for Economic and Clinical Health Act. These are Federal Laws in the United States that requires, among other things, to protect individual’s health care information. Below is a detailed analysis of the laws and the regulation with relation to Oracle database auditing, and how this translates to practical requirements.
Go to page123All

The Law

Title 42 of the United States Code is the Public Health and Welfare. Chapter 156 is Health Information Technology. Subchapter III is Privacy. Part A (§17931 – §17940) is Improved Privacy Provisions and Security Provisions.
§17931 (c) Annual guidance
...the Secretary of Health and Human Services shall... annually issue guidance on the most effective and appropriate technical safeguards for use in carrying out the sections referred to in subsection (a) and the security standards in subpart C of part 164 of title 45, Code of Federal Regulations...
§17940. Audits
The Secretary shall provide for periodic audits to ensure that covered entities and business associates that are subject to the requirements of this subchapter and subparts C and E of part 164 of title 45, Code of Federal Regulations...
In other words, we need to look at the regulation to see how HIPAA and HITECH should be implemented.

The Regulation

Title 45 of the Code of Federal Regulations is the Public Welfare and Human Services. Part 164 deals with Security and Privacy.
The interesting subparts are:
  • Subpart C — Security Standards for the Protection of Electronic Protected Health Information
  • Subpart E — Privacy of Individually Identifiable Health Information
To help you understand how HIPAA relates to Oracle database auditing, we’ve included relevant portions of the regulations, with our interpretation of the requirements in practical technical terms.
A good place to start is by reading the beginning:
§ 164.306 Security standards: General rules
(a) General requirements. Covered entities must do the following:
(1) Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity 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 subpart E of this part.
(4)Ensure compliance with this subpart by its workforce.”
The “General Rules” are important as they explain the intention of the regulation. Don’t be dismayed by the generality of these paragraphs as HIPAA provides a lot more detail later on.

The Process

§ 164.308 (a)(1)(i) Standard: Security management process.
Implement policies and procedures to prevent, detect, contain, and correct security violations.
(ii) Implementation specifications:
(A) Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity.
(B) Risk management (Required). Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with §164.306(a).
(C) Sanction policy (Required). Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity.
(D) Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.
This means that HIPAA follows the same basic principals as most compliance regulations:
  • Evaluate Risk
  • Implement Controls to reduce the risk
  • Audit activity on a regular basis
While the risks and controls tend to be similar in many environments, this article focuses on Oracle database auditing and, therefore, on the last point – audit the activity [164.308 (a)(1)(ii)(D)]
Since the regulation was not written specifically for the Oracle database, it does not mention sessions or SQLs. It does however mention access reports which translate into two things in Oracle databases:
  • Sessions – Anyone accessing Oracle databases that contain PHI (Protected Health Information)
  • SQLs – Any SQL that is accessing Oracle tables that contain PHI (Protected Health Information)

The Workforce

§ 164.308 (a)(3)(i) Standard: Workforce security.
Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information, as provided under paragraph (a)(4) of this section, and to prevent those workforce members who do not have access under paragraph (a)(4) of this section from obtaining access to electronic protected health information.
(ii) Implementation specifications:
(A) Authorization and/or supervision (Addressable). Implement procedures for the authorization and/or supervision of workforce members who work with electronic protected health information or in locations where it might be accessed.
(B) Workforce clearance procedure (Addressable). Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate.
(C) Termination procedures (Addressable). Implement procedures for terminating access to electronic protected health information when the employment of a workforce member ends or as required by determinations made as specified in paragraph (a)(3)(ii)(B) of this section
An “Addressable” requirement can have different implementations depending on the environment, and alternate implementations could be acceptable given documentation of the justification.
Section (A) discusses the authorization or supervision of the workforce. A likely implementation in the Oracle database would be:
  • Authorization – only employees that should have access to PHI should be granted such access. In most cases, only the application should access PHI.
  • Supervision – employees whose access cannot be restricted (i.e. DBAs), should have their activities supervised. That means that all the activity of DBAs and privileged users should be recorded and reviewed by appropriate personnel

Access Management

§ 164.308 (a)(4)(i) Standard: Information access management.
Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part.
(ii) Implementation specifications:
(A) Isolating health care clearinghouse functions (Required).
If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization.
(B) Access authorization (Addressable).
Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism.
(C) Access establishment and modification (Addressable).
Implement policies and procedures that, based upon the entity’s access authorization policies, establish, document, review, and modify a user’s right of access to a workstation, transaction, program, or process.
Paragraphs (C) discusses the way in which access is granted. The mechanism involves:
  • Establishment – the process for determining whether access should be granted, and the type of access needed.
  • Modification – the process that eventually grants the access
  • Documentation – the method used to record the establishment and modification (e.g. a change control system)
  • Review – the method used to audit all the steps.
The last step requires a little more clarification. A possible implementation of the review process could be:
  • Audit – report on all Oracle database changes to users and privileges (Authorization DDLs)
  • Reconcile – compare the audit reports to the change control system to ensure no other permissions were granted
  • Approve – occasionally re-approve all the granted permissions to ensure current job duties require the permissions granted

Login Monitoring

§ 164.308 (a)(5)(C) Log-in monitoring (Addressable).
Procedures for monitoring log-in attempts and reporting discrepancies
The login monitoring requirement is very clear – HIPAA compliance requires monitoring of successful and failed logins to the Oracle database.

Audit & Integrity

§ 164.312 Technical safeguards.
A covered entity must, in accordance with §164.306:
(a)(1) Standard: Access control. Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in §164.308(a)(4).
...
(b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.
(c)(1) Standard: Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.
Paragraph (a) clearly states that auditing is required. The likely implementation in Oracle databases is auditing of SQL activity in general, and one that accesses PHI in particular.
Paragraph (c) discusses integrity of PHI. The likely implementation in Oracle databases is:
  • Limit access to PHI. Usually that would mean that only the application (and DBAs) could write to tables containing PHI.
  • Audit SQLs that access PHI – to ensure DBAs and privileges users do not modify PHI

Privacy Safeguards

Subpart E deals with privacy of PHI, and the only portion of this subpart that has relevance to Oracle database auditing is this:
§ 164.530 (c)(1) Standard: Safeguards.
A covered entity must have in place appropriate administrative, technical, and physical safeguards to protect the privacy of protected health information.
(2)(i) Implementation specification: Safeguards.
A covered entity must reasonably safeguard protected health information from any intentional or unintentional use or disclosure that is in violation of the standards, implementation specifications or other requirements of this subpart.
(ii) A covered entity must reasonably safeguard protected health information to limit incidental uses or disclosures made pursuant to an otherwise permitted or required use or disclosure.
As you can see, the privacy portion doesn’t provide detailed requirements and leaves the implementation to you. However, likely implementations in Oracle databases would include at the very least:
  • Least Privilege – make sure access to such information is as restricted as possible. In most cases, only the application (and DBAs) will have access.
  • Audit – audit all access to such information to ensure it is not accessed by DBAs, privileged users, or anyone else that should not be looking at it
Additional suggestions are available in the last section below.

Put Together

The regulations repeat several times the need to audit Oracle database activity. At a minimum, the regulations require this in terms of Oracle database auditing:
  • Session Auditing – Audit all logins and failed logins in the Oracle database – §164.308(a)(5)(C)
  • DBA Auditing – Audit all SQL activity of DBAs & privileged users – §164.308(a)(3)(i)(A)
  • PHI Write Auditing – Audit all DML SQL activity that modified tables containing PHI – §164.312(c)(1)
  • PHI Read Auditing – Audit all queries (select) that access tables containing PHI – §164.530(c)(2)
  • Authorization DDL Auditing – Audit all authorization DDLs. Creation, altering, and deletion of Oracle accounts as well as granting, and revoking of privileges – §164.308(a)(4)(ii)(C)
While the above issues are pointed out specifically, the overall responsibility for the data lies on you (For PHI: §164.308(a)(1)(ii)(B), For privacy: §164.530(c))
It is, therefore, up to you to determine what additional security measures should be deployed. While every environment is different, a good start from an auditing perspective would be:
  • Application Account Security – report on unapproved usage of the application account
  • PHI Security - SQL Anomaly – report on unusual SQL access to tables with PHI information
  • DDL Activity – report on all DDL activity in the database
  • Program Monitoring – monitor all program activity for programs like SQL*Plus and Toad
  • SQL Injection – report on suspicious SQL activity that could indicate an attack such as a SQL injection
  • High SQL Volume – report on unusually high frequency of particular SQLs, from particular accounts, machines etc.
  • New SQL Sources – report on SQL sources that haven’t been seen recently (such as accounts, machines, or programs)