Ochrana řídících systémů distribučních sítí
Pro monitoring a řízení distribučních procesů v sítích jsou požívány systémy známé jako SCADA (Supervisory Control and Data Aqusition). Umožňují centralizovat dohled a řídit prvky distribuční sítě jako jsou ventily, pumpy, pohony a další, bez nichž by dodávka energií a médií odběratelům nebyla možná.
Tyto řídící systémy se zpočátku vyvíjely většinou odděleně od zbytku ICT infrastruktury distribučních společností. Převažovaly také (proprietární) komunikační protokoly, které lépe reflektovaly deterministickou povahu řídicích systémů. Vývoj však postupně vede k takovému začleňování SCADA do IT architektury společností, jehož výsledkem je jak rozšíření funkcionalit, tak vyšší robustnost řešení a jeho interoperabilita. Nechtěným důsledkem otevřené architektury systémů je ale zvýšená možnost napadení z vnějšího i vnitřního prostředí.
Obecně se při řízení bezpečnosti informačních aktiv berou v úvahu tři hlediska – dodržení důvěrnosti, integrita a dostupnost. V případě SCADA je zřejmě primárním hlediskem zajištění dostupnosti služby, tedy toho aby bylo možné prostřednictvím systému ovládat technologická zařízení.
Příklady incidentů
Incidenty o nichž byly zveřejněny alespoň nějaké informace ukazují, že výpadky bývají způsobeny právě využitím bezpečnostních slabin vyplývajících z nemožnosti systém plně oddělit. Zde je přehled několika známých událostí, které byly zveřejněny:
-
2009 - Integral Energy (Austrálie) – bylo napadena virem celá podniková síť, což mělo za následek nutnou reinstalaci více než jednoho tisíce desktopů, aby byla nákaza izolována od řídícího systému
-
2009 - Zdravotnické zařízení, Texas (USA) – utočník převzal kontrolu nad klimatizačním systémem
-
2005 – Mezninárodně operující energetická společnost – malware infikoval SCADA, důsledkem bylo zneschopnění funkce bezpečnostního protokolu
-
2003 – Atomová elektrárna Davis – Besse, Ohio (USA) - selhání bezpečnostního systému způsobilo výpadek na dobu delší pěti hodin
-
1998 – Gazprom (Rusko) – hackeři převzali kontrolu nad plynovodem dodávajícím do Evropy pomocí trojského koně
Hlavní hrozby, jimž je nutné čelit
Z výše uvedeného krátkého přehledu lze dovodit následující možnosti útočníka: využití viru resp. trojského koně nebo červa, které bylo v letech 2004-2008 nejčastějším typem útoku, či neautorizovaný přístup k zařízení tzv. spoofing nebo přímo hacking. Použití různých metod útoků však může mít souvislost s cíli útočníků. Ty mohou být různé, počínaje cíleným vyřazením protivníka v politickém nebo obchodním sporu a konče pomstou nespokojeného zaměstnance. . Současně je nutné připustit, že statistiky jsou v tomto směru značně neúplné. Lze přepokládat, že zprávy přinejmenším o části incidentů nebyly publikovány, což lze vysvětlit ekonomickými zájmy operátorů.
S těmi však souvisí další, zatím neuvedené hrozby. Vzhledem k tomu, že SCADA dodávají data z měření, na jejichž základě je prováděna např. fakturace, má funkčnost systému přesah i tímto směrem. Na druhé straně nelze přehlédnout i nutnost ochrany sbíraných a transferovaných dat, například data o objemu odběrů. Jejich případná krádež může mít podstatný reputační dopad v případě dodavatelů maloodběratelům. Napadení dat s cílem jejich modifikace nebo narušení jejich integrity pak má jednoznačné ekonomické důsledky spojené i s možným selháním obchodních procesů. Ochrana SCADA tedy zahrnuje nejen ochranu samotného systému, ale rovněž dat, která jsou využívána navazujícími aplikacemi zpracovávajícími např. vyučtování. V konečném důsledku tak jde o ochranu stavu fundamentálních ukazatelů zveřejňovaných ve výročních zprávách.
Jak minimalizovat rizika?
Co můžeme tedy udělat abychom minimalizovali rizika spojená s provozováním řídících systémů? V první řadě je třeba si uvědomit, že infrastruktura řídicích systémů se i přes značnou konvergenci s podnikovými systémy jen obtížně integruje se standardními bezpečnostními technologiemi a procesy jako je např. IDS/IPS, antivirus, šifrování nebo patch management. Jakýkoli neuvážený pokus o implementaci těchto řešení a procesů by totiž v konečném důsledku mohl vést ke zpomalení systémů, zvýšení latence nebo dokonce i k výpadku a odstavení technologického celku.
Proto je nutné při implementaci těchto bezpečnostních opatření postupovat odlišným způsobem, než je tomu v případě běžného nasazení. Řídící systémy jsou totiž již od počátku navrženy primárně s požadavkem na vysokou stabilitu. Používají proto např. specializované průmyslové protokoly, které kladou vysoký důraz na interoperabilitu a efektivitu přenosu dat a přitom velmi často opomíjejí (mnohdy i záměrně) bezpečnostní prvky a Zároveň s tím jsou však tyto systémy stále častěji provozovány na standardních operačních systémech Unix a Windows a pro síťovou komunikaci vyžívají rodinu protokolů IP. Tím tedy na druhé straně dochází ke sbližování se standardním podnikovým ICT.
Kromě nasazení řady procesních a organizačních opatření, jako je například definování jasných pravidel pro přístup externích subjektů k technologii prostřednictvím VPN, je tedy nutné komplementárně zvolit i vhodnou strategii implementace technologických opatření. Ta by měla být vybrána s ohledem na již zmiňovaná specifika infrastruktury řídících systému. Tato specifika pak mohou v konečném důsledku vyústit například v zavržení implementace standardního podnikového antiviru a preferování jiného méně invazivního řešení detekujícího virové hrozby jiným způsobem (např. na síťové vrstvě), a to se znalostí specializovaných průmyslových protokolů a aplikací.
Komplexní architektura, propojenost a požadavky na vysokou dostupnost řídicích systémů vyžadují, aby si organizace vytvořily akční plán pro zmírnění zranitelností a bezpečnostní hrozeb. A to nejen kvůli zachování vysoké dostupnosti a spolehlivosti kritické infrastruktury, ale i s ohledem na naplnění nových průmyslových standardů (např. NERC CIP, ISA-SP99 nebo AGA 12) a legislativních požadavků. Jen tak je možné i do budoucna zachovat stávající vysokou dostupnost a spolehlivost distribuční sítě a kritické infrastruktury vůbec.
Jan Vachuda a Jiří Kaplický, specialisté na informační bezpečnost společnosti Logica