česky english Vítejte, dnes je neděle 17. listopad 2024

Stručný úvod ke spolehlivému provozu vestavných zařízení v medicíně

DPS 3/2021 | Články
Autor: Marten L. Smith | Microchip Technology
01.jpg

Když dojde na návrh vzájemně propojeného vybavení používaného v medicíně, bezpečnost, resp. zabezpečení vestavných zařízení se zde staly jednou z hlavních priorit. Na druhou stranu není to zase tak dávno, kdy si mnozí začali potřebu něco v této věci učinit teprve přiznávat.

Z důvodu dlouhých vývojových cyklů však implementace bezpečnostních opatření u medicínských systémů zaznamenala nižší prioritu, takže bylo nutné čekat na další generaci produktů, nebo dokonce i dvě. Takový druh uvažování se naštěstí postupně vytratil, zvláště když uvážíme spoustu bezpečnostních hrozeb pro zařízení internetu věcí (IoT) z poslední doby.

Nekonečný proud novinek zahrnujících bezpečnostní útoky a oznámení o zranitelnostech se dnes dotýká všech typů vzájemně propojených zařízení. A systémy používané v medicíně zde bohužel nemají žádnou výjimku.

S rostoucím počtem propojených medicínských zařízení, která se nyní dále stávají součástí tzv. IoMT, tedy Internet of Medical Things, se bude zvyšovat i zranitelnost těchto systémů zahrnujících též údaje o pacientech. Znepokojení ohledně právní odpovědnosti, stejně jako ochrany firemní značky, duševního vlastnictví a také výnosů se stává realitou všedního dne.

V této oblasti je zapotřebí počítat se spoustou bezpečnostních hrozeb různého typu. Konkrétní volba protiopatření, která bude v rámci vestavného zařízení pro medicínské účely nutné zapracovat, závisí na dané aplikaci a také způsobu, jak vše nakonec bude využíváno.

vyvoj-1
Obr. 1 Zabezpečení vestavných návrhů pro medicínské účely nelze brát na lehkou váhu

K nejsilnějším důvodům, proč medicínská zařízení připojovat do cloudu, patří realizace nových řešení umožňujících sledování stavu pacienta a jeho vzdálený dozor. Jakmile se však zařízení někam připojí, může se naneštěstí stát cílem pro útočníky. Příkladem dvou častých hrozeb ze strany počítačových pirátů se pro medicínské systémy provázané s cloudem stávají tzv. útoky typu „denial-of-service“ a „man-in-the-middle“.

K útoku ve stylu „denial-of-service“ může např. dojít v případě, když hackeři převezmou kontrolu nad propojeným, dálkově monitorovaným systémem pacienta a zahltí cloudový server spoustou nadbytečných požadavků směřujících k tomu, aby jej přetížili a zamezili přitom vykonání oprávněných požadavků. Nejhorší případ pak bude spočívat v distribuovaném útoku takového typu. Útočníci se např. nabourají do všech propojených monitorovacích systémů pacientů v nemocnici a odesílají takové množství redundantních požadavků, až přetíží cloudový server obsluhující veškeré monitorovací jednotky.

O útoku ve stylu „man-in-the-middle“ pak hovoříme v případě, kdy počítačoví piráti získávají přístup třeba k propojené pumpě s infuzí dodávající pacientovi odměřené množství morfinu. Hacker nyní dokáže komunikaci mezi pumpou a serverem nejen odposlouchávat, ale rovněž ji pro kteroukoli ze stran zfalšovat. Útočník je tedy mimo jiné schopný převzít nad pumpou vlastní kontrolu a ve výsledku žádný medikament buď nepodat vůbec, nebo pacienta pro změnu předávkovat. Oba scénáře mohou být pro pacienta i všechny zúčastněné katastrofální.

Klasická protiopatření u těchto a také dalších typů útoků dříve plně spočívala v režii softwarových řešení. Nyní se však implementují v rámci rychlejších a cenově dostupnějších hardwarových prvků. Ideální návrh hardwarových protiopatření může proto zahrnovat integraci řady tradičních softwarových funkcí přímo do čipů.

Bezpečnostní čipy jsou k dispozici v mnoha různých provedeních. Vývojáři zařízení pro medicínské účely by se proto měli již na samotném začátku návrhového cyklu rozhodnout, které funkce a také vrstvy zabezpečení jsou pro jejich řešení nezbytné. Až tak učiní, potřebují dále vybrat bezpečnostní čipy, které takové funkce zprostředkují.

Z různých druhů bezpečnostních čipů zmiňujeme například kryptografické mikrokontroléry a mikroprocesory, stejně jako další bezpečnostní prvky. Ve spojení s dobře navrženým firmwarem a také organizovanou architekturou cloudového zabezpečení takové čipy přináší bezpečnostní funkce a protiopatření zajišťující u propojených medicínských zařízení důvěrnost informací, integritu dat i prokazování věrohodnosti. Více informací ke zmíněným typům čipů naleznete v odkazech na konci článku.

