You may not need to follow breach-notification rules in the wake of the Heartbleed Internet security crisis, but you do need to take steps to inform patients and ensure their data are safe. Everyone who uses the Internet was alarmed by the recent revelation that OpenSSL, the widely used code library behind a huge percentage of Web security — including the “https” protocol of commercial sites — has had an undetected bug in it for two years. Dubbed Heartbleed, the bug theoretically makes it possible for a hacker to make Web servers give up valuable information such as passwords and credit card numbers. Perhaps the most frightening thing about the bug is that, while it affects millions of Web servers, it’s not known how much sensitive information was removed with it because a Heartbleed-based attack leaves no evidence in server logs. “So far, I’ve only heard of two data hacks attributed to Heartbleed,” says David Harlow, principal of The Harlow Group LLC health care law consultancy and proprietor of the HealthBlawg blog.
How HIPAA and Heartbleed intersect For health care providers, the fear is compounded by the need to observe HIPAA regulations regarding breaches of patients’ protected health information (PHI). The massive spread of the Heartbleed bug raises a question: Should all covered entities just assume they’ve suffered a reportable breach? The consensus among experts Part B News spoke to is that, absent direct evidence of misused PHI, the threat is too vague to constitute a reportable breach. “If you look at the questions on the HHS Breach Notification form, a number of specific details need to be included,” says Jay Hodes, president, Colington Security Consulting, Washington, D.C. “In my opinion, providers may have a difficult task in being able to provide specific details. … For one thing, I’m not sure a provider would be able to make an accurate determination as to how many records could have been compromised.” Under the four-part assessment HHS’ Office for Civil Rights (OCR) advises providers to take to determine the risk level of a breach, most providers’ Heartbleed exposure would be judged low-risk, Harlow adds. The way Heartbleed works, an intruder would have to “pick your service or application as a needle in the haystack then actively listen for data that might be of interest to them and then exploit that data,” says Dr. Michael G. Mathews, president, COO and co-founder of CynergisTek, Inc.
3 things to do now
Notwithstanding the slim chance of trouble, you can’t just ignore Heartbleed. For one thing, you’ve heard of it even if only by reading this — and that means you have to respond if you want to protect yourself in the event of a future exploit. “Providers should also make sure to document their processes and responses as necessary in case something does go wrong so that they can demonstrate they were taking commercially reasonable efforts to protect PHI,” says Tatiana Melnik, health care and technology attorney at Melnik Legal in Tampa, Fla. Experts recommend responding in these three ways:
• Notify patients about Heartbleed.
Notify patients “whose data you store or process, much as non- health care organizations did in the wake of Heartbleed,” recommends Travis Good, M.D., co-founder and CEO of Catalyze Inc. in Madison, Wis. This isn’t a breach notification — just a heads-up about Heartbleed to assure your patients that you’re aware of the problem. Inform patients “of the potential risk of a breach or that the risk had been mitigated and the vulnerability patched,” says Good.
• Check for problems and fix them.
Several sources offer specific Heartbleed advice, including Codenomicon’s heartbleed.com site. The first step is to check for vulnerabilities. Mathews notes that several free tests online will do that check; some, such as security experts McAfee’s, may be more reliable than others. If the tests show your system is vulnerable, it should patched or taken out of production until a patch is supplied by the vendor, says Good. Mathews advises looking at new tech to shield your applications from direct access by the public — for example, “thin-client” solutions that allow secure remote connections. You also could install an application layer (proxy) firewall and unified threat management (UTM) solutions for “a safe handoff of traffic between the public network and the local area network for the SSL protocol,” he adds. Sound a little technical for you? Then:
• Give more responsibility to your IT vendor.
This crisis provides “encouragement for practices to move away from the break-fix relationship with their IT vendor into a managed service relationship,” says Jeff Mongelli, CEO of Acentec in Irvine, Calif. Given this increasing pressure, smaller offices that have been trying to handle their own IT security or who use IT professionals occasionally may want to reconsider those plans.
— Roy Edroso (email@example.com)