Szerverterem agyi képalkotó felvétellel, felhőkapcsolattal és kórházi hálózattal
Szolgáltatások · Orvostechnikai eszközök kiberbiztonsága

Kiberbiztonsági dokumentáció hálózatra kapcsolt orvostechnikai eszközökhöz

Ha egy eszköz szoftvere képes internetkapcsolatot létesíteni, az eszköz az FD&C Act 524B. szakasza szerint cyber device besorolást kap. Az EU MDR a szoftveres eszközöknél információbiztonsági szempontú tervezést ír elő (I. melléklet, 17.2., 17.4. és 18.8. pont). A Silurus Software az IEC 81001-5-1 szerint készíti el a threat modelt (amerikai szóhasználatban threat modeling), dolgozza ki a biztonsági követelményeket, és végzi el azok verifikációját. Ugyanezen szabvány szerint állítjuk össze az SBOM-ot (software bill of materials, a build összes szoftverkomponensének jegyzéke), és alakítjuk ki a sérülékenységkezelési folyamatot. Mindez az EU MDR szerinti műszaki dokumentációt és az FDA forgalomba hozatal előtti benyújtását szolgálja. A szabályozási felelősség és a release-ről szóló döntés továbbra is a jogi gyártóként eljáró ügyfélnél marad.

Szabvány
IEC 81001-5-1
FDA
Forgalomba hozatal előtti kiberbiztonság
SBOM
CycloneDX · SPDX · VEX-nyilatkozatok
Folyamat
IEC 62304 · ISO 13485 · ISO 14971
Mivel foglalkozunk

A teljes eszköz kiberbiztonsága

01

Threat modeling

A teljes rendszert egyetlen threat model alapján vizsgáljuk. Minden fenyegetésnél értékeljük, mennyire használható ki, és milyen hatással lehet a betegre. Ha a fenyegetés ártalmat okozhat, összekapcsoljuk az ISO 14971 szerinti kockázatkezelési dokumentáció megfelelő tételével. Minden fenyegetéshez biztonsági intézkedést rendelünk, vagy dokumentáljuk a kockázat elfogadását.

02

Biztonsági architektúra

Már az architektúra tervezésekor megtervezzük az azonosítást, a titkosítást, a secure bootot, a naplózást és a rendszerelemek elkülönítését.

03

Biztonsági követelmények és tesztek

Minden védelmi intézkedéshez követelményt rendelünk, amelyet teszttel, elemzéssel vagy felülvizsgálattal verifikálunk. Az eredményeket és a fennmaradó kockázatot a funkcionális tesztekkel közös nyomon követhetőségi mátrixban rögzítjük.

Verifikáció és validáció →
04

SBOM és SOUP

Minden buildből CycloneDX vagy SPDX formátumú SBOM-ot állítunk elő, majd összevetjük a kiadott szoftvercsomaggal. Az SBOM és a SOUP-lista (az eszközben használt, ismeretlen eredetű, külső féltől származó kódok jegyzéke) ugyanazokat az azonosítókat használja. A komponensek támogatási állapotát és a támogatás megszűnését is nyilvántartjuk.

05

Sérülékenységkezelés a release után

Az új sérülékenységeket összevetjük az SBOM-mal. Dokumentáljuk, hogy érintik-e az adott eszközt, és milyen intézkedést igényelnek. Ha az ügyfél kéri, az eredményt VEX-nyilatkozatban is megosztjuk. A javításokat szabályozott változáskezelési folyamatban végezzük.

06

Biztonságos frissítések

A frissítéseket digitálisan aláírjuk, ellenőrizzük az aláírásukat, és megakadályozzuk a korábbi verziókra történő jogosulatlan visszaállítást. A helyreállítást szabályozott eljárás szerint végezzük. Ezeket az intézkedéseket a kockázatkezelési dokumentációban és a threat modelben is elemezzük.

Beágyazott szoftver- és firmware-fejlesztés →
07

Hálózati interfészek

