Néhány héttel ezelőtt én is írtam arról, hogy iráni illetékesek szerint kibertámadás érte az iráni olajipar egyik legfontosabb létesítményét. Már abban a posztban is írtam arról, hogy indokolt egyre óvatosabban kezelni azokat a kijelentéseket, amik egy-egy ipari baleset vagy safety incidens után nagyon gyorsan kibertámadás neveznek meg vagy sejtetnek, mint kiváltó okot anélkül, hogy erre vonakozóan konkrét bizonyítékokat ismertetnének. Ezt erősítette meg Robert M. Lee október 20-án publikált posztja is (elérhető a Dragos weboldalán és Robert saját blogján is), amiben nem először ír arról, hogy bár az ipari szereplőket és ICS rendszereket támadó csoportok egyre agresszívebbek és egyre gyakrabban céljuk bizonyíthatóan a fizikai károkozás (elég csak a Trition/TriSIS malware-támadásra vagy a Industroyer/CrashOverride malware-ről nemrég publikált újabb elemzés következtetéseire gondolni), helytelennek tartja, hogy egy incidens után az első reakció az, hogy az illetékesek kibertámadásra hivatkoznak kiváltó okként. A konkrét esetről ma még csak annyit lehet tudni, hogy az olajfinomító egyik csatornájában, ahol a finomítás során keletkező hulladékanyagokat vezették el, tűz ütött ki.
Robert fontosnak tartja kiemelni, hogy a legtöbb ICS rendszereket üzemeltető szervezetnek (ide értve feltehetően az abadani olajfinomítót is) jelenleg nem állnak rendelkezésére azok a képességek és az a képzett és tapasztalt ICS biztonsági csapat, akikkel egy hasonló kategóriájú incidens esetén a fizikai következmények felszámolása során már egy alapos <<root-cause analysis>>-t tudjanak végrehajtani, amelynek során képesek alaposan átvizsgálni az érintett ICS rendszereket bármilyen, illegális vagy helytelen (hiszen nem szabad elfelejteni, a legtöbb ICS biztonsági incidens mind a mai napig nem ellenséges szándékú támadók, hanem jó szándékú és valamilyen legitim hozzáféréssel rendelkező ember tevékenységének a következménye) módosítás nyomait.
Ahhoz, hogy az ICS rendszerek és eszközök biztonsági szintjén javítani lehessen, korántsem elegendő a döntéshozók és a társadalom figyelmét ráirányítani a valóban létező problémára (arról nem is beszélve, hogy mennyire kontraproduktívnak tartom, hogy minden ICS rendszerrel kapcsolatos incidenst azonnal és gondolkodás nélkül kibertámadásra visszavezetni nagyjából annyira szolgálja az ipari szektorban működő szervezetek és a kritikus infrastruktúrák érdekeit, mint amennyire a mesebeli fiúnak érdemes volt rendszeresen farkast kiálltani), de mindenképp olyan intézkedéseket kell javasolni, amikkel jelentősen lehet javítani az ICS rendszerek biztonsági helyzetét. Néhány ilyen intézkedés lehet:
- Az ipari szektorban működő szervezetek kockázatainak felmérése és értékelése, a magasnak ítélt kockázatokra vonatkozóan kockázatcsökkentő intézkedések alkalmazása. Itt fontosnak tartom megemlíteni, hogy ma még az ipari szektorban sem sok helyen sikerült elmozdulni a fizikai eszközök és az adatok számszerűsített értékén alapuló kockázatelemzési megközelítéstől, pedig figyelembe véve, hogy az ICS rendszereket és berendezéseket használó szervezetek számára szinte kivétel nélkül az egyik legfontosabb érték az ICS rendszerekkel vezérelt folyamatok biztonságának (safety), megbízhatóságának és rendelkezésre állásának biztosítása, ezért úgy gondolom, hogy legalább is megfontolásra érdemes lehet egy másfajta, a fizikai folyamatokkal kapcsolatos elvárások irányából közelítő kockázatelemzési módszertan alkalmazása. Ezzel nyilván nem azt állítom, hogy az adatok nem fontosak, de mérlegelni kell, hogy egyes adatkörök fontossága hogyan viszonyul a felügyelt folyamatok különböző szempontok alapján értékelt fontosságához.
- ICS eszközleltár: A vállalati IT biztonság terén már igen régóta számos szabvány írja elő a napra kész eszközleltár vezetését. ICS környezetekben egy ilyen nyilvántartás kialakítása talán nehezebb lehet (hiszen fontos eszközök lehetnek távoli, akár személyzettel nem is rendelkező telephelyeken), azonban az ICS rendszerek már többször is említett statikussága ebben az esetben kifejezetten előnyt jelent.
- ICS rendszerek szeparálása publikus/külső hálózatoktól: Lassan már unalomig ismételt alapszabály, hogy ICS rendszerekhez ne engedjünk hozzáférést publikus hálózatokról (pl. Internet) vagy olyan külső hálózati zónákból, ami nem áll teljes mértékben az ellenőrzésünk alatt. Amennyiben nem lehet teljes mértékben elkülöníteni a külső hálózatokat az ICS rendszerektől (pl. mert külső szakértőknek is hozzáférést kell biztosítani a rendszer bizonyos részeihez, akkor használjuk a Purdue-modellt vagy annak valamelyik modernizált változatát.
- A rendszerek és kommunikációjuk átláthatóságának megteremtése: biztosítani kell azt, hogy az (ICS) kiberbiztonsággal foglalkozó szakemberek minél teljesebb képpel rendelkezzenek arról, mi is történik a hálózatokban és rendszerekben. Ennek leginkább hatékony módszere (a korábban már említett pontos és naprakész eszközleltáron túl) a folyamatos, 7/24-es hálózatbiztonsági monitoring tevékenység magas szintre fejlesztése.
Miközben ezt a posztot írtam, jöttek a hírek arról, hogy ransomware-támadás érte a Pemex nevű mexikói állami olajtársaságot. Bár a Pemex nem szolgált részletekkel (mindössze annyit közöltek, hogy az incidens nem érintette a termelésirányításért felelős rendszereiket), de egyes biztonsági kutatók nem megerősített hírei szerint az incidensért a DoppelPaymer ransomware a felelős. Egyes elemzések szerint a DoppelPaymer mögött ugyanaz a támadói csoport állhat, akik a Dridex és Locky ransomware-támadásokért is felelősek lehetnek.
Ahogy közeledünk az év végéhez, lassan megállapíthatjuk, hogy 2019 az ipari szervezetek (és az állami és önkormányzati szervek) elleni ransomware-támadások éve és nem sok jele van annak, hogy a helyzet 2020-ban javulna - valószínűleg inkább csak romlani fog. Azt hiszem éppen ideje mindenkinek feltenni magának a kérdést: fel vagyunk készülve hasonló incidensekre, mint amivel a Norsk Hydro-nak vagy a Johannesburg-i áramszolgáltatónak kellett megküzdenie?
