Provozování MaR z hlediska bezpečnosti
I když kybernetická bezpečnost systému řízení budovy musí být řešena dávno před začátkem provozu, tedy při projektování, instalaci a oživení, subjektem, který nese dopady všech problémů, je nakonec provozovatel.
V následujícím textu si ukážeme, jak provozní problémy a z nich vyplývající rizika a škody minimalizovat. Podrobnější technické informace pro projektanty a programátory najdete zde https://www.domat-int.com/cs/projektovani-a-instalace-mar-z-hlediska-bezpecnosti a zde https://www.domat-int.com/cs/programovani-a-konfigurace-mar-z-hlediska-bezpecnosti.
Práce provozovatele začíná už v době přebírání budovy či technologie od dodavatele nebo předchozího vlastníka či provozující firmy. Provozovatel musí nejprve zjistit následující informace a zpracovat je tak, aby je měl k dispozici – tedy uložit v papírové a (nebo) digitální podobě a zajistit jejich zálohy:
Kontakty na dodavatele MaR
Jméno a adresa dodavatelské firmy, jména, telefony, e-maily. Kontakt na servisní oddělení, neboť pozáruční péči může poskytovat jiné oddělení firmy, než které zakázku realizovalo. Pokud realizační firma není známa, můžeme se pokusit ji zjistit u výrobce systému podle sériového čísla instalovaného PLC, vstupně-výstupních modulů nebo jiného hardwaru.
Dokumentace skutečného provedení
Pokud možno co nejdříve po předání a přímo od dodavatele. V případě, že dokumentaci dodává generální dodavatel nebo dodavatel nadřazeného celku, skutečné provedení nemusí být úplné nebo aktuální. Doporučuje se vždy ověřit aktuálnost podkladů s firmou, která řídicí systém uváděla do provozu.
Fyzické vazby na okolí
Sem patří dokumentace s umístěním periferií a dalších zařízení a jejich dostupností. Týká se to např. komunikačního rozhraní pro připojení k Internetu, ale i vedení sběrnic, síťových zásuvek napojených na technologickou síť – a důležitá věc: kdo má od příslušných místností či rozvaděčů klíče.
Digitální vazby na okolí
Tím myslíme závislost řídicího systému, resp. jeho požadovaných funkcí, na vnějších zdrojích a službách:
- Je nutná konektivita do Internetu? Kdo ji zajišťuje?
- Vyžaduje systém nějaké cloudové služby? Jaké?
- Odesílá data do externích databází? Pokud ano, jak je služba smluvně zajištěna?
- Využívá pro zasílání alarmů e-mail? Pokud ano, přes jaký e-mailový server, jaký uživatelský účet?
- Jsou alarmy zasílány pomocí SMS? Pokud ano, je použita internetová brána – s jakými přístupovými údaji?
- Je nasazen GSM modem? Pokud ano, kdo spravuje a platí tarif pro SIM? Předplacená služba s nutností pravidelného dobíjení představuje riziko, že se na dobití zapomene.
- Je využit webový přístup? Pokud ano, je dostupný z Internetu? Jak je webový server aktuálně zabezpečen proti útokům?
- Je pro ovládání použita aplikace pro mobilní telefony? Pokud ano, existují vnitrofiremní pravidla pro její používání?
- Využívá dodavatel MaR pro servis dálkový přístup? Pokud ano, je tento vztah podložen písemnou smlouvou, která určuje technické standardy a povinnosti jednotlivých stran?
- Je-li použita VPN, máme zazálohovanou konfiguraci, certifikáty a přístupové údaje?
Dalším krokem je definovat, jaké úrovně bezpečnosti chceme dosáhnout a jaké na to jsme ochotni vynaložit prostředky. Kybernetická bezpečnost není „buď – anebo“, jde o spojitý proces, při kterém bezpečnost zvyšujeme průběžným posilováním opatření a jejich kontrolou. Zároveň ale může docházet ke snižování bezpečnosti ať už vnějšími vlivy (sofistikovanější útoky, zvýšený zájem útočníků), nebo vlivy vnitřními (nová situace, kterou aktuální opatření neřeší).
Nejspíše si ve spolupráci s IT oddělením stanovíme pravidla, která by měl systém řízení budovy splňovat. Je důležité, aby IT oddělení vzalo problém (IT části) bezpečnosti řídicího systému za svůj, zejména pokud již ve firmě existují pravidla pro řešení kybernetické bezpečnosti – může jít například o směrnice při certifikaci podle ISO 27001 nebo o jiné vnitrofiremní předpisy.
Následuje odhad nákladů. Většina opatření je organizačních, tedy proveditelných s minimálními náklady. Nesmíme ovšem zapomenout na náklady nepřímé či budoucí, například není-li systém řízení budovy přístupný přes Internet pro servisní firmu, může to znamenat vyšší náklady na cestovné, případně delší dobu od nahlášení problému po reakci. To ale může prodloužit dobu odstávky technologie a tím pádem způsobit škody provozní.
Teprve pak má smysl předstoupit před vedení a nechat si opatření schválit. Pokud má firma certifikované procesy podle ISO 9001, dává smysl, aby se i tato opatření stala jejich součástí – možné následky problémů v řídicím systému budovy budou mít pravděpodobně vliv i na kvalitu výrobků nebo služeb.
Základní pravidla pro bezpečnou práci s daty
Dvě nejzávažnější hrozby jsou ztráta dat a únik dat. Abychom se proti nim bránili, musíme dělat zdánlivě protichůdná opatření: proti ztrátě je dobré zálohovat na více míst a zálohy mít snadno dostupné a obnovitelné, zatímco proti úniku dat obvykle bojujeme jejich znepřístupňováním. Proto data, spojená se systémem řízení budovy, dělíme do několika skupin a podle toho s nimi nakládáme:
Projekty, ve smyslu realizační dokumentace i zdrojových kódů k aplikačním programům a systémům SCADA, a další dokumenty, které popisují funkční stav věcí, jako jsou plány IP adres, zálohy konfigurací některých zařízení, provozní manuály pro konkrétní instalaci atd.
Tato data jsou velmi obtížně nahraditelná, ztráta zdrojových kódů k programovatelným podstanicím může znamenat statisícové náklady na jejich opětné vytvoření. Přijdeme-li o projekt skutečného provedení, servis se stává velmi komplikovanou činností – jde v podstatě o průzkum neznámého prostředí a hledání chyb naslepo.
Zapojovací schémata rozvaděčů nejsou kritickými dokumenty z hlediska úniku dat, proto se doporučuje mít jedno paré v rozvaděči a navíc dobrou zálohu (nejlépe v elektronické podobě, aby se dala kdykoli vytisknout).
Zdrojové kódy k aplikačním programům a další data spravuje buď dodavatel systému MaR (resp. servisní firma), tedy externí subjekt, nebo provozovatel budovy. Otázkou je, co je výhodnější: při správě externím subjektem se nemusí provozovatel starat o zálohování a aktuálnost dat, měl by ale mít smluvně ošetřenu jejich dostupnost pro případ, že by došlo k přerušení obchodních vztahů – například z důvodu ukončení činnosti firmy. Pokud se provozovatel stará o data sám, musí zajistit, aby při každém servisním zásahu programátor pracoval s aktuální verzí. Po skončení prací by si měl tedy vždy vyžádat kopii, kterou si jako verzovanou bezpečně uloží.
Katalogové listy, obecné návody k obsluze atd. To jsou dokumenty, které nejsou specifické pro konkrétní instalaci a měly by být dostupné u dodavatelů zařízení, ideálně na jejich webových stránkách. Přesto může být užitečné je mít k dispozici offline, roztříděné tak, aby potřebné informace byly snadno a rychle k nalezení. Někdy se pro tento účel využívá SCADA, která obsahuje odkazy na jednotlivé dokumenty, uložené jako součást implementace vizualizačního programu (tedy někde poblíž ve zvláštních adresářích, které se zálohují spolu s projektem). Offline dostupnost oceníme zejména po letech, kdy dokumentace k již nedodávaným zařízením nemusí být na webu výrobce ke stažení.
Záznamy – data, která vznikají během provozu systému. Jde zejména o historická data včetně odečtů hodnot z měřičů energií, logy událostí či alarmů, automatické zálohy a další údaje včetně záznamů jiných než elektronických (jako jsou například pravidelné revizní zprávy). Důležité záznamy je dobré skenovat a ukládat v digitální podobě, usnadní se tím zálohování a zálohy mohou být dostupné i na dálku.
Adresáře se záznamy nebo jejich databáze by měly být pravidelně zálohovány. Musíme si uvědomit, že naměřená data už nikdy znovu naměřit nepůjde. Některá data mohou být zapotřebí až po letech, například pro provedení energetického auditu. Zálohování může být i automatické, vždy je nutné pravidelně kontrolovat dostupnost záloh, tedy zda zálohovaná data umíme zrekonstruovat (např. jsou známa hesla pro přístup na úložiště?) a jak dlouho rekonstrukce potrvá.
Zálohování a celá agenda okolo něj s sebou samozřejmě nese určité náklady na hardware (disky, disková pole), služby (outsourcovaná úložiště) i vlastní výkony: čas strávený zálohováním a kontrolou, školení, průběžné vylepšování celého procesu. Ty bychom měli umět vyčíslit a přednést managementu k odsouhlasení.
Dalším typem dat jsou přístupová jména a hesla, certifikáty pro VPN a podobně. To jsou již kritické informace, které musíme chránit před únikem. Jejich správa proto bude vypadat jinak, než je tomu například u projektové dokumentace. Měla by tu platit obecná pravidla IT, aplikovaná i na ostatní aktiva v organizaci, včetně opatření, jako je pravidelná (řekněme půlroční) revize uživatelských účtů a rušení účtů již nepoužívaných.
Nezapomínejme na to, že například certifikáty pro zabezpečený přístup na webové servery (https://) je nutné pravidelně obnovovat, jejich platnost je omezena na dva roky (a není vyloučeno, že se bude ještě zkracovat). Zde nejde ani tak o náklady, jako o organizaci celého procesu, aby se nestalo, že webový přístup do vizualizace bude najednou nedostupný a začne sháňka po někom, kdo ví co se stalo a umí to spravit.
Otázky instalace a hardwaru
Přebíráme-li již funkční systém řízení budovy, některé věci již nemůžeme příliš ovlivnit. Patří mezi ně rozmístění rozvaděčů a jejich propojení sběrnicemi, obvykle technologickou sítí Ethernet. Tato síť je buď vedena samostatně, nebo je součástí (fyzickou, logickou či obojí) firemní infrastruktury. Oddělená síť představuje významnou bezpečnostní výhodu, musíme ovšem zvažovat i bezpečnost fyzickou (podle ISO 27002 kapitola 11 – Fyzická bezpečnost a bezpečnost prostředí), jako je stanovení bezpečnostního perimetru, kontrola vstupu, ale zejména umístění zařízení a bezpečnost kabelových rozvodů. Nezřídka vidíme klíčové komponenty, jako jsou routery a switche, umístěné v naprosto nevyhovujících podmínkách – na stole mezi kabely, pod stolem s pracovní stanicí, v rozvaděči bez jakéhokoli mechanického upevnění atd.
Proto zvažme, jestli se nevyplatí síť zrekonstruovat a dostat ji do souladu s požadavky na kvalitní IT infrastrukturu. Minimálním standardem je zde uzamykatelný datový rozvaděč. Je-li síť pod správou IT oddělení, mělo by to být tím snadnější.
Málo známé riziko představují IT komponenty, které v technologické síti vysílají data, jež prvky řídicího systému nemusejí vždy dobře snášet. Jde například o pakety IP V6, protokoly pro vzájemnou komunikaci mezi routery atd. Důsledkem jsou náhlé, těžko diagnostikovatelné problémy tam, kde dosud vše fungovalo správně. Projevují se u převodníků nebo PLC jako zasekávání komunikace, případně celých zařízení, a mohou působit dojmem, že jde o vědomý útok. To ovšem obvykle není pravda. Při zjišťování příčiny problému nejprve oddělíme technologickou síť od IT infrastruktury (zcela fyzicky nebo alespoň routerem s jen nejnutnějšími pravidly) a sledujeme, zda se problémy budou vyskytovat i nadále.
Je-li v systému řízení budovy zdroj UPS, měl by být pravidelně kontrolován a baterie posílána na repasi v intervalech podle doporučení dodavatele.
Riziko je definováno jako součin pravděpodobnosti, že nastane nějaká událost, a škody, kterou by výskyt této události způsobil. V případě kvalitně naprojektovaného a nainstalovaného řídicího systému budovy je pravděpodobnost selhání poměrně nízká, potenciální škoda je však vysoká – i když by celková nefunkčnost MaR nemusela mít za následek přímé ztráty ve výrobě či provozu, bez aktuální dokumentace a záloh softwaru je velmi nákladné systém dostat do původního stavu. Pak je na zvážení, zda nebude výhodnější preventivní rekonstrukce. Ta může mít několik podob:
- recommissioning (kompletní kontrola periferií, jako při prvním uvádění do provozu, a revize, případně znovuvytvoření softwaru),
- náhrada řídicího systému novým při ponechání periferií a silové části, nebo
- výměna kompletní instalace včetně periferií.
Při rozhodování záleží zejména na dostupnosti a podpoře hardwaru a softwaru – podstanic, vstupně-výstupních modulů, vývojových nástrojů i grafických programů (SCADA).
V případě náhrady řídicího systému nebo kompletní rekonstrukce musí montážním pracem předcházet projekt. Při projektování je nutná úzká spolupráce s dodavatelem řídicího systému i s oddělením IT, aby pak nedošlo ke konfliktům při uvádění do provozu. Zde by provozovatel měl vystupovat alespoň v roli konzultanta, který všechny zúčastněné strany včas seznámí s aktuálním stavem zařízení i s požadavky, které bude na nový systém mít.
Domat Control System s.r.o. patří k evropské špičce dodavatelů řídicích systémů a regulací pro inteligentní budovy, průmysl a energetiku. Cílem této ryze české společnosti je vyvíjet, vyrábět a dodávat řídící systémy v mezinárodním měřítku.
