A cikk legfontosabb pontjai:
A szöveg azokat a látszólag helyes kiberkockázat-elemzéseket bírálja, amelyek nem vezetnek le mérnöki döntésekre és nem épülnek be a termék fenntartásába. Bemutatja a paradigmaváltást a kockázatalapú megközelítés felé, a valós használati kontextusban és a teljes életciklus mentén.
- A tipikus „kiberkockázat-értékelés” gyakran egy low/medium/high táblázat: megfelel a compliance követelményeknek, de nincs hatással a termékarchitektúrára és a támogatásra.
- Az uniós megközelítés (CRA, MDR, 2023/1230 gépekről szóló rendelet) a kérdést a használati feltételekre és az életciklus során végzett kockázatellenőrzésre helyezi át.
- A termékkockázat-értékelés nem IT-elemzés, nem penteszt és nem az ISO 27001 bevezetése; a termék és a gyártó azon képességére vonatkozik, hogy időben fenn tudják tartani a biztonságot.
- A sebezhetőség (pl. CVE) technikai hiba; a termékkockázatot a használati kontextus, az integráció, a felhasználói viselkedés, a javításkezelés és az incidenskezelés határozza meg.
- A rosszul megválasztott védelmi intézkedések növelhetik a kockázatot: az OT-ben alkalmazott MFA, az IoMT-ben az automatikus frissítések, az IoT-ben pedig az interfészek lezárása új támadási vektorokat és mellékhatásokat hoz létre.
A technológiai vállalatok döntő többségénél már létezik a kiberkockázat-értékelésként ismert folyamat. Többnyire egy terjedelmes táblázat, bonyolult mátrix vagy olyan munkalap formáját ölti, ahol a „low”, „medium” és „high” értékek dominálnak. A dokumentum hosszú listát tartalmaz általános fenyegetésekről, rövid leírásokat a lehetséges sérülékenységekről, valamint egy készletnyi standard kontrollintézkedést. Formailag minden rendben van: a dokumentum teljes, a vezetőség aláírta, és biztonságosan archiválták.
A gond az, hogy a mérnöki gyakorlatban ez a dokumentum semmin nem változtat.
Nem hat a tervezett eszköz architektúrájára. Nem befolyásolja a frissítések szállításának módjáról szóló döntést. Nem alakítja át az értékesítés utáni támogatási modellt, és nem vizsgálja felül a komponensbeszállítókkal fennálló kapcsolatokat. Compliance szempontból rendben lévő dokumentum, de a valós termékkiberbiztonság szempontjából teljesen közömbös. Ez azonban nem a mérnöki vagy security csapatok kompetenciahiányának a következménye. A probléma a kiindulópont alapvetően hibás megválasztása.
A hagyományos kockázatelemzések többsége azzal a kérdéssel indul: „Milyen fenyegetések fordulhatnak elő?”. Ezzel szemben az Európai Unió új, szabályozói megközelítése – amely jól látható olyan jogszabályokban, mint a Cyber Resilience Act (CRA), az orvostechnikai irányelvek (MDR) vagy az új gépekről szóló rendelet 2023/1230 – teljesen más nézőpontot kényszerít ki. Ez pedig a következő kérdéssel kezdődik:
Milyen használati feltételek mellett válhat a termék kockázathordozóvá a felhasználó, a rendszer vagy a piac számára – és képes-e a gyártó ezt a kockázatot a teljes életciklus során kézben tartani?
Ez alapvető paradigmaváltás. A kiberkockázat-értékelés termékkörnyezetben nem egyszerűen az IT-infrastruktúra fenyegetéseinek újabb elemzése. Nem is penetrációs teszt, és nem az ISO 27001 iránymutatásainak mechanikus bevezetése. Sokkal inkább a termék és a gyártó képességeinek mélyreható vizsgálata arra vonatkozóan, hogy valós üzemeltetési környezetben, időben tartósan fenn tudják-e tartani a biztonságot.
Technikai sérülékenység és termékkockázat – a kiberbiztonsági megkülönböztetés
Ahhoz, hogy a kockázatértékelés ne pusztán egy hivatali táblázat legyen, hanem mérnöki döntéstámogató eszközzé váljon, pontosan szét kell választanunk két fogalmat, amelyeket a piacon gyakran összekevernek. Ne feledjük: a sérülékenység nem egyenlő a termékkockázattal.
- Technikai sérülékenység egy konkrét, azonosítható hiba a szoftverben, a hardverkonfigurációban vagy magában a tervben. Ilyen lehet a hibás adatvalidálás, egy elavult programkönyvtár, vagy rés a hitelesítési mechanizmusban. Az ilyen hibákat olyan adatbázisokban tartják nyilván, mint a CVE rendszer (Common Vulnerabilities and Exposures). Ez azonban továbbra is kizárólag technikai szintű értékelés.
- Termékkockázat csak akkor jelenik meg, amikor a fenti sérülékenység (vagy akár annak átmeneti hiánya) beágyazódik a használat kíméletlen realitásaiba.
Ez a kontextus számos változót foglal magában: a működési környezetet (nyílt vagy izolált hálózat), az integráció módját más rendszerekkel, a felhasználói viselkedést, a biztonsági frissítések elérhetőségét (ún. patch management), valamint a gyártó szervezeti képességét az incidensekre való reagálásra.
Előfordulhat, hogy a termék a megjelenés napján nem tartalmaz ismert sérülékenységet, mégis kritikus kockázatot jelent, ha a fejlesztője nem rendelkezik hosszú távú támogatási folyamatokkal. Ennek a különbségnek a megértése rendet tesz a teljes mérnöki munkában. Erre épül a kockázatalapú megközelítés (risk-based approach). A biztonsági intézkedéseknek az előre látható visszaélési forgatókönyvekhez kell arányosnak lenniük, nem pedig egy internetes, elvont listához.
A védelem paradoxona: amikor a védekezés növeli a kockázatot IT-ben és OT-ben
A kiberbiztonsági tervezésben gyakran azt feltételezik, hogy egy új „lakat” hozzáadása mindig csökkenti a kockázatot. A gyakorlat azt mutatja, hogy néha épp az ellenkezője történik. A kontextus megértése nélkül bevezetett intézkedés új fenyegetési vektorokat hoz létre.
1. Erős hitelesítés ipari környezetben (OT)
Képzeljük el, hogy egy ipari gépen többtényezős hitelesítést (MFA) vezetünk be. IT-s szemmel ez példás lépés, azonban a kiberbiztonság az ipari automatizálásban teljesen más valóság. Gyári környezetben a berendezés 24/7 üzemel, a szervizbeavatkozások pedig időnyomás alatt zajlanak. Ha a hálózat hibázik, a technikus nem tudja online módon jóváhagyni a tokent. A termelés leáll. Mi lesz az eredmény? A frusztrált ügyfél végleg kikapcsolja ezt a mechanizmust, teljesen megkerülve a védelmet. Az intézkedés, amelynek védenie kellett volna, jelentős üzemeltetési kockázatot generált.
2. Automatikus frissítések orvostechnikai eszközökben (IoMT)
A sérülékenységek gyors javítása minimalizálja a támadásoknak való kitettséget – ez az IT világában alapelv. Az orvostechnikai eszközök esetében viszont egy eljárás közben kikényszerített frissítés megváltoztathatja a rendszer viselkedését, vagy megszakíthatja a kórházi hálózattal való kommunikációt. Ilyenkor a technológiai védelem kritikus klinikai és szabályozási kockázatot teremt (az MDR szerinti tanúsítás megsértése).
3. Interfészek lezárása fogyasztói eszközökben (IoT)
A gyártó fizikailag eltávolítja a helyi diagnosztikai portokat az okosotthon-eszközből, hogy megnehezítse a hackerek hozzáférését. A gyakorlatban az arra jogosult szervizek instabil interfészeken, titkosítás mellőzésével kezdenek hibát diagnosztizálni, a haladó felhasználók pedig tömegesen telepítenek módosított szoftvert (custom firmware). Az eredmény: a gyártó teljesen elveszíti az irányítást a saját ökoszisztémája felett.
A valódi kiberkockázat-elemzés azt kérdezi: „Hogyan változik az egész ökoszisztéma stabilitása, használhatósága és biztonsága ennek a konkrét mechanizmusnak a bevezetése után?”.
A technológiai termékek kockázatelemzésének 5 leggyakoribb hibája
Az elektronikai és szoftvertermékeket piacra vivő vállalatok folyamatait értékelve a kiberbiztonsági szakértők visszatérő mintázatokat látnak.
- A vállalati IT-modell átmásolása a termékek világába. Egy termék nem szerverterem. Ismeretlen környezetben működik, gyakran offline, és laikusok konfigurálják. Az IT-eszközök termékelemzésre való ráhúzása oda vezet, hogy figyelmen kívül maradnak a kulcskérdések: az eszköz életciklusa és a kikényszerített frissítések hiánya.
- Elvont fenyegetések elemzése valós forgatókönyvek helyett. Olyan kifejezések táblázatba írása, mint a „jogosulatlan hozzáférés”, elemzési szempontból haszontalan. Az elemzésnek konkrétumokra kell épülnie: Ki? Milyen interfészen keresztül? Milyen célból? Milyen következménnyel?
- A termék életciklusának figyelmen kívül hagyása (End-of-Life). A kockázatelemzés többnyire a piacra lépés pillanatára fókuszál. Közben a kockázat idővel nő: az open-source könyvtárak elavulnak, a komponensbeszállítók pedig megszüntetik a támogatást. Fenntartási modell nélkül az elemzés hamis.
- Elszigetelődés a fejlesztőcsapattól (R&D). A kockázatértékelés audit előtti ellenőrzőlistaként kezelése egyenes út a katasztrófához. Az eredményeknek vissza kell kerülniük a mérnökökhöz, mint kőkemény architekturális követelményeknek (Secure by Design).
- A technológia fetisizálása az eljárások rovására. A cégek vagyonokat költenek fejlett kriptográfiára, de nem tudják, a vállalaton belül ki felel azért, hogy egy kutató által bejelentett sérülékenység után (Vulnerability Disclosure Program) biztonsági javítás (patch) kerüljön kiadásra.
Hogyan végezzünk a Cyber Resilience Actnek megfelelő elemzést? 7 mérnöki lépés
A kiberkockázat-értékelésnek meg kell szűnnie bürokratikus tehernek lenni. Az alábbiakban egy piaci, uniós megközelítéssel (többek között a CRA követelményeivel) összhangban álló működési modell található.
- Határozd meg a termék határait. A termék nem csak a hardver. Ide tartozik a mobilalkalmazás, a felhő, az OTA-szerverek és az API-interfészek is.
- Írd le a használati környezet kíméletlen valóságát. Ne laboratóriumi környezetet írj le. Válaszolj a tényleges internetkapcsolatra, a felhasználók kompetenciáira és az eszközhöz való fizikai hozzáférés lehetőségeire vonatkozó kérdésekre.
- Azonosítsd a visszaélési forgatókönyveket (Threat Modeling). Vesd el a generikus listákat. Használj bevált, mérnöki kockázatbecslési módszereket és eszközöket, hogy a saját iparágadhoz illesztett, pontos támadási vektorokra koncentrálj.
- Számszerűsítsd a nem pénzügyi következményeket. Értékeld a termeléskiesés, az egészségkárosodás, illetve a szabályozói kötelezettségek megsértésének kockázatát.
- Tedd fel az irányítás kérdését. Gyártóként képes vagy megelőzni, észlelni és gyorsan reagálni az azonosított visszaélési forgatókönyvre?
- Tervezd meg az arányos védelmi mechanizmusokat. A titkosításról vagy a hálózatszegmentálásról szóló döntéseknek közvetlenül az előző lépésekben adott válaszokból kell következniük.
- Tervezd meg a fenntartási folyamatot (Lifecycle). Dokumentáld a biztonsági javítások kiadásának politikáját, a támogatási időszakot, valamint az ügyféllel való kommunikáció csatornáit.
Összefoglalás: Minek kell megmaradnia egy alapos kockázatértékelés után?
A termék kiberbiztonsági kockázatértékelésének helyes lezárása soha nem egy szövegtől sűrű „költemény” az auditor számára. A munkának kézzelfogható eredményeket kell adnia: a rendszerhatárok világos térképét, kőkemény architekturális döntéseket az R&D-ben, jóváhagyott költségkeretet a frissítési politikára, valamint egy koherens auditnyomot, amely igazolja az uniós irányelveknek való megfelelést.
Egy technológiailag érett szervezet már nem azt kérdezi: „100%-ban biztonságban vagyunk?”. Ehelyett azt kérdezi: „Pontosan hol vagyunk kitéve, és képesek vagyunk-e ezt időben kezelni?”.
A terméked készen áll az új szabályozásokra?
A biztonság nem egyszeri tanúsítvány, hanem folyamatos folyamat. Ha nem szeretnéd, hogy a vállalatodnál a kockázatértékelés csak „papírmunka” legyen, érdemes proaktívan lépni. Nézd meg, hogyan készítheted fel a terméket a Cyber Resilience Act (CRA) 2026–2027-es időszakára a hivatalos harmonizált szabványok megjelenése előtt.
A termékek kiberkockázat-értékelése: miért tűnik a legtöbb biztonsági elemzés látszólag helyesnek, miközben a gyakorlatban használhatatlan?
Mert általában teljesíti a megfelelőségi (compliance) követelményeket, de nem befolyásolja a mérnöki döntéseket: az architektúrát, a frissítéseket, az értékesítés utáni támogatást és a beszállítói kapcsolatokat. Ennek eredményeként formailag rendben van, gyakorlatilag pedig közömbös.
Nem absztrakt veszélyek felsorolásából kell kiindulni, hanem azokból a használati feltételekből, amelyek között a termék a kockázat hordozójává válhat, valamint abból, hogy a gyártó képes-e ezt a kockázatot a teljes életciklus során kézben tartani. Ez a megközelítés összhangban van a CRA-ban, az MDR-ben és a 2023/1230 gépekről szóló rendeletben is megjelenő szabályozói szemlélettel.
A technikai sérülékenység egy konkrét hiba a szoftverben, a konfigurációban vagy a tervezésben (például egy hitelesítési rés), és rögzíthető például CVE-ként. A termékkockázat csak a tényleges használat, az integráció, a felhasználói viselkedés, a frissítések elérhetősége és a gyártó reagálóképessége összefüggésében jelenik meg.
Nem — a rosszul megválasztott mechanizmus növelheti a kockázatot, mert új működési problémavektorokat hoz létre. A szövegben szereplő példák azt mutatják, hogy az OT-környezetben alkalmazott MFA, az IoMT-ben az automatikus frissítések, illetve az IoT-ben az interfészek „lezárása” a védelmi megoldások megkerüléséhez, illetve működési és megfelelőségi kockázatokhoz vezethet.
Ide tartozik többek között a vállalati IT működési modelljének átmásolása a termékek világába, az általánosságokra támaszkodás a forgatókönyvek („ki, hogyan, miért és milyen eredménnyel”) helyett, valamint az életciklus és az End-of-Life problémák figyelmen kívül hagyása. Ennek következménye egy olyan elemzés, amely nem jelöl meg valós tervezési döntéseket és nem irányoz elő karbantartási/üzemfenntartási tevékenységeket.