Oszt majd felpörgetik jól az atomcentrifugát! – Ipari hálózatok biztonsága

nozomi-dashboard.png

Amúgy is akartam már régebb óta írni egy SCADA/ICS biztonsággal foglalkozó postot, talán már 2017-ben, amikor megtaláltam a zseniális ICSCYBERSEC blogot – és amikor még egyébként se volt blogom – de aztán nem írtam, csak most, hogy a kiberboxoló Csinos „Vlagyimir Clico” Tamás tollából született egy ITBUSINESS cikk a témában.

Nagyra becsült szaktársam cikkének jelentős részével egyetértek, főleg azzal, hogy az ICS/SCADA környezetek külső szemmel igen csak elhanyagoltnak tűnnek:

  • Nincs patchelés, a sérülékeny alkalmazásokat és az operációs rendszereket nem javítják
  • Nincs vírus- és malware védelem az eszközökön
  • Az eszközök távmenedzsmentje és jelszókezelése kaotikus
  • Az üzemeltetők igyekeznek egyáltalán nem hozzányúlni ezekhez az eszközökhöz

Mivel az utóbbi időben volt szerencsém jó néhány olyan rendszert auditálni, amelynek ipari eszközök is a részei voltak, egy kicsit szeretném megvédeni az üzemeltetőket, és megvilágítani, hogy miért is vannak ilyen állapotban ezek a rendszerek, kiegészítve ezzel a fent említett cikk tartalmát.

Sérülékenységek javítása, időablak probléma

Nagyon fontos azzal tisztában lenni, hogy az ipari eszközök 365/24-ben működnek, ezért ezeknek az eszközöknek a legtöbb esetben sajnos egyáltalán nem létezik karbantartási időablaka.

Azaz mivel a 365 nap minden egyes percében működnie kell az eszközöknek, a szerencsétlen üzemeltetőknek lehetősége sincsen javításokat telepíteni a hostokra, legyenek azok bármilyen elavultak és sérülékenyek.

A PLC meg SCADA cuccoknak az állási idejét (amikor nem termel) aranyban mérik. Amikor áll, kiesik a termelés – határidők csúsznak, amikre horribilis kötbérek vonatkoznak. El lehet tehát képzelni azt a pillanatot, amikor az üzemeltető az egyébként is kevés, és emiatt 120%-osan kihasznált eszközzel rendelkező cégnél arra kéri a vezetőket, hogy ugyan állítsák már le a szalagot, robotot, atomcentrifugát – mert szeretne javításokat telepíteni, és hogy 1-2 óra kiesne, plusz a leállítási idő, plusz az újra indítási idő, stb.

Nem kérdés, hogy páros lábbal tapossák meg az....önérzetét.

Néhol vannak tervezett leállási idők, pl. a pirosbetűs ünnepek (már ahol, mert nagyon sok helyen TÉNYLEG 365/24 üzem van), vagy esetleg évente egy alkalommal (pl. tisztaszoba fertőtlenítés, stb.), de hogy ciklusban lehessen javításokat telepíteni, az ebben a világban nem megoldható.

Sérülékenységek javítása, „ha működik, ne piszkáld” probléma

A témakör következő problémája, hogy operációs rendszer szinten egy XP vagy Win2k esetében ugye mi a fenét lehetne javítani, jellemzően nincs már rá frissítés. De ha lenne is, vagy éppenséggel van, mert „új” rendszer és véletlenül Win7-en vagy Win10-en fut, egy OS frissítés miatt (nagyon sok esetben) nem fog működni az alkalmazás, mert az adott alkalmazást az adott OS/dll/lib/stb állapotában adták át, azzal a környezettel működik, de ha lecserélsz 2 DLL-t már nem működik. Ja, és akkor még a support is ugrott. Ezt a kockázatot SENKI nem vállalja fel szívesen.

