Sie befin­den sich hier:Start­sei­te/Blog/How to ward off Cyber Attacks On Medi­cal Products

How to ward off Cyber Attacks On Medical Products

Lese­zeit: 4 Minu­ten
How to ward off Cyber Attacks On Medical Products

Security controls, i.e. measures to increase the security of a product, are defined by regulatory documents

Within the US-Admi­nis­tra­ti­on – e.g. Depart­ment of Defen­se, Home­land­Se­cu­ri­ty, Depart­ment of Veterans Affairs, Food and Drug Admin­stra­ti­on, Natio­nal Elec­tri­cal Asso­cia­ti­on – docu­ments have been deve­lo­ped which defi­ne mea­su­res to increase the secu­ri­ty of a pro­duct. For exam­p­le the NEMA stan­dard HN 1–2013: “Manu­fac­tu­rer Dis­clo­sure State­ment for Medi­cal Device Secu­ri­ty” MDS”, the stan­dard SP 800–53A “Asses­sing Secu­ri­ty and Pri­va­cy Con­trols in Fede­ral Infor­ma­ti­on Sys­tems and Orga­ni­zai­tons Buil­ding Effec­ti­ve Assess­ment Plans” or SP 800–53 “Secu­ri­ty and Pri­va­cy Con­trols for Fede­ral Infor­ma­ti­on Sys­tems and Orga­ni­zai­tons” by the NIST.

Deri­ving from Euro­pe, the ETSI TR 103 305–1 V2.1.1 “Cri­ti­cal Secu­ri­ty Con­trols for Effec­ti­ve Cyber Defence” could be men­tio­ned. The­se publi­ca­ti­ons are sup­ple­men­ted by non-bin­ding docu­ments like “Com­mon Weak­ne­ss Enu­me­ra­ti­on”, “Com­mon Cri­te­ria”, “CIS Cri­ti­cal Secu­ri­ty Con­trols” and many more.

The­se docu­ments sta­te requi­re­ments are:

  • Is the pro­duct capa­ble of enco­ding pati­ents’ data?
  • How can be ensu­red that such data can­not be mani­pu­la­ted when sent?
  • Does the ope­ra­ting sys­tem run on the latest patch level, how is it being instal­led, and how do you ensu­re that unwan­ted third-par­ty-soft­ware will not be instal­led on the product?
  • “Off-the-Shelf-Soft­ware” is on the latest patch-level.
  • Mini­mal admi­nis­tra­ti­ve rights.
  • Exclu­si­ve­ly neces­sa­ry ser­vices, users, shares and ports are installed.
  • No boot­ing of remo­va­ble sto­rage devices.
  • Limi­ta­ti­on of net­work traf­fic to trus­ted IPs.
  • Two-fac­tor-authen­ti­fi­ca­ti­on for admin­stra­ti­ve users. An audit-trail is estab­lished which can be archi­ved and signed digitally.
  • Per­so­nal data on USB data car­ri­ers have to be encoded.
  • Trai­ning of developers.
  • Iden­ti­fi­ca­ti­on of duly aut­ho­ri­zed repre­sen­ta­ti­ves for Inci­dent Respon­se Management.

All of the­se docu­ments have in com­mon that lists of secu­ri­ty aspects can be deri­ved from them. Such lists of secu­ri­ty aspects are being deve­lo­ped during the design-pha­se of a pro­duct and have to be review­ed after all signi­fi­cant modi­fi­ca­ti­ons. The­se modi­fi­ca­ti­ons can eit­her be inter­nal (the pro­duct its­elf is modi­fied) or exter­nal (the soft­ware appli­ed recei­ves a secu­ri­ty rele­vant patch). The review of secu­ri­ty requi­re­ments does not end with the release, but has to be exten­ded to the enti­re life cycle of the product.

The chall­enge con­sists in defi­ning for every sin­gle ele­ment on the list the value and the con­se­quence of this requi­re­ment on the pro­duct. In case a net­work con­nec­tion can­not be estab­lished it will be annoy­ing to the ser­vice ope­ra­tor and can hop­eful­ly be avo­ided by means of remo­va­ble sto­rage devices, while such a black­out will be harmful to a web application.

Second­ly, the pro­ba­bi­li­ty of such an occur­rence has to be defi­ned. Here the spy­ing on pass­words through the Melt­down/S­pect­re-leak is to ser­ve as an exam­p­le. It is being attempt­ed to read the sto­rage of ano­ther pro­cess as well as of the ope­ra­ting sys­tem via this gap. Actual­ly, the pro­ba­bi­li­ty is real when­ever the pro­duct is in use.

cybersecurity grafik groc39f english
cybersecurity grafik klein english

Still, pre­con­di­ti­ons to suc­cessful­ly car­ry out such a hack are very high. Gene­ral­ly, the nor­mal user should not at all be able to open the com­mand-shell and the sys­tem should be pro­tec­ted by a white­list. So the pro­ba­bi­li­ty of a suc­cessful cyber­at­tack is smal­ler than expec­ted at first sight.
As a third step, it is to be eva­lua­ted how high the effort is to clo­se the secu­ri­ty leak. Meltdown/Spectre can only be clo­sed extern­al­ly, but mea­su­res to impe­de the attack are recom­men­ded and practicable.

The Risk and Thre­at Ana­ly­sis con­sists of at least the­se three steps. They form a matrix of secu­ri­ty cha­rac­te­ristics for the pro­duct. For big-sized pro­ducts, the use of tool sup­port is recom­men­ded. But that’s ano­ther story …

The steps descri­bed can only gua­ran­tee pas­si­ve secu­ri­ty. They app­ly to gene­ral secu­ri­ty aspects, to lists deri­ved from the docu­ments men­tio­ned abo­ve or secu­ri­ty rele­vant defaults detec­ted pre­vious­ly, like patch days by soft­ware pro­du­cers. Errors within the own pro­duct are ther­eby not taken into account. Acti­ve secu­ri­ty can only be found after pro­duct spe­ci­fic tests. Only sta­tic code ana­ly­sis, fuz­zing and pene­tra­ti­on tests can gua­ran­tee acti­ve secu­ri­ty. Again, ano­ther sto­ry to be told…

One final point: The OWASP Test­ing Gui­de 4 alre­a­dy sta­ted that while the space of time bet­ween the dis­co­very of an end­an­ger­ment and its patch stays the same, the time for acti­ve explo­ita­ti­on is redu­ced. Con­se­quent­ly, the­re is an increased neces­si­ty to exe­cu­te the steps of risk-ana­ly­sis descri­bed abo­ve and con­ti­nuous appli­ca­ti­on of secu­ri­ty test­ing to the product.

If you would like to learn more about this topic, do not hesi­ta­te to cont­act me, plea­se. I am loo­king for­ward to a con­ver­sa­ti­on with you.

Kommentare und Feedback gerne via Social Media:

Blei­ben Sie auf dem Lau­fen­den – mit dem monat­li­chen Newsletter: