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

ICS Cyber Security blog

ICS Cyber Security blog

A technológia-közeli eszközök védelmének erősítéséről

2021. augusztus 14. - icscybersec

Augusztus 5-én GéPé kolléga (írásai mind gyakoribb és örömtelibb vendégek ezen a blogon is) egy fontos posztot jelentetett meg a SeConSys blogján, amiben Joe Weiss írásai nyomán az ICS rendszerek technológia-közeli berendezéseinek védelmi megoldásai (illetve azok hiánya) kérdéseit boncolgatta.

Régóta érlelődik bennem egy poszt a témával kapcsolatban, még inkább Joe idestova 4 éve kitartóan hangoztatott érveinek az én nézőpontomból történő vizsgálatáról, szóval most végképp eljött az ideje, hogy erről én is írjak.

Talán már írtam róla, hogy Joe Weiss blogját 2014 óta olvasom és Joe-t 2015. október óta ismerem személyesen (egyszerűen leült mellém a bárpulthoz a szállodában, ahol egy konferencia miatt voltam), a vele folytatott hosszabb beszélgetések adták meg az utolsó lökést, hogy elindítsam ezt a blogot és mind mélyebben ássam bele magam az ICS kiberbiztonság témájába. Szóval Joe egyfajta korai mentor volt számomra és mindig csodálattal néztem azt a kitartást, amit ő és néhány hozzá hasonló úttörő tanúsított az ICS biztonság ügye iránt. 2017-re már elég nyilvánvaló volt, hogy az ICS biztonság nem csupán egy maroknyi üldözési mániás őrült hagymázas rémálma, egyre több ICS rendszer üzemeltető és a szállítói oldal is egyre inkább felismerte, hogy a témával bizony foglalkozni kell. Joe ekkor kezdett arról beszélni, hogy az ICS biztonság nem csak az OT hálózatok biztonságát jelenti, hanem az ICS végponti berendezések kiberbiztonsága is súlyos hiányosságokkal küzd. Az elmúlt évek során ebbéli meggyőződése odáig fejlődött, hogy posztjaiban és egyéb megnyilatkozásaiban már vagy-vagy választásként beszél az OT hálózatbiztonságról és az ICS végponti eszközök kiberbiztonságáról.

Tavaly, már a COViD-járvány alatt volt egy hosszabb Zoom-beszélgetésünk, ahol próbáltam finoman érdeklődni, hogy vajon nem lenne jobb úgy megközelíteni ezt a témát, hogy nem választani kell az OT hálózatbiztonság és a (Purdue-modell szerinti) L1/L0 eszközök biztonsága között, hanem inkább azokat mint egymás kiegészítő biztonsági kontrolljait kéne nézni, az OT hálózatbiztonsághoz úgyis inkább klasszikus IP hálózatbiztonsági (IT biztonsági) mérnökökre van szükség, a L1/L0 eszközök biztonsága pedig olyan téma, amihez a folyamatirányítási logikát mélyebben ismerő mérnökök értenek jobban. Végső soron pedig ismét ugyanoda jutunk: ahhoz, hogy az ICS kiberbiztonság a rendszer minden szintjén egyenszilárd lehessen, az IT, IT biztonsági és folyamatirányítási mérnökök eddiginél és jelenleginél sokkal jobb, hatékonyabb és szorosabb együttműködése szükséges. Mindaddig, amíg a résztvevő mérnökök külön-külön, egymást nem partnernek, inkább ellenfélnek vagy nehezítő tényezőnek tekintve dolgoznak, a támadók mindig találni fognak olyan gyenge pontokat, amiket mindkét (vagy mindhárom) csapat kihagyott a biztonságosabb rendszerekért folytatott munka során és ezeket kihasználva képesek lesznek megzavarni a fizikai folyamatok irányítását.

Ráadásul már az sem lenne elég, ha az IT/OT hálózatbiztonsági és folyamatirányítási mérnökök között létezne egy, a mostaninál sokkal jobb szakmai együttműködés, hiszen a Colonial Pipeline-incidens elég világosan megmutatta (bár nem ez volt az első ilyen incidens, de ennek volt az átlagemberek életére olyan széleskörű negatív hatása, amit már nem tudott senki, a mainstream média és a politikai döntéshozók sem figyelmen kívül hagyni), hogy elég, ha a fizikai folyamatokra épülő üzleti rendszerek némelyike esik áldozatául egy kiberbiztonsági incidensnek, már egy ilyen eset is vezethet oda, hogy az ICS rendszerek leállítása (és ezen keresztül a fizikai folyamatok leállítása) lesz a kisebbik rossz.

Összefoglalva (és válaszolva GéPé kérdéseire):

"Mi a véleményetek a technológia közeli védelem megerősítésének vázolt koncepciójáról?"

Mindenképp szükségesnek gondolom a L1/L0 eszközök kiberbiztonsági képességeinek és védelmi szintjének javítását (érdekes adalék egyébként, hogy egy távoli munkatársam, aki ismeri Joe-t, vitatja Joe azon állítását, hogy a L1/L0 eszközökben semmilyen kiberbiztonsági funkció ne lenne, de konkrét példákat, mint ellenérve még tőle sem láttam) és a SIGA OT Solutions által készített megoldás is lehet olyan jó, mint bármelyik OT hálózatbiztonsági termék, ezt igazán majd az idő és a gyakorlati alkalmazás fogja megmutatni.

"Egy ilyen védelem valóban csökkentené-e egy zsarolóvírusos támadó késztetését?"

Ebben viszont nem hiszek. A ransomware-bandák azért működnek hosszú évek óta ilyen sikeresen, mert kis befektetés mellett tudtak nagy tömegeket támadni (amíg a fő célpontjaik a magánszemélyek voltak), aztán felismerték, hogy a vállalatok elleni támadásokkal jóval nagyobb összegeket is követelhetnek, majd azt, hogy ha a civilizációnk alapjait biztosító ipari folyamatokat irányító szervezetek automatizált rendszereit támadják, sokkal komolyabb nyomást tudnak gyakorolni, hiszen az adatok helyreállításánál sokkal fontosabb, hogy a folyamatvezérlés működjön. Viszont a támadók (némi OSINT felderítéssel) azt is megtudhatják, hogy milyen ügyviteli rendszereket kell ahhoz támadniuk, hogy siker esetén a célpont szervezet fizikai folyamatirányítása majdnem vagy pontosan ugyanannyira megbénuljon, mintha a (jó esetben) sokkal nehezebben hozzáférhető ICS rendszereket és különösképpen a L1/L0 eszközöket támadnák. Éppen ezért én nem számítok arra, hogy a közeli jövőben csökkenne az ipari szervezetek elleni zsarolóvírus-támadások száma, inkább csak növekedni fog.

Első körben ennyit gondoltam hozzátenni a témához (így is hosszabb lett ez a poszt, mint elsőre gondoltam, tovább is tartott megírni, mint eredetileg terveztem), de remélem ez a téma nem itt és most hal el, hanem többen elkezdenek írni a vele kapcsolatos gondolatairól.

A bejegyzés trackback címe:

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

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.

Nincsenek hozzászólások.
süti beállítások módosítása