Az elmúlt közel egy évtizedben teljes mértékben át kellett értékelni az ICS rendszerek biztonságát és ez nem hagyja érintetlenül az ICS rendszerekkel kapcsolatos incidenskezelési folyamatok és eszközök területét sem. A vállalati IT biztonság területén jó ideje legalább olyan fontossá vált a biztnosági incidensek észlelésének és elhárításának feladata, mint a támadások megelőzésének szempontja, az ICS világában azonban ez az érettségi állapot még nem jött el, jelenleg még mindig él a régi 80/20 szabály, az ICS biztonsági ráfordítások 80%-át költik a preventív és csak 20%-át a detektív és reaktív intézkedésekre. Ma már észre lehet venni a változások első jeleit, ilyen például az EU NIS direktívája (amit már a magyar jogrendbe is beillesztettek, főként a kritikus infrastruktúra védelméről szóló illetve ahhoz kapcsolódó törvényekbe illesztve).
Az ICS rendszerek esetén az incidensek észlelése és elhárítása különböző okok miatt egyszerre lehet nehezebb és könnyebb, mint az ügyviteli IT rendszerek esetén.
Könnyebbséget jelenthet az ICS rendszerek relatív statikussága, mert ez a körülmény könnyebbé teheti a nem engedélyezett változtatások mielőbbi felfedezését és így a támadók tevékenységének minél korábbi észlelését. Ha az IT/IT biztonsági és OT szakterületek közötti kommunikáció és együttműködés magas szintű, az incidenskezelés során a szokásosnál több és az adott rendszert mélyebben ismerő szakértői csapat állhat a szervezet rendelkezésére.
Nehézséget jelent ugyanakkor a tény, hogy az ügyviteli IT rendszerek esetén már egy ideje használt incidenskezelési eljárások egy része az ICS incidenskezelés során nem vagy csak jelentős változtatásokkal használható. Vegyük példának a malware-fertőzés esetét, az ügyviteli hálózatok esetén a fertőzött számítógéppel kapcsolatos első tevékenység az adott számítógép fizikai leválasztása a hálózatról, igaz? Nos az ICS incidenskezelést oktató tanfolyamok (pl. ez) ennél több mérlegelést javasolnak, az incidenskezelő csoportra illetve az azt vezető menedzserek döntésére bízva, hogy az adott incidens kockázatait (úgy a biztonsági, mint az üzembiztonsági kockázatait) mérlegelve végül szabad-e eltávolítani az adott ICS berendezést a hálózatról vagy produktív működés közben kell eltávolítani az adott kártékony kódot.
Egy másik problémás pont az ICS rendszerek és berendezések esetén a naplózási kapacitásaik véges természete, jellemzően sokkal rövidebb időtáv logjait képesek tárolni, mint az ügyviteli IT rendszerek és mostanáig az ICS rendszerek és berendezések SIEM-integrációja sem számít mindennapos gyakorlatnak.
Az ICS incidenskezelés területén a legfontosabb tevékenység a felkészülés. Mivel az ICS rendszerek esetén gyakran rendelkezésre áll szimulátor vagy labor körülmények között üzemelő rendszer, ami sok tekintettben hasonlít a produktív rendszerre, ezeket (az OT és IT biztonsági területek megfelelő együttműködése esetén) fel lehet használni olyan incidenskezelési felkészülés tesztekre, ahol az érintett, különböző területekről bevont szakemberek üzembiztonsági kockázatok nélkül tudják gyakorolni az incidenskezelési folyamatban rájuk osztott feladatokat. Az ilyen felkészítő gyakorlatok nagyon fontosak, egy éles incidens elhárítása során a különbséget jelenthetik siker és kudarc (és annak következtében egy jelentős üzemzavar) között.
A második legfontosabb lépés az incidensek felfedezése, ami jelenlegi ismereteink szerint az egyik legnehezebb feladat. Az ügyviteli IT rendszerek esetén évekkel ezelőtt még 400 napnál magasabb volt az átlagos IT biztonsági incidensek felfedezésének ideje és ez még ma is valamivel 200 nap felett van. Az ICS biztonsági incidensek esetén ezek a számok jellemzően jóval magasabbak (a Stuxnet, a Duqu és más, feltételezhetően titkosszolgálati hátterű csoportok által végrehajtott támadások akár évekig is észrevétlenek maradtak, de a 2015-ös ukrán áramszolgáltatók elleni támadást is 9 hónapnyi felderítő tevékenység előzte meg az érintett szervezetek hálózataiban). Az incidensek észlelése során kiemelten fontos feladat a rendellenes hálózati forgalmak és események felismerése és helyes kategorizálása, ehhez még ma sem állnak rendelkezésre olyan műszaki megoldások, amivel jelentős és komoly tapasztalatokkal rendelkező biztonsági (és OT - nem lehet eleget hangsúlyozni az IT-OT együttműködés fontosságát!) szakértők bevonása nélkül lehetne hatékonyan felismerni az ICS rendszerek elleni támadásokat.
Az incidenskezelés következő lépése a felfedezett támadás behatárolása, ami az ICS rendszerek esetén megint egy érzékeny pont lehet, mert egy incidensre adott túlzott reakció nagyobb károkat okozhat az ICS berendezések által vezérelt fizikai folyamatokban, mint maga a biztonsági incidens (pl. egy bitcoin-bányász malware által fertőzött számítógép performancia-vesztése okozhat nehézségeket az adott szervezetnek, de vajon a csökkentett funkcionalitás vagy az adott számítógép teljes elvesztése jelent nagyobb kockázatot?).
A támadás nyomainak felszámolása és az üzemszerű működés helyreállítása a következő tevékenység, ami szintén jelenthet nehézségeket, ilyen például a rendszeresen elkészített mentések (ha készülnek) ugyancsak rendszeres ellenőrzése, tesztelése - gondolok itt nem csak maguknak a mentéseknek a tesztelésére, hanem a mentések helyreállítási folyamatainak a tesztelésére, hiszen egy mentés önmagában semmit nem ér, ha a mérnökök, akiknek abból helyre kell állítaniuk egy rendszer működését, nem tudják pontosan mi is a feladatuk - egy ilyen szituációban még a legjobb esetben is a feltétlenül szükséges leállási idő többszörösére lehet szükségük, rosszabb esetben nem lesz teljesen sikeres a helyreállítás.
Az utolsó tevékenység az incidenskezelési folyamat során szerzett tapasztalatok értékelése és az ebből tanultak beépítése az incidenskezelési eljárásokba, majd a módosított tervek újratesztelése.
Ahogy a fentiekből is látszik, a ICS incidensek sikeres kezelésének két fontos része van, a teljes incidenskezelési ciklus rendszeres tesztelése és a tanultak alkalmazása valamint a minél szorosabb és hatékonyabb IT-OT együttműködés.
