A múlt heti posztban Joe Weiss S4x-es előadása nyomán azt a kérdést hagytam nyitva, hogy vajon az ICS rendszerek hálózatbiztonsága (ide értve az ICS/SCADA rendszereket és az ICS rendszerek mérnöki munkaállomásait és HMI-ait is) vagy a Purdue-modell alapján level1/level0-nak nevezett berendezések (PLC-k, RTU-k és különböző motorok, szelepek, áramváltók, digitális védelmek, stb.) kiberbiztonsága a fontosabb-e?
Előre kell bocsátanom, hogy az alábbiak az én személyes véleményemet mutatják be.
Szóval én úgy látom, hogy erre a kérdésre nem lehet egyszerű választ adni, mert nem vagy-vagy kérdésről van szó. Egyrészt úgy gondolom, hogy Joe igazát nem lehet elvitatni, a level1/level0 szintű eszközök esetében a Stuxnet óta mindig felmerül a kérdés, hogy a tőlük kapott adatok valósak-e? (Ugye erről írtam a múlt héten a Boeing 737 MAX katasztrófákat példaként hozva, de a Stuxnet gyakorlatilag ugyanezt a biztonsági rést használta ki arra, hogy százasával tegye tönkre az iráni centrifugákat - senkinek nem jutott eszébe megkérdőjelezni az ottani ICS rendszerbe beérkező adatok hitelességét, pedig az urándúsító centrifugák fordulatszáma kb. minden más volt, csak az az érték nem, ami a kijelzőkön megjelent). Ezért aztán úgy gondolom, hogy a szakmának igenis nagyon komolyan foglalkoznia kell azzal a problémával, amire Joe immár vagy 3 éve folyamatosan próbálja ráirányítani a figyelmet.
A másik oldalon ott az ICS rendszerek hálózat- és host szintű biztonságának kérdése. Ha alaposan elolvassuk a különböző, fizikai folyamatok vezérlését célzó támadásokról készült elemzéseket, igen gyorsan fel lehet fedezni azt a közös pontot, hogy minden ilyen incidens azzal kezdődött, hogy a támadók valamilyen, kifinomult, de korántsem forradalmian újszerű IT biztonsági rést kihasználva szereztek hozzáférést az adott szervezet hálózatához (még ha ehhez adott esetben egy vagy több nulladik napi sérülékenységet használtak is fel - ahogy arról már volt szó itt a blogon is, nem túl nehéz egy-egy nulladik vagy első napi sérülékenységet találni az ICS rendszerek tágabb környezetében). Éppen ezért tartom fontosnak, hogy a "hagyományos" IT biztonsági eszközökkel és eljárásokkal a lehető legjobban megerősítsék a szervezetek az IT és ICS rendszereik biztonságát, ahol lehet, a megelőzésre koncentrálva, ahol pedig a megelőző kontrollok és biztonsági megoldások alkalmazása valamilyen ok miatt nem lehetséges, ott az incidensek (legyenek azok akár rosszindulatúak, akár jó szándékú beavatkozásból származóak) mielőbbi észlelésére és hatékony felszámolására alkalmas eszközökre és incidenskezelési eljárásokra van szükség.
Az érintett szervezetek (fejlesztők, integrátorok, üzemeltetők és ne tagadjuk le: még az ICS biztonsági szakma is) meglehetősen lassan ébredtek a Stuxnet nyilvánosságra kerülése óta elmúlt 9 évben és sajnálatos módon nem koncentráltak eléggé az ICS rendszerek és berendezések biztonságának egyenszilárd növelésére, így ma már nem kockáztathatjuk, hogy az ICS rendszereink csak egyik vagy csak másik elemének biztonságát fejlesztjük. Új megközelítésre van szükség, ahol az ICS rendszerek minden szintjén egyetlen nagy képet figyelve fejlesztjük a kiberbiztonságot, nem pedig arra, hogy az IT-OT szembenállás mellett felépítsük az IT-OT-folyamatirányítási mérnökök hármas patthelyzeti vitáját. Észre kell végre venni, hogy ha az ICS rendszerek körül dolgozó szakemberek nem fognak össze mindannyian, akkor a támadók (akinek nincsenek ilyen problémáik, mert nem vesztegetik az időt kicsinyes, szakmai és felségterületi féltékenységből fakadó vitákra) nagyon rövid időn belül fölénk fognak kerekedni, az pedig nem csupán egy adott szervezet belső problémája lesz, hanem régiók, országok fogják nyögni a következményeit!