Penetrační testování průmyslových systémů (OT/ICS)

Rozdíl je v tom, co se stane při chybě. Na webovém serveru aktivní sken najde chybu a nanejvýš spadne služba, kterou restartujete. V OT může tentýž sken nebo pokus o zneužití shodit živý PLC, tedy programovatelný automat, který řídí výrobní proces, a zastavit linku nebo ohrozit bezpečnost lidí u ní. Že průmyslová zařízení nemusí snést ani sken, platí obecně a je to tady důvod k opatrnosti, ne fráze.

Průmyslové systémy jsou k tomu stavěné na roky nepřetržitého běhu, ne na neobvyklý provoz. Řídicí jednotky běží roky bez restartu, mají omezenou paměť a nepočítají s tím, že jim někdo pošle nečekaný požadavek. Co IT síť ustojí, dokáže v OT vyvolat výpadek, který stojí víc než celý test. Bezpečnost provozu je proto první věc, ne až druhá po nálezech.

Neznamená to, že se OT testovat nedá. Znamená to, že se testuje jinak: víc se poslouchá a analyzuje, míň se do provozu aktivně zasahuje, a co zasáhnout musí, se dělá po domluvě a v okně, kdy to provoz unese. Tuhle disciplínu bereme jako součást profese, ne jako výmluvu. Čím se to liší od běžného pentestu, rozebírá i článek o tom, proč se OT testuje jinak než IT.

Začínáme u hranice mezi IT a OT. Purdue model, tedy vrstvené uspořádání průmyslové sítě od podnikového IT dolů k senzorům a pohonům, popisuje, kde mají být hranice mezi zónami. Díváme se, jestli tam ty hranice opravdu jsou, nebo jestli se z kancelářské sítě dá dojít rovnou k řídicím jednotkám. Samotnou drátovou IT síť pod tou hranicí prověřuje test infrastruktury, který ukazuje, kde končí IT síť a začíná OT.

Dál jdeme po průmyslových protokolech. Modbus, DNP3 a OPC přenášejí povely mezi řídicím systémem a zařízeními a řada z nich vznikla v době, kdy se s útočníkem v síti nepočítalo, takže nemají ověření ani šifrování. Sledujeme, kudy tečou, kdo do nich vidí a jestli se dá povel podvrhnout nebo odposlechnout.

Předmětem jsou i samotné komponenty a přístup k nim: konfigurace PLC a RTU, tedy jednotek, které sbírají data a ovládají procesy v terénu, stanic HMI a systémů SCADA nebo DCS, přes které operátor proces řídí, a hlavně vzdálený přístup do OT. Právě vzdálená údržba od dodavatele je cesta, kterou se do průmyslové sítě dostane někdo zvenčí.

Základ práce je pasivní. Odposloucháváme provoz na síti a analyzujeme konfigurace, aniž bychom do systémů aktivně zasahovali, takže provoz o testu neví. Z pasivního odposlechu se dá vyčíst překvapivě moc: jaké protokoly jedou, kdo s kým mluví, kde chybí segmentace a kde jdou povely bez ověření.

Aktivní kroky děláme jen tam, kde dávají smysl, a jen po schválení. Plánujeme je do servisního okna, kdy je proces odstavený nebo v režimu, který zásah unese, a jedeme je v kooperaci s vaším provozem, který má u toho ruku na vypínači. Kde existuje testovací nebo záložní prostředí, přesuneme rizikové kroky tam. Průmyslový provoz ho ale nemusí mít, a s tím počítáme.

Před každým rizikovým krokem voláme a popíšeme, co se chystáme udělat a co by se teoreticky mohlo stát. Rozhodnutí necháváme na tom, kdo za provoz odpovídá. Radši nález doložíme konfigurací a popisem dopadu než pokusem, který by ohrozil výrobu. Opatrnost tady není slabina testu, je to podmínka, aby vůbec mohl proběhnout.

IEC 62443 je mezinárodní řada norem pro bezpečnost průmyslových automatizačních a řídicích systémů. Popisuje, jak má být OT síť rozdělená do zón a spojů mezi nimi, jaké mají mít úrovně zabezpečení a co se očekává od provozovatele i od dodavatele technologií. Je to referenční rámec, proti kterému se dá měřit.

Nálezy na ni mapujeme: ukážeme, kde konfigurace nebo segmentace požadavkům normy neodpovídá a co upravit, aby odpovídala. Certifikát podle IEC 62443 přitom nevydáváme, na to je certifikační orgán; my dodáme technický pohled a kroky ke shodě. Část OT provozů navíc spadá pod regulaci, a jestli je váš provoz regulovanou službou, projdeme hned na začátku.

Rozsah drží počet lokalit, počet zón podle Purdue modelu, počet zařízení a počet různých protokolů v provozu. Jedna výrobní hala s jedním PLC je jiná práce než tři závody s vlastními SCADA systémy a vzdálenou údržbou; u OT rozhoduje počet zón a zařízení, ne počet IP adres.

Kalendářně jde o pět až deset člověkodnů a dva až tři týdny od zahájení po předání reportu. Přesnou nabídku dostanete po vymezení rozsahu, ne jako otevřenou hodinovku; cena a rozsah testu OT a ICS vychází z počtu lokalit, zón a zařízení.

Nejdřív kooperaci provozu. OT test se nedá udělat bez lidí, kteří systémy znají a mají u nich odpovědnost, protože oni vědí, co který zásah udělá a kdy je bezpečné okno. K tomu potřebujeme schéma sítě a rozdělení do zón, seznam hlavních zařízení a protokolů a kontakt na člověka odpovědného za provoz, dostupného po celou dobu testu.

Dál domluvené servisní okno pro aktivní kroky a pravidla zapojení: co se smí pasivně kdykoli, co jen v okně a co je úplně mimo, protože to provoz neunese. Tahle pravidla se dohodnou předem, ne až když test narazí na živé zařízení.

Report, ne export ze skeneru. Každý nález má popis, dopad na provoz, důkaz a konkrétní nápravu, a k tomu mapování na IEC 62443, aby bylo jasné, kterého požadavku normy se týká. Severitu řadíme podle dopadu na váš provoz a bezpečnost, ne podle obecného skóre, protože v OT může mít i zdánlivě drobná chyba na špatném místě velký dopad.

U nálezů, kde vede cesta z IT do OT nebo přímo k řídicí jednotce, popíšeme celý řetěz kroků, aby bylo jasné, proč je to riziko. Jeden retest opravených nálezů je součástí ceny, a naplánujeme ho stejně jako test tak, aby ověření nezasáhlo do provozu.