HIPAA Database Security Audit

Burleson Consulting takes a holistic approach to Oracle Database Security related to HIPAA regulations.  We evaluate the security measures currently in place from a database perspective, report our findings and make recommendations according to our discovery.   In addition we will review your existing auditing procedures related to the database and make recommendations for ongoing auditing and monitoring. 

The Health/Insurance Portability and Accountability Act of 1996 (HIPAA) was created to ensure privacy for medical patient data. HIPAA requires complete auditing to show everyone who has viewed confidential medical patient information.  This permeates from Hospitals, insurance companies, and dozens of healthcare related industries.  HIPAA is a framework that provides a complete security access and auditing for Oracle database information.

A proper HIPAA compliant security implementation makes sure all these access points are identified clearly and that proper security and auditing are firmly in place. As any seasoned IT professional would guess, the most sensible way is to seal off all access points except the bare minimum, and to audit access at those points.

In the next section you will find the main areas that will be scrutinized by Burleson Consulting for HIPAA compliance related to the Oracle database and it’s environment.


Oracle Database Security and Audit Review Areas:

• Security Administration
  
  This is the procedures and policies of maintaining security overall within the database and it’s environment.   In order to maintain proper security of the data,  one of most, if not the most important facet is to monitor and audit that administration.   This is akin to policing the police. 
   
• User Access Control

When users wish to connect, the database makes sure that they are indeed authorized to access, a process known as Authentication. This can occur in several ways – the users could be defined as users in the database and then authenticated, or they may have been authenticated elsewhere and their credentials are passed on to the database as valid.

• Oracle Created Accounts
  
  After Oracle is installed and a database is created, several users are created that may not necessarily be required by the application. In Oracle 9i, at least they are prompted to have a non-default password and most of them are locked. But in Oracle 8i and prior versions they are not. These accounts, such as the user DBSNMP, may have sweeping privileges and provide a back-door security hole. These must be identified and shutdown.
   
• Object Access
  
  Granting privileges to an object requires careful analysis and planning. Under no circumstances should a user be granted all the possible privileges on an object. HIPAA requirements clearly mandate that the access privileges of users be documented and enforced.
   
• Data Change
  
  The regular auditing features of Oracle record that the user has updated some rows of a table, but not which particular rows, and more importantly, what the value was before the change. HIPAA compliance requires that the sensitive data be audited for changes, and that means recording the pre-change value as well as the post-change one. Some other security and auditing policies, such as the Safe Harbor Law, may also mandate that.
   
• DDL
  
  Data Definition Language (DDL). The DDLs are used to create tables, views, procedures, etc. They are also used to modify the structure of such objects, e.g. changing the length of a column from 12 digits to 15. Under HIPAA regulations, any alteration to the structure of the data containers, such as tables and views, should be strictly audited. 
   

• Server Errors
  
  Although it may not be strictly necessary to audit the errors encountered by the Oracle server, the recording of this information may provide clues on potential threats. Oracle audits errors through an event named servererror, which triggers a piece of code.  After this trigger populates the servererror_log table, a complete report on the potential threats, etc. can be obtained.
   
• Grants
  
  Oracle provides auditing options to record object accesses only with this privilege. The audit trail can be examined to see what kind of objects the user is accessing. Later, using the information, the user can be given appropriate grants.
   

• Archiving Audit Data
  
  The size of the data in the audit trail, no matter how it is collected, grows with time. This requires periodic purging so that the size is manageable. However, the old purged data can't just be thrown away in most cases, it might be useful for analysis later.
   
• Database Log Files
  
  The Oracle database creates a log file of its activity called alert log. Any time a specific database maintenance activity occurs, a record is written into this file. These events include adding a data file, adding or dropping a tablespace, etc. The information in the log file should be preserved to maintain a record of when certain events occur.
   
• Network Access
  
  Oracle Net (also known as SQL*Net or Net8) creates certain log files during its operation. A prominent one is produced by the listener process, which records the incoming requests for connection, as well as the status, i.e. whether or not those requests are successful. This can be very useful in analyzing database connections.
   

• Materialized Views
  
  The MV can be refreshed from time to time.  Because the data is not up to date, the data the user sees depends heavily on the time the MV is created or refreshed. This may sound irrelevant, but consider a situation where the patient record shows that the patient has a common cold. This is not a piece of protected health information and, therefore, the MV is refreshed with this information. Later, the diagnosis is changed to HIV, and this record becomes part of PHI.  This indicates why it is important to record the time when the refresh is performed – it indicates the nature of the data that was visible to the users at a given time. This type of auditing is not usually set up by DBAs, but it is important to consider recording the refresh times.
   
• Replication
  
  The process of maintaining a data image in another database is known as replication. For instance, to decrease the load on the production database, the data can be replicated to a different database, and a reporting application can run from there.  The same problem with timing of the refresh comes into play here. The data at the replicated site is not as current as the master site. It is as current as the last time it was refreshed. Therefore, a careful analysis of when it was refreshed must be maintained to identify the nature of the data visible at a certain time.

In the next section you will find a checklist overview of various key Oracle security features to be reviewed.
 

Oracle Security Features Checklist

• Firewalls for the servers exist and the database server is not directly accessible from the firewall.
   
• UNIX file permissions for key Oracle executables are acceptable.
   
• Oracle executable has the execute permissions removed for others.
   
• UNIX filesystem permissions are as per the acceptable security standard.
   
• The trace directories are not mounted or shared with any other host.
   
• The init.ora parameter utl_file_dir is not set to "*", but some specific directory, and that directory does not contain any sensitive files.
   
• The init.ora parameter _trace_files_public is not set at all, or is set to FALSE.
   
• The SYS user is protected against any unauthorized access from the OS user belonging to the group DBA or OINSTALL.
   
• Any UNIX process does not display the passwords. If a password must be used, it is protected by a password supplying script so that the ps –aef command dos not show the password.
   
• A user is authenticated either by password or by the OS, never both.
   
• The remote operating system authentication is turned off.
   
• The operating system authenticated users are kept to the minimum and they have the least privileges.
   
• The parameter os_authent_prefix is set to "" (null).
   
• The domain authentication (in Windows) is TRUE (default).
   
• Remote user group management is false.
   
• Oracle created accounts such as HR are dropped or expired, if not used.
   
• The password of the DBNSMP user is not the default, DBSNMP. The Oracle Intelligent Agent parameter files are updated accordingly.
   
• A password management function exists and is enforced by a profile.
   
• No user has sweeping system privileges.
   
• No user has CREATE DIRECTORY privilege.
   
• No non-schema user has schema creation privileges.
   
• No user has more than required space quota on any tablespace.
   
• The users have only those grants required by the application, not more.
   
• No user has grants with ADMIN option.
   
• Roles have adequate privileges, not more.
   
• Profile is set to disconnect users after a certain time and idle time.
   
• A view-based security exists for critical data that should be shown only based on the user who logs in.
   
• Critical functionalities in an application are encapsulated via stored programs.
   
• The programs are created with the Invoker rights model so that the privileges can be checked at the run-time.
   
• Adequate measures have been taken to protect against SQL Injection attacks.
   
• SQL*Plus is secured using Product Profiles.
   
• Restrictions have been placed in sqlplus for some commands such as HOST, which can be potentially vulnerable in the hands of malicious users.

Click here for details on Oracle software AuditPack services for HIPAA and secure databases.

For details on Oracle HIPAA Auditing Consulting for HIPAA audits, call