Egy ipari vállalatnál a kiberbiztonságot sokáig az irodai informatika részének tekintették. Tűzfal, vírusvédelem, jelszavak, mentések — majd a gyártási vagy energetikai rendszer ettől külön, saját műszaki logika szerint működött.

Az IT és OT összekapcsolódásával ez a választóvonal eltűnt. A PLC, inverter, épületautomatika, SCADA, gateway és távoli szervizkapcsolat ma már ugyanannak a digitális kockázati térnek a része lehet. Közben a következmény továbbra is fizikai: leálló termelés, hibás szabályozás, kieső energiaellátás vagy nem elérhető szolgáltatás.

A NIS2 ezért vezetői és szervezeti szintre emeli a kiberkockázat kezelését. Az IEC 62443 pedig olyan ipari biztonsági szemléletet és követelményrendszert ad, amellyel az OT-környezet műszakilag is rendezhető.

A NIS2 nem technológiai bevásárlólista

Az Európai Unió NIS2 irányelve egységesebb kiberbiztonsági keretet hozott létre 18 kritikus ágazat számára. A hatály alá tartozó közép- és nagyvállalatoknak megfelelő kockázatkezelési intézkedéseket és incidensbejelentési folyamatokat kell kialakítaniuk. Az irányelv külön hangsúlyozza a felső vezetés felelősségét is.

Ez fontos változás: a kiberbiztonság nem delegálható korlátlanul egy rendszergazdának vagy külső szolgáltatónak. A vezetésnek értenie és kezelnie kell, hogy mely digitális függőségek veszélyeztetik az alapvető működést.

A NIS2 nem azt mondja meg, melyik gyártó melyik tűzfalát kell megvenni. Kockázatalapú működést vár el, többek között:

  • incidenskezelés;
  • üzletmenet-folytonosság és helyreállítás;
  • ellátási lánc biztonsága;
  • sérülékenységkezelés;
  • hozzáférés-szabályozás;
  • kriptográfia és kommunikációbiztonság;
  • biztonságtudatosság;
  • az intézkedések eredményességének értékelése.

Hogy egy adott szervezet pontosan a hatály alá tartozik-e és milyen nemzeti követelmények vonatkoznak rá (Magyarországon a NIS2-t a 2023. évi XXIII. törvény ülteti át), azt az ágazat, a méret, a szolgáltatás és az alkalmazandó nemzeti jog alapján egyedileg kell megállapítani. A műszaki kockázatok kezelése azonban akkor is üzleti érdek, ha egy vállalat végül nem kötelezett.

Miért különleges az OT-kockázat?

Az OT-rendszerek hosszú életciklusúak. Nem ritka a tíz-húsz éves berendezés, a már nem támogatott operációs rendszer vagy az olyan vezérlő, amelyet termelésleállás nélkül nehéz frissíteni.

Emellett az OT-ban:

  • a rendelkezésre állás és a fizikai biztonság elsődleges;
  • a változtatásokat technológiai kockázat miatt tesztelni kell;
  • sok eszközt eleve nem ellenséges hálózati környezetre terveztek;
  • a gyártói vagy karbantartói távoli elérés gyakori;
  • az eszközleltár sokszor hiányos;
  • a felelősség megoszlik IT, automatizálás, üzemeltetés és beszállítók között.

Ezért egy hagyományos IT-biztonsági szabályzat egyszerű átmásolása nem elég.

Az IEC 62443 szerepe

Az ISA/IEC 62443 szabványsorozat az ipari automatizálási és vezérlőrendszerek kiberbiztonságát teljes életciklusban kezeli. Nem csak az üzemeltetőre gondol: követelményeket és szerepeket határoz meg az eszközgyártó, rendszerintegrátor és eszköztulajdonos (asset owner) számára is.

A megközelítés egyik kulcsa a kockázatalapú zónák és a köztük lévő szabályozott kommunikációs kapcsolatok (conduitok) kialakítása.

Egy zónába olyan eszközök kerülhetnek, amelyek hasonló kockázattal és biztonsági igénnyel rendelkeznek. A zónák közötti adatáramlás pedig csak meghatározott útvonalon, protokollon és szabályok szerint történhet.

