Secure Personal Health Information (PHI)

I get frustrated when someone throws around that they have developed a system that keeps PHI “secure.” I have a checklist that I generally go through as attacks come in many forms and there is not a single solution that addresses all attacks.

SSL Access

The first step in security is generally forcing all traffic to and from the website to be sent over a secure connection.  This connection can be established by either generating a self signed certificate or purchasing a secure certificate from a signing authority.  Neither encryption is stronger per say.  The benefit of purchasing the secure certificate from the signing authority is that your identification can be confirmed.

If you purchase a certificate from a signing authority and a third party attempts a man in the middle attack on one of your clients, the client’s web browser will warn the client that the secure certificate is not signed by a valid authority.

Often when someone says their system is “secure,” this is the extent of their claim.

Prevent Page Caching

If your client forgets to close their browser session at the conclusion of their time on the website, it is possible that a third party with physical access to the machine be simply be able to use the back button to navigate to a page that has been cached.  The solution here is relatively easy although you cannot guarantee your clients’ web browser implements any of these common measures.

<meta http-equiv=”cache-control” content=”max-age=0″ />
<meta http-equiv=”cache-control” content=”no-cache” />
<meta http-equiv=”expires” content=”0″ />
<meta http-equiv=”expires” content=”Tue, 01 Jan 1980 1:00:00 GMT” />
<meta http-equiv=”pragma” content=”no-cache” />

Non-MD5 Passwords

If your clients are using dictionary words as their password or basing passwords on dictionary words, the system may be compromised.  While any hashing method is at risk for a brute force attack, if your users’ password hashes are compromised, MD5 is probably the least secure and easiest to reverse look up in attempt to retrieve the plain text password.

Sanitizing Database Input

An sql injection attack is an attack on a database where a third party submits malformed input into a form that is submitted to the database.  The malformed input then either allowed unauthenticated users to gain access to the system or worse, to allow remote code execution and compromise access to the whole system.

SSL Database Communication

If the database is on a separate machine, there is always the possibility of someone sniffing the connection between the website and database host.  This is not an issue of the database and webserver reside on the machine.  The solution, like above, is to force encryption of the communication.

Allow Database-level Encryption

You can encrypt the database on the filesystem.  This prevents someone from copying the database and accessing it on other system.  This isn’t a perfect scenario as the keys for the encryption are typically stored on the hard disk so if the keys are compromised as well, the encryption doesn’t help a lot.

Allow Filesystem Encryption

Unlike database-level encryption, filesystem-wide encryption typically does not have the keys stored on the device but are instead entered at type of booting the system or mounting the filesystem.  This protects against a third party with physical access to the machine from unplugging it and taking it to a lab somewhere.  It also prevents a third party from reading the disk by booting off a usb or cd.

Two Factor Authentication

If a third party steals a client’s password, two factor authentication prevents the third party from logging in.  The basic idea is that you can only log in with something you know and something you have.  The former is generally a password.  The latter is typically a key fob, pager, or cell phone.

Further Encryption

In the event the only a few users have access to discrete information stored in the database, it might make sense to encrypt the information prior to storage with a key that is entered by the client at time of entering and retrieving the data.  The biggest benefit to this system it that even if you had over the data in the form of an sqldump to a third party, that party would still need the key to decrypt the information.  Therefore, the only attack would be intercepting the communicating after decryption and before deliver to the client or a brute force attack on the encrypted information.  In this scenario, even the system administrator cannot gain access to the information so even a fully compromised system protected personal health information.

There are three major downsides however.

1. it is difficult to allow new clients access to the information
2. if the key is a secondary hash of the client’s password, great care has to be taken if the client ever changes his or her password
3. in the event that a client forgets his or her password, the information is lost

Hopefully this helps in a primary security evaluation.  Prior to implementation of any system, contact your security officer.