Minden interfésznél elemezzük a fenyegetéseket, és kialakítjuk a szükséges védelmet. A vizsgálat során a kórházi hálózat felőli kapcsolatokat is ellenőrizzük.

A gyakorlatban

Feladatok, amelyekkel hozzánk fordulnak

Kiindulási helyzet

FDA-beadvány előtt álló, hálózatra kapcsolt eszköz

Egy hálózatra kapcsolt orvostechnikai eszköz FDA-benyújtás előtt áll. Az eszköznek teljesítenie kell az FD&C Act 524B. szakaszában előírt, forgalomba hozatal előtti kiberbiztonsági követelményeket.

Így dolgozunk

Elkészítjük a threat modelt, a biztonsági architektúra nézeteit, a kiberbiztonsági kockázatértékelést és az SBOM-ot. Az ismert sérülékenységeket is értékeljük, és dokumentáljuk a release utáni kiberbiztonsági intézkedések tervét. Mérnökeink biztonsági teszteket, köztük penetrációs teszteket végeznek, az eredményeket pedig összekapcsolják a biztonsági intézkedésekkel. A dokumentumokat az eSTAR-benyújtáshoz állítjuk össze.

Kiindulási helyzet

Forgalomban lévő eszköz hiányzó kiberbiztonsági dokumentációval

Egy hálózatra kapcsolt eszköz már forgalomban van. Egy kórház vagy a bejelentett szervezet (az eszközt az EU MDR szerint tanúsító független szervezet) bekéri a biztonsági dokumentációját.

Így dolgozunk

A meglévő architektúrát és forráskódot vizsgáljuk meg először. Elkészítjük a threat modelt és az SBOM-ot, teszteljük a biztonsági intézkedéseket, és megválaszoljuk a felmerülő kérdéseket. A kórházi beszerzésekhez szükséges kérdőívek, például az MDS2 kitöltésében is segítünk.

A folyamat menete

Az architektúrától a sérülékenységkezelésig

1. lépés

Architektúra

Feltérképezzük a teljes rendszer adatáramlását, interfészeit és bizalmi határait.

2. lépés

Fenyegetésmodell

Minden fenyegetésnél értékeljük a kihasználhatóságot és a lehetséges ártalmat. Mindegyikhez védelmi intézkedést vagy dokumentált kockázatelfogadást rendelünk.

3. lépés

Követelmények és tesztek

Minden védelmi intézkedéshez követelményt fogalmazunk meg, amelyet teszttel, elemzéssel vagy felülvizsgálattal verifikálunk.

4. lépés

SBOM és release utáni sérülékenységkezelés

Minden buildből SBOM-ot készítünk, és minden release-nél ellenőrizzük. Az új sérülékenységeket értékeljük, az eredményeket pedig dokumentáljuk.

Mit adunk át

Kiberbiztonsági dokumentáció

D-01

Threat model és a biztonsági architektúra nézetei

Elkészítjük az FDA útmutatójában megnevezett architektúranézeteket. Bemutatjuk a teljes rendszert, a több beteget érintő ártalmakat, a frissíthetőséget, a biztonsági javítások telepíthetőségét és a biztonsági használati eseteket. Ábrázoljuk a bizalmi határokat is. Minden fenyegetéshez hozzárendeljük a védelmi intézkedést, annak verifikációját és a fennmaradó kockázatot.

STRIDE fenyegetéselemzési táblázatminta →
D-02

Kiberbiztonsági kockázatértékelés és tesztelés

Minden fenyegetésnél értékeljük a kihasználhatóságot, és az ISO 14971 szerinti dokumentációban összekapcsoljuk a lehetséges ártalommal. A védelmi intézkedésekhez követelményeket fogalmazunk meg, és hozzárendeljük őket a tervezéshez és a verifikációhoz. Elkészítjük a biztonsági tesztjelentést, és értékeljük a még nem megoldott rendellenességek biztonsági kockázatait.

D-03

SBOM és VEX

A buildből SBOM-ot készítünk, és minden ismert sérülékenységnél megvizsgáljuk, hogy érinti-e az eszközt.

