The night­mare sce­nario: di­al­ing de­vices to deadly

Modern Healthcare - - NEWS - By Adam Ruben­fire

Data breaches are the most im­me­di­ate cy­ber­se­cu­rity worry for health­care or­ga­ni­za­tions. Noth­ing less than pa­tient pri­vacy, data ac­cess, ran­somware cash and even the in­sti­tu­tion’s rep­u­ta­tion could be put in play through slip­shod data se­cu­rity prac­tices. But loom­ing over Amer­ica’s hos­pi­tals and med­i­cal prac­tices is a po­ten­tially dead­lier threat: hack­ers or black­mail- ers tak­ing over web-con­nected med­i­cal de­vices and threat­en­ing to in­flict pa­tient harm.

Health­care cy­ber­se­cu­rity pro­fes­sion­als are sound­ing the alarm bells about a med­i­cal de­vice in­dus­try that has lagged be­hind other in­dus­tries in equip­ping their prod­ucts with strong de­fenses against hack­ing. It’s a prob­lem providers can’t avoid, even though they have limited staff to en­sure that their med­i­cal de­vice se­cu­rity is up-to-date

“You don’t need a car crash to know that a car is go­ing to crash if the wheels are com­ing off.” Kevin Fu, chief sci­en­tist at cy­ber­se­cu­rity startup Virta Lab­o­ra­to­ries

and their net­worked data flow has ad­e­quate pro­tec­tions.

It has be­come com­mon prac­tice for hos­pi­tals to se­quester de­vices in restricted parts of their net­works so hack­ers can’t ex­ploit their weak­nesses to in­fil­trate PCs and servers, said Tre­mayne Smith, chief in­for­ma­tion se­cu­rity of­fi­cer at Ohio State Univer­sity Wexner Med­i­cal Cen­ter.

“You have to man­age it that way, be­cause in my opin­ion, the med­i­cal de­vice space has to catch up to the other more so­phis­ti­cated places in our net­work and they shouldn’t nec­es­sar­ily play in the same play­ground right now with­out be­ing mon­i­tored,” Smith said.

A wide range of tech­nolo­gies that are crit­i­cal to pa­tient care are con­nected to the web and there­fore vul­ner­a­ble to hack­ing. Pa­tient mon­i­tors, in­fu­sion pumps, imag­ing de­vices and di­ag­nos­tic equip­ment can all be con­nected to providers’ net­works so they can au­to­mat­i­cally send in­for­ma­tion and files to the elec­tronic health record and nurs­ing sta­tion mon­i­tors or store files on hospi­tal servers.

The­o­ret­i­cally, a hacker could force a life-sav­ing de­vice to mal­func­tion, gain ac­cess to pa­tient data from a pa­tient mon­i­tor or imag­ing de­vice, or sim­ply as a gate­way into the provider’s net­work.

But the night­mare sce­nario is still the­o­ret­i­cal—there’s no known in­stance of a hacker us­ing a de­vice to harm a pa­tient. That doesn’t mean it won’t hap­pen.

“You don’t need a car crash to know that a car is go­ing to crash if the wheels are com­ing off,” said Kevin Fu, chief sci­en­tist at Virta Lab­o­ra­to­ries, a cy­ber­se­cu­rity startup that wants to help hos­pi­tals bet­ter track their de­vices.

Some man­u­fac­tur­ers have ac­knowl­edged that hack­ers could dis­rupt care for fi­nan­cial gain or other rea­sons, although that is of­ten in re­sponse to prod­ding by the Food and Drug Ad­min­is­tra­tion. Man­u­fac­tur­ers and the FDA alerted providers and pa­tients to a num­ber of vul­ner­a­ble de­vices in the past few years, in­clud­ing in Hospira’s Sym­biq in­fu­sion pump and an in­sulin pump made by John­son & John­son sub­sidiary An­i­mas Corp.

Some man­u­fac­tur­ers have ac­tively re­sisted ac­knowl­edg­ing prob­lems with their tech­nolo­gies. Last fall, St. Jude Med­i­cal, which was re­cently ac­quired by Ab­bott Lab­o­ra­to­ries, ve­he­mently de­nied ac­cu­sa­tions by a short­selling firm that its de­fib­ril­la­tors and other car­diac de­vices were vul­ner­a­ble to hacks that could cause dan­ger­ous mal­func­tions. But after the FDA and Depart­ment of Home­land Se­cu­rity launched an in­ves­ti­ga­tion, which con­cluded ear­lier this month, the com­pany ad­mit­ted that a Mer­lin@home, a de­vice that trans­mits data from a St. Jude car­diac im­plant, had a vul­ner­a­bil­ity that could al­low hack­ers to de­plete the de­vice’s bat­tery or cause in­ap­pro­pri­ate pac­ing or shocks to the heart.

