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

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)