SBOM-részletminta →
D-04

Kiberbiztonság-kezelési terv

Kidolgozzuk a biztonsági felügyelet, az összehangolt sérülékenység-bejelentés és a javítások folyamatát. A javításokat a gyártó változáskezelési rendszeréhez igazítjuk. Elkészítjük a címkézéshez szükséges biztonsági információkat, és dokumentáljuk a kórházi hálózat biztonságos konfigurációját.

EU és USA

Közös bizonyítékkészlet két benyújtáshoz

Európai Unió

EU MDR

Szabályozási szakértőinkkel közösen az EU MDR I. mellékletének 17.2., 17.4. és 18.8. pontjaihoz rendeljük a kiberbiztonsági követelmények teljesítését igazoló bizonyítékokat. Ezek a műszaki dokumentáció részét képezik.

Egyesült Államok

FDA

FDA-tanácsadóinkkal közösen elkészítjük a forgalomba hozatal előtti beadvány kiberbiztonsági részeit.

Technológiák és szabványok

Amivel dolgozunk

Technológiák és eszközök

SonarQubeCoverityPolyspacePC-lintclang-tidyCodeQLSemgrepOWASP Dependency-CheckSyftGrypeDependency-TrackANSI/AAMI SW96:2023

Szabványok, előírások és fejlesztési gyakorlatok

MISRA CIEC 81001-5-1FDA section 524BFDA premarket cybersecurity guidanceMDCG 2019-16 rev.1EU MDREU MDR Annex IISO 14971AAMI TIR57IEC 62304ISO 13485Threat modellingSTRIDECybersecurity risk assessmentSecurity architecture viewsSBOMCycloneDXSPDXVEXPenetration testingCoordinated vulnerability disclosureeSTARMDS2

Silurus Software

  • A Silurus Software 2017-ben alakult, irodái Budapesten és Szingapúrban találhatók
  • Több mint 40 mérnök, EU MDR szabályozási szakértők és FDA-tanácsadók
  • Az ügyfél ISO 13485 szerinti minőségirányítási rendszerében dolgozunk. A feladatokat és a felelősségi köröket még a munka megkezdése előtt írásban rögzítjük. Ha az ügyfélnek még nincsenek dokumentált szoftverfejlesztési eljárásai, IEC 62304 szerinti sablonokat adunk. Ezeket az ügyfél beépítheti a saját rendszerébe.
  • Többéves mérnöki együttműködés egy európai MedTech-gyártóval
  • Török Péter alapító és CTO 1999 óta foglalkozik orvostechnikai szoftverekkel. Korábban a Siemens Healthcare (syngo.via) szoftverfejlesztési igazgatója, majd a Mediso Medical Imaging Systems K+F vezetője volt.
  • ISO 9001:2015 (NQA, 171041 számú tanúsítvány, érvényes 2027. márciusig) és ISO/IEC 27001:2022 (NQA, 728872 számú tanúsítvány, érvényes 2029. augusztusig)
  • 2025-ben AAA minősítést kaptunk a Dun & Bradstreet hitelképességi értékelésében, amely a legmagasabb minősítési fokozat
  • A budapesti Eötvös Loránd Tudományegyetem (ELTE) kutatási partnerei vagyunk
  • 2027-től ipari partnerként veszünk részt az EU Horizon Europe LOGOS projektjében a Bolognai Egyetemmel, a Pisai Egyetemmel, az Amszterdami Egyetemmel és a brnói Masaryk Egyetemmel
  • Dr. Szántó Linda ügyvezető 2025-ben elnyerte a Female Business Leader of the Year, 2026-ban pedig a The Pioneer Award díjat
Hogyan dolgozunk →Minőség és szabványok →Dokumentumminták →Esettanulmányok →
FAQ

Gyakori kérdések

01

Milyen SBOM-formátumot adtok át?

Minden buildből CycloneDX vagy SPDX formátumú SBOM-ot készítünk. Összevetjük a release-ben szereplő szoftverrel, így az átadott dokumentum pontosan a kiadott verziót írja le.

