Požadavky na kybernetickou bezpečnost SaMD podle EU MDR

Proč je kybernetická bezpečnost otázkou bezpečnosti, ne jen IT

Tady je klíčová změna perspektivy: podle EU MDR se kybernetická bezpečnost považuje za otázku bezpečnosti pacientů, nikoli za datovou bezpečnost nebo provoz IT. Kybernetický útok, který zkorumpuje diagnostický výstup, nebo ransomware, který vyřadí klinický systém, vytváří riziko pro bezpečnost pacienta. Proto jsou požadavky na kybernetickou bezpečnost v GSPR — Obecných požadavcích na bezpečnost a výkon v Příloze I — a ne v samostatné IT příloze.

GSPR 17.2 je konkrétní ustanovení: prostředky, které zahrnují software nebo jsou softwarem, musí být vyvíjeny a udržovány tak, aby zajišťovaly přiměřenou úroveň bezpečnosti v prostředích, ve kterých jsou používány, včetně ochrany před neoprávněným přístupem, který by mohl ohrozit bezpečnost a výkon. Klíčová fráze je „prostředí, ve kterých jsou používány" — musíte pochopit, jak a kde váš software běží, jak realisticky vypadá prostředí hrozeb, a kolem toho postavit bezpečnostní opatření.

MDCG 2019-16 rev.2 — praktický průvodce

MDCG 2019-16 rev.2 je dokument, který vám říká, jak „přiměřená kybernetická bezpečnost" skutečně vypadá v technickém souboru. Pokrývá celý životní cyklus prostředku: od bezpečného návrhu přes nasazení až po konec životnosti. Dokument zavedl strukturovaný přístup, který se stal de facto standardem pro to, co Notifikované osoby očekávají.

Klíčové prvky, které vás pokyny vyzývají řešit:

Modelování hrozeb a hodnocení bezpečnostních rizik — systematický proces pro identifikaci hrozeb, posouzení pravděpodobnosti a dopadu a určení bezpečnostních kontrol. Zde žije integrace s ISO 14971. Bezpečnostní hrozby jsou nebezpečné situace; úspěšné zneužití těchto hrozeb je nebezpečnou situací; újma na pacientovi je škodlivá událost. Prožeňte to procesem řízení rizik.

Bezpečnostní požadavky — odvozené z modelu hrozeb. Požadavky na autentizaci, pravidla řízení přístupu, ochrana integrity dat, protokolování auditu, požadavky na šifrování. Musí být zdokumentovány jako formální požadavky a sledovány celým vývojovým procesem IEC 62304.

Bezpečný návrh — architektonická rozhodnutí, která snižují útočnou plochu: přístup s minimálními oprávněními, validace vstupů, bezpečná komunikace (TLS, certificate pinning), správa závislostí. Dokumentujte designová rozhodnutí a jejich zdůvodnění.

Správa zranitelností — proces pro zjišťování, posuzování a řešení zranitelností v softwaru a jeho závislostech po celou dobu životního cyklu produktu. Zahrnuje sledování veřejných databází zranitelností (CVE/NVD) pro zranitelnosti v knihovnách třetích stran, které používáte.

Plánování konce životnosti — kdy přestanete podporovat bezpečnostní aktualizace? Co se stane s uživateli starších verzí? MDR vyžaduje, abyste měli plán.

Integrace kybernetické bezpečnosti do ISO 14971

Nejčastější strukturální chyba, kterou týmy dělají, je nakládat s kybernetickými riziky jako s oddělenou analýzou vedle souboru rizik ISO 14971. MDCG 2019-16 rev.2 je explicitní: kybernetická rizika patří do hlavního souboru řízení rizik. Model hrozeb informuje identifikaci nebezpečí. Bezpečnostní kontroly jsou opatření pro snížení rizika. Zbytkové riziko z kybernetických hrozeb přispívá k celkovému závěru o přínosu a riziku.

V praxi to znamená:

1. Váš plán řízení rizik by měl výslovně zahrnovat kybernetická rizika do rozsahu.
2. Identifikace nebezpečí by měla zahrnovat kybernetické hrozby (neoprávněný přístup, útoky na integritu dat, útoky na dostupnost, spoofing, manipulace).
3. Bezpečnostní kontroly by měly být zdokumentovány jako zmírnění rizik s verifikačními důkazy.
4. Zpráva o řízení rizik by měla řešit zbytkové kybernetické riziko a zahrnout ho do celkové analýzy přínosu a rizika.

Pokud soubor ISO 14971 kybernetickou bezpečnost vůbec nezmiňuje, jde o mezeru. Notifikovaná osoba ji najde.

Jak vypadá dobrý stav v různých třídách prostředků

Třída I SaMD: i bez přezkumu Notifikovanou osobou se GSPR 17.2 stále uplatňuje. Zdokumentujte model hrozeb a bezpečnostní kontroly v technickém souboru. Nemusí být propracované, ale musí být přítomny a přiměřené prostředí hrozeb, ve kterém software funguje.

Třída IIa: počítejte s otázkami Notifikované osoby ohledně bezpečnostních požadavků, jak byly odvozeny a jak jste je testovali. Záznamy V&V by měly zahrnovat bezpečnostní testování.

Třídy IIb a III: plný přezkum. Model hrozeb, bezpečnostní architektura, důkazy z penetračního testování a proces správy zranitelností budou přezkoumány. Pro software, který se připojuje k sítím, zpracovává citlivá data pacientů nebo se integruje s nemocniční IT infrastrukturou, je penetrační testování kvalifikovanou třetí stranou v podstatě očekáváno.

Postmarketingová dimenze

Co týmy překvapí: povinnosti kybernetické bezpečnosti nekončí spuštěním. Váš systém PMS musí zahrnovat monitorování nových kybernetických zranitelností a hrozeb. Pokud je v knihovně, kterou software používá, objevena závažná nová zranitelnost, musíte ji posoudit, rozhodnout o reakci a tu realizovat — včetně záplaty a potenciálně vydání Field Safety Corrective Action, pokud by mohla být ohrožena bezpečnost pacientů.

Zabudujte od prvního dne do PMS lehký proces monitorování zranitelností. Je mnohem snazší udržovat ho než ho dodatečně implementovat.

Poznámka k průniku s NIS2 a AI Act

Pokud je váš SaMD nasazen ve zdravotnickém zařízení pokrytém NIS2 (směrnice o bezpečnosti sítí a informací), může mít vaše organizace dodatečné povinnosti kybernetické bezpečnosti nad rámec MDR. A pokud software obsahuje AI/ML komponenty, mohou se také uplatňovat bezpečnostní požadavky EU AI Actu pro vysoce rizikové AI systémy. Tyto rámce se navzájem nerušení — musíte splnit všechny. Zdroj o AI/ML jako zdravotnickém prostředku v této kategorii pokrývá průnik s AI Actem podrobněji.