Évről-évre egyre több sérülékenységről jelennek meg információk és ez a probléma már régóta nem csak az IT rendszerek sajátja (nehéz is lenne, ha figyelembe vesszük, hogy az ICS/OT rendszerek egyre nagyobb hányada használ OT komponenseket). Ha pedig egyre több a sérülékenység, akkor érthető módon jelenik meg az igény ezeknek a hibáknak a javítására (ha rendelkezésre áll a javítás az adott hibára) vagyis a patch-elésre. A kérdés csak az, hogyan csináljuk?

Kézenfekvő lenne a válasz, hogy kérjünk karbantartási ablakot az adott rendszer üzemeltetőitől/felelősétől, telepítsük a patch-eket. Ez - legalább is azok számára, akik IT rendszereken tanulták ki a sérülékenység-menedzsmentet - egyértelműnek tűnik, de ICS/OT rendszerek esetén ugyanez a tevékenység több részleten is elbukhat, ilyenek, a teljesség igénye nélkül:

• Nincs fejlesztői/teszt rendszer;
• A következő fél-egy évben nincs betervezett karbantartás, így karbantartási ablak sem;
• Az ICS/OT rendszer gyártója (még) nem vizsgálta be az adott hibát javító patch-et, ezért annak a telepítése súlyos negatív következményekkel (üzembiztonsági kockázat, safety kockázat, funkcióvesztés, garanciavesztés, stb.) járhat;

Részben ezek miatt érdemes a (bármilyen) folyamatvezérlő rendszereket üzemeltető szervezeteknek egy külön, OT rendszerekre vonatkozó sérülékenység-menedzsment eljárást kidolgozniuk, begyakorolniuk és alkalmazniuk. Egy ilyen eljárás jellemzően az alábbi lépésekből állhat (ezek egy jó része ismerős lehet egy jobb IT sérülékenység-menedzsment eljárásból):

1. Folyamatosan kövessük nyomon, hogy milyen ICS/OT sérülékenységekről jelennek meg információk (ehhez figyelhetjük a mi szervezetünk által használt OT rendszerek gyártóinak közleményeit és például az ICS-CERT publikációit is);
2. Vizsgáljuk meg, hogy egy adott ICS/OT sérülékenység érinti-e a szervezetünk által használt ICS/OT rendszereket (ehhez mondjuk nem árt egy naprakész eszközleltárral rendelkezni, de tapasztalataim szerint egy ilyen kialakítani és folyamatosan frissíteni egy meglehetősen komoly kihívásnak minősül szinte minden szervezet számára...);
3. Ha a sérülékenység jelen van az ICS/OT rendszereinkben, akkor következhet a kockázatelemzés. Az elemzés során több kérdésre érdemes választ keresni, ilyenek lehetnek egyebek mellett:

• Melyik rendszer(ek) érintett(ek)?
• Mikor működnek az érintett rendszerek éles üzemben?
• Léteznek-e és elérhetőek-e kompenzáló/alternatív kontrollok a sérülékenység okozta kockázatok csökkentésére?
• A sérülékenység hatására nőnek-e az ICS/OT rendszerekkel kapcsolatba kerülő emberek életét és/vagy testi épségét (safety) fenyegető kockázatok?
• Milyen következményei lehetnek, ha valaki kihasználja az adott sérülékenységet;

Fontos, hogy egy ICS/OT kockázatelemzés lefolytatásához minden érintett szakembert vonjunk be, mert csak úgy fogunk pontos kockázati eredményeket kapni, ha mindenkit (pl. OT mérnököket mindenképp) bevonunk az elemzésbe, akik a különböző szakterületeket és különböző nézőpontokat, szempontokat, prioritásokat megfelelően képviselni tudják.

A kockázatelemzés végén, a pontos kockázatokat ismerve és az adott ICS/OT rendszer (és az általa automatizált folyamatok) felelősével, mint az elemzés során vizsgált kockázatokat viselő felelős vezetőkkel egyeztetve válaszokat kell találni a következő kérdésekre:

• Szükséges-e változtatásokat tervezni a sérülékenység javítása érdekében?
• Ha szükséges, milyen gyorsan kell ezt megtenni?

Amint megvannak a válaszaink a fenti kérdésekre, lehet tervezni a további lépéseket.

Azt hiszem, a fentiekből is látszik, hogy az IT-OT konvergencia fejlődésével az olyan feladatok terén, mint az ICS/OT sérülékenység-menedzsment is egyre több hasonlóságot lehet felfedezni az IT és OT rendszerek között, ugyanakkor a különbségek ezek ellenére sem tűnnek el és ezeket a különségeket nem szabad sem figyelmen kívül hagyni, sem a fontosságukat kisebbíteni, különben nagyon komoly (esetenként akár safety) kockázatokat okozhat egy teljesen jóindulatú, de nem kellően körültekintően kezdeményezett változtatás. Emlékezzünk Joe Weiss egyik fontos gondolatára: attól, hogy egy incidens kiváltó oka egy nem rosszindulatú változtatás volt, attól az még incidens!