Ipari és folyamatirányítási informatikai rendszerek biztonságáról magyarul.

ICS Cyber Security blog

ICS Cyber Security blog

ICS rendszerek biztonsága

Hol égetőbb a kiberbiztonság kérdése az ICS rendszerekben?

2019. július 13. - icscybersec

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!

A bejegyzés trackback címe:

https://icscybersec.blog.hu/api/trackback/id/tr6414930954

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

papikg 2019.11.13. 18:02:58

Fontos és helytálló gondolatok, és fontos kérdés feltevés. Ami szerintem nagyon hiányzik, és az egész alapja lehet, az a teljes rendszert (humán-technika-policíy) egyben értelmezni képes látásmód. Olyan szakembergárda/vezető aki érti az OT-ban zajló folyamatokat, szót tud érteni az ott dolgozó emberekkel, és ismeri ezeknek a nem ritkán legacy rendszereknek a technikai kihívásait is. Vagy legalábbis hajlandó megismerni, megérteni.
Technikai szinten maradva, azt gondolom, hogy vannak azért ide vonatkozó szabványok (ansi/isa s95 pl) amit akár be is lehetne tartani. Egészen biztosan nem lesznek egységes megoldások még egy rendszeren belül sem, s95 layerenként más és más lesz a használható technológia. Egy komplex rendszer esetén nem nagyon tudok elképzelni működőképesebbet a mélységben tagolt védekezésnél.
Új beszerzéseknél jó lenne ha a security by design is a követelmények közt lenne, így talán elkerülhető a másik posztodban említett hamis távadó esete.
Alapvetően tudomásul kell venni azt hiszem, hogy folyik a 3. nagy háború, és a csatatér közepén állnak a rendszereink. Ez pedig szemléletváltást igényel. Mégpedig úgy hogy az eddigi értékeket nem engedjük el (költség hatékony, magas rendelkezésre állású, megbízható, robosztus rendszerek)
Szép kihívás... ezeket szeretjük.

papikg 2019.11.13. 18:07:00

@papikg: Ansi/ISA S99, ezt elírtam...

snwx 2019.12.16. 22:39:44

Mar regota akartam hozzaszolni itt, most pont belefutottam ebbe a cikkbe, es bar nem vagyok teljesen kepben hogy esetleg foglalkoztal-e mar az IT-OT fighttal reszletesebben, de megerne egy miset :-)

icscybersec 2019.12.19. 19:12:53

@papikg: Egyetértünk, az egész ICS témakört alapjaitól kéne újragondolni, hogy a gyakran több évtizedes berögződéseket meg lehessen végre haladni és ne a kölcsönös bizalmatlanság legyen az alap az IT-OT viszonyban. Sajnos ennek nem sok nyomát látom, a kérdés most igazán az, hogy az OT elfogadja-e a kiberbiztonsági kockázatok létezését és folyamatos növekedését - az én tapasztalatom az, hogy nem vagy éppen hogy csak. Aztán a szembenállás egy egészen másik szintjének tartom azt a vitát, amit legjobban Joe Weiss és (főleg) a Dragos elemzői közötti, blogbejegyzésekben megjelenő adok-kapok illusztrál nagyon szépen, történetesen, hogy hova kell helyezni a hangsúlyt az ICS biztonságon és az ICS rendszereken belül? Hálózatbiztonság, SCADA/DCS hostok vagy field device-ok felől érdemesebb közelíteni, hova kell fókuszálni a mindenhol véges (valójában nagyon kevés) erőforrást? Azt hiszem erről is fogok még írni, van saját véleményem a témában.

@snwx: Eddig három poszt szólt többé-kevésbé az IT-OT szembenállásról, ezek:
icscybersec.blog.hu/2019/06/15/ot-vs-it
icscybersec.blog.hu/2019/08/03/it-ot-megoldasi-lehetosegek
icscybersec.blog.hu/2019/10/05/it-ot-szembenallas-kockazatai

Terveim szerint lesz még bőven ilyen témájú írásom, mert nagyon finoman szólva is hihetetlenül messze vagyunk a szerintem elfogadható együttműködéstől.
süti beállítások módosítása