Projektování a instalace MaR z hlediska bezpečnosti
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.
Pokrytí normami
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.
Úroveň periferií
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.
Úroveň podstanic
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í:
- PLC jsou připojena v samostatné (technologické) síti, která je považována za „chráněnou“, a bezpečnost se řeší pouze v místě, kde tato technologická síť vstupuje do intranetu, resp. do internetu. Technologická síť je od okolního světa oddělena routerem, ideálně pak bezpečnostním routerem. Tento přístup umožňuje do sítě připojit i zařízení, která mají zabezpečení velmi slabé nebo žádné. Jde zejména o vzduchotechniky s autonomní regulací, různé převodníky „XY na Ethernet“, čidla, frekvenční měniče a podobně. Zároveň to znamená, že celá technologická síť by měla být fyzicky zabezpečena proti připojování cizích zařízení a dalším útokům, tedy veškeré aktivní prvky by měly být pod zámkem, infrastruktura (kabely, patch panely…) pokud možno oddělená od ostatních IT zařízení a podobně. V síti by neměly být bezdrátové přístupové body a pokud jsou opravdu nutné, měly by být chráněny kromě dostatečně silného šifrování ještě například filtrováním MAC adres.
- PLC jsou součástí intranetu a mohou sdílet i stejnou logickou síť jako další zařízení, která nejsou součástí MaR (např. tiskárny, klientské stanice, servery, routery). Bezpečnost je tedy nutné řešit „na patě“ každého PLC, resp. zařízení MaR se síťovou komunikací. To může být někdy problém, protože jednodušší komponenty nemají pro tuto úlohu dostatečný výpočetní výkon nebo jejich komunikační protokoly zabezpečení ani dobře neumožňují (např. Modbus TCP). U některých zařízení je možné alespoň přepínačem zablokovat webové konfigurační rozhraní, což ovšem nebrání například útokům založeným na zahlcení síťové karty extrémně silným provozem.
1. Systém řízení budovy v samostatné technologické síti
Samostatná technologická síť
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
MaR součástí intranetu
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:
- IT infrastruktura (zásuvky, kabeláž, patch panely, racky, aktivní prvky atd.) je dodávána a spravována zákazníkem. Pro nás to znamená, že musíme jen vyspecifikovat potřebný počet a umístění přípojných míst (síťových zásuvek). To v zásadě není špatná zpráva.
- Zařízení, připojená v síti, mají IP adresy přidělované protokolem DHCP, ne pevně nastavené. IT technik určí, že DHCP server přiděluje IP adresy podle MAC adres zařízení (ty jsou neměnné – z výroby vázané na konkrétní kus hardwaru). Switche si tak mohou hlídat, co je připojeno do které zásuvky, a pokud v síti dojde ke změně hardwaru, je vysláno bezpečnostní upozornění. Problém může nastat ve chvíli, kdy PLC pro poruchu vyměníme: po připojení do sítě mu bude přiřazena jiná IP adresa nebo síť připojení zcela odmítne. Servisní technik tudíž musí vědět, že výměnu jakéhokoli zařízení s rozhraním Ethernet musí koordinovat s IT oddělením zákazníka.
- Pravidla pro komunikaci mezi sítěmi (tzv. otevřené porty) se periodicky revidují a promazávají, aby v systému nebyly staré, nepoužívané záznamy, které představují bezpečnostní riziko. Někdy se stane, že do firmy přijde nový síťař, který postupuje tak, že všechny záznamy smaže a čeká, kdo se ozve; nutná pravidla pak definuje znovu. Tím sice zajistí pročištění tabulek, může se však stát, že například záznamy teplot z chladicích boxů pro hygienickou službu nejsou několik měsíců ukládány, než se na problém náhodou přijde.
- Odchozí komunikace je omezená nebo zcela zablokovaná. To může postihnout cloudové služby, které se u dodavatelů řídicích systémů těší stále větší oblibě. Pokud je tedy v projektu uvažován přenos dat do vzdálené databáze (např. Merbon ContPort, různé servisní a diagnostické služby, proxy služby pro dálkový přístup bez příchozích spojení do sítě), musíme předem prověřit, jestli vůbec bude taková služba realizovatelná. Možná se podaří domluvit omezení odchozích spojení pouze na konkrétní IP adresu, pak je ale nutné hlídat její případnou změnu (například při přechodu hostování služby k jinému poskytovateli) a včas IT oddělení zákazníka informovat, aby mohlo pravidla aktualizovat. To je problém zejména u dlouho existujících vztahů, kdy po několika letech bezproblémového chodu už pomalu nikdo neví, jak vlastně všechno funguje.
- Příchozí komunikace je zcela zablokovaná. To by nás nemělo překvapit, jde o jedno ze základních bezpečnostních opatření. Pro vzdálený přístup pro servis se snažíme domluvit připojení pomocí VPN.
- Pro servisní přístup se často používá VPN, kterou považujeme za vysoce bezpečný prostředek vzdálené správy. Platí to ale jen v případě dodržování dalších bezpečnostních pravidel, jako je neukládání hesla v čitelné formě na vzdáleném počítači, pravidelná obměna hesel a certifikátů, přístup pouze z definovaných IP adres atd. Zde jde ale již o provozní opatření, v projektu stačí po dohodě s provozovatelem zmínit, že servisní přístup bude mít tuto formu a podmínky jsou již na dohodě mezi provozovatelem a dodavatelem MaR. Nutno podotknout, že vzdálený servis skutečně významně urychluje řešení problémů, zaregulování a zaškolení obsluhy, a proto se u větších instalací (nad 1000 datových bodů) stal již samozřejmostí.
- Do sítě není možné připojovat jakákoli další zařízení s internetovou konektivitou (GPRS/LTE routery apod.). Šlo by o hrubé porušení bezpečnostních pravidel a pachatel by pocítil nevoli správců sítě se všemi důsledky. Není tedy možné si takhle „pomoci“ v případě, že některé služby jsou správcem IT z jakýchkoli důvodů omezeny.
Č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.
Pro zvýšení bezpečnosti na úrovni PLC je zde několik tipů:
- nepoužíváme výchozí hesla, zejména pro uživatele s právy Engineering a Full Control
- webové servery v PLC zablokujeme, pokud nejsou používány
- u převodníků, terminálů atd. zablokujeme FTP přístup a webové rozhraní, pokud je to možné
- u HMI panelů nepoužíváme pro administrátorský přístup uživatele jménem Admin, ale „méně nápadné“ jméno
- jsou-li v síti zařízení, která nelze zabezpečit (Modbus, BACnet servery atd., preferujme oddělenou technologickou síť
- pro vzdálený přístup používáme VPN, nikoli přímé mapování portů PLC na veřejnou IP adresu
- zálohy projektů nenecháváme na PC s vizualizací.
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.
Úroveň vizualizace
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ěkolik tipů pro konfiguraci OS a Merbon SCADA:
Instalace, aktualizace, zálohy
- v běžném provozu chránit hardware zablokováním čtení a zápisu z CD mechanik, USB portů atd.
- zablokovat nepotřebné služby, odinstalovat nepotřebné programy (hry atd.)
- kontrolovat pravidelné aktualizace OS, antivirových programů i aplikací (SCADA)
- pravidelně zálohovat a testovat obnovitelnost ze záloh (!)
Konfigurace, přístupy
- u služeb nepoužívat defaultní uživatelská jména a hesla
- neukládat hesla v prohlížeči
- pro přístup na SCADA server využívat port 443 (https://)
- pokud je SCADA server přístupný z Internetu (a ne jen z vnitřní sítě), omezit přístup jen z určitých IP adres
- vzdálený přístup pouze přes VPN, nikdy nenechávat otevřený port pro vzdálenou plochu (RDP) či jiné služby na Internetu
Uživatelská politika
- pravidelně (cca. po 6 měsících) revidovat revidovat seznamy uživatelů a již nepotřebné účty mazat (i s ohledem na GDPR)
- uživatelům nastavovat jen ta práva, která potřebují pro svou práci
- pokud je počítač využíván i pro práci na Internetu, dbát na pravidla rozumného chování
- využít uživatelskou politiku OS Windows, uživatele s právy Administrator používat pouze pro konfiguraci systému, ne pro běžnou práci.
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 1 000 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.
Závěrem
Shrňme tedy základní pravidla pro projektování bezpečných systémů v několika bodech:
- rozvaděče umisťujeme tam, kde nehrozí neautorizovaná manipulace s ovládacími prvky
- ve veřejně přístupných prostorech má mít skříň zámek na klíč, ne jen na kličku
- sériové sběrnice vedoucí mimo rozvaděč připojujeme na jiné porty, než na kterých jsou I/O moduly v rozvaděči
- technologickou síť připojíme do intranetu nebo internetu v jednom bodu a přes bezpečnostní router, jehož správce je si vědom své úlohy
- aktivní prvky, servery, datová úložiště umisťujeme do dostatečně zabezpečených prostorů s vhodným prostředím (teplota, vlhkost, prašnost)
- pokud systém vyžaduje externí zdroje (cloudové služby, obnovu certifikátů atd.), v projektu na to upozorníme a s náklady pro nějaké období počítáme ve výkazu výměr
- specifikaci hardwaru pracovních stanic a serverů si necháme odsouhlasit dodavatelem MaR
- s kyberbezpečností vždy řešíme i přiměřenou fyzickou bezpečnost (nemá smysl instalovat diskové úložiště s šifrovaným přístupem do rozvaděče, který stojí na veřejně přístupné chodbě a dá se otevřít bez pomoci nástrojů)
- všechny věci řešíme s předstihem – komunikace vždy dlouho trvá, protože stavební firma většinou problematice nerozumí a má zcela jiné starosti
- snažíme se komunikovat přímo s koncovým uživatelem, je-li znám.
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.
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.