St. Jude re­cently re­leased an au­to­mat­i­cally down­loaded soft­ware up­date that ad­dressed the prob­lem. No in­juries have been re­ported as a re­sult of the vul­ner­a­bil­ity.

“The safety and se­cu­rity of pa­tients is al­ways our pri­mary focus,” said Phil Ebel­ing, St. Jude’s vice pres­i­dent and chief tech­nol­ogy of­fi­cer, in a state­ment ear­lier this month. “We’ll con­tinue to work with agen­cies, se­cu­rity re­searchers, physi­cians and oth­ers in the in­dus­try in a co­or­di­nated way to de­velop best prac­tices and stan­dards that fur­ther en­hance the se­cu­rity of de­vices across the med­i­cal in­dus­try.”

Be­cause hack­ers can find vul­ner­a­bil­i­ties in soft­ware, some de­vice­mak­ers have de­signed re­dun­dan­cies in their prod­ucts’ core fea­tures to guard against re­mote ac­ti­va­tion or ac­cess. The tech­nol­ogy locks can also pro­tect against ma­li­cious, in-per­son use of the de­vices.

For ex­am­ple, in­fu­sion pumps made by Bec­ton, Dick­in­son and Co. re­quire clin­i­cians to push a phys­i­cal but­ton on the de­vice to ini­ti­ate an in­tra­venous treat­ment. They also al­low clin­i­cians to pro­gram dose pa­ram­e­ters into the ma­chines. Th­ese safe­guards are in­tended to pro­tect against the night­mare sce­nario of a hacker re­motely ac­ti­vat­ing a pump and over­dos­ing a pa­tient. The de­vices use hospi­tal net­works to trans­mit data to the EHR.

Welch Al­lyn equip­ment that mon­i­tors and records pa­tient vi­tal signs can be con­fig­ured to re­quire au­then­ti­ca­tion with clin­i­cian and pa­tient cre­den­tials us­ing ei­ther a lo­gin or bar­code scan­ning. This pro­tects the de­vices from re­mote hack­ing and en­sures the data is trans­mit­ted to the right pa­tient record. Some of BD’s in­fu­sion pumps also of­fer bar­code scan­ning of cre­den­tials and drugs.

“While we are con­tin­u­ally mon­i­tor­ing for th­ese de­vices, we find in­stances where fa­cil­i­ties will add de­vices and not in­form cor­po­rate IT.” Mod­ern Health­care sur­vey re­spon­dent

While they are con­fi­dent in the se­cu­rity of their de­vices, BD and Welch Al­lyn don’t guar­an­tee that their de­vices can’t be ma­nip­u­lated. Some providers choose not to con­nect cer­tain de­vices, con­clud­ing the po­ten­tial for hacker dis­rup­tion out­weighs the con­ve­nience of trans­mit­ting di­ag­nos­tic data di­rectly to the EHR. Oth­ers don’t have the in­fra­struc­ture or ex­per­tise to do so.

This is es­pe­cially true for Welch Al­lyn’s vi­tal signs de­vices, said Gar­ri­son Gomez, a se­nior di­rec­tor at Welch Al­lyn. A num­ber of providers choose to type that in­for­ma­tion, such as body tem­per­a­ture or blood pres­sure, into the EHR sep­a­rately.

But the ac­cu­racy and ease that come with con­nect­ing the de­vices di­rectly to the EHR can­not be over­stated, Gomez said. Man­u­fac­tur­ers like Welch Al­lyn have ramped up ef­forts to pro­tect their web-con­nected de­vices and in­vested in ef­forts to help providers de­sign safer net­works.

Many web-con­nected fea­tures have be­come avail­able only in the past five years or so. Dur­ing that time, de­vice­mak­ers learned they needed to im­prove their se­cu­rity mea­sures. Many have re­placed Mi­crosoft Win­dows op­er­at­ing sys­tems with pro­pri­etary op­er­at­ing sys­tems that should be harder to hack be­cause they aren’t pub­lic-fac­ing and vary be­tween brands.

