Specifika aktualizaci v OT

Aktualizace OT proti nově zjištěným zranitelnostem mají svá specifika, stručné informace k této problematice.

Udržení OT v aktualizovaném stavu opravdovou výzvou. Pokud je uvažována životnost OT 15 a více let, je třeba vzít v úvahu postupné zastarávání použitých prostředků, zejména IT. 15 let je pro operační systém velmi dlouhá doba a většinou přestane postupně být podporován. A jeho přeinstalace sebou nese řadu problémů. Často vlastní technické oddělení nemá dostatek prostředků a znalostí pro provedení aktualizací a je třeba využít dodavatele.

Aktualizace OT tedy patří k nejvíce nákladným opatřením kybernetické bezpečnosti v OT. Bohužel se jedná také o opakující se nikdy nekončící činnost. Nové zranitelnosti se objevují stále.

Informace o zranitelnostech je možno se dozvědět od výrobce, ICS-CERTu, médií nebo upozornění na významné zranitelnosti bývá i na stránkách NÚKIB.

Neexistuje standardizovaný formát publikování aktualizací a záplat. Někteří výrobci je zveřejňují na svých webových stránkách, někteří o nich informují pomocí e-mailu a lze se setkat i s přístupem, kdy instalace záplaty způsobí zánik záruky. Ideální je dosažení co největší automatizace, kdy systém zprávy aktiv automaticky informuje o všech nových zranitelnostech, které byly objeveny pro používané OT.

Obvykle ale bývá problematické identifikovat, zda se konkrétní objevená zranitelnost týká i provozovaného OT a je tedy nutné ho aktualizovat. Je tedy vždy nutné identifikovat verzi provozovaného firmware a funkce, které jsou používané. Například pokud se zranitelnost týká webového rozhraní, které máte vypnuté.

Samotné aktualizace nezajistí bezpečnost OT. Řada komunikačních protokolů v OT nebyla navržena s ohledem na kybernetickou bezpečnost a neumožňuje spolehlivou autentizaci účastníků komunikace. Pokud tedy získá útočník přístup k síťovým prostředkům nebude mu nic bránit v jeho činnosti. Problémem velkého množství zejména starších zařízení je náchylnost na přetížení svého komunikačního rozhraní. Velkým problémem bývají webové servery umístěné na PLC.

Zásady pro provádění aktualizací v OT

• Mít vytvořený proces pro stanovení významu aktualizace, její kompatibility a určení času, který bude zavedení aktualizace vyžadovat. Stejně tak je nezbytné mít definováno postupy pro testování aktualizací, jejich nasazování, případný návrat k předchozí verzi a kontrolu systémů po provedení aktualizací. Ideální je mít na testování aktualizací vyčleněný zvláštní testovací systém, bohužel to není ve většině případů možné pro příliš vysoké náklady na jeho vybudování systému.

• Pro identifikaci a určení vlivu na OT mít dobrou dokumentaci:

  • zaznamenaný veškerý používaný software včetně verze produktu a nainstalovaných záplat.
  • kompletní dokumentaci hardware tj. evidovat typ, model, verze firmware atd.

• Aktualizace důsledně plánovat. Často se provádí jen jednou nebo dvakrát ročně, protože častěji to pro ně není možné zrealizovat.

• Nepoužívat používat automatické aktualizace. Není možné jen tak resetovat řídicí systém. Většina OT běží 24 hodin denně, 7 dní v týdnu a není možné jejich chod přerušit kvůli instalaci bezpečnostní aktualizace nebo nové verzi firmware.

• Důsledně provádět kontrolu aktualizace. Každá oprava nebo aktualizace firmware musí být také zkontrolována na kompatibilitu s nainstalovanými aplikacemi a knihovnami. Instalace záplaty nebo aktualizace může vyvolat nechtěný vedlejší efekt jehož důsledkem může být přerušení výroby. V mnoha provozech aktualizace odpovídá procesu řízení změn a je třeba, aby byla schválena.

• Ověřit vždy kompatibilitu všech používaných OT s novým operačním systémem. Často si nový operační sytém vyžádá novou verzi OT a s tím i další HW. Je třeba také ověřit zda jsou konfigurační soubory nových verzí software navzájem kompatibilní.

• Vytvořit si standardizované konfigurace a referenční architektury a snažit se je využívat, všude, kde je to možné. Například mít stejnou konfiguraci pro inženýrské stanice, HMI a operátorské stanice. Rozšířením těchto standardizovaných stanic dojde k usnadnění následného testování aktualizací a záplat, nebude již třeba testovat tolik různých variant systémů.

Situaci ale nelze zjednodušit a prohlásit, že aktualizace se nevyplatí pro špatný poměr cena/výkon, ale je třeba postupovat systematicky. Zaměřit se na nejdůležitější části systému a snažit se modernizovat zařízení využívající zastaralé mechanizmy. Je vhodné upřednostnit aktualizace nejvíce exponovaných systémů jako jsou systémy umístěné v DMZ, JUMP servery a firewally. Jelikož jsou toto především IT systémy lze očekávat, že jejich aktualizace nebudou mít tak drastické nároky na testování a tedy i čas.