Action plan: Present the executive staff with findings about what will be needed, while emphasizing the potential business benefits.
We were similarly situated when we chose to improve our credit card-handling processes by going through a full Level 1 type of PCI assessment. We fall short of the number of credit card transactions that would make a full Report on Compliance necessary, but we made a business decision to become more attractive to customers by reaching that level of compliance. When it comes to personally identifiable health information (PHI), some customers have said they would like to store it in our application. Up to now, we have advised against that because we are not HIPAA-compliant. But with the realization that our stance could result in some lost opportunities with prospective customers, we’ve decided to look into what it would take to reach HIPAA compliance.
To get started, I hired a third party to assist with a gap analysis. It turned up one area where we have a big gap between where we are and where we should be for HIPAA purposes: logging. A second gap that we identified, in the area of encryption, is not a problem for HIPAA compliance (surprisingly, encryption of data isn’t mandatory under the current requirements), but we nonetheless decided it was a failing that could contribute to customers’ reluctance to use our application.
For HIPAA, companies have to create, enable, collect and store a lot of log data. You need to know who accessed data and whether they just viewed it or changed something. If they did make changes, you need to know when they changed it and the previous value before the change was made. Was a report generated, and did that report contain any PHI Was data transferred to a third party via our API or some other data-delivery mechanism If so, what data was transferred, where did it go and who initiated the activity All of the log data needs to be available in a timely manner and retained for a certain period of time. To make all of that possible will require a considerable amount of engineering effort.
Encryption is also problematic. We already encrypt things such as passwords and credit card data (which is, of course, a PCI requirement). But our application architecture makes it extremely difficult to encrypt all data in the database, because application performance would take a hit, and we are very sensitive to our customers’ needs for a high-performing application.
We could offload encryption to a third party, we could encrypt the entire hard drive, or we could encrypt data at the application layer, which would provide encryption at rest.
The operations team was leaning toward encrypting the hard drives, because options that are fairly easy to deploy are available. I agreed that it would be easy to do, but I objected that the method wouldn’t really be effective from a security perspective (and encryption is one thing that should be all about security). When you encrypt a hard drive, you are ensuring that anyone who comes into possession of that drive can’t access the data. In other words, the only way such encryption would protect the company would be if the hard drive were stolen. Now, the likelihood is infinitesimally small that a bad guy is going to determine where our highly secure data center is located; get past the security guards, man traps and biometrics; and then figure out which of the hundreds of drives to pull out.
Encrypting the data as it sits in the database is more secure, but it requires a considerable amount of coding. Besides encrypting the required data, you have to be able to unencrypt it when it’s needed in reports, visually rendered in the application or called up during other required data-delivery operations.
Now that the gap analysis is complete, the findings will be presented to the executive staff, which will make a business decision: Is it worth the time, money, resources and shifting of other priorities to become HIPAA-compliant, or do we continue to turn away business
Phrasing the question like that should do the trick.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
Click here for more security articles.