Encryption's Role in Risk Management

Pinpointing the Best Applications for HITECH Compliance
Healthcare organizations need to develop a better understanding of how encryption fits as one of many components in a broad risk management strategy, says Mac McMillan, CEO at CynergisTek.

In an interview, McMillan notes that despite the long list of healthcare information breaches reported to federal authorities that have involved the theft or loss of unencrypted devices, many organizations have been reluctant to adopt encryption, citing concerns about the cost and the potential adverse impact on system performance, McMillan notes.

To address these concerns, hospitals and other organizations need to take steps to implement encryption on as limited a scope as is feasible, he suggests. He advises organizations that want to minimize the risk of major breaches, which now must be reported to federal authorities as a result of the HITECH Act's breach notification rule, to:

  • Assess where patient information resides, such as on laptops, desktops, smart phones, USB drives and databases, and determine who can access the data;
  • Determine whether to limit the number of places where patient information resides, such as, for example, by switching from desktop PCs to thin clients without storage capabilities;
  • Adopt segmentation of networks, other access controls and data loss prevention software;
  • Apply encryption only for devices and data for which there is no other acceptable control mechanism.

McMillan is co-founder and CEO of CynergisTek Inc. an Austin, Texas-based firm specializing in information security and regulatory compliance. He is chair of the Healthcare Information and Management Systems Society's Privacy & Security Steering Committee. He was a contributing author and editor for the HIMSS book, "Information Security in Healthcare: Managing Risk."

HOWARD ANDERSON: The majority of the major healthcare information breaches reported to federal authorities so far have involved the theft or loss of unencrypted computer devices. Under the HITECH Act, breaches involving data encrypted to a certain standard do not have to be reported. So why isn't the use of encryption more common by now?

MAC McMILLAN: You would think that everybody would want the benefit of having a safe harbor to protect themselves from having to report these things, and having to go through either being talked about in the press, or more importantly, having to explain an unnecessary breach to their patients. But there are several reasons why more are not using encryption. The first reason is that encryption, even today, under HITECH, is still addressable. In other words, it's not a mandatory requirement. It is something that they can do if they choose to, to avoid notification. But there is no hard requirement in HIPAA or HITECH for them to encrypt their data, so they still have a choice. That is one of the reasons that we are not seeing more of it, because as long as it is a choice for organizations, they are going to make risk-based decisions, in terms of how they perceive risk.

Organizations that are more averse to risk are the ones who are becoming early adopters of the encryption technology, and those that are less averse to risk are holding back still. The other going on is that some people are just waiting to see what the leaders do -- to see which solutions work best. A lot of hospitals are not early adopters when it comes to technology. So, except for the big guys who have greater resources and greater capabilities and more staff to address some of these things, a lot of the smaller and medium-sized hospitals are in that late or mid-range adopter group who like to see what others do first and see what works before they go out and invest.

The second reason we haven't seen quite as much encryption as one might think is the cost. ... I'll give you a couple of examples. Take a mid-range hospital, one of our customers that we work with: For them to encrypt somewhere around 300 or so laptops cost them about $18,000. That's not a bad price, but that's a ballpark for somebody who is just thinking about encryption technology for laptops, which is one of the biggest concerns we have right now, with respect to losing data. Another larger hospital system, which has multiple hospitals, spends anywhere from $200,000 to $300,000 annually on encryption. So, that's a line item in somebody's budget that has to be there annually. ...

So there is a real cost issue, and a lot of hospitals don't have encryption, per se, in their budgets. So now they are having to find the dollars to do this.

The third thing that impacts this is the aspect of an adverse impact on the user experience. People have the impression that "Once I encrypt my data, it's going to slow the system down." They believe it's going to slow response down and it's going to be an extra set of steps that the physicians have to go through or the workers have to go through, in order to get to the data to be able to do whatever it is that they need to do. And that, too, is not necessarily unfounded. There is absolute evidence that when you start encrypting, particularly back-end databases on large systems, it does have an impact, not only on the performance of the system and the response time for the user, but also for the maintenance and administration. ... And, there's another cost associated with that, as well, and that is that once you encrypt, in order to meet HITECH safe harbor, you have to use an encryption algorithm that is approved under the NIST guidelines and the FIPS 140-2 guidebook, in order to be compliant. What that means is that every time that standard changes, you are going to have to go back and refresh your encryption solution, or your vendors are going to have to refresh their encryption component of their solution in order for you to stay current or compliant.

So, there is not just an up-front cost. There is not just a cost in terms of impact to the system and to the user. There is also a downstream cost in terms of maintaining encryption. All of those reasons combined have caused some folks to go slowly into encrypting their data.

Assessing Role of Encryption

ANDERSON: What steps should healthcare organizations take as they assess whether to apply encryption at all, and if so, how to apply it?

McMILLAN: First of all, one of the things that we should realize about encryption is that it is just one of the tools in our toolbox, in what I call the "defense in depth" strategy for protecting data or protecting systems from unauthorized access. So we shouldn't address encryption as a point solution. In other words, we shouldn't just say "I need to encrypt everything," without taking into consideration the other pieces of the puzzle and making sure that the encryption is part of a greater strategy, as opposed to a single program element all by itself.