Jedním druhem čipu, který dokáže zmírnit rizika spojená s útoky typu „denial-of-service“ a „man-in-the-middle“, máme obvykle na mysli bezpečnostní prvek nebo obvod CryptoAuthentication™. Typicky se jedná o malé čipy, např. v pouzdrech typu UFDN či SOIC s osmi vývody, které je možné do návrhu propojeného medicínského zařízení snadno doplnit. Bezpečnostní prvek byl přitom navržen tak, aby v příslušném zapojení spolupracoval s MCU.

Zmíněné bezpečnostní prvky – čipy – zde nabízí funkce, jako jsou kvalitní generátor náhodného čísla, hardwarové šifrování, zajištěné uložení klíče a pro mikrokontroléry rovněž i možnosti bezpečného zavádění. K dispozici máme také protiopatření – ochranu před útoky vedenými postranním kanálem nebo aktivní zamezení neoprávněnému zásahu, která pak mohou potlačit vliv „zadních vrátek“ spojovaných s nedokonalým návrhem softwaru medicínského zařízení.

Pokud bychom chtěli pro bezpečnostní prvek – čip – vybrat jednoduchou analogii, zvolíme trezor střežící něco důvěrného. Taková tajemství se přitom do trezoru vkládají během výrobního procesu.

V kontextu bezpečnostního prvku – čipu – se zmíněná tajemství nazývají klíče. Na klíče zde přitom lze nahlížet jako na jakousi pověřovací listinu s oprávněním ukončit nebo také nařídit – schválit – spojení s medicínským zařízením. Schvalování v procesu připojování nazýváme autentizací.

Postup vpravení těchto klíčů do čipu se označuje jako „provisioning“. Jedná se o dopředu naprogramovanou záležitost – proces, k jehož dokončení dochází v chráněných podmínkách výrobce čipu. Díky takto zabezpečenému přístupu není možné, aby klíče kdokoli spatřil, takže nejsou nikdy ani odhaleny.

Ve výsledku jsou tedy medicínská zařízení během své činnosti v nemocnicích, na klinikách nebo i doma u pacientů fyzicky zabezpečená. Posledně popsaný spolehlivý proces pomůže rovněž vyloučit riziko spojené s výrobci desky třetích stran a případným odcizením klíčů uložených v bezpečnostním prvku.

Když je tedy zařízené určené pro medicínské účely v provozu a hodlá se připojit do cloudu, projde si procesem ověřování pravosti. Cloudový server v jeho průběhu odesílá výzvu bezpečnostnímu prvku – čipu, který dále poskytuje odezvu na základě tajného klíče. Pokud je odpověď bezpečnostního prvku v pořádku, bude přístup k serveru umožněn.

vyvoj-2
Obr. 2 Jinak tomu nebude ani v případě otázek spojených s bezpečným provozem

Bezpečné prokazování pravosti cloudovému serveru je pro vývojáře medicínských zařízení, kteří by chtěli něco takového implementovat „na vlastní pěst“, složitým a možná i neznámým procesem. Z tohoto důvodu může být bezpečnostní prvek – čip – ve výrobním závodě dodavatele dopředu rovněž i nakonfigurován a zajištěn společně s kredity pro potvrzení věrohodnosti v návaznosti na oblíbené cloudové služby typu Amazon Web Services (AWS) IoT Core, Microsoft Azure IoT Hub nebo Google IoT Core. Návrh si tak budeme moci výrazně zjednodušit, zrychlit a v porovnání s vývojáři zařízení pro medicínské účely, kteří se o vše pokoušejí sami, rovněž i zlevnit.

V reakci na spoustu starostí o bezpečnost dnes máme okamžitě k dispozici řešení zvyšující ochranu medicínských zařízení. Bezpečnostní prvek nebo čipy CryptoAuthentication mohou být docela jednodušší a také finančně méně náročnou cestou, jak v případě cloudu a současných propojených zařízení v medicíně zavést funkce ověřování pravosti, včetně možností celkového zabezpečení.

Nejen zabezpečení, ale i bezpečnost

Bezpečnostní požadavky se rozšířily v mnoha průmyslových odvětvích. Pro naše účely lze použít definici, že bezpečnostní procesy a funkce zaznamenávají selhání u elektrických či elektronických systémů a produktů s cílem zabránit úrazům, škodám nebo též událostem, které by mohly případně ohrozit životy. S novými otázkami a také požadavky se z hlediska bezpečnosti potkáváme v řadě různých aplikací, třeba u automobilů, v rámci průmyslových elektronických systémů, domácích spotřebičů a také u zařízení používaných v medicíně.

Za účelem návrhu bezpečných a také robustních medicínských zařízení se již toho ve zmíněném odvětví vykonalo mnoho. Protože však mohou elektronické systémy obecně vypovědět službu, musí zde existovat způsob, jak taková selhání s jistotou uchopit.

