Sie befin­den sich hier:Start­sei­te/Blog/Cyber­an­grif­fe auf Medi­zin­pro­duk­te abwehren

Cyberangriffe auf Medizinprodukte abwehren

Lese­zeit: 4 Minu­ten
cyber security 1 socialshare

Im Umkreis der ame­ri­ka­ni­schen Ver­wal­tung – Depart­ment of Defen­se, Home­land Secu­ri­ty, Depart­ment of Vete­rans Affairs, Food and Drug Asso­cia­ti­on, Natio­nal Electri­cal Manu­fac­tu­rers Asso­cia­ti­on – enstan­de­ne Tex­te defi­nie­ren Maß­nah­men zur Sicher­heit eines Pro­dukts. Etwa der Stan­dard HN 1–2013 der NEMA: „Manu­fac­tu­rer Dis­clo­sure State­ment for Medi­cal Device Secu­ri­ty“ MDS2, die SP 800–53A des NIST: “Asses­sing Secu­ri­ty and Pri­va­cy Con­trols in Federal Infor­ma­ti­on Sys­tems and Orga­niz­a­ti­ons Buil­ding Effec­ti­ve Assess­ment Plans“ oder SP 800–53 “Secu­ri­ty and Pri­va­cy Con­trol­s­for Federal Infor­ma­ti­on Sys­tems and Organizations“.

Aus Euro­pa könn­te das ETSI TR 103 305–1 V2.1.1 „Cri­ti­cal Secu­ri­ty Con­trols for Effec­ti­ve Cyber Defence“ genannt wer­den. Ergänzt wer­den sol­che Ver­öf­fent­li­chun­gen durch nicht bin­den­de Doku­men­te wie die „Com­mon Weak­ness Enu­me­ra­ti­on“, „Com­mon Cri­te­ria“, „CIS Cri­ti­cal Secu­ri­ty Con­trols“ und vie­le mehr.

In sol­chen Doku­men­ten wer­den Anfor­de­run­gen defi­niert wie: 

  • kann das Pro­dukt Pati­en­ten­da­ten verschlüsseln?
  • wie kann sicher­ge­stellt wer­den, dass sol­che Daten beim Ver­sen­den nicht mani­pu­liert werden?
  • ist das Betriebs­sys­tem auf dem letz­ten Patch-Level, wie wird die­ser auf­ge­spielt und sicher­ge­stellt, dass kei­ne uner­wünsch­te Fremd­soft­ware auf dem Pro­dukt instal­liert wird?
  • „Off–the-Shelf-Software“ ist auf dem letz­ten Patch-Level.
  • mini­ma­le admi­nis­tra­ti­ve Rechte.
  • nur not­wen­di­ge Diens­te, User, Shares, Ports sind eingerichtet.
  • kein Boo­ten von Wechseldatenträgern.
  • Begren­zung des Netz­werk­ver­kehrs auf ver­trau­ens­wür­di­ge IPs.
  • Zwei-Fak­tor-Authen­ti­fi­ka­ti­on für admi­nis­tra­ti­ve Benut­zer. Ein Audit-Trail wird erstellt und kann archi­viert und digi­tal signiert werden.
  • per­so­nen­be­zo­ge­ne Daten auf USB Daten­trä­gern sind zu verschlüsseln.
  • Schu­lung der Entwickler.
  • Benen­nen von Beauf­trag­ten im Inci­dent Respon­se Management.

Allen die­sen Doku­men­ten ist gemein­sam, dass sich aus ihnen Lis­ten zu Sicher­heits­aspek­ten ablei­ten las­sen. Sol­che Lis­ten von Sicher­heits­an­for­de­run­gen wer­den in der Design-Pha­se eines Pro­dukts erstellt und nach allen wesent­li­chen Ände­run­gen über­prüft. Ände­run­gen kön­nen intern (am Pro­dukt ändert sich etwas) wie extern (benutz­te Soft­ware bekommt einen sicher­heits­re­le­van­ten Patch) sein. Die Über­prü­fung der Sicher­heits­an­for­de­run­gen ist mit der Frei­ga­be nicht been­det, son­dern auf den gan­zen Lebens­zy­klus des Pro­dukts auszuweiten.