When you do get around to addressing encryption, you need to define, first of all, where your data is, how you create it, how you transport it, where you store it, where you process it, who is touching it, what they are doing with it, how you share it and then how you dispose of it. ...

It's important to identify exactly where PHI (protected health information) resides in the enterprise. Is it in databases, on desktops, laptops, thumb drives, smart phones? Where in the environment does this information actually reside? Once I now know where it is, I can look at all of those different mechanisms I have and controls that I have in order to protect it.

What I want to really try to do is limit my encryption footprint. Because if I want to minimize those impacts that I talked about earlier in terms of the system performance and the user experience, as well as the administration and maintenance and the costs, then I want to reduce or limit the footprint of the area that I actually have to encrypt. So if I determine where we are producing this data, where we are storing it, where we are processing it, where it is going, how we are using it, etc., then I can identify exactly what is available to protect it.

So then you need to determine exactly where it needs to reside -- can I limit my encryption by reducing the number of locations where I allow PHI to exist? In other words, do I have to have PHI resident on desktops, or can I use desktops that don't allow data to be stored there, but just accessed from them? If I can, then I may not need to encrypt my desktops.

The next thing I need to do is a risk assessment, taking into consideration all of the controls available, such as segmentation of the network. Can I put data in a protected enclave within my architecture so that only a very limited few actually have direct access? And I can use both physical and logical controls in order to limit the risk, and thereby not necessarily have to encrypt everything? ... Can I configure those desktops or other devices such that I don't have to worry about protected health information being out there? Can I limit access to sensitive data to those few individuals who actually need that information in order to perform their duties, and thereby, again, reduce a lot of the risk? Can I use other technology, such as data loss prevention technology, that allows me to put rules around the data itself and say "This person can't download PHI to a thumb drive, because they're not authorized." Or, "This PHI cannot go on this particular laptop because this laptop is not authorized to have PHI on it." Can I use other controls to limit where this data can actually be exposed to risk?

Once I have done that, then finally, I have a picture of where exactly I need encryption. Where are the points within my environment where I cannot use other measures to limit access to this data, or restrict it to the point that I have to now use some physical control or security feature, such as encryption, to protect it properly?

And the next step is to take into consideration all of that information that I have gathered through this process, develop my safe harbor strategy, using an integrated approach, with all of those different layers, and then encrypt those devices and data where no other acceptable countermeasure can adequately protect that information.

Encryption and Mobile Devices

ANDERSON: So many of the breaches reported to federal authorities so far have involved portable devices. Should healthcare organizations be considering whether to have PHI on portable devices, in the first place? And, if there is PHI on portable devices, should it, as a matter of routine, be encrypted? And is it ever worthwhile to encrypt databases?

McMILLAN: We should be looking at our use of portable devices and whether or not it is absolutely necessary to actually have the data on the devices, or whether it is sufficient to have the devices be able to access the data remotely. Because if I can do what I need to do without ... actually having to put that data on that portable device, then that portable device doesn't become as much of a risk to me anymore, and I may or may not have to encrypt it.

If there is PHI on that portable device, then absolutely, organizations should be encrypting those devices. We have seen breach after breach after breach of mobile devices, laptops, etc. that have gone missing and were not encrypted, and there is no way to answer the question for sure whether or not that information is or is not at risk. The rule is pretty simple in the HITECH Act: If there is data out there that is not encrypted, then it is considered unsecure data. If it is unsecure data, then you have to go through the risk analysis process to determine whether or not you have to report a breach. And encryption is the only real way to just avoid that experience. On the back end piece, the databases, they are no different in terms of how you approach them, and how you think through that process of determining, "Do I need to encrypt or not encrypt?"

Although, with databases, encryption has more of an impact on performance. So when it comes to data at rest, we are going to see a lot of folks really looking hard at whether or not they encrypt. The fortunate thing is that back-end databases don't pose as much risk as portable devices do. Usually, back-end databases are sitting on servers or in share files on servers that are sitting in data centers and have physical control around them and have limited direct access to them. And if the network is configured properly and segmented properly, then it is much more difficult to get to that information than a laptop that's got files sitting on it that aren't encrypted.

However, organizations do need to understand that ... if their database were to be hacked and someone were to get into that data, then they would have the same reporting requirements that they would for a stolen mobile device. ...

They still should be going through the process of looking at where their data is sitting in the environment, what kinds of protections they have, and limitations on who can access that information, how they present that information out to the system where the user touches it, how others are connecting to their environment to access to those databases and those applications. There are some newer technologies coming out with embedded encryption capability in them that are going to reduce the impacts and reduce the costs with respect to encrypting things like back-end databases.

Successful Encryption Strategy

ANDERSON: To wrap up, what would you say is the key to a successful implementation of encryption?

McMILLAN: Well, I think the key to being successful is to really stop and think about it and come up with a plan, document that plan, understand how encryption fits in your overall defense-in-depth strategy, and then start looking at the various encryption solutions that are available to you.

What folks will find is that if they do that, it will save them money in the long run; it will make for a much better solution, and it will reduce the impact of encryption on the system, the user or even the IT staffs that have to maintain this.

Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing healthcareinfosecurity.com, you agree to our use of cookies.