Az alkalmazás esetében pedig a frissítést a legtöbb esetben a rendszert szállító cég mérnökei végzik (ha egyáltalán végzik), horribilis áron. Tényleg, nem tudod elképzelni, milyen árak vannak! Nem úgy van ebben a világban, hogy kijött a 3.2.2.11.23 verzió, hopp, frissítsük le!

Ugyanúgy az időablak problémába is ütközünk (mikor?), de tényleg inkább abba, hogy a szállító szakmérnöke egészen horribilis árakon tevékenykedik (eskü, olyan óradíjjal dolgoznak, hogy abból 2-3 sztárügyvédet is meg lehetne fizetni), szóval ez nem a „5ezer, védősisak nélkül” kategória.

Sok esetben a frissítés tulajdonképpen egy teljesen új verziót jelent, amit többnyire a teljesen új szoftver áráért lehet megvenni (önmagában is sokmilliós tétel), plusz a supportőr költsége, plusz...csillagállás, plusz tíz fekete kakas taraja, stb. És itt nem next-next-finish frissítésekről beszélünk. Egy működő rendszerhez hozzányúlni óriási kockázat ebben a szegmensben, óriási költséggel.

Nincs vírusvédelem az eszközökön („Lassú fos partot tosz”-probléma)

Na ja, nincs is szebb annál, amikor a robot megáll, és nem szereli a visszapillantót (vagy nem palackozza a sört!), mert a Panda/NOD/bármi éppen frissít, szkennel, vagy valami mást csinál, ami miatt lassulás lép fel, processz fagy be vagy ilyesmi. Ez minden ipari mérnök álma olyan eszközökön, amelyek már eleve sem a világsebesség bajnokai.

Vírusvédelem SCADA/HMI/PLC eszközökön elképzelhetetlen, még akkor is, ha Tamás helyesen rámutatott, hogy HMI vagy SCADA és akár PLC szinten is PC-szerűségekről van szó. A funkcionalitás miatt azonban semmilyen intrusive alkalmazás nem működhet ezeken az eszközökön. A gyártók egyébként jellemzően ezt ki is kötik, bár szerintem senkinek nem jut eszébe ezekre a cuccokra vírusvédelmet telepíteni.

Távmenedzsment és jelszókezelés („Szarnak-bajnak nincs gazdája”-probléma)

A fentiekből talán már látszik, hogy a böcsületes üzemeltetők messzire elkerülik az ipari eszközöket, mint egy leprás-triót. Igyekeznek távol tartani magukat és a szépen gondozott eszközeiket ettől a fertőtől, persze látni fogjuk, hogy kevés sikerrel.

A cikk is hivatkozott arra a bölcsességre, hogy az ICS-hálózat már nem az a zárt világ, mint régen, a legtöbb ipari protokoll már TCP-be van burkolva, és sajnos ezek az eszközök sem mennek input adatok nélkül, és nincs munkavégzés output adatok nélkül.

A legtöbb rendszer valamilyen módon integrált, a termelésről, eseményekről, állapotokról, eredményekről folyamatosan adatot közöl, amit valakinek/valaminek meg kell kapni, fel kell dolgozni, meg kell jeleníteni, stb. Sok esetben a cég ERP rendszere össze van kapcsolva az ipari eszközökkel, minden lepalackozott sör, minden felszerelt visszapillantó, minden elhasznált anyag, áram, életenergia, stb. nyomon követhető és nyomon is követik.

Az ipari rendszernek tehát valahova adatot kell írnia, fájl share-re, adatbázisba, bárhova: és ez a bárhova sajnos a normál hálózatban működő szervereket, adatbázisokat, alkalmazásokat jelenti. A legtöbb esetben az ipari eszközök ugyanis pontosan ugyanabban a hálózatban működnek, mint a szervezet többi IT eszköze, szervere, munkaállomása, nyomtatója. Nem azért, mert felelőtlenek, hanem mert így alakult ki, és átalakítani, megbontani a fenti okok miatt borzalmasan macerás.

Lehet mondani, hogy kérem, miért nem a security-by-design alapon lett tervezve a hálózat, miért nincsen legalább VLAN szeparáció az ipari eszközök számára – de sajnos azt kell mondanom, hogy annak idején erre nem gondoltak, és amikor már gondoltak, nagyon költséges lett volna a rendszer átalakítása, és inkább nem nyúlnak hozzá.

A távmenedzsment kérdése még durvább, ugyanis ezeket a rendszereket - ha a gyártó/supportőr felügyeli, akkor a legtöbb esetben teljes hozzáférése van a hosthoz – perzisztens TeamViewer, VNC, stb alkalmazáson – és lehetőleg az Interneten keresztül, mert 0-24-ben be kell tudniuk lépni, be kell avatkozniuk, stb.

Nem lehet engedélyeztetésre, jóváhagyásra várni, ha Herr Grüber látja, hogy valami probléma van (vagy a rendszer jelez neki), akkor azonnal be kell lépnie, és hangolnia kell a cuccon, különben mosogatólé kerül a sörösüvegbe, vagy index szerelődik a BMW-be. 

A hosthoz történő ilyen hozzáférés nyilván azt fogja eredményezni, hogy Herr Grüber a hálózathoz és a többi eszközhöz is hozzáfér, hiszen, ha TeamViewer-ezett a SCADA hostra, onnan a többi eszközt lokálisan is eléri.

A jelszavakat meg hagyjuk, szerencsére az eszközök nem részei az AD-nek, igazából nincs is felhasználó rajtuk, a lokál admin megy, az futtat mindent. Jelszócsere no way, az alkalmazásokhoz, adatbázisokhoz szükséges jelszavak bele vannak kódolva az alkalmazásokba, bele vannak írva a registry-be, vagy szöveges állományokban találhatók. Eszébe se jut senkinek a jelszócsere, mert a büdös életbe nem fog működni többé a rendszer.

Vakfolt („A sötétben minden tehén fekete” - probléma)

A fentiek mellett én azt emelném ki fő problémaként, hogy a szervezeteknek a legtöbb esetben lövésük sincs arról, hogy milyen kapcsolat van az ipari eszközök és a „normál” hálózat között.

Egyszerűen nem tudják, hogy mit, hova, hogyan, merre, miért kommunikálnak az ICS cuccok, mi szükséges kommunikáció és mi nem az, mi üzemszerű és mi nem az.

Átláthatatlan és emiatt kezelhetetlen a történet, és ez a fentieknél is nagyobb kockázatokat rejthet.

Ha valami, vagy valaki az adott rendszernek olyan parancsot küld valahonnan, amelyben módosít egy változót, ezzel megtriplázza az atomcentrifuga fordulatszámát – abból sokkal nagyobb baj lehet, mint önmagában abból, hogy a host egy XP ami nincs frissítve.

(Sok esetben a paraméterek változásaira csak akkor figyelnek a rendszerek, ha hirtelen ugrásszerűen megnőnek, pl. egy ugrással 5-ről 5000-re változik a paraméter, de a többszöri, fokozatos emelés alatta maradhat az egyszeri tresholdnak).

Szóval szerintem a környezet kommunikációjának átláthatatlansága (ki, mikor, mit, hova, hogyan küldhet, honnan fogadhat, stb.) egyrészt üzemeltetői probléma, de nagyon markánsan vonzza magával a biztonsági problémákat is.

Mit lehet tenni?

A fentiekből látszik, hogy sok esetben valóban fertő az egész. Viszont legalább megjavítani sem lehet teljesen. Sőt.

lepra.jpeg

Nem véletlen, hogy annak idején a leprásokat elkerítették valami szigetre, szerintem ez jelenti az egyetlen használható védelmi megoldást: az ipari eszközöknek saját szegmensben kellene működnie, amelyet egy jól konfigurált, és csak a legminimálisabb és legszükségesebb átjárást engedélyező tűzfal választ el a „normál” hálózattól.

