Historically HIPAA has allowed covered entities to self-interpret security initiatives for the most part but the new ARRA/HITECH will cause a significant uphill battle for compliance.
In this economic downturn, due to budget restrictions most security initiatives are implemented not because the enhancement helps protect the network but because the company needs to meet one of the many regulations, whether SOX, HIPAA, PCI or a government C&A. All regulations call for encryption! In complex networks that requirement alone could extend to 75% of the network!
Let’s momentarily visit my nightmare – HIPAA. For readers that are not familiar with HIPAA, it’s the healthcare regulation that is divided into 3 primary sections – Technical, Physical, Administrative. The regulation has historically been hugely open to interpretation as the sub-sections are categorized as ‘Required’ or ‘Addressable’. In my opinion, the biggest downfall of HIPAA is that it doesn’t provide any more guidance or insight into either Section and doesn’t explicitly define fairly cornerstone concepts. I understand HHS’ original intent for the casual restrictions was so smaller ‘covered entities’ wouldn’t get bumped out but with the recent ARRA and HITECH provisions it’s obviously that HHS is starting to tighten its hold on the InfoSec aspect. But until that clarification is released, we’re left to decipher HIPAA for ourselves (and hope the auditors and lawyers meet us half way).
HIPAA “indirectly” requires log auditing to consist of the following (of course HIPAA doesn’t explicitly say this but reaching out to 6 fairly well known HIPAA auditors they individually concurred with this):
WHO did WHAT (action) to WHAT (data) WHEN (timestamp) and from WHERE (IP or terminal ID – especially for remote access).
Now most default database audit logs don’t capture that extensive level of information so DBAs need to enable C2 auditing (https://www.databasejournal.com/features/mssql/article.php/3399241/SQL-Server-2000-Security—Part-10—Auditing.htm). Not a huge deal but now the database logs become as sought after as the database itself! So not only do I need to encrypt the transmission of the logs to the log server but now I face the hard drive encryption solution for log server. Introducing data-at-rest encryption on servers…CRAP!!!
So 3 take aways from this:
- Log servers within HIPAA networks are more of a primary target than the database server!
- Encrypting sensitive data does make sense but between data-at-rest encryption (on servers, as well as, backup tapes) I would highly recommend companies keeping an UNENCRYPTED database just in case. Obviously keep the unencrypted database offline, air-gapped and kept locked away in a dual biometric accessed safe in a SCIF-ish datacenter (or the closest equivalent your company can afford) that only the most trusted employees can access.
- AND MOST IMPORTANTLY – companies aren’t ready for this new ARRA/HITECH level of compliance and while it absolutely makes sense…it will cause mass confusion!
