Počítače řídící průmyslové systémy (ICS, SCADA…) představují z hlediska zabezpečení speciální problém. Jak by se podniky měly postavit k souvisejícím rizikům?
Na jednu stranu se řídící počítače stále nacházejí v relativně izolovaném prostředí: nemusejí být přímo připojeny k Internetu (ovšem jsou-li připojeny k síti, malware se sem stejně dokáže dostat oklikou) a nepoužívají se k běžné práci (takže na rozdíl od PC zaměstnance sem třeba nepronikne malware po otevření přílohy e-mailu – alespoň ne přímo).
Na straně druhé má ale ovládnutí řídicích počítačů pro útočníky velkou cenu. Systémy ICS a SCADA bývají kritické, zajímavé jsou z hlediska průmyslové špionáže, destrukce klíčových procesů (kybernetická válka) a nově také jako výnosný cíl pro ransomware. Navíc počítače pro řízení průmyslových systémů (výroba, energetika, utility…) často fungují ve zvláštním režimu, kdy se neaktualizují (raději nevrtat do toho, co musí fungovat) a IT oddělení je nespravuje, eventuálně o nich ani prakticky neví. Sice zde nejsou spouštěny běžné aplikace – jako hlavní bezpečnostní riziko na většině PC – ale kromě často zastaralých operačních systémů může být zdrojem zranitelností zase specializovaný software (o němž v celém podniku opět nikdo skoro nic neví).
Speciálně rizika průmyslových systémů a aktuální situaci v této oblasti shrnuje studie iSIGHT Intelligence bezpečnostní firmy FireEye. Především se zde upozorňuje, že v softwaru pro systémy ICS se nachází stále větší množství zranitelností. Neznamená to, že by se kvalita tohoto softwaru nějak zhoršovala, ale že se o příslušný segment zajímá stále větší množství výzkumníků (což logicky znamená i více exploitů v rukou útočníků, více informací o zranitelnostech obchodovaných na černém trhu, v archivech tajných služeb/vojenských institucí apod.).
Analýza mj. zdůrazňuje následující problémy:
Protokoly používané pro komunikaci ICS systémů často postrádají šifrování a autentizaci. Kdokoliv tak může systém ovládnout, stačí mu specifická znalost (security by obscurity) a přístup k místní síti nebo i jen příslušné komunikační infrastruktuře. Podniky by samozřejmě měly zavést ověřování všude, kde to zvládají technicky a kde se tím neohrožuje funkčnost systému (např. v důsledku zvýšené latence tam, kde je prioritní okamžitá reakce). K počítačům řídícím průmyslový provoz by se mělo přistupovat přes VPN a měly by být umístěny za firewally podporujícími hloubkovou inspekci paketů. Pravidla firewallů by měla být nastavena i s ohledem právě na systémy ICS. Souvisejícím problémem je pak implementace hesel, často jsou v těchto zastaralých systémech ukládána v otevřené podobě, tímto způsobem přenášena atd. Zde opět pomůže pouze monitoring síťového provozu. Speciálně je pak třeba konfigurovat ochranu přístupu u systémů PLC.
Zastaralý hardware systémů ICS může usnadňovat třeba útoky na odepření služby. Pro zasíťované prostředí představují takové systémy riziko hned z několika důvodů (včetně toho, že i běžný síťový provoz může narušovat jejich fungování), částečným řešením je ochrana síťové komunikace firewallem.
ICS systémy často nepodporují žádné systémy digitálních podpisů/certifikátů ani integrity souborů. Nelze pak zaručit, zda instalovaný software není zcela podvržen nebo nebyl na cestě od dodavatele pozměněn. Útočník může do systému propašovat vlastní knihovny nebo ovladače. FireEye v této souvislosti doporučuje, aby spouštění pouze podepsaného kódu bylo implementováno ne na vrstvě ICS, ale přímo na operačním systému příslušného zařízení (a dále zde nastaven whitelist, tj. povoleno spouštění pouze určených aplikací). Fungování veškerého softwaru, který se takto nasazuje, by se nejprve mělo vyzkoušet v simulovaném prostředí – a to i když malware dokáže různě skrývat své funkce, pokud např. zjistí, že je spuštěn ve virtuálním stroji. Taktéž lze doporučit spolupráci s dodavatelem, která umožní získat soubory hash, a provést příslušnou kontrolu třeba i ručně.
O zastaralých operačních systémech (dále nepodporované verze Windows apod.) je třeba podle doporučení FireEye přinejmenším vědět a mít plán, jak problém postupně omezovat a upgradovat. Vyplatí se i provádět různé dodatečné bezpečnostní operace, alespoň skenování proti známým a nejčastěji zneužívaným zranitelnostem nebo bezpečnostním chybám specificky vztaženým k ICS.
ICS systémy často nemají jediného dodavatele, respektive ten často není totožný s původním tvůrcem softwaru. V důsledku toho se pak podnik nedozví o objevu zranitelnosti, eventuálně mu v rámci komplikovaného ekosystému nemá kdo doručit opravu. Zákazník může v reakci na to např. požadovat, aby při implementaci získal přehled o softwaru třetích stran, který je zde použit, a to včetně open source kódů. Pak lze mj. sledovat databáze zranitelností i zdroje příslušných dodavatelů. Jednou z možností je také smluvně vyžadovat, aby hlavní dodavatel zajistil distribuci záplat, včetně oprav od třetích stran (a včetně kontroly interoperability), eventuálně aby o zjištěných zranitelnostech či opravách alespoň pravidelně informoval.
Zdroj: Computerweekly.com a další
