ICS/SCADA rendszerek biztosítása 2026-ban

Az ipari vezérlőrendszerek biztonsága nem az IT-biztonság egy részhalmaza. Más a fenyegetési modell, mások a prioritások, és ami a legfontosabb: más a hibázás ára. Egy irodai munkaállomás újratelepítése kellemetlenség. Egy gyártósor leállítása óránként milliókban mérhető, egy hibásan beavatkozó biztonsági eszköz pedig emberéletet is veszélyeztethet.

Ez a cikk arról szól, hogyan lehet ipari környezetben úgy építeni biztonsági programot, hogy az ne az üzemeltetés ellenében működjön.

Miért nem másolható át az IT-eszköztár

Az IT-biztonság prioritási sorrendje a klasszikus CIA: bizalmasság, sértetlenség, rendelkezésre állás. Az OT-ban ez fordítva van, a rendelkezésre állás és az emberi biztonság az első, a bizalmasság az utolsó. Ebből több gyakorlati következmény adódik:

Nem lehet menetrend szerint patch-elni. Egy PLC firmware-frissítése tervezett leállást igényel, amire évente egyszer-kétszer van ablak. Sok eszköz gyártói támogatása lejárt, vagy a frissítés érvénytelenítené a rendszer minősítését. A sérülékenységkezelés itt nem a patch-elésről szól, hanem a kompenzáló kontrollokról.

Nem lehet mindenhová ügynököt telepíteni. Egy Windows XP-n futó HMI-re nem telepítesz modern EDR-t. Sok vezérlő egyszerűen nem futtat idegen kódot.

Az aktív szkennelés kárt okozhat. Egy szokásos hálózati sérülékenység-szkenner képes megbénítani egy régebbi PLC-t pusztán azzal, hogy váratlan csomagokat küld neki. Az OT-felderítésnek alapesetben passzívnak kell lennie: forgalomtükrözésből, protokoll-elemzésből épül az eszközleltár.

A protokollok nem ismerik a hitelesítést. A Modbus, a DNP3, az S7comm és társaik olyan korban születtek, amikor a hálózat fizikailag zárt volt. Nincs bennük hitelesítés vagy titkosítás, aki eléri a hálózatot, az parancsot adhat.

Kezdd az eszközleltárral, mindig

Nem lehet megvédeni azt, amiről nem tudsz. Az OT-projektek túlnyomó többsége azért akad el, mert kiderül: senki nem tudja pontosan, mi van a hálózaton.

Egy használható leltár nem eszközlista, hanem a következőket tartalmazza minden elemre:

• gyártó, típus, firmware-verzió (ez adja a sérülékenység-illesztést),
• hálózati elhelyezkedés, IP/MAC, a beszélt protokollok,
• kommunikációs partnerek, ki kivel beszél normál üzemben,
• a hozzá tartozó folyamat és annak kritikussága,
• támogatottsági állapot és a felelős szállító.

A kommunikációs mátrix az, ami a legtöbbet ér: ebből derül ki, hogy az irodai hálózatból közvetlen kapcsolat él egy vezérlőre, vagy hogy egy karbantartói laptop rendszeresen felcsatlakozik VPN nélkül.

Építs zónákat és csatornákat (IEC 62443)

Az IEC 62443 az OT-biztonság referencia-szabványa. A leghasznosabb eleme a zóna- és csatorna-modell: a rendszert azonos biztonsági követelményű csoportokra (zónákra) bontod, és pontosan definiálod, milyen forgalom mehet át közöttük (csatornák).

A klasszikus Purdue-modell rétegei jó kiindulópontot adnak:

Szint	Tartalom	Tipikus zóna-határ
4–5	Vállalati IT, ERP	Ez már IT-terület
3.5	Ipari DMZ	A legfontosabb választóvonal
3	Üzemi felügyelet, historian, MES
2	SCADA, HMI
1	PLC, RTU, vezérlők
0	Érzékelők, beavatkozók

A gyakorlatban a legnagyobb hozamú egyetlen intézkedés az ipari DMZ kiépítése a 3-as és 4-es szint közé. Semmilyen forgalom ne menjen közvetlenül az irodai hálózat és az üzem között: minden adatcsere a DMZ-ben álló köztes rendszereken (replikált historian, jump server, fájlátadó) keresztül történjen.

