HIPAA and HITECH in Oracle Databases
HIPAA and HITECH are are federal laws in the United States. HIPAA is the Health Insurance Portability and Accountability Act. HITECH is the Health Information Technology for Economic and Clinical Health Act.
HIPAA and HITECH include requirements for security protection of individual’s health information (§ 164.306). The protected information is called PHI (Protected Health Information) or EPHI (Electronic Protected Health Information).
As part of it’s goal of securing Protected Health Information (PHI), HIPAA requires a risk-control methodology (§ 164.308 (a)(1)).
In addition to the risk-control approach, HIPAA also details specific security aspects that must be addressed. Those aspects include, for example, Access Management, Integrity, the Workforce, and Privacy. For more information about the security aspects that relate to database auditing, see our detailed analysis.
Included in the detailed security requirements are auditing requirements as well. Those auditing requirements are not sufficient for HIPAA compliance, but can be seen as a minimal expected level:
- 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)
We have to stress that this only reflects our analysis of HIPAA as it relates to Oracle database auditing. Setting up proper security entails more than just database auditing, and every environment can have different requirements.
Compliance and implementation of Oracle database auditing always poses multiple challenges, the most difficult of which is the data capture. Data capture is the method used to collect the audit information from the Oracle database and transport it to secured log facility.
The reason this is a problematic issue is the data volume. Oracle databases tend to process thousands if not tens of thousands of SQLs per second, and auditing each one has the potential of slowing the database to a halt.
Query capture is vital in several HIPAA requirements, and most prominently in the Privacy section that has the entire Subpart E devoted to it. While there are several ways to capture DMLs and DDLs, only three methods will capture queries (select) as well:
- Oracle Auditing – The old well known built-in Oracle audit facility. Unfortunately, it slows the database to a halt, and almost no Oracle DBA will turn this on in a production database. Additionally, this feature has no log security, transport, processing, reporting etc.
- Fine-Grained Auditing – FGA is a newer built-in facility in Oracle that allows partial auditing of pre-defined activity only. It has several technical limitations (such as DDLs and overhead), in addition to the lack of processing, reporting etc.
- Core Audit – A complete 3rd party solution from Blue Core Research that includes capture, processing, reports and more. The new Full Capture technology developed by Blue Core Research, can perform full auditing at less than 3% overhead.
Core Audit’s Full Capture is the only capture technology that provides 100% capture of all the activity in the Oracle database at an overhead that will not impact any production environment.
The other challenges in implementation of Oracle database auditing relate to processing of the audit data, storage, long term retention, and reporting.
Your options are:
- Oracle Audit Vault & Database Firewall – These costly Oracle products can only use the Oracle data captures (with their limitations), and are complex to install and manage.
- SIEM – Many 3rd party solutions called SIEM exist. However, they all require a data capture source to feed them activity from Oracle databases. Your options are the above mentioned Oracle Auditing, FGA, or Core Audit.
- Core Audit – A complete 3rd party solution from Blue Core Research equipped with everything needed for HIPAA database auditing compliance and much more. It comes built-in with its own Full Capture agents, repository, reports, incident investigation tools, and more.
I want to know more about Core Audit!Great! Here are a few options: