Július 19-én, európai idő szerint hajnalban egy (vagy kettő) komolyabb hiba miatt világszerte tömegével váltak használhatatlanná Windows szerver-alapú rendszerek. Leálltak repülőterek és földön maradtak a világ nagy légitársaságainak (többek között a United, az American Airlines és más társaságok) járatai. Az első hírek a Microsoft Azure felhőszolgáltatásának leállásáról szóltak, majd nem sokkal később már a CloudStrike nevű kiberbiztonsági cég Falcon Sensor néven ismert végpontvédelmi szoftverének hibás működéséből adódó kiesésről lehetett olvasni (egy hibás frissítés - az új verzió egy olyan memóriaterületről is megpróbált olvasni, ami a Windows operációs rendszerben védettnek számít és bármilyen szoftvert, ami innen olvasni próbál, a Windows azonnal leállít) miatt a Falcon Sensort futtató hostok kék halállal álltak le és nem lehetett őket egy egyszerű újraindítással megjavítani, a csökkentett módban történő indítás után törölni kellett egy ún. Channel File-t (0409-es időbélyeggel rendelkező C-00000291*.sys fájlt) a C:\Windows\System32\drivers\CrowdStrike\ könyvtárból, majd normál módban újraindítani az érintett hostot.
Az incidens (mert ugye ez is egy igen súlyos incidens volt, még ha nem is kiberbiztonsági incidens, hiszen egy - vagy két - üzemeltetési/fejlesztési hiba okozta) ismét szépen rámutatott arra, hogy még ha közvetlenül nem is érintettek ICS/OT rendszerek, az IT-OT konvergencia néven nevezett, egyre szorosabb integráció a két technológiai terület között milyen súlyos hatásokkal tud lenni egy informatikai hiba a fizikai világ folyamatainak vezérlésére is. Erről írt tegnap délben a LinkedIn-en Kocsis Tamás.
A cikket mindenképp elolvasásra ajánlom, mert jól összeszedett írás, aminek azért megvannak a korlátai, például az, hogy a szerző saját tapasztalataiból építkezik, aki láthatóan gyártásautomatizálási és villamosenergia-termelési tapasztalatokkal rendelkezik. Ezt persze nem hibaként rovom fel Tamásnak, hiszen ez szinte mindenkire (így persze rám is) érvényes, aki az OT kiberbiztonság területén dolgozik, lévén annyira még nem régi és annyira szerteágazó, számos iparágat magába foglaló ez a szakma, hogy egy embernek még jó ideig nem lesz esélye sem, hogy sok különböző iparág folyamatrányítási rendszereivel kapcsolatos sajátosságokat a saját tapasztalatai alapján tudjon feldolgozni.
Ahogy Tamás írta a cikkben, a gyártásautomatizálásban, főleg a Just-in-Time termelési modell miatt egyre szorosabbá vált az integráció a termélést vezérlő rendszerek és egyes IT rendszerek (pl. készletgazdálkodási rendszerek) között, hogy elég csak egy vagy több IT rendszernek egy, a CloudStrike-éhoz hasonló hiba miatt leállni és ez már azonnal megzavarja a termelésirányítás működését is.
Tamás második példája a villamosenergia-erőműveket hozza példának, amiről viszont nem szól, az a villamosenergia-rendszer többi szereplőjének (átviteli- és elosztói rendszerirányítók) rendszerei, pedig itt is számos olyan rendszer lehet (pl. villamosenergia-piaci rendszerek, a kiegyenlítő-energia kereskedelméhez használt rendszerek vagy akár a - legszegényebb társadalmi rétegeket érintő, feltöltőkártyás mérőórák feltöltéséhez használható rendszerek), amik alapvetően IT megoldások és jellemzően IT hálózatokban üzemelnek, de kiesésük adott esetben nagyon súlyos, extrém esetben akár komolyabb áramkimaradásokat eredményező üzemzavarokat is okozhatnak, kevésbé rossz esetekben pedig jelentős anyagi károkat okozhatnak az érintett szervezeteknek - vagy kisebb, de még mindig súlyos károkat a fogyasztóknak.
A harmadik szektor, amit példaként fel kell hozni (ezt már én teszem), az olaj- és gáz-szektorból jön, a már többször (egyebek mellett általam is) emlegetett Colonial Pipeline ransomware-incidens példája, ahol szintén IT rendszerek (forrásaim szerint az amerikai terméktávvezeték üzemeltetéséért felelős cég kereskedelmi rendszerei) estek a támadás áldozatául, ami végül a teljes csővezeték-hálózat leállításában csúcsosodott ki.
A fenti példák (szerintem) elég jól megmutatják, hogy az IT-OT konvergencia milyen kockázatokat hordozhat magában a különböző folyamatirányító rendszerek zavartalan és biztonságos működésére nézve.
Felmerül azonban a kérdés, hogy mi várható most és mit lehet tenni, ha a mi feladatunk az folyamatvezérlő rendszerek kiberbiztonságának megteremtése és fenntartása?
Egyrészt kezdeni kell valamit az IT-OT rendszerek összekapcsolásának biztonsági kérdéseivel, ehhez még ma is kiváló alapokat biztosít a Purdue-modell (amiről szintén írtam még a blog indulása környékén), aminek a tanácsait követve ki lehet dolgozni az adott szervezet és folyamatirányító rendszereinek gyakran egyedi igényeihez illeszkedő biztonsági architektúra-modellt.
Külön érdemes beszélni (a Microsoft Azure szolgáltatásainak leállása apropóján) a felhőszolgáltatások és a folyamatirányító rendszerek kapcsolatáról, amihez szintén jó kiindulási alap lehet a Purdue-modell - és a felhőszolgáltatók rendszereinek az adott szervezet on-premise rendszereivel történő összekapcsolásának jó gyakorlatai.
Másrészt, nem lehet elmenni szó nélkül az antivírus/végpontvédelmi megoldások ICS/OT rendszereken történő használata mellett, hiszen a CrowdStrike-frissítés adott esetben akár folyamatirányító rendszerek leállását is okozhatta. Mondjuk erre épp kicsi esélyt érzek, mert (ismét visszautalva Tamás LinkedIn-es cikkére) egyrészt nagyon sok folyamatirányító rendszerben az L2 rendszerek (SCADA, DCS rendszerek, mérnöki/operátori munkaállomások) hostjain sem használnak antivírus/végpontvédelmi megoldásokat, másrészt ahol használnak, ott sem az ügyfél döntése, milyen host-szintű biztonsági megoldást választ a folyamatirányítási rendszereihez, hanem az ICS/OT gyártó megmondja, hogy milyen AV/EPP megoldást támogat és ha ettől valaki eltér, az azonnal a gyártói garancia elvesztését eredményezi, ezt pedig a folyamatirányítási mérnökök nem nagyon vállalják fel (én személy szerint még nem találkoztam ilyen mérnökkel, egyszer hallottam hasonló döntésről, amit a Delta Airlines adatközpontjainak épületgépész mérnökei hoztak meg, de annak sem biztonsági megfontolásai voltak).
Ami a konkrét esetet illeti, CrowdStrike AV/EPP megoldást én nem hogy nem láttam ICS/OT rendszereken használva, de nem is hallottam róla (igazság szerint két iparág ICS/OT rendszereiben is csak egyetlen, az IT-ban is patinásnak számító biztonsági gyártó megoldásaival találkoztam). Viszont az, hogy ipari rendszereknél jellemzően egy gyártó AV termékét támogatják az ICS/OT vendorok, még nem jelenti azt, hogy ilyen nem fordulhat elő az adott gyártóval, mert ez a gyártó is produkált már ilyen hibát (igaz közel két évtizede), de gyakorlatilag nem tudok olyan AV/EPP gyártót mondani, amelyik az elmúlt 20-25 évben legalább egyszer ne követett volna el valami hasonlót.
Az ilyen, biztonsági gyártói hibák kivédésére én jelenleg egy megoldást látok, amihez szintén nélkülözhetetlen a megfelelő (Purdue-modell alapú IT-OT hálózatok szegmentálása), ez pedig az OT rendszereken használt biztonsági megoldások frissítésének csúsztatott (legalább fél-egy napos késéssel megvalósított) frissítése - ekkor a hasonló hibákat mások már előttünk meg fogják tapasztalni, így lesz lehetőségünk arra, hogy megtegyük a szükséges preventív intézkedéseket a rendszereink megóvása érdekében. Nyilván egy késletetett frissítés hordoz magában bizonyos szintű kockázatokat (pl. egy EternalBlue sérülékenységet kihasználó, féreg-szerű terjedési képességekkel rendelkező malware támadása esetén), de ha az IT rendszereken használt AV/EPP megoldások eltérnek az OT rendszerek végpontvédelmi megoldásától, akkor az javíthatja az IT hálózatok felől az ICS/OT rendszereket célzó fenyegetések elleni védekezés esélyeit.
