Ismét jelentkeztek a túlmozgásos orosz hacktivisták, ezúttal egy okosotthonok épületautomatizálási rendszereit telepítő-építő-integráló cég rendszerébe mentek be, "természetesen" illegálisan.
Az incidensről (mint a Sector16 magyar automatizálási rendszerek elleni támadásai esetén már-már megszokhattuk) a kiber.blog.hu-n lehet részletesebben olvasni.
Ennyi miatt még nem írtam volna meg ezt a posztot (ezzel is tovább tolva egy engem egyébként jobban érdeklő témát, <SPOILER-ALERT> az akkumulátoros villamosenergia-tároló rendszerek biztonságát - ez majd 26-án következik), de a Sector16 ezúttal tanácsokat is adott arra vonatkozóan, hogyan kéne biztonsgosabbá tenni a magyar OT rendszereket. Ez pedig már ér annyit, hogy tételesen végignézzük, szerintük mik a helyes intézkedések és én mit is gondolok ezekről.
„Az adminisztrátoroknak erősen ajánlott további védelmi intézkedéseket bevezetni a rendszer biztonsága érdekében:
1. Többrétegű védelem
Alkalmazzanak többrétegű védelmet, beleértve tűzfalak, behatolásmegelőző rendszerek (IPS) és vírusirtó szoftverek használatát."
Többrétegű védelem, tűzfalak - igen, ezek hasznosak, ha jól alkalmazzák őket. AV/Endpoint Protection/EDR megoldások - Ezek az eszközök szintén segíthetnek biztonságosabbá tenni a rendszereinket, már amennyiben lehet ilyeneket telepíteni, ahogy többször is szóba került már, PLC-kre, RTU-kra, naperőművi inverterekre és sok más, a Purdue-modellben jellemző Level1 és Level0 berendezésre ez utóbbiaknak túl sok esélyük nincs. De általánosságban végül is igazuk van. Viszont: IPS - nagyon nem jó ötlet, ha csak a biztonságért felelős ember nem szeretne egy kósza fals pozitív detekcióból induló blokkolás okozta üzemzavart elhárítani vagy a(z igen feldúlt és a magyar nyelv igen színes ékítő jelzőit sűrűn használó) folyamatirányító mérnök kollégáknak azzal kapcsolatban magyarázkodni, hogyan is okozta a hibásan blokkolt forgalom a rendszerük működési zavarait. Esetleg a fizikai folyamat hogyan indult el egy veszélyes irányba.
"2. Rendszeres frissítések
Biztosítsák, hogy a rendszer valamennyi eleme – hardver és szoftver egyaránt – folyamatosan naprakész legyen, így védve a már ismert sérülékenységekkel szemben."
Igen, a frissítések telepítése fontos. Kérdés csak az, hogy:
1) van-e rendelkezésre álló frissítés, hibajavítás. Mint tudjuk, a különböző folyamatvezérlésben alkalmazott firmware- és szoftver-komponensek életciklusa és használati ideje nagyon durván képes elválni egymástól, én magam rendszeresen látok még Windows XP, Windows 7 operációs rendszereket éles folyamatirányító rendszerek alatt, de a csúcs az volt, amikor a 2017-es WannaCry incidens nyomán kiderült, hogy akkoriban egy helyen volt olyan ICS berendezés, aminek a konfigurálásához használt szoftvert csak MS-DOS-os lehetett futtatni...
2) Ha van telepíthető frissítés, mikor telepítsék? Az IT-val ellentétben (lehetőleg minél előbb, de legkésőbb a következő rendszeres karbantartási ablakban) az OT rendszereknél ennek meghatározásához több információ kell. Jóváhagyta-e már a hibajavítás/újabb verzió telepítését az ICS/OT rendszer gyártója? Ha nem, akkor bizony garanciavesztéssel vagy újratelepítéssel, esetleg egy hibátlan javítás/frissítés után egy nem vagy nem hibátlanul működő OT rendszer lehet a beavatkozás eredménye. Még akkor sem vagyunk kifejezetten a frissítés telepítésének célegyenesében, ha az OT gyártó már megadta a hozzájárulását a telepítéshez, hiszen egy OT rendszernél a frissítés okozta leállás nem biztos, hogy elfogadható az üzleti vezetők számára. Ekkor pedig nincs más hátra, mint várni a következő tervezett leállást, ami bizony hónapokig vagy akár 1,5-2 évig is tarthat. Az ICS/OT rendszerek sérülékenység-menedzsmentjével kapcsolatban mindmáig a legjobb megközelítésnek azt a "Now-Next-Never" modellt gondolom, amit még az S4x25-ön láttam a Dragos-os Logan Carpentertől (itt írtam röviden az előadásáról.)
"3. Erős jelszavak és jelszóváltási politika
Használjanak erős, bonyolult jelszavakat, és írjanak elő rendszeres jelszócserét a jogosulatlan hozzáférés kockázatának minimalizálása érdekében."
Általános és legalább 20-30 éve létező tanács az IT-ban, hogy használjunk nehezen kitalálható, összetett és hosszú jelszavakat, mert ezek a biztonságosak. Azt most inkább hagyjuk, hogy már legalább 4-5 éve az erős jelszavak önmagukban nem számítanak biztonságosnak és már a kétfaktoros azonosítási módokat is kiszorították az MFA-k, beszéljünk inkább arról, hogy egy erősnek és biztonságosnak tekintett jelszó (bármelyik a mára klasszikussá nemesedett xkcd képregény példa jelszavai közül) miért nem jó választás egy ICS/OT rendszer esetén? Leginkább azért, mert amikor egy komolyabb üzemzavar idején kell a folyamatirányító mérnöknek vagy az operátornak bejelentkezni, hogy megakadályozzon egy súlyosabb (akár safety) incidenst, akkor nem szabad és lehet megkockáztatni azt, hogy elgépeli a correct horse battery staple-t vagy éppen jut eszébe, hogy a múlt héten cserélték le az elmúlt 1 hónapban/1 évben használt jelszót egy újra. Ezzel persze nem azt mondom, hogy az 123, a password vagy a ninja megfelelő jelszavak lennének (pedig amióta a Sector16 magyar rendszerek iránti érdeklődését figyelemmel követjük, ennél még egyszerűbb/rosszabb jelszavakat is bőven látunk a hazai folyamatirányító rendszerekben), de ahogy az életben majdnem mindenhol, úgy ebben az esetben is célszerű megtalálni az egyensúlyi pontot. Legyen a jelszó nehezebben törhető, de könnyen használható.
"4. Naplózás és eseménymonitorozás
Kapcsolják be a kritikus műveletek részletes naplózását, és rendszeresen elemezzék a logokat gyanús tevékenységek felderítésére."
Imádom a naplózást és a naplógyűjtő/elemző rendszereket. Kevesen tudják, hogy a karrierem kb. azért tudott elindulni, mert felvettek az első munkahelyemre logokat elemezni. Szóval, ha valaki egyetért ezzel a tanáccsal, az én vagyok. Ebben az esetben is csak az a probléma, hogy számos olyan ICS berendezést ismerünk, ami nem vagy nem nagyon tud úgy naplózni, ahogyan azt azok a "kedves és segítőkész" emberek az általuk ismert IT rendszereknél megszokták. Szóval igen, ha egy ICS/OT rendszer tud logokat küldeni egy központi SIEM rendszerbe, küldjék oda és utána dolgozzanak az illetékesek a parsing-on, a korrelációs és riasztási szabályokon - és nem utolsó sorban, keressenek valamilyen kompenzáló kontroll(oka)t az olyan esetekre, amikor ez nem lehetséges.
"5. Hozzáférés-szegregáció
Korlátozzák a rendszerhozzáférést szerepkörök szerint, csak azokat a jogosultságokat adva meg a felhasználóknak, amelyek a feladataik ellátásához feltétlenül szükségesek."
Ez a tanács így, ahogy van, hibátlan, bár érdemes megemlékezni azokról a folyamatirányítási alkalmazásokról, amiknek a futásához 1) rendszergazdai jogosultsági szintnél kevesebb nem elég; 2) egy aktívan bejelentkezett rendszergazdai jogosultságú felhasználóra van szükség.
"6. Penetrációs tesztek
Rendszeresen végezzenek penetrációs teszteket a rendszer gyenge pontjainak felderítése és megszüntetése céljából."
Igazság szerint ez volt az a pont, amit olvasva eldöntöttem, hogy ez a mai poszt meg kell, hogy szülessen. Az ICS/OT rendszerek pentesztelése az egyik legveszélyesebb dolog, amit kiberbiztonsági szakember egy folyamatirányító rendszerrel tehet. Én személy szerint csak két esetben tartom elképzelhetőnek és elfogadhatónak egy OT rendszer pentesztjét, egyrészt a SAT (Site Acceptance Test - helyszíni elfogadási teszt) részeként, másrészt pedig, ha az OT rendszerről készült mentéseknek van visszaállítási tesztje (labor körülmények között), akkor a sikeresen visszaállított és funkcionálisan már végigtesztelt rendszer lebontása előtt hasznos lehet egy pentesztet végezni. Lévén laborban történik a teszt, így nem fordulhat elő, hogy nem ismert hiba felfeldezése vagy az OT rendszer penteszt során előforduló, nem várt viselkezése üzembiztonsági vagy safety incidenst okozna.
"7. Képzés és tudatosság
Folyamatosan fejlesszék a munkatársak biztonságtudatosságát, tájékoztatva őket a felmerülő fenyegetésekről és a hatékony védekezési módszerekről.”
Végül ez az a tanács, ami valóban hasznosítható, mindenfajta változtatás vagy kommentár nélkül.
Összességében én azt látom, hogy a Sector16 néven tevékenykedő csoport valamiért rákapott a gyengén vagy sehogy sem védett, kisebb méretű magyar OT rendszerek elleni akciókra, de az is látszik hogy (eddig legalább is) elegendőnek látták belépni ezekbe a rendszerekbe és képeket/videókat közölni arról, hogy mire képesek. A most tárgyalt tanácsaik alapján kezd az az érzésem lenni, hogy (még?) keveset tudnak az ICS/OT rendszerekről, azonban nagyon fontos lenne az illetékeseknek figyelembe venni, hogy nem is kell egy támadónak ennél többet tudnia ahhoz, hogy romboljon vagy komoly károkat okozzon - főleg, ha a vezérelt fizikai folyamatok jellemzőivel sincs tisztában. Ettől csak még veszélyesebb lesz.
