A december 23-i, ukrán villamosenergia-rendszert érintő kibertámadás az elmúlt több, mint két hónapban majdnem annyira sokszor hivatkozott incidens lett, mint a Stuxnet volt 2010-ben - én is több alkalommal írtam az esetről, ahogy újabb és újabb részletek váltak publikussá. A múlt héten az amerikai belbiztonsági minisztérium (Department of Homeland Security, DHS) nyilvánosságra hozta az incidenssel kapcsolatos jelentését.
A jelentés szerint több amerikai ügynökség (egyes források szerint a DHS-en kívül az amerikai energiaügyi minisztérium, a Department of Energy, DoE is) küldött szakértőket Ukrajnába, akik hat különböző ukrán szervezet vezetőivel és munkatársaival folytatott interjúk során gyűjtöttek első kézből származó információkat. Ezekből az információkból végül kirajzolódott a kép, hogy a kibertámadások összesen három régiós áramszolgáltató (Distribution System Operator, DSO) rendszereit érintették, összesen mintegy 225.000 fogyasztónál okozva áramkimaradást (a korábbi információk még két DSO-ról és mintegy 700.000 fogyasztóról szóltak). Három további, meg nem nevezett szervezet, köztük legalább egy kritikus infrastruktúra-elem informatikai rendszereit szintén kompromittálták a támadók, de ezek a szervezetek nem tapasztalták, hogy a támadás hatással lett volna az ipari folyamataikra.
Mindhárom érintett vállalatnál megtalálták a BlackEnergy malware nyomait, ami célzott adathalász támadások során talált utat a célba vett informatikai rendszerekbe, azonban a DHS szerint továbbra sincs egyértelmű bizonyíték arra, hogy a BlackEnergy malware jelenléte és a támadás között közvetlen összefüggés lenne. Az elemzők mindazonáltal ugyanarra a következtetésre jutottak, ami már többször is elhangzott, hogy a BlackEnergy adhatta az eredeti hozzáférést a célba vett szervezetek rendszereihez és az így nyert hozzáférésre alapozva hajtották végre a december 23-i üzemzavart kiváltó támadást.
Immár nyilvánvaló bizonyítokok állnak rendelkezésre azzal kapcsolatban, hogy a különböző szervezetek ellen indított támadásokat egymással szinkronban hajtották végre, feltételezhetően a célba vett hálózatok alapos felderítése után (itt megint felmerül a kérdés, hogy a támadók vajon mióta rendelkeztek hozzáféréssel a kompromittált ipari/folyamatirányító rendszerekhez, mennyi ideig vártak türelmesen, kitanulva a rendszer normál üzemi működését - hasonlóan ahhoz, amiről az Associated Press december 21-i, általam is hivatkozott cikkében írtak, hogy az amerikai kritikus infrastruktúrába számos támadó szerzett már hozzáféréseket).
A megtámadott vállalatok munkatársai szerint az áramkimaradásokat előidéző támadás mindenhol 30 percen belül végbement úgy, hogy egyidejűleg több, központi és régiós létesítményt is érintettek. Ez idő alatt a támadók, távoli, operációs rendszer-szinten működő illetve ICS kliens szoftvereket használtak, ez utóbbiakat VPN-kapcsolatokon keresztül. Az érintett vállalatok okkal feltételezik, hogy a támadók korábban megszerzett, legitim felhasználóneveket és jelszavakat is használtak a támadás során.
Mindhárom DSO arról számolt be, hogy a támadók a KillDisk malware-t használva törölték a célba vett rendszerekről a működéshez szükséges állományokat és tették használhatatlanná az MBR-t, valamint egy esetben felülírták egy Windows-alapú, RTU-ba integrált HMI fájljait és használhatatlanná tették az alállomási Serial-to-Ethernet eszközök firmware-jeit is, továbbá beütemezték a szerverek UPS-ről történő szoftveres lecsatlakoztatását is az UPS remote management interfészén keresztül. Ezek a tevékenységek az utólagos elemzések alapján arra irányultak, hogy minél jobban megnehezítsék az incidens utáni helyreállítási munkákat.
A DHS javaslatai a kockázatok csökkentésére
Első lépésként az információs rendszerek kezelésének legjobb gyakorlatának alkalmazását javasolják, amire néhány példát is adnak: megbízható hardverek és szoftverek beszerzése és a kapcsolódó licencek kezelése, naprakész nyilvántartás arról, hogy ki és mi kapcsolódhat a hálózathoz automatizált hardver és szoftverleltárak segítségével, időben történő patch-telepítések, stratégiai technológia-frissítések (ezek közül a patchelések és a technológia-frissítések kérdése meglehetősen komoly problémákat jelenthetnek ICS rendszerek esetén, ahogy arról korábban már én is írtam).
Egy másik javaslat az üzlet- és technológia-folytonossági tervek készítése. A BCP elkészítése ma már majdnem minden szervezet számára magától értetődő feladat, de a különböző technológiai folyamatok folytonosságára vonatkozó tervek (főleg, ha egy, az ukrán esethez hasonlóan súlyos ICS/SCADA rendszert érintő üzemzavar esetén kellene alkalmazni őket) nem léteznek vagy még nem a megfelelő minőségűek. Ez az incidens nagyon pontosan rámutat arra, hogy alapvető szükség van olyan eljárásokra és helyettesítő folyamatokra, amikor az ICS/SCADA rendszerek már nem a biztonságos ipari/folyamatirányítási munkavégzést támogatják, hanem éppen ellenkezőleg, azok ellenében vannak használva.
A támadók által használt szoftverek elleni védelemben az ICS-CERT az alkalmazások fehérlistázását (application whitelisting) javasolja, ami (megfelelő paraméterezés és naprakészen tartás mellett) segíthet megelőzni egy sikeres támadást vagy legalább csökkenteni egy sikeres támadás hatásait. Ebből a szempontból az ICS rendszerek korábban már többször, akkor negatív tulajdonságként említett statikussága előnyt jelent, hiszen az átlagos üzleti szoftverekkel szemben az ICS rendszereknél használt fehérlistákat jóval ritkábban kell módosítani.
Az ICS-CERT ebben az elemzésében sem hagyja feledésbe merülni, hogy az ICS rendszereket hálózatilag a lehető legnagyobb mértékben szeparálni kell az üzleti és egyéb hálózatoktól, elsősorban pedig az Internettől. Ugyanilyen fontos az ICS rendszerek alapszintű hardeningje, a nem használt portokat le kell zárni, a nem használt szolgáltatásokat/folyamatokat le kell állítani, a nem szükséges szoftvereket és csomagokat el kell távolítani az ICS rendszerekről. Amennyiben egy üzleti/technológiai folyamat külső (az ICS hálózatán kívüli) hálózati hozzáférést igényel, azt csak azokban az időszakokban szabad engedélyezni, amikor ez indokolt. Ha egy hálózati forgalom kizárólag egy irányba történik üzleti/technológiai okokból, célszerű lehet megfontolni az adat-diódák bevezetését. A kétirányú hálózati forgalmak esetén minimalizálni kell a kommunikációra használt portok számát és ezeket is csak biztonságosnak tekintett hálózati útvonalakon szabad elérhetővé tenni.
Ahol csak lehet, limitálni kell az ICS rendszerek távoli elérését, a modemek különösen nagy kockázatot jelentenek az ICS rendszerek számára. A szállítók számára nem szabad tartósan távoli elérést biztosítani. Minden, az ICS rendszerekhez történő távoli hozzáférést időkorlátosan operátori kontroll alá kell vonni és alapértelmezetten letiltott állapotban kell tartani. Mindenképpen erős többfaktoros azonosítást célszerű alkalmazni minden távoli ICS rendszer-elérés esetén és figyelni kell arra is, hogy az egyes azonosítási módokat ne lehessen hasonló módszerekkel kompromittálni (pl. jelszó és szoftveres tanúsítvány).
Nagyjából ennyit tartalmaz az ICS-CERT által publikált DHS összefoglaló, amivel kapcsolatban többen is igen gyorsan leírták a saját véleményüket, ezek közül én most Robert M. Lee és Joe Weiss írását ismertetem röviden.
A SANS ICS Security blogján megjelent írásában Robert megjegyzi, hogy a DHS összefoglalója meglehetősen kevés valódi elemzést tartalmaz az incidenssel kapcsolatban, jelentős részben az érintett ukrán szervezetek munkatársaival folytatott interjúkon megtudott információkból építkezik, amelyek ugyan fontos információforrások, de rendelkezésre álltak az incidens részleteivel kapcsolatos technikai bizonyítékok is, amelyeket szinte egyáltalán nem említenek az anyagban. Azt is kiemeli, hogy a DHS meglehetősen bátortalanul ír a BlackEnergy malware szerepéről az incidensben. Ez a tartózkodás, tekintve, hogy az áramkimaradásokban a BlackEnergy-nek közvetlen szerepe nem volt, érthető, de a malware és az incidens kapcsolatáról korábban már számos, publikus elérhető forrásban jelentek meg részletek, így nehezen érthető, hogy a DHS jelentéséből miért maradtak ki ezek az információk.
Robert másik, az előzőnél jóval súlyosabb kritikája az incidennsel kapcsolatban, hogy a különböző amerikai kormányzati szerveknek sokkal gyorsabban és jobban koordinálva kellett volna kezelniük ezt a precedens értékű, nemzetközi ICS-biztonsági és kiberbiztonsági incidenst. A harmadik észrevétel a DHS kockázatcsökkentésre irányuló javaslataira vonatkozik. Robert véleménye szerint az ICS rendszereken futó alkalmazások fehérlistázása ugyan jó lépés, de önmagában nem fog megoldást jelenteni az ilyen támadások esetén, ahogy az ukrán incidensnél sem állította volna meg a támadókat, akik hónapokon át rendelkeztek hozzáféréssel azokhoz a rendszerekhez, amelyeket aztán az üzemzavar előidézéséhez felhasználtak és képesek voltak az összes passzív védelmi intézkedéshez és biztonsági rendszerhez olyan módon alkalmazkodni a módszereikkel, hogy sehol nem váltottak ki riasztásokat az általuk végrehajtott műveletek. A VPN-kapcsolatok limitálása, a többfaktoros authentikáció, a patch-elés és a többi javaslat, amit a DHS tesz, szintén hasznos intézkedések és nagy segítséget nyújtanak egy biztonságosabb és védhetőbb ICS-környezet kialakítása során és egy támadás során időt nyerhetünk magunknak, de ezektől még nem lesz védett semmilyen ICS rendszer a támadások ellen. Az egyetlen módszer, amivel meg lehet védeni az ICS rendszereket, az a rendszerrel kapcsolatba kerülő emberek képzése. (Jelenleg valóban ez tűnik a leginkább hatékony ICS biztonsági intézkedésnek, egy ICS rendszer teljes életciklusa során minden olyan személyt/csoportot képezni kell biztonsági téren, akik kapcsolatba kerülnek a rendszerrel, felhasználókat, fejlesztőket, projektmenedzsereket, tesztelőket, üzemeltetőket és külön képezni kell azokat az IT biztonsági szakembereket, akik ICS rendszerekkel kell, hogy dolgozzanak, mert nekik az ICS rendszerek sajátosságaival kapcsolatban kell új ismereteket szerezniük).
Joe Weiss blogpostjában hosszasan taglalja a DHS-nek azt az ajánlását, hogy az ICS rendszerek legyen minél jobban szeparálva minden más hálózati szegmenstől és különösképpen az Internettől. A BlackEnergy támadások minden korábbinál jobban bizonyítják azt a régóta hangoztatott ICS-biztonsági érvet, hogy nem szabad ICS rendszereket az Internetre kapcsolni, mert ezeket előbb vagy utóbb majdnem biztosan kompromittálni fogják. A BlackEnergy által megfertőzőtt összes ICS rendszer esetén utólag kiderült, hogy a rendszer rendelkezett Internet-kapcsolattal és/vagy elérhető volt az Internet felől úgy, hogy mindeközben nem voltak megfelelő biztonsági intézkedések életbe léptetve. Joe ismét felhívja a figyelmet arra is, hogy bizonyított, a BlackEnergy több, az amerikai kritikus infrastruktúrába tartozó szervezet rendszereit is megfertőzte. Joe szerint az ukrán incidens és a DHS jelentése is azt bizonyítja, hogy NERC CIP jelenlegi formájában nem alkalmas biztonságos ICS rendszerek kialakításának támogatására, ezért a FERC-nek és az NRC-nek felül kéne vizsgálnia a kritikus infrastruktúrák biztonságára vonatkozó ajánlásait és előírásait.