De ahogy írtam, szerintem egy élő rendszernek az ilyen átalakítása óriási erőforrást igényel, ami mellé jelentős költség is járul, emiatt nagyon kevesen vágnak bele egy ilyen mértékű átalakításba (és akkor bónusz, láttam már olyan eszközt, ahol a fix IP-re volt a licensz konfigurálva, tehát az IP-váltás miatt licenszcserét kellett volna megvalósítani egy olyan gyártónál, aki már nem licenszeli az adott eszközt, supportálja, de nem ad ki másik licenszt).

Megoldás lehet, hogy ha az ipari cuccokat nem lehet átcímezni és áthelyezni másik hálózatba, akkor maradjanak, ahol vannak, a normál hálózatot kell leválasztani és áttenni egy külön VLAN-ba.

Iszonyú munka a címtárat, szervereket stb. áttenni másik hálózatba, de mégis megoldhatóbb, mint olyan cuccokhoz hozzápiszkálni, ahol már azért is support-vesztés van, ha nem köszönnek hangosan a berendezésnek reggelente.

A sérülékeny ipari eszközök nem csak önmagukra, de minden más eszközre is veszélyt jelentenek, és sajnos a sérülékenységek javítására nincsen jó megoldás. El kell fogadni, hogy ez van, de a kockázatot a szeparációval jelentősen csillapítani lehet.

A vírusvédelemre host-szinten nincs jó megoldás, de ha a hostokról nincsen Internet kijárat (azaz a TeamViewer meg az egyéb távmenedzsment toolok is csak a lokális hálózatból, pl. VPN után működnek), mert abból a szegmensből a tűzfal nem engedélyez Internet forgalmat, már jelentős javulás érhető el. És persze akkor ott van még az a lehetőség, hogy a hálózati forgalmat vizsgáljuk és keressünk benne kártékony kódot vagy kommunikációt.

A távoli hozzáféréseket is szabályozni kell, be kell vezetni, hogy csak VPN kapcsolat után, csak a szükséges hostot lehessen a távmenedzsmenttel elérni. Nyilván akkor is ott van annak a problémája, hogy a hostról elérhető a többi ipari eszköz, de a szegmentálás miatt legalább már nem a teljes hálózat lesz elérhető.

A legtöbb esetben egyébként a cég azt sem tudja, hogy Herr Grüber mit csinált pontosan az adott eszközön, ez is óriási probléma lehet, hiszen a cégnek semmiféle bizonyíték nem áll a rendelkezésére, hogy a gyártó felé igazolja, nem a cég munkatársa, hanem Herr Grüber a supportőr/gyártó saját szakembere barmolta el a rendszert.

Erre is van műszaki kontroll, ha a VPN-el csak egy „jumping host” érhető el, és Herr Grüber csak onnan indíthatja a távmenedzsmentet az által támogatott eszközökre, a ”jumping hoston” videószerűen rögzíteni lehet Herr Grüber minden mozdulatát (privileged session recording terület),  amely alapján a cég pontosan tudni fogja, hogy mi történt az eszközön, és ezt bizonyítani is tudja a gyártó/supportőr felé.

Az is jó ötlet lehet, ha az ipari hálózatba bemenő, illetve onnan kijövő állományok kerülnek mélyebb vizsgálatra, az adatbeléptetés és adatkiléptetés problémájára szintén vannak műszaki megoldások. Nyilván szabályozni kell, hogyan vihető be adat, fájl akár USB adathordozón ilyen környezetbe, erre akár az adminisztratív kontroll is működhet.

Szóval mindig lehet tenni valamit, mindig lehet csillapító intézkedéseket megvalósítani, csak szándék és idő legyen rá – no meg büdzsé.  És lehetőleg legalább kettő egy időben álljon rendelkezésre.