Die Her­aus­for­de­rung besteht dar­in, für jedes Lis­ten­ele­ment fest­zu­le­gen, wel­chen Wert und wel­che Kon­se­quenz die­se Anfor­de­rung für das Pro­dukt hat. Wenn die Netz­werk­ver­bin­dung, die ein Ser­vice­tech­ni­ker braucht, ein­mal nicht zustan­de kommt, ist das ärger­lich und kann hof­fent­lich durch Ver­wen­dung von Wech­sel­da­ten­trä­gern umgan­gen wer­den, für eine Web­ap­pli­ka­ti­on jedoch ist ein sol­cher Aus­fall schädlich.

Als Zwei­tes ist die Wahr­schein­lich­keit zu bestim­men, mit der sol­che Ereig­nis­se ein­tre­ten kön­nen. Das Aus­spio­nie­ren von Pass­wör­tern über die Meltdown/­Spect­re-Lücke soll hier als Bei­spiel die­nen. Über die­se Lücke wird ver­sucht, den Spei­cher eines ande­ren Pro­zes­ses, aber auch des Betriebs­sys­tems, aus­zu­le­sen. Die Wahr­schein­lich­keit ist eigent­lich immer gege­ben, wenn ein Anwen­der das Pro­dukt bedient.

cybersecurity grafik groc39f

Die Vor­aus­set­zun­gen, die­sen Hack über­haupt durch­füh­ren zu kön­nen, sind aber sehr hoch. In der Regel soll­te der nor­ma­le Anwen­der über­haupt kei­ne Com­mand-Shell öff­nen dür­fen und das Sys­tem soll­te durch eine White­list geschützt sein. D.h. die Wahr­schein­lich­keit, dass der Cyber­an­griff erfolg­reich durch­ge­führt wird, ist gerin­ger als im ers­ten Moment erwartet.

Als drit­ter Schritt ist zu bewer­ten, wie groß der Auf­wand ist, eine Sicher­heits­lü­cke zu schlie­ßen. Meltdown/Spectre kann nur extern geschlos­sen wer­den, aber Maß­nah­men, um den Angriff zu erschwe­ren, sind emp­feh­lens­wert und durchführbar.

Aus min­des­tens die­sen drei Schrit­ten besteht eine Risi­ko­ana­ly­se, auch als Risk and Thre­at Ana­ly­sis bezeich­net. Es ent­steht eine Matrix zu Sicher­heits­ei­gen­schaf­ten des Produkts.

cybersecurity grafik klein

Für grö­ße­re Pro­duk­te emp­fiehlt sich der Ein­satz von Werk­zeug­un­ter­stüt­zung. Aber das ist eine ande­re Geschichte.

Die ange­ris­se­nen Schrit­te kön­nen nur pas­si­ve Sicher­heit gewähr­leis­ten. Denn bis­her wur­den Sicher­heits­aspek­te betrach­tet, die all­ge­mei­ner Natur sind, die Lis­ten aus den ange­spro­che­nen Doku­men­ten, oder sicher­heits­re­le­van­te Feh­ler, die ande­re schon gefun­den haben, wie Patch­days von Soft­ware-Her­stel­lern. Feh­ler im eige­nen Pro­dukt wer­den dadurch nicht berück­sich­tigt. Akti­ve Sicher­heit kann nur durch pro­dukt­spe­zi­fi­sche Tests gefun­den wer­den. Erst sta­ti­sche Code­ana­ly­se, Fuz­zing und Pene­tra­tion­tests kön­nen akti­ve Sicher­heit gewähr­leis­ten. Die nächs­te Geschich­te, die zu erzäh­len wäre …

Und ein abschlie­ßen­der Punkt: Schon der Tes­ting Gui­de 4 von OWASP stell­te fest, dass zwar die Zeit zwi­schen der Ent­de­ckung einer Gefähr­dung und ihrem Patch gleich bleibt, die Zeit bis zur akti­ven Aus­nut­zung aber immer kür­zer wird. Umso not­wen­di­ger wird die Durch­füh­rung der ange­führ­ten Schrit­te zur Risi­ko­ana­ly­se und regel­mä­ßi­ger Test des Pro­dukts auf Sicherheitslücken.

Sie möch­ten mehr über die­ses The­ma erfah­ren? Dann spre­chen Sie mich bit­te jeder­zeit an. Ich freue mich auf das Gespräch mit Ihnen.

Kommentare und Feedback gerne via Social Media:

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