Ez a gondolkodás sokkal pontosabb annál, hogy „van tűzfalunk az internet felé”. A támadás vagy hiba ugyanis belülről, távoli karbantartói kapcsolaton, beszállítói laptopról vagy egy kompromittált IT-rendszerből is elindulhat.

Az első kellemetlen feladat: eszköz- és adatkapcsolati leltár

Nem lehet megvédeni azt, amiről nem tudjuk, hogy létezik.

Az OT-biztonság első érdemi lépése ezért rendszerint nem egy új termék telepítése, hanem a valós környezet feltérképezése:

  • milyen PLC-k, HMI-k, mérők, inverterek és gateway-ek működnek;
  • milyen firmware- és szoftververzióval;
  • milyen hálózaton érhetők el;
  • kivel és milyen protokollon kommunikálnak;
  • ki fér hozzájuk helyben és távolról;
  • milyen üzleti vagy fizikai folyamat függ tőlük;
  • mi történik a kiesésük vagy kompromittálódásuk esetén.

A leltárnak nem statikus Excelnek kell maradnia. A változásokat, felelősségeket, eseményeket és dokumentumokat is követhető rendszerbe érdemes kapcsolni.

A távoli elérés tipikus gyenge pont

Az ipari rendszerekhez gyakran kell gyártói vagy integrátori támogatás. A probléma nem maga a távoli hozzáférés, hanem az ellenőrizetlen, állandó és közvetlen hozzáférés.

Egy védhető megoldásnál meg kell határozni:

  • ki kezdeményezheti a kapcsolatot;
  • szükséges-e többtényezős hitelesítés;
  • melyik konkrét rendszer érhető el;
  • milyen időablakban;
  • szükséges-e helyi vagy vezetői jóváhagyás;
  • naplózható-e a munkamenet;
  • hogyan vonható vissza a jogosultság;
  • mi történik a beszállítói szerződés megszűnésekor.

Az „AnyDesk fent van a gépen, ha kell” típusú megoldás kényelmes, de nem biztonsági architektúra.

A szállítói lánc az OT része

Egy ipari rendszerben a biztonságot nem csak a saját csapat határozza meg. A hardvergyártó, firmware-beszállító, integrátor, telekommunikációs szolgáltató és felhőplatform egyaránt része lehet a kockázati láncnak.

Ezért a műszaki specifikációban és szerződésekben is szerepelnie kell például:

  • a támogatási és frissítési időszaknak;
  • a sérülékenységek bejelentési módjának;
  • a hozzáférési és naplózási követelményeknek;
  • a komponens- és verzióinformációknak;
  • az incidens alatti együttműködésnek;
  • az adatok és konfigurációk visszaadásának.

Itt találkozik a NIS2 ellátásilánc-szemlélete az IEC 62443 életciklus- és szerepköralapú megközelítésével.

Megfelelőség helyett működő biztonság

Egy auditlista kipipálása önmagában nem állít meg támadást. A valódi cél az, hogy a szervezet ismerje a kritikus folyamatait, csökkentse a támadási felületet, észlelje a rendellenességet, korlátozza a terjedést és bizonyítottan helyre tudja állítani a működést.

Az OrigSmart ebben a környezetben nem pusztán adatmegjelenítő platformként értelmezhető. A terepi eszközök, gateway-ek, hálózati kapcsolatok, identitások, események és végrehajtható folyamatok közös kezelése segít abban, hogy a biztonsági elvárás technikai működéssé váljon.

Az OrigSmart által kezelt projektekben a biztonságot az architektúra részeként kell megtervezni: szegmentált kapcsolatok, legkisebb szükséges jogosultság, naplózott események, ellenőrzött távoli elérés, helyi fallback működés és követhető intézkedés.

A NIS2 megmondja, hogy a kiberkockázatot szervezeti szinten komolyan kell venni. Az IEC 62443 pedig segít lefordítani ezt az OT-rendszerek műszaki valóságára.

Beszéljük át az Ön projektjét

Források

Megjegyzés: a cikk általános szakmai tájékoztatás, nem jogi vagy megfelelőségi tanácsadás.