Miért nem működik a hagyományos antivírus és EDR az üzemben, és milyen elvekre épül az OT-specifikus végpontvédelem, a txOne Networks eszközeinek példáján.
Amikor egy szervezet először próbálja kiterjeszteni az IT-biztonsági eszközeit az üzemre, jellemzően ugyanabba a falba ütközik: a végpontvédelmi ügynök vagy nem telepíthető, vagy telepíthető ugyan, de az üzemeltetés nem engedi. Ez nem ellenállás, hanem jogos óvatosság.
Ez a cikk arról szól, mi az a néhány alapvető különbség, ami miatt az OT-környezet külön eszközosztályt igényel, és hogyan néz ki ez a gyakorlatban.
Az operációs rendszerek régiek. Az üzemi HMI-k és mérnöki munkaállomások jelentős része Windows 7-en, sőt XP-n fut. Nem azért, mert senki nem gondolt rá, hanem mert a rajta futó vezérlőszoftver csak arra van minősítve, és a berendezés gyártója újabbat nem támogat. A modern EDR-ügynökök ezeken vagy nem futnak, vagy nem támogatottak.
Az erőforrás szűkös. Egy ipari panel PC-n gyakran 2 GB memória van. Egy folyamatosan szkennelő ügynök elviszi azt a tartalékot, amire a vezérlőalkalmazásnak szüksége lenne, és a késleltetés itt nem kényelmi kérdés.
Nincs internetkapcsolat. A szegmentált OT-hálózatnak elvileg nincs kijárata. A napi szignatúra-frissítésre épülő modell így nem működik.
A hamis pozitív leállást okoz. Ha egy IT-környezetben az EDR tévedésből karanténba tesz egy fájlt, valaki bosszankodik. Ha ugyanez egy vezérlőalkalmazás komponensével történik, leáll a gyártás.
A gyártói jóváhagyás hiányzik. Sok berendezésnél a szállító kifejezetten megtiltja idegen szoftver telepítését, különben megszűnik a garancia vagy a minősítés.
Az erre a célra tervezett eszközök más logikát követnek.
Az IT-védelem alapkérdése: ez a fájl rosszindulatú-e? Ehhez folyamatosan frissülő tudásbázis kell.
Az OT-védelemé: ez a fájl szerepel-e azon a listán, aminek futnia szabad? Egy gyártósori HMI szoftverkészlete hónapokig, sokszor évekig változatlan. Ha rögzítjük az engedélyezett alkalmazások listáját, minden más futtatása alapból tiltott, függetlenül attól, ismert-e a kártevő. Ez a megközelítés a nulladik napi támadások ellen is véd, és nem igényel napi frissítést.
Ezt hívják application lockdown-nak vagy trust list alapú védelemnek. A txOne Stellar termékcsaládja például erre az elvre épül, és külön kezeli a modern és az örökölt (legacy) rendszereket.
Van, ahová semmit nem lehet telepíteni. Ezekre a hordozható vizsgálat a válasz: egy USB-eszköz, amit a mérnök csatlakoztat, lefuttatja az ellenőrzést, majd viszi a következő géphez. Nincs telepítés, nincs futó folyamat, nincs erőforrás-igény.
Ez egyben megoldja a beszállítói eszközök problémáját is: a karbantartásra érkező technikus laptopját vagy USB-kulcsát a belépés előtt átvizsgálják. Az USB-adathordozó továbbra is az egyik leggyakoribb fertőzési út az elszigetelt hálózatokon, a Stuxnet óta ez nem változott. A txOne Portable Inspector eszköze pontosan ezt a használati esetet fedi le.
Ha a sérülékeny eszközt nem lehet frissíteni, a védelmet elé kell tenni. A hálózatba sorosan beépített ipari IPS felismeri az adott sérülékenységet célzó forgalmat, és blokkolja, miközben maga az eszköz érintetlen marad.
Ez a virtuális patch: nem javítja a hibát, de megakadályozza a kihasználását. Ipari környezetben gyakran ez az egyetlen reális válasz egy olyan CVE-re, amelyhez évekig nem lesz gyártói javítás. A txOne EdgeIPS és EdgeFire eszközei ezt a réteget képviselik, ipari protokollok (Modbus, S7comm, EtherNet/IP, DNP3) mély elemzésével.
Egy általános tűzfal a Modbus-forgalmat egyetlen TCP-portként látja. Egy OT-tudatos eszköz látja a függvénykódot is: meg tudja különböztetni az olvasási műveletet az írástól, a normál működést a programletöltéstől.
Ez teszi lehetővé az olyan szabályokat, mint „ebből a szegmensből a PLC-k csak olvashatók, írni csak a mérnöki munkaállomásról szabad, változáskezelési ablakban". Ez a fajta granularitás az, amit egy IT-tűzfal nem tud megadni.
A végpontvédelem önmagában nem program. A hasznos sorrend:
A végpontvédelem tehát a negyedik lépés, nem az első. Aki a leltár és a szegmentálás előtt kezd ügynököket telepíteni, jellemzően sok munkával kevés kockázatot csökkent.
Kezdd figyelő módban. Az engedélyezőlistát nem lehet elméletben összeállítani. Először tanuló üzemmódban fut a rendszer, összegyűjti, mi fut ténylegesen a gépen, és csak az ellenőrzés után váltasz kikényszerítő módra.
Egyeztess a berendezés-szállítóval. Sok gyártó ma már támogatja vagy kifejezetten ajánlja az OT-specifikus védelmi eszközöket. A garanciális kérdést előre tisztázd.
Tesztelj tartalék eszközön. Ha van azonos konfigurációjú tartalék HMI, ott validáld a telepítést, mielőtt éles gépre kerül.
Számolj a változáskezeléssel. Amikor a berendezés-szállító frissíti a vezérlőszoftvert, az engedélyezőlistát is frissíteni kell. Ez a folyamat része legyen, ne utólagos meglepetés.
Használd ki a megfelelőségi átfedést. A NIS2 ötödik intézkedési területe (sérülékenységkezelés) és kilencedik területe (eszközleltár, hozzáférés-kezelés) is teljesíthető ezekkel az eszközökkel, a bevezetés dokumentációja így kettős célt szolgál.
Az OT-végpontvédelem nem az IT-megoldás lebutított változata, hanem más tervezési elvekre épül: engedélyezőlista a feketelista helyett, offline működés a felhőfüggőség helyett, virtuális patch a frissítés helyett, és protokollismeret a portszűrés helyett.
Az ARLITECH a txOne Networks partnereként ezeket az eszközöket ipari környezetben vezeti be: de a bevezetés mindig a leltárral és a szegmentálással kezdődik, mert az eszköz csak akkor ér valamit, ha tudjuk, mit védünk és mitől.
Ha aktuális a téma, az OT eszközmegerősítés szolgáltatásunk ezt a területet fedi le, a teljes kínálat pedig az OT szolgáltatások oldalon található.
OT Eszközmegerősítés (OT-specifikus szolgáltatás. PLC-k, HMI-k, RTU-k és gateway-k célzott megerősítése)…
OT kiberbiztonsági szolgáltatások: kockázatértékelés, szabályozási megfelelés, eszközmegerősítés, hálózati…
Miért nem működik az IT-biztonsági eszköztár az üzemben, és hogyan építs OT biztonsági programot az IEC…
Szakértőink szívesen átbeszélik, mit jelent mindez az Ön szervezetének környezetében.