Show Menu

Oracle Security HIPPA Requirements Cheat Sheet by

oracle     security     hipaa


To present a holistic and indepe­ndent view of the requir­ements, we turned to the indepe­ndent industry associ­ation Associ­ation for Electronic Health Care Transa­ction, Inc. (www.a­feh­ct.o­rg), of Elmsford, NY, which has developed an excellent checklist for HIPAA security compli­ance.
Oracle Privacy Security Auditing Includes HIPAA Regulatory Compliance
Second Edition Arup Nanda

Unique individual identifier for each user

This essent­ially translates to the unique identifier for a user in the database. Even if an LDAP solution is used to authen­ticate users, the database must have the LDAP user identi­fied. The simplest way to achieve this compliance is to create an individual user id for each named user. If that is not possible, then the next best altern­ative is to use Single Sign On (SSO) using LDAP and Oracle users identified Extern­ally. If an applic­ation using a database table authen­ticates users rather than LDAP, then a method for secure applic­ation user authen­tic­ation must be followed that is not easy to break and is immune to attacks such as SQL Injection.

Automatic logoff after specified time

This requires that if a user is idle for some specified time, the connection must be termin­ated, requiring the user to login again. Idle connec­tions are easy targets for hackers. Chapter 4, the section on Profile Based Security, explains how to achieve this using Oracle Profiles.

Change passwords often (enforced by system)

Even if the hackers crack the password, if they are changed often, the discovery becomes useless. However, most users do not change their password often. This requir­ement calls for establ­ishing a mechanism that forces the users to change passwords at regular intervals.

System generates random password

This requir­ement makes the assumption that most admini­str­ato­r-a­ssigned passwords are easy to guess, as they are either the same every time or follow a pattern. Therefore, the system assigned passwords should be random. In Oracle, however, the better option is to assign a password and expire it immedi­ately. When the user logs in, he will be prompted for a new password, thus elimin­ating the need to have a random system generated password.

Weak passwords not allowable

Weak passwords, i.e. those are easy to guess and amenable to cracking by hackers, come in many forms. Some are as easy as just common terms: abc123, password, the user?s user id, etc. In order to prevent a weak password, Oracle?s Password Management Function is handy. It checks the password the user chooses and uses a stored procedure to check to see if it conforms to a standard establ­ished by the DBA.

System stores password encrypted

This is not a problem for Oracle user ids, as the password is stored in hash format and cannot be retrieved by the DBA; it can only be changed. However, other types of password manage­ment, such as that done through the applic­ation using a database table, tend to be stored in clear text. This practice should be prevented and the passwords should be encrypted using Oracle?s Obfusc­ation Toolkit, which is a set of encryption APIs.

Uniform User ID across organi­zation

This requir­ement calls for assigning a single user id to a physical user, regardless of which system the user accesses. This is desirable for several reasons, the most important being the ability to maintain strong passwords. However, this may be quite difficult to achieve. For instance, co-exi­stence of legacy and open systems requires different ways of handling authen­tic­ation and is not the same in all cases. In some cases, disparate systems can still be consol­idated under a single user authen­tic­ation system using Single Sign On (SSO). A user might logon to the Company network running Microsoft Windows. The database users can be LDAP users created by the clause ?ident­ified extern­ally?. This allows all three systems ? domain, email and database to have the same user id and password, i.e. the same authen­tic­ation system.

Incentives to reduce key account sharing

This follows the same premise as the first requir­ement ? users should have their own user ids, be they in database, in some directory, or in some applic­ation user table. This is possible by using unique ids for all users.

Single-use or token based passwords

This is not strictly within a database framework. It means the ability to assign a password that can be used only once, after which the password expires. This can be implem­ented in an indirect way, using triggers to capture when the user logged in and then altering the DBA to expire the account, or change the password.

Token card plus password or PIN

This security model requires two forms of authen­tic­ation ?a password and a token card. This combin­ation is challe­nging for the hackers to break. Oracle Advanced Security provides several options to use Token Card Authen­tic­ation in addition to passwords.

Biometric (finge­rprint, retinal scan, etc.)

An altern­ative to using token cards, etc. is using biometric authen­tic­ation. Authen­tic­ation is done using physical attributes such as retinal scans and finger­prints. It authen­ticates the person, not just the holder of an authen­tic­ation token.

Caller-ID verifi­cation of remote location

In this security model, the remote user calls up the system from a known phone number as verified by the caller id service. This model falls in the telephone connec­tivity software setup, which is outside the Oracle database security framework.

Telephone callback for remote users

This is also outside the realm of the Oracle database security framework. After a user dials the number for remote connec­tivity, the number is confirmed by caller id service as that of a known caller. The call is then terminated and the system initiates the call to the remote number to establish the connec­tion. This ensures security even if the remote user somehow masque­rades the calling number.

Different security in different locations

This falls under the domain of physical security. A terminal located inside a physically secure data center is less likely to be attacked as opposed to one outside.

Comply with Orange Book C2 or better

This is a security specif­ication recomm­ended by an indepe­ndent party. Oracle database and software is already compliant, so there is no cause of concern for compliance here.

Account canceled when employee leaves

This calls for procedural modifi­cations to the security admini­str­ation. When an employee leaves, there should be a well-d­efined procedure for the help desk to system­ati­cally lock all the accounts used by the employee ? email, domain, and database. Often, mostly due to lack of proper procedure, the accounts are left open, which can become prime targets for hackers.

Emergency access for forgotten password

This is a procedural issue. Forgotten passwords are common among users, and the request to retrieve them costs a lot for the organi­zation. This results in a generic password resetting method used by the help desk. This can be easily integrated with Oracle passwords by changing the password and then expiring it immedi­ately. The user logging in will have to set a new password upon logging in.

Download the Oracle Security HIPPA Requirements Cheat Sheet

2 Pages

PDF (recommended)

Alternative Downloads

Share This Cheat Sheet!



No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Oracle SQL Developer Keyboard Shortcuts

          More Cheat Sheets by Davidpol

          Inspecting Home for Fall Hazards Cheat Sheet
          Barcelona Principles 2.0 Cheat Sheet