Encryption: Four Essential StepsSecurity Expert Addresses Breach Prevention Issues
Encryption is an important breach prevention tool. But to make the right decisions about how to apply encryption, healthcare organizations should take four specific steps, says security expert Feisal Nanji.
The first step is to precisely identify where all protected health information is stored, Nanji says in an interview with HealthcareInfoSecurity (transcript below). "It's in biomedical devices, in iPads, in laptops, in servers, in databases - a wide range of things. So first we do an inventory of where all our ePHI lies."
Second, organizations should assign tiers of risk based on where the data resides. Then, they should map where data flows, including transmission over the Internet. The final step, he says, is to efficiently determine how to apply security controls, including encryption.
In the interview, Nanji also:
- Clarifies what HIPAA and the HITECH Act electronic health record incentive program say about the use of encryption;
- Describes the technical challenges involved in applying encryption;
- Explains why he believes CIOs should not be responsible for security.
Nanji is executive director of Techumen, an information security firm focusing exclusively on securing healthcare information. He has more than 25 years of information technology experience. He is a Certified Information Security Systems Professional.
HOWARD ANDERSON: Can you clarify what both HIPAA and the HITECH Act have to say about encryption? Neither one explicitly requires it, right?
FEISAL NANJI: That's precisely right. ... But let me just step back and explain that if we really think about security in healthcare, there are at least four interlocking considerations for security. The first is clearly the breach notification rule - if you encrypt anything, you're given a free pass, a get-out-of-jail-free card [encrypted data that's breached does not need to be reported]. Second is the annual guidance [from] the Health and Human Services Department as part of the HITECH Act. Every year, there's supposed to be guidance on how you should consider encryption. The third is clearly the HIPAA Security Rule, which is the cornerstone of information security within healthcare. And [under that rule, encryption] is still an "addressable" requirement [not required if an alternative reasonable protection is taken and documented]. ... And the fourth is the [HITECH] meaningful use [electronic health record incentive program]. ...
For HITECH Stage 1, there really wasn't any explicit mention of encryption, but there was an implied mention, which is [a reminder that you must] conduct a security risk assessment. And that means if you conduct a security risk assessment ... you get to know where your areas of most risk are, and therefore where you might want to encrypt. That was for Stage 1.
Stage 2 requires three things: The first thing is that EHR vendors should have the ability to provide you secure messaging for e-mail and other forms of communication with your patients or vendors or other partners. The EHR system must be able to do that for you. ... The second thing in Stage 2 is each EHR vendor must be able to wipe out any data that exists on any viewing device, like an iPad or a tablet. So once you, as a doctor, have looked at patient information on your iPad, you must be able to, as an EHR vendor, wipe that out. So your iPad acts as a thin client. Or you can encrypt it [the EHR must, by default, encrypt any data that's actually stored]; but most people will opt for wiping it clean. And the third piece is also a new, implied encryption challenge - and that is ... a percentage of patients ... must be able to download, view, or transmit their PHI. ... So this means that the implied encryption piece is that you as a healthcare provider have to make sure and support the encryption mechanisms because it's probably impossible for patients to do that. And so you really have to look at your vendors very, very closely. ...
I think you really have to make sure that you understand what the vendor is providing to you in terms of tracking and disabling and enabling the encryption through login mechanisms, the ability to actually conduct encryption, and the ability to actually do other things that are around encryption that improve your process.
ANDERSON: Now, more than half of the major breaches reported so far have involved the loss or theft of unencrypted devices or media. So why isn't encryption more widespread? Why are we seeing so many breaches of unencrypted devices?
NANJI: Well, interestingly enough, there are some no-brainers that people should have for encryption. It is absolutely absurd that people do not have encryption for the following: All mobile devices, all easily-accessible servers and desktops. So by that I mean even in an office, it should be encrypted.
The other area where I think encryption has to be done is in terms of backup tapes. If you're a hospital, say, and you generate a lot of data on a weekly basis, what you're doing is you're taking the data that you're backing up on tape ... and then shipping it out. Well, the problem with that is if you're not encrypting that data, there's a small chance that the [delivery] person could lose the tape. And it's happened. And so there are some no-brainers with regards to encryption that you have to do: Backup tapes, mobile devices, laptops, and desktops or servers which are not housed in the data center.
ANDERSON: And why isn't that being done more commonly now?
NANJI: You know, that boggles the mind. I think it's a failure of governance. ... The security officer in a hospital organization typically reports to the CIO. Therein lies the problem. The CIO is responsible for operational excellence, not compliance excellence or integrity monitoring. And so in this case, the fox is running the hen house. And of course, the CIO is going to really put all his dollars in operational performance as much as he can. ... So here we have a governance problem, and I think the CEOs need to realize that the CIO should not be in charge of both operating IT infrastructure and monitoring that infrastructure; those should be separate.
ANDERSON: Are there particular technical challenges involved in using encryption that cause people trouble?
NANJI: Oh, absolutely. The main technical challenges are around processing power required. It becomes very slow if you're using software-based encryption. It takes a long time for the thing to boot up and then get decrypted. So processing power is the big issue. But also latency. If you're encrypting and you require an encryption key, you're sending stuff over a large network, you have very poor response times. And [another] area where it's problematic from an IT perspective is that there are many places where you can encrypt. You can encrypt at the file level, you could encrypt at the hard drive level, you can encrypt entirely on a mail folder level. And so [the issue is] where you encrypt and what's the most suitable way for encryption. So those are some of the technical challenges.
ANDERSON: So what are some of the core decisions that an organization has to make as it develops an encryption strategy as a result of all that?
NANJI: So the first thing that you need to do is you need to identify where all your ePHI lies. We don't really know in most organizations where all our ePHI is - it lies in biomedical devices, in iPads, in laptops, in servers, in databases - a wide range of things. So first we do an inventory of where all our ePHI lies.
Second, we assign tiers of risk to where this ePHI is. How risky is it based on where it sits? So this is part of the risk assessment. You would end up with, for example: 20 applications that are really risky, another 30 applications of medium risk, and 30 applications which are not as sensitive. ... So once you've gotten through this risk assessment process, then you do the third thing: Conduct what is known as data flow mapping. And data flow mapping basically maps where your data is flowing from one point to the other. And the reason why that's important is because if you're transmitting data from point A to point B, a lot of times you might be actually using an external network or an external carrier like AT&T or Comcast. And if that's the case, you've got to be careful about [those carriers] because they do not encrypt the data for you. Furthermore, if you're using any applications in the cloud, you are clearly sending data over the Internet into the cloud. So how are your cloud vendors securing your data? Do they have the right physical facilities? Do they have the right administrative facilities? Do they have the right technical controls? And you really have to judge that. ...
So once you've gone through those three steps, then you go to step four. And step four is: Now I understand my situation; I understand where all my data is that's really sensitive; I know how it's being transmitted; I clearly recognize that there are tiers of risk. And so now I can then use my precious resources ... and choose from the myriad range of [security] controls that there are.