02

Az eszközünk már forgalomban van. Utólag is elkészíthetitek a kiberbiztonsági dokumentációt?

Igen. A meglévő architektúrát és forráskódot vizsgáljuk meg, majd elkészítjük a threat modelt, az SBOM-ot, valamint a hiányzó követelményeket és teszteket. Az utólag elkészített dokumentáció az eszköz tényleges állapotát írja le. A hiányzó biztonsági intézkedéseket megvalósítjuk a szoftverben, majd dokumentáljuk őket.

03

Hogyan követhetők nyomon a biztonsági tesztek?

A funkcionális tesztekkel közös nyomon követhetőségi mátrixot használunk. Minden tesztet összekapcsolunk azzal a védelmi intézkedéssel, amelyet verifikál.

04

A mi minőségirányítási rendszerünkben és sablonjainkkal dolgoztok?

Igen. A dokumentumokat a meglévő sablonok alapján készítjük el, és az ügyfél dokumentumkezelési szabályait követjük.

05

Ugyanaz a munka megfelelhet az EU MDR és az FDA követelményeinek?

Igen. Mindkét eljáráshoz közös bizonyítékkészletet használunk. A threat model, a tesztek és az SBOM az FDA és az EU MDR követelményeinek igazolására is felhasználhatók. Szabályozási szakértőink és FDA-tanácsadóink külön elkészítik az FDA-benyújtáshoz szükséges tartalmat és az MDR I. mellékletének követelményeihez rendelt dokumentációt.

06

Ki felel a kiberbiztonsági dokumentációért?

Te, mint gyártó. Te hagyod jóvá a dokumentumokat, te döntesz a release-ről, és a szabályozási felelősség is a tiéd marad. Mi a minőségirányítási rendszeredben készítjük el és verifikáljuk a dokumentációt.

07

Végeztek penetrációs teszteket?

Igen. Mérnökeink penetrációs teszteket és más biztonsági teszteket végeznek az eszközön, annak interfészein és a felhőalapú komponenseken. A feltárt problémákat beépítjük a kockázatértékelésbe és a változáskezelési folyamatba.

08

Milyen kiberbiztonsági dokumentumokat készítetek az FDA számára?

Átadjuk a threat modelt, a biztonsági architektúra nézeteit, a kiberbiztonsági kockázatértékelést és az SBOM-ot a sérülékenységértékeléssel együtt. A dokumentáció részei a biztonsági tesztjelentések és a kiberbiztonsági intézkedések terve is.

09

Mennyi idő alatt készül el a kiberbiztonsági dokumentáció?

A szükséges munka az architektúrától és a meglévő dokumentációtól függ. Először gap analysist (a szabvány követelményeihez képest fennálló hiányosságok vizsgálata) végzünk, hogy felmérjük a rendszer jelenlegi állapotát és a feladatok terjedelmét.

10

Hogyan érinti az FDA QMSR a kiberbiztonsági munkát?

Az FDA minőségirányítási rendelete, a QMSR (21 CFR 820) 2026. február 2. óta hatályos, és hivatkozással beépíti az ISO 13485 követelményeit. A threat modelt, a kockázatértékelést és a biztonsági tesztek dokumentációját a tervezési dokumentáció részeként kezeljük ebben a minőségirányítási rendszerben. Az EU MDR szerinti műszaki dokumentáció ugyanezekre az ISO 13485 szerinti dokumentumokra épül. Így az 524B szakasz és az EU MDR követelményeinek teljesítését közös bizonyítékkészlettel igazolhatjuk.

Vedd fel velünk a kapcsolatot

Mutasd be az eszközt

Írd meg, milyen eszközről van szó, milyen rendszerekhez kapcsolódik, és melyik piacra készül. Válaszunkban ismertetjük, milyen dokumentációra lesz szükséged, és mivel érdemes elkezdeni a munkát.

Foglalj időpontot egy 30 perces szakmai egyeztetésre
Egy munkanapon belül válaszolunk.