Ehhez tartozik a Security Level (SL) meghatározás is: zónánként eldöntöd, milyen képességű támadóval szemben kell védeni. Nem minden zónának kell SL 3-nak lennie, a besorolás kockázatarányos, és ez teszi a programot finanszírozhatóvá.

Szüntesd meg a szegmentálatlan lapos hálózatot

Sok üzemben a teljes gyártás egyetlen broadcast domain. Ez azt jelenti, hogy egy fertőzött karbantartói laptop szabadon elér minden vezérlőt.

A szegmentálás sorrendje, hozam szerint:

1. IT/OT szétválasztás ipari DMZ-vel, ez adja a legnagyobb kockázatcsökkenést.
2. Cellák/sorok elkülönítése, hogy egy sor kompromittálódása ne terjedjen át a másikra.
3. Kritikus eszközök mikroszegmentálása, biztonsági rendszerek (SIS), kulcsvezérlők.
4. Távoli hozzáférés csatornásítása: minden külső belépés egyetlen, naplózott, MFA-val védett ponton.

A távoli hozzáférés külön figyelmet érdemel: a szállítói karbantartói csatornák a leggyakoribb belépési pontok. Ha egy géptelepítő cég saját VPN-nel csatlakozik közvetlenül a berendezésére, az egy ellenőrizetlen ajtó a hálózaton.

Monitorozz passzívan, de folyamatosan

Ha megvan a kommunikációs mátrix, abból baseline lesz. Az OT-forgalom az IT-hez képest rendkívül kiszámítható: ugyanazok az eszközök beszélnek ugyanazokkal, ugyanolyan ütemben. Ez azt jelenti, hogy az anomáliadetektálás itt sokkal jobban működik, mint IT-környezetben.

Amit érdemes figyelni:

• új eszköz megjelenése a hálózaton,
• új kommunikációs kapcsolat két korábban nem beszélő eszköz között,
• mérnöki parancsok (programletöltés, üzemmódváltás, firmware-írás): ezek ritkák és mindig gyanúsak, ha nincs hozzájuk változáskezelési jegy,
• protokollszabálysértések és forgalmi mennyiség-eltérések.

Tervezz az incidensre: OT-specifikusan

Az IT-incidenskezelési terv nem használható változtatás nélkül. OT-ban:

• Az izolálás nem alapértelmezett válasz. Egy szegmens lekapcsolása leállíthatja a folyamatot; a döntést az üzemvezetéssel közösen kell meghozni, előre definiált kritériumok mentén.
• Az emberi biztonság felülír mindent. A biztonsági rendszerek (SIS) működésébe nem nyúlunk incidenskezelés címén.
• A helyreállításhoz offline mentés kell a PLC-programokból és a HMI-projektekből. Ezeket tesztelni is kell, sok szervezetnél a „mentés" egy évekkel ezelőtti fájl egy mérnök laptopján.
• Gyakorolj asztali szimulációval. Egy féléves rendszerességű tabletop az üzemvezetés és az IT részvételével többet ér, mint bármilyen dokumentum.

Reális ütemterv

Egy OT biztonsági program nem hat hét alatt épül fel. Egy működő sorrend:

0–3. hónap: passzív eszközfelderítés, kommunikációs mátrix, kockázatértékelés, gyors győzelmek (alapértelmezett jelszavak, felesleges szolgáltatások, dokumentálatlan távoli hozzáférések lezárása).

3–9. hónap: ipari DMZ, IT/OT szétválasztás, távoli hozzáférés csatornásítása, folyamatos monitorozás bevezetése.

9–18. hónap: cellaszintű szegmentálás, eszközmegerősítés, mentési és visszaállítási program, OT-specifikus incidenskezelési terv és gyakorlás.

Folyamatosan: sérülékenységkezelés kompenzáló kontrollokkal, szállítói biztonság, mérés és felülvizsgálat.

Ez a sorrend nem véletlen: minden lépés az előzőre épül, és mindegyik önmagában is mérhető kockázatcsökkenést hoz. Ha a szegmentálással kezdesz eszközleltár nélkül, vakon fogsz tűzfalszabályt írni, és az első hibás szabály után az üzem nem fog többet engedni közel a hálózathoz.

Ha szeretnéd felmérni, hol tart az OT-környezeted, az OT kockázatértékelésünk pontosan ezzel a logikával halad, a hálózati szeparációs szolgáltatásunk pedig a zónamodell megvalósítását fedi le.