Bevezető
Hogyan kezdjünk hozzá egy vállalat IT- és OT-rendszereinek védelméhez? Gyakorlati útmutató informatikusoknak, rendszergazdáknak és automatizálási mérnököknek.
Egy vállalat informatikai vezetője új feladatot ad a rendszergazdának: „A gyártóberendezések hálózatát is be kell vonnunk a kiberbiztonsági rendszerünkbe.”
Elsőre nem tűnik különösebben bonyolultnak. Vannak IP-címek, switchek, hálózati eszközök és számítógépek. Megvizsgáljuk a tűzfalszabályokat, ellenőrizzük a frissítéseket, telepítünk néhány biztonsági megoldást, és elkészítjük a dokumentációt.
Csakhogy a hálózat másik végén ezúttal nem feltétlenül egy szerver vagy munkaállomás található, hanem egy PLC, amely szállítószalagot vezérel. Esetleg robot, frekvenciaváltó, kazán, szivattyú vagy egy komplett gyártósor.
Üdvözlünk az OT – Operational Technology – világában!
Mi az OT, és miért más, mint az IT?
Az OT olyan hardver- és szoftverrendszerek összessége, amelyek fizikai folyamatokat figyelnek, irányítanak vagy vezérelnek.
Ide tartoznak például a PLC-k, HMI kezelőpanelek, SCADA rendszerek, robotvezérlők, hajtások, ipari számítógépek és az ezeket összekötő kommunikációs hálózatok.
Az OT azonban nem kizárólag a gyártóipar sajátossága. Ugyanilyen rendszerekkel találkozhatunk épületautomatizálásban, vízműveknél, energetikai létesítményekben és közlekedési infrastruktúrában is.
A legfontosabb különbség az IT és OT között a védelem következményeiben keresendő.
Az IT-biztonság klasszikus céljai a bizalmasság, az adatok sértetlensége és a rendelkezésre állás. OT-ben ezek ugyanúgy fontosak, de gyakran kiemelt szerepet kap a fizikai biztonság, a folyamatok integritása és a folyamatos működés.
Egy irodai számítógép váratlan újraindítása kellemetlenség. Egy vezérlőrendszer újraindítása viszont teljes termelésleállást okozhat, vagy veszélyes technológiai állapotot idézhet elő.
Ezért az IT-ban megszokott automatikus frissítés, újraindítás vagy aktív hálózati vizsgálat OT-környezetben előzetes hatásvizsgálatot igényelhet.
A Purdue-modell: tegyünk rendet a hálózatban!
Az OT-security tervezésének egyik legismertebb kiindulópontja a Purdue-modell.
Ez egy logikai referencia-architektúra, amely különböző szintekre osztja a vállalati informatikai és ipari vezérlési rendszereket.
A felső szinteken találjuk a vállalati IT-t: az ERP-t, az irodai hálózatot és az üzleti alkalmazásokat. Alattuk az üzemirányítás, a SCADA és a mérnöki munkaállomások következnek. Legalul a PLC-k, robotvezérlők és a fizikai folyamatok helyezkednek el.
Az IT és OT közé gyakran egy külön biztonsági terület, az OT DMZ kerül. Itt történhet a két világ közötti szabályozott adatcsere és a távoli hozzáférések kezelése.
Zones & Conduits: ki kommunikálhat kivel?
Az IEC 62443 ipari kiberbiztonsági szabványcsalád egyik alapvető koncepciója a Zones & Conduits megközelítés.
A Zone olyan biztonsági tartomány, amelynek eszközei hasonló védelmi követelményekkel rendelkeznek. Egy különálló gyártócella, az engineering hálózat vagy az OT DMZ egyaránt alkothat zónát.
A Conduit pedig a zónák közötti szabályozott kommunikációs kapcsolat.
Képzeljünk el egy öt gépcellából álló gyártósort. Minden cellában található PLC, HMI és több ipari eszköz. Az egyes cellák külön VLAN-ba kerülnek, a közöttük zajló kommunikációt pedig megfelelő hálózati szabályok korlátozzák.
Fontos megérteni, hogy a VLAN önmagában nem tűzfal. Ha a hálózati infrastruktúra korlátozás nélkül irányítja a forgalmat a VLAN-ok között, a szegmentálás biztonsági előnye jelentősen csökken.
A megoldás az engedélyezett kommunikáció pontos meghatározása.
Például:
|
Forrás |
Cél |
Kommunikáció |
| HMI | PLC | Engedélyezett kezelői kapcsolat |
| PLC | Robot | Engedélyezett vezérlés |
| SCADA | PLC | Szükséges adatgyűjtés |
| Engineering PC | PLC | Korlátozott programozói hozzáférés |
| Irodai PC | PLC | Alapértelmezetten tiltott |
| Internet | PLC | Közvetlen hozzáférés tiltott |
Ez a Communication Matrix a hálózatbiztonsági tervezés egyik legfontosabb dokumentuma.
Az alapelv egyszerű: csak azt a kommunikációt engedélyezzük, amelyre valóban szükség van.
Az engineering laptop: egy gyakran alábecsült kockázat
Egy PLC-programozó vagy karbantartó mérnök laptopján gyakran egyszerre található irodai szoftver, böngésző, VPN-kliens, PLC-programozó környezet, robotdiagnosztikai szoftver és különféle gyártói alkalmazás.
Ugyanez a számítógép akár több különböző gyár hálózatához is csatlakozhat.
Ezért az engineering munkaállomás potenciális belépési pont az OT-rendszerbe.
A biztonságosabb megoldás a kontrollált mérnöki hozzáférés: elkülönített engineering hálózat, jogosultságkezelés, naplózás és csak a szükséges célberendezések elérése.
Ugyanez vonatkozik a távoli gyártói szervizre is. Egy VPN-kapcsolat önmagában nem jelenti azt, hogy a hozzáférés biztonságos.
A megfelelő kialakítás jellemzően többtényezős hitelesítést (MFA), köztes hozzáférési szervert (jump server), célrendszerre korlátozott jogosultságot és naplózást alkalmaz.
Mi történik a régi berendezésekkel?
Az OT-rendszerek életciklusa gyakran jóval hosszabb az irodai informatikai eszközökénél.
Egy 15–20 éves PLC működhet kifogástalanul, miközben a firmware-e már nem támogatott, vagy az alkalmazott kommunikációs protokoll nem rendelkezik korszerű hitelesítéssel és titkosítással.
Az ilyen berendezések cseréje vagy frissítése nem mindig lehetséges.
Ilyenkor kerülnek előtérbe a kompenzáló védelmi intézkedések: hálózati szegmentálás, korlátozott hozzáférés, passzív monitorozás és megfelelő incidenskezelési eljárások.
A cél nem feltétlenül az, hogy minden eszközt a legújabb verzióra frissítsünk, hanem hogy a rendszer kockázatait elfogadható szintre csökkentsük.
Hol kezdjünk hozzá a gyakorlatban?
Egy OT-security projektet nem érdemes rögtön tűzfalvásárlással vagy sérülékenységvizsgálattal indítani.
Az első lépések sokkal inkább a meglévő rendszer megismeréséről szólnak.
- Eszközleltár
Milyen PLC-k, HMI-k, ipari PC-k, switchek és szerverek működnek a rendszerben? - Hálózati topológia
Hogyan kapcsolódnak egymáshoz az eszközök, és hol találkozik az IT és az OT? - Biztonsági zónák
Mely rendszerek tartoznak közös biztonsági tartományba? - Kommunikációs mátrix
Ki, kivel, milyen protokollon és milyen célból kommunikál? - Szegmentálás
Hol szükséges VLAN, ACL, tűzfal vagy más hálózati kontroll? - Hozzáférés-kezelés
Ki módosíthat programot, és hogyan férhetnek hozzá a külső szervizpartnerek? - Mentés és helyreállítás
Megvannak-e a PLC-, HMI-, robot- és hálózati konfigurációk mentései, és tesztelték-e a visszaállítást? - Monitoring és változáskezelés
Hogyan észleljük a rendellenességeket, és hogyan követjük a módosításokat?
Ezeket a feladatokat az IT- és automatizálási szakembereknek közösen kell elvégezniük. Egy PLC-hálózat aktív vizsgálata, tűzfalszabályainak módosítása vagy berendezésének leválasztása ugyanis közvetlen hatással lehet a termelésre.
Milyen szabványok és előírások segítenek?
Az OT-biztonság kialakításához három fontos kiindulópontot érdemes megismerni.
Az IEC 62443 az ipari automatizálási és vezérlőrendszerek biztonságával foglalkozó szabványcsalád. Többek között a kockázatértékelés, a zónák, a biztonsági szintek és a rendszerkövetelmények meghatározásához nyújt keretet.
A NIST SP 800-82 Rev. 3 részletes, gyakorlatorientált útmutató az OT-rendszerek biztonságához.
Az Európai Unióban a NIS2 irányelv, illetve annak nemzeti végrehajtási szabályai bizonyos ágazatok és szervezetek számára kötelező kiberbiztonsági kockázatkezelési követelményeket határoznak meg. Az alkalmazhatóságot a szervezet tevékenysége, mérete és jogi besorolása alapján kell vizsgálni.
Fontos különbség: egy műszaki szabvány alkalmazása és egy jogszabály szerinti megfelelés nem ugyanaz.
Összegzés: nem a tűzfallal kezdődik
Az OT-security elsőre speciális, ismeretlen világnak tűnhet. Valójában azonban sok alapelve ismerős lesz az IT-szakemberek számára: eszköznyilvántartás, hálózati szegmentálás, jogosultságkezelés, mentés, naplózás és incidenskezelés.
A különbség az, hogy itt mindezek mögött fizikai folyamatok működnek.
A legfontosabb kérdés ezért nem pusztán az, hogy egy berendezés elérhető-e a hálózaton, hanem az, hogy ki érheti el, milyen célból, milyen jogosultsággal, és mi történik, ha a kapcsolat megszakad vagy kompromittálódik.
Az OT-biztonság nem az IT és OT teljes elszigeteléséről szól, hanem a közöttük szükséges kapcsolatok tudatos, dokumentált és ellenőrizhető kialakításáról.
És ehhez az első lépés nem egy új biztonsági eszköz beszerzése, hanem a meglévő rendszer megértése.
Szakmai hivatkozások: NIST SP 800-82 Rev. 3 · IEC 62443 szabványcsalád · EU NIS2 irányelv
Legutóbbi hozzászólások