But un­der­stand­ing the vul­ner­a­bil­i­ties in a net­work means hav­ing full in­ven­tory of the ma­chines and soft­ware that are us­ing it, and many health­care or­ga­ni­za­tions don’t.

A Mod­ern Health­care sur­vey found 31% of 51 re­spon­dents didn’t have an ac­cu­rate, com­plete record of all their web-con­nected de­vices, whether med­i­cal or non­med­i­cal.

“If you don’t know what equip­ment you have in your hospi­tal, how are you go­ing to pro­tect it?” said Fu, of the cy­ber­se­cu­rity startup Virta. Fu is also an as­so­ciate pro­fes­sor of com­puter science and engi­neer­ing at the Univer­sity of Michi­gan in Ann Ar­bor.

Virta has de­vel­oped BlueFlow, soft­ware that scans provider net­works for con­nected med­i­cal de­vices and triages any se­cu­rity vul­ner­a­bil­i­ties to help providers de­ter­mine what gaps should be ad­dressed first. But even with ad­e­quate records some fa­cil­i­ties still ad­mit dif­fi­cul­ties in get­ting staff to fol­low proper pro­ce­dures in no­ti­fy­ing IT staff about newly con­nected de­vices.

“While we are con­tin­u­ally mon­i­tor­ing for th­ese de­vices, we find in­stances where fa­cil­i­ties will add de­vices and not in­form cor­po­rate IT,” said one ex­ec­u­tive sur­veyed by Mod­ern Health­care.

In an ef­fort to re­spond to weak­nesses dis­cov­ered by in­ter­nal hack­ers and “white hat” hacker re­searchers, man­u­fac­tur­ers of­fer se­cu­rity “patches” in­tended to re­solve gaps in cyberdefense. St. Jude has re­leased seven up­dates in the past three years for Mer­lin@home, the de­vice re­cently deemed vul­ner­a­ble by the FDA. The com­pany plans to im­ple­ment ad­di­tional up­dates later this year to ad­dress re­main­ing vul­ner­a­bil­i­ties. The FDA said the ben­e­fits of us­ing the de­vice out­weigh any out­stand­ing cy­ber­se­cu­rity risks.

The FDA is­sued guid­ance in De­cem­ber that called on man­u­fac­tur­ers to closely mon­i­tor, iden­tify and re­spond to cy­ber­se­cu­rity vul­ner­a­bil­i­ties as part of rou­tine post-mar­ket sur­veil­lance of their de­vices. Rob Suarez, BD’s di­rec­tor of prod­uct se­cu­rity, said the guid­ance has helped make it clear to man­u­fac­tur­ers that soft­ware se­cu­rity patches gen­er­ally don’t re­quire FDA re­view be­fore re­lease, and there­fore should be ex­pe­dited to en­sure pa­tient safety.

Even if man­u­fac­tur­ers do their part with patches, providers don’t al­ways de­ploy them in a timely man­ner. Com­mu­ni­ca­tion through di­rect con­tact and prod­uct se­cu­rity web­sites is cru­cial to en­sur­ing de­vices are ac­tu­ally se­cured by end users, Suarez said. “We are de­vel­op­ing those se­cu­rity patches for a rea­son.”

Cy­ber­se­cu­rity ex­perts and man­u­fac­tur­ers alike told Mod­ern Health­care that providers have to get more se­ri­ous about quickly and con­sis­tently im­ple­ment­ing se­cu­rity patches.

Even when a man­u­fac­turer is dili­gent about mak­ing patches avail­able, keep­ing up to date with them is tax­ing. Hos­pi­tals are of­ten low on staff and have too many pa­tients to take de­vices out of ser­vice for se­cu­rity patches, which must be tested to en­sure they don’t dis­rupt func­tion­al­ity. A large hospi­tal or health sys­tem might have thou­sands of a par­tic­u­lar de­vice across nu­mer­ous lo­ca­tions.

While some hos­pi­tals in­stall patches to their de­vices ev­ery few months, oth­ers can go a year or more with­out up­dat­ing their de­vice soft­ware. At Ne­braska Medicine and the Univer­sity of Ne­braska Med­i­cal Cen­ter, staff are look­ing ev­ery day for ways to be more ef­fi­cient with test­ing and im­ple­ment­ing soft­ware patches, said Sharon Welna, di­rec­tor of in­for­ma­tion se­cu­rity and com­pli­ance for the health sys­tem. But she em­pha­sized that the hospi­tal must take a mea­sured ap­proach to

Newspapers in English

Newspapers from USA

© PressReader. All rights reserved.