To present a holistic and independent view of the requirements, we turned to the independent industry association Association for Electronic Health Care Transaction, Inc. (www.afehct.org), of Elmsford, NY, which has developed an excellent checklist for HIPAA security compliance.
Oracle Privacy Security Auditing Includes HIPAA Regulatory Compliance
Second Edition Arup Nanda
Unique individual identifier for each user
This essentially translates to the unique identifier for a user in the database. Even if an LDAP solution is used to authenticate users, the database must have the LDAP user identified. 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 alternative is to use Single Sign On (SSO) using LDAP and Oracle users identified Externally. If an application using a database table authenticates users rather than LDAP, then a method for secure application user authentication 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 terminated, requiring the user to login again. Idle connections 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 requirement calls for establishing a mechanism that forces the users to change passwords at regular intervals.
System generates random password
This requirement makes the assumption that most administrator-assigned 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 immediately. When the user logs in, he will be prompted for a new password, thus eliminating 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 established 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 management, such as that done through the application 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 Obfuscation Toolkit, which is a set of encryption APIs.
Uniform User ID across organization
This requirement 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-existence of legacy and open systems requires different ways of handling authentication and is not the same in all cases. In some cases, disparate systems can still be consolidated under a single user authentication 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 ?identified externally?. This allows all three systems ? domain, email and database to have the same user id and password, i.e. the same authentication system.
Incentives to reduce key account sharing
This follows the same premise as the first requirement ? users should have their own user ids, be they in database, in some directory, or in some application 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 implemented 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 authentication ?a password and a token card. This combination is challenging for the hackers to break. Oracle Advanced Security provides several options to use Token Card Authentication in addition to passwords.
Biometric (fingerprint, retinal scan, etc.)
An alternative to using token cards, etc. is using biometric authentication. Authentication is done using physical attributes such as retinal scans and fingerprints. It authenticates the person, not just the holder of an authentication token.
Caller-ID verification 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 connectivity 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 connectivity, 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 connection. This ensures security even if the remote user somehow masquerades 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 specification recommended by an independent 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 modifications to the security administration. When an employee leaves, there should be a well-defined procedure for the help desk to systematically 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 organization. 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 immediately. The user logging in will have to set a new password upon logging in.