A szoftveres hibajavítások alkalmazása az ICS rendszerek világában mind a mai napig meglehetősen heves vitákat szokott kiváltani az IT biztonsági szakemberek és az OT mérnökök között. Alapvető filozófiai különbségek vannak a két szakterület között, az OT mérnököket az első munkanapjuktól kezdve arra tanítják, hogy egy működő rendszert csakis a legsúlyosabb indok esetén szabad módosítani. Ráadásul ugyanazok az idősebb, több évtizedes tapasztalattal rendelkező mérnökök, akik ezt tanították nekik, még bőven a Stuxnet megjelenése után is meggyőződéssel vallották (és néha még ma is meggyőződésük), hogy a folyamatvezérlő rendszereikhez nem lehet hozzáférni a vállalati vagy publikus hálózatokról. Harmadrészt igen sokáig az ICS rendszerek gyártói is azt az álláspontot képviselték, hogy az általuk fejlesztett folyamatirányító rendszerekben és eszközökben feltárt hibákat nem szükséges javítani, amennyiben azok valós kockázatnövekedést okoznak a felhasználó rendszerében, azt tökéletesen lehet kompenzáló kontrollok (pl. tűzfalak és egyéb hálózatbiztonsági megoldások) alkalmazásával ellensúlyozni.

Az elmúlt néhány évben (ahogy az ICS kiberbiztonsági incidensek és publikált sérülékenységek száma egyre gyorsabban nőtt), már nem csak a nagy és széles körben ismert gyártók (pl. Siemens, ABB, Schneider Electric, stb.) fordítanak egyre nagyobb figyelmet a termékeik hibajavításaira, hanem a kisebb és kevésbé ismert fejlesztőcégek is egyre gyakrabban működnek együtt az ICS-CERT-tel és a hibákat felfedező kutatókkal.

Az OT mérnököknek egy dologban azonban igazuk van: egy ICS rendszer esetén a hibajavítás sokkal nagyobb körültekintést igényel, mint egy mégoly fontos vállalati IT rendszeré. Ehhez próbálok a mai posztban egy rövid útmutatót adni (ami nyilván nem az egyetlen és nem is a tökéletes ICS patch menedzsment eljárás, de talán alapnak jó lehet, ha valaki a saját eljárását kell, hogy kialakítsa).

Ahogy az IT és az ICS rendszerek és folyamatok esetén sokszor, az ICS patch menedzsment esetében is ciklikus körforgásról beszélhetünk, aminek ebben az esetben 6 fázisa van.

1. Eszközök és fontosabb szoftverek azonosítása: Az ICS biztonság egyik alappillére, hogy naprakész nyilvántartással rendelkezzünk az alkalmazott eszközeinkről és a rajtuk futó fontosabb szoftver verziókról. Ez egy meglehetősen összetett, idő- és energiaigényes feladat tud lenni, de jelentősen segít az ICS rendszerek biztonsági szintjének növelésében, méghozzá anélkül, hogy a változások emelnék az ICS rendszerek üzembiztonsági kockázatait.

2. Az elérhető patch-ek ellenőrzése: Ha már tudjuk, pontosan milyen eszközeinken milyen verziókat használunk, ellenőrizni lehet, hogy milyen frissítések és hibajavítások érhetőek el a gyártónál.

3. Az elérhető patch-ek alkalmazhatóságának ellenőrzése: Mivel nem minden, a gyártó által kiadott frissítést lehet alkalmazni (pl. a rendszerünkben meglévő egyedi módosítások miatt), minden esetben külön ellenőrizni kell, hogy az adott patch-et lehet-e és szabad-e telepíteni. Ide tartozik a gyártó által kiadott, a telepítést kifejezett engedélyező nyilatkozat, ami nélkül súlyosabb esetben akár a gyártói garanciát is elveszíthetjük az adott rendszeren (gyakran éppen ettől tartva tiltakoznak az OT-s mérnök kollégák a hibajavítások telepítése ellen).

4. A patch-ek beszerzése: Az ICS világban a patch-ek beszerzése nem mindig olyan egyszerű, mint amihez az IT világban hozzá lehetett szokni az elmúlt évtizedekben. Számos esetben a gyártók még az elérhetővé tett patch-ek hash-eit sem adják közre, így pedig nehezebb ellenőrizni, hogy valóban a gyártó által kiadott javítást töltöttük-e le.

5. A letöltött patch-ek tesztelése és ellenőrzése: Ahogy a 4. pontban is írtam, mindenképp meg kell győződni arról, hogy a letöltött patch-ek valóban azokat a változásokat hozzák a rendszerbe, amire számítunk, ugyanakkor még ha a gyártó által kiadott eredeti patch-et is töltöttük le, akkor sem garantálható, hogy a telepítés nem fog valamilyen nem várt változást okozni az ICS rendszerünkben. Mivel minden ICS rendszer egyedi, ezért minden körülmények között célszerű labor körülmények között tesztelni a patch telepítésének hatásait és hogy a telepítéssel járó változások magukkal hoznak-e további legitim változási igényeket (pl. tűzfal szabályok módosításait, változásokat a végpont védelmi szoftver kivétel listájában, stb.).

6. Telepítés: A 6. pontban leírt tesztelési és ellenőrzési folyamat során el kell készíteni az éles (és ha van, tartalék) környezetben használható telepítő csomagot, ami tartalmazza a telepítési leírást és azoknak az eszközöknek a listáját is, amikre a telepítő csomagot telepíteni kell.

 Ahogy már írtam a poszt elején, ezek a lépések nyilván nem adnak egy teljes útmutatót az ICS rendszerek patch-eléséhez, de nem is ez volt a célom. Ha azonban csak egy kollégának is tudok segíteni az elindulásban, már megérte megírni ezt a posztot.