Sok más egyéb különbség mellett a patch-ek telepítése az egyik legkarakteresebb különbség az ICS/OT és az IT rendszerek között. Persze tudjuk, hogy az IT rendszerek esetében is gyakorta elmarad a szoftveres javítócsomagok telepítése, de ott ez (ma már) egy elismerten rossz gyakorlat és senkinek nem ajánlják ezt, míg az ICS/OT rendszerek esetén mind a mai napig megszokottnak számít, hogy

a) a hibajavításokat egyáltalán nem telepítik;
b) a javításokat csak a gyártó előzetes, írásos hozzájárulása után telepítik (mert a gyártó jóváhagyása nélkül telepített szoftverek, akár a hivatalos, Microsoft Windows patch-ek telepítése a gyártói garancia azonnali elvesztését eredményezhetik);

Látható tehát, hogy még ha az adott szervezet ICS/OT rendszereiért felelős kollégák értik a szoftveres javítások telepítésének fontosságát és szándékukban áll azokat mielőbb telepíteni, még ebben az ideális esetben is jóval lassabb lehet a patch-ek telepítése, mint egy átlagos IT rendszer esetén. A kérdés már csak az, hogy milyen lehetőségeink vannak akkor, ha bármilyen ok miatt nem vagy nem kellően gyorsan tudunk patch-elni egy ICS/OT rendszert?

Ezt a témát járja körbe az isa.org-on megjelent cikkében Stephan Venter (Linux evangelista és TuxCare-publicista).

Stephan első, témába vágó tanácsa (Linux-os kötődésére emlékezve nem igazán meglepő módon) a live patch-ing lehetőségének mérlegelése, ami azonban egyrészt csak Linux operációs rendszereket futtató ICS/OT rendszerek esetén létezhet, mint lehetőség, másrészt én személy szerint kíváncsi lennék, hogy melyik ICS gyártó fog jóváhagyást adni egy éles folyamatirányító rendszer üzem közben live patch-elésére (főleg, ha ez a frissítés egy kernel patch-et is tartalmaz)? Fogalmazzunk úgy, hogy nem számítok túl nagy tolongásra a gyártók között...

A többi tanács már jóval konzervatívabb (és - szerintem legalább is - realistább):

- eszköz (hardver- és szoftverleltár) és priorizálás;
- biztonságos ICS/OT/IoT architektúra modellek (Purdue, Gartner IoT reference architecture vagy az ENISA IoT security baseline ajánlása) alkalmazása (ez mindenképp hasznos tanács, de az én tapasztalataim szerint már üzemelő ICS/OT rendszerek Purdue- vagy egyéb referencia architektúra modellhez hasonló architektúrára történő átalakítására ritkán és csak hosszabb átmenet eredményeként szokott lehetőség nyílni, szóval egy sürgősen telepítésre váró, kritikus hibát javító patch telepítése esetén nem biztos, hogy ez a leggyorsabb megoldás);
- az alkalmazások fehérlistázása (vagyis csak az ismert és bizonyítottan nem kártékony alkalmazások futtatásának engedélyezése);
- monitoring megoldások és eljárások, biztonsági naplózás és incidenskezelési eljáráok kidolgozása és bevezetése.