Kybernetická bezpečnost hraje v systémech řízení budov čím dál větší roli. Bohužel je obvykle řešena až při implementaci, kdy se potkávají konečný zákazník (provozovatel) a dodavatel řídicího systému. Základní bezpečnostní vlastnosti by však měly být definovány již ve fázi projekční, nejpozději v realizačním projektu. Projektanti se většinou vymlouvají na to, že nemají partnera, s nímž by tyto požadavky řešili – stavební firmu to nezajímá a provozovatel (nebo jeho odpovědný pracovník) ještě není znám. To ale neznamená, že projektant by si neměl být bezpečnostních aspektů vědom a že by je neměl aspoň v nějaké základní podobě v projektu sám od sebe zohlednit. Podívejme se na klasickou topologii řídicího systému z bezpečnostního hlediska a pojďme najít několik pravidel, podle nichž by řídicí systém měl být projektován a instalován tak, aby byl schopný úspěšného předání provozovateli z hlediska kyberbezpečnosti – a zároveň se dal komfortně a účinně provozovat a servisovat.
Jako první narazíme na ČSN ISO/IEC 27001 a navazující, Informační technologie – Bezpečnostní techniky – Systémy řízení bezpečnosti informací. Tato skupina norem ale pojednává spíše o organizaci procesů a hodnocení opatření, pro projektování v ní mnoho nenajdeme. Zajímavější je ČSN EN IEC 62443, která v části 3-3 definuje bezpečnostní úrovně (Security Levels, SL) a požadavky na ně. Při podrobnějším průzkumu zjistíme, že prakticky žádný řídicí systém budov sám o sobě (nemluvíme zde o průmyslových systémech!), dostupný na trhu, nenabízí ani vlastnosti požadované základní úrovní SL 1. Při dalších úvahách se tedy pokusíme síťovou bezpečnost maximalizovat pomocí standardních prostředků, tak, aby investiční i provozní náklady na systém MaR byly navýšeny jen minimálně nebo raději vůbec ne.
Periferní zařízení, jako jsou čidla, ventily, pohony klapek a další komponenty řídicího systému, lze obvykle chránit pouze „polohou“. Prvky by měly být umístěny tak, aby se minimalizoval možný cizí zásah nebo poškození. U periferií instalovaných ve strojovnách problém nenastane, horší je to s pokojovými ovladači ve veřejně přístupných prostorech (chodby, kanceláře) nebo dokonce s venkovními čidly namontovanými na fasádě. Při poškození pokojového čidla, ovladače nebo termostatu je naštěstí postižena pouze jedna místnost či zóna a ztráta komunikace nebo přerušení signálu by se měly objevit na centrále jako alarm. Poškození venkovního čidla může již mít zásadní vliv na chování otopného systému, proto by vybočení signálu (způsobené přerušeným vedením či zkratem) mimo rozumné meze mělo být nejen hlášeno jako alarm, ale také ošetřeno v programu, například zapsáním „bezpečné“ hodnoty (např. 5 °C), která aspoň v zimě zaručí nouzový, byť ne energeticky optimální chod zařízení.
U termostatů, zejména bezpečnostních (ohřev vody, havarijní termostat na výměníku atd.), preferujme interní nastavení požadované hodnoty před ovladačem na krytu.
Rozvaděče umístěné ve veřejně přístupných prostorech by měly být zamykatelné (klíčem, ne jen standardní kličkou) a jejich čelní panely by měly obsahovat minimum ovládacích prvků. Mějme na paměti, že v rozvaděči obvykle je i PLC a switch, který již umožňuje přístup do celé technologické sítě nebo dokonce do sítě firemní.
Mezi periferní zařízení se někdy počítají i sběrnice se zónovými regulátory. Zkrat sběrnice vyřadí z provozu celou linku, rozpojení znamená ztrátu komunikace pro část sběrnice za poruchou. Rozpojení však může vyřadit z provozu celou linku, pokud je sběrnice citlivá na chybějící ukončení zakončovacím členem nebo odporem (např. u sběrnic LON či RS485). Při projektování se proto snažíme připojit zařízení mimo rozvaděč na samostatný komunikační port (u markMX nejčastěji COM4) a I/O moduly, umístěné v rozvaděči, na druhou linku (COM3). Tak při poruše sběrnice zůstane zachována alespoň komunikace s I/O moduly v rozvaděči.
Zde již je situace kritičtější, protože procesní podstanice (PLC) mají rozhraní Ethernet a jsou tedy připojeny do technologické sítě nebo vnitřní sítě budovy, což bývá nejčastější cesta, kterou je veden útok. Zároveň obsahují řídicí algoritmy, jejichž poškození nebo napadení má zásadní vliv na funkci budovy, včetně fyzických dopadů - řízení motorů, klapek, ventilů atd. a zejména navazujících technologií. Zároveň ale můžeme pro zabezpečení použít organizační pravidla i technické prostředky, které známe z IT prostředí, což nám zjednodušuje práci. Obvykle nastane jedna z těchto situací:
1. Systém řízení budovy v samostatné technologické síti
V případě topologie podle bodu 1, tedy když PLC a případně další IP zařízení mají samostatnou technologickou síť, musíme vyřešit propojení s intranetem budovy. V projektu by mělo stačit vyspecifikovat router (postačí např. Mikrotik řady RB2011 nebo dokonce hEX), případně po dohodě s IT technikem zákazníka jiné zařízení. U routeru změníme administrátorské heslo. Lze i domluvit, že router si dodá zákazník, aby udržel jednotný systém pro společnou správu aktivních prvků.
2. Komponenty systému řízení budovy jako součást sítě zákazníka
Pokud plánujeme systém podle bodu 2, počítejme s možnými problémy při koexistenci IT zařízení zákazníka a komponenty MaR. Několikrát jsme se setkali se závadami, kdy PLC „náhodně“ zamrzalo, vypadávala komunikace mezi PLC navzájem a podobně. Příčinou byl například zapnutý spanning tree protokol na switchích zákazníka, který zřejmě ethernetové rozhraní v PLC neumělo dobře zpracovat. Diagnostika je složitá, protože k poruše dochází jen občas. Můžeme jako projektanti podobným potížím předejít?
Z projekčního hlediska by bylo nejlepší kontaktovat budoucího provozovatele, zjistit jeho přístup k otázkám propojování technologické sítě s intranetem a podmínky zohlednit v technické zprávě, případně v topologii řídicího systému. U některých projektů je to naprosto zásadní krok. Typicky jde o řetězce poboček (obchody, banky) s vlastní IT infrastrukturou a IT oddělením, které se řídí pravidly nadnárodního vlastníka. V těchto případech je domluva sice zdlouhavá, ale pracujeme s kompetentním partnerem, s nímž máme společný zájem. Proto se řešení většinou podaří najít, připravme se však na to, že systém MaR bude muset splňovat několik podmínek:
Častým bodem střetu je zasílání alarmových e-mailů. Pro jejich odesílání musí PLC nebo centrála mít přístup na mail server. Provozovatel tedy musí na svém mail serveru zřídit uživatelský účet, který bude pro odesílání pošty využíván. Přístupové údaje pak sdělí dodavateli MaR, aby odesílání alarmů mohlo být nastaveno. Příslušná centrála nebo PLC zároveň musí mít přístup na internet. Tyto požadavky je opět vhodné mít v technické zprávě projektu, dodavatel MaR je pak do jisté míry chráněn. Používání freemailových služeb se v prvním plánu snažíme vyhnout.
Akce se nesmí dostat do stavu, kdy nasmlouvanou, prodanou a zaplacenou funkci není možné aktivovat a předat zákazníkovi. Dodavatel pak není schopen zařízení předat a odběratel má výborný důvod k zadržování plateb („to jste si měli zjistit / domluvit předem“). Zejména u veřejných zakázek nebo dotačních titulů, kdy je třeba přísně dodržovat zadání, se můžeme dostat do velmi obtížně řešitelné situace.
Zde najdeme obslužné počítače – klientské stanice SCADA, servery pro ukládání dat, webové servery pro vizualizaci atd. Jedná se vesměs o hardware na bázi osobních počítačů. Základní ochrana spočívá v rozumně nastavené uživatelské politice a pravidelné údržbě. Největší riziko je obvykle na straně uživatele, zde pomůže snad jen provozní předpis, důkladné školení a hrozba sankcí. Co se týče zálohování, není ho nikdy dost, ale v zálohách musíme udržovat pořádek, aby disk nebyl plný adresářů s názvy „poslední verze“, „nemazat“, „staré“, „záloha_nechodí“ atd. To je ale již spíše problém provozu a servisu. Projektant by měl po domluvě s dodavatelem MaR vyspecifikovat PC s potřebnými hardwarovými parametry (zejména velikost paměti RAM a disku) a určit umístění hardwaru. Je chyba, když počítač s databází uložených hodnot desetiletého provozu systému s několika tisíci datových bodů najdeme zaprášený někde pod stolem. Pro servery je i s ohledem na spolehlivost a životnost vhodná klimatizovaná místnost, která zároveň poskytuje fyzické zabezpečení; dnešní budovy již vyhrazenou serverovnu mají.
Některé služby jsou dnes již zcela virtualizovány. Znamená to, že pro jejich chod potřebujeme využívat zdroje (PC, úložiště), o jejichž fyzickém umístění nic nevíme a na něž přistupujeme výhradně pomocí sítě Internet. Jde o ukládání historických dat, portály pro servis a diagnostiku, webové portály pro obsluhu na dálku atd. Toto může být v rozporu s bezpečnostní politikou zákazníka, proto při projektování musíme zjistit, zda uvažovaný systém virtuální zdroje využívá, a pokud ano, zda to je zákazníkem akceptovatelné.
Souvisejí s tím i provozní náklady cloudového řešení. Ty mají sice málo společného s bezpečností, ale jelikož se tento problém objevuje čím dál častěji, považuji za nutné je v projektu aspoň zmínit. Ve výkazu výměr by projektant měl uvést jednak jednorázové náklady na instalaci, jednak měsíční nebo roční náklady na provoz služby. Pokud je v zadání výslovně specifikováno nějaké období, po které má být služba zaručena, uvedeme tyto náklady jako samostatnou položku (např. „přístup na webový portál MyCloudAccess pro 1000 datových bodů po dobu dvou let“). Generální dodavatel pak nese náklady po tuto dobu v rámci dodávky, následně přechází povinnost platby na zákazníka – provozovatele.
Velmi zajímavá situace nastane, když jsou pro komunikaci použity bezpečnostní certifikáty a klíče. Tyto prostředky mají omezenou platnost. Doménové certifikáty (používané např. pro zabezpečený přístup, bez kterého dnes již některé prohlížeče odmítají zobrazit data z webového serveru) například nelze vydávat na delší období než 27 měsíců. V praxi to znamená, že těsně po skončení záruky může vizualizace nebo výměna dat mezi PLC přestat fungovat. Zákazník buď musí předem vědět, že je nutné certifikáty obnovit, a obnovu si objedná, nebo musí mít uzavřenou servisní smlouvu s dodavatelem systému. Existují sice systémy pro automatickou aktualizaci certifikátů, ale i ty je nutné spravovat. Vzniká tak nový obchodní model, v němž může mít zákazník pocit, že se stává jakýmsi rukojmím odsouzeným k trvalým platbám. Je potřeba mu vysvětlit, že jde o nutnou údržbu, vyplývající z principů zabezpečení. To s sebou nese nové nároky na dodavatele řídicího systému i na jeho projektanta.
Shrňme tedy základní pravidla pro projektování bezpečných systémů v několika bodech:
Technologie se rychle mění a pokud chceme, abychom i v budoucnu byli schopni odvádět kvalitní projekční práci, musíme si udržet odbornou kompetenci. Uvidíme, že čas strávený „zvyšováním kvalifikace“ se nám několikanásobně vrátí, protože nebudeme muset následně řešit nepříjemné spory během realizace.