Jednoduše řečeno, smysl funkční bezpečnosti spočívá v detekci selhání a přiměřené reakci, takže nebude ublíženo lidem. Lze toho dosáhnout dvěma způsoby. První cesta znamená omezení systematických chyb již v průběhu vývoje, zatímco další se pak dotýká návrhu, který je schopný odhalit náhodná selhání a přejít do bezpečného režimu.

Nesmíme však zapomínat na jednu věc. Funkční bezpečnost nesnižuje celkovou četnost výskytu chyb. Ta je přitom ošetřena návrhem a procesy při řízení kvality ve výrobě – jak pro samostatné součástky použité v návrhu, tak též u medicínského zařízení samotného. Smysl práce se standardy funkční bezpečnosti spočívá spíše v přeměně nebezpečných poruch na bezpečné. Jedná se rovněž o proces, při kterém smí vývojář pro nebezpečná selhání definovat přípustnou mez.

Negativní novinové titulky na adresu bezpečnostních problémů medicínských zařízení už nejsou zapotřebí. Zajištění spolehlivého provozu je v této věci pro vývojáře zcela klíčové, protože zmiňovaná zařízení mohou mít vliv na zdraví pacientů, kteří jsou na nich závislí. Podobně jako u zabezpečení potřebujeme i v případě bezpečnosti vše uvážit již na začátku vývoje každého zařízení pro medicínské účely.

Pro spoustu různých průmyslových oblastí zde máme řadu standardů funkční bezpečnosti. Bezpečnost návrhu vestavného medicínského zařízení tak může záviset na zapracování více než jednoho z těchto standardů. Vývojáři zde například zjistili, že své návrhy nestačí jen podřídit požadavkům IEC 62304 s ohledem na životní cyklus softwaru, ale do svého návrhového procesu potřebují rovněž zahrnout průmyslový standard funkční bezpečnosti IEC 61508. Prvně zmiňovaný standard takové návrhy ve skutečnosti vede k tomu, aby jako základ pro dobré softwarové metody, postupy a nástroje rovněž použili IEC 61508.

Je důležité si uvědomit, že funkční bezpečnost není u medicínského zařízení jen o hardwaru či softwaru, ale k tomu, aby návrh zůstal bez rizika, zahrnuje celý vývojový proces, včetně jeho ekosystému. Například mikrokontroléry navržené pro aplikace zahrnující požadavky na funkční bezpečnost jsou podporovány z hlediska integrovaných hardwarových funkcí, knihoven a testů – softwarové diagnostiky, bezpečnostních manuálů a zpráv (FMEDA), v závislosti na standardu a úrovni bezpečnosti, kterou také podporují.

Funkce takového ekosystému nejenže pomohou vyhovět z hlediska bezpečnostních standardů, ale mohou hrát rovněž významnou roli při detekci chyb v průběhu samotné činnosti systému. Na kritéria spojená s funkční bezpečností by se proto při výběru mikrokontroléru, který vývojáři hodlají použít ve svém návrhu bezpečného medicínského zařízení, nemělo rozhodně zapomínat.

Níže v textu uvádíme několik příkladů podpůrných možností u MCU zohledňujících funkční bezpečnost, které mohou být v návrhu medicínského zařízení významné z hlediska detekce chyb:

  • knihovny pro diagnostiku s činností jak po resetu, tak i během samotného chodu, pro zajištění, že v rámci systému nedochází k žádným chybám,
  • vývojové nástroje pro mikrokontrolér jsou považovány za bezpečné, takže do systému nevnáší chyby; předpoklady z pohledu standardů funkční bezpečnosti jsou v případě vývojového nástroje jeho důležitou součástí,
  • návrh s mikrokontroléry vybavenými integrovanými a chytře navrženými perifériemi pomůže zvýšit spolehlivost a monitorovat aplikace, které jsou z hlediska bezpečnosti klíčové.

Ve světě zařízení určených pro medicínské účely bychom z pohledu bezpečnosti neměli činit žádné kompromisy. Hardwarové a také softwarové funkce pak společně zajistí, že takový systém pracuje podle očekávání a bude rovněž spolehlivě odstaven, pokud se již nějaká výjimka či problém objeví.

Závěr

Otázky spojované jak se zabezpečením, tak i samotnou bezpečností vestavných medicínských zařízení hrály v minulosti u návrhového procesu obvykle „druhé housle“. Něco takového již ale nelze vůbec akceptovat. Veřejné zdraví, stejně jako dobré jméno firmy, čistý rejstřík a také finanční úspěchy z velké části závisí právě na řešeních, která pracují spolehlivě a nikomu přitom neubližují.

Odkazy:

[1] Secure Element / CryptoAuthentication, www.microchip.com/design-centers/security-ics/trust-platform

[2] Embedded Design Security, www.microchip.com/design-centers/embedded-security

[3] Functional Safety, www.microchip.com/design-centers/functional-safety

[4] Embedded Medical Device Design, www.microchip.com/design-centers/medical