Všeobecné pravidlá pre partnerské firmy dodávajúce OT infraštruktúru a softvér
Všeobecné pravidlá pre partnerské firmy dodávajúce OT infraštruktúru a softvér
Platné od: 11.9.2023
Verzia: 1.0
Vydal: Oddelenie rozvoja a prevádzky riadiacich systémov
Obsah
5 Komunikačné rozhrania a protokoly 8
5.3 Zoznam obmedzených protokolov 8
7 Databázy a databázové servery 11
7.2 Preferovaný dadabázový server 12
9.2 Operačný systém a firmware 14
9.3 Aktualizácie OS a firmware 14
12 Antivírus a zabezpečenie 16
13.5 Automatizačné komponenty 17
16 Bezpečnostné logovanie a monitoring 18
17 Access a identity management 20
17.2 Vytváranie používateľov a skupín v AD 20
17.3 Autentifikácia používateľov 20
17.4 Autorizácia používateľov 20
18.2 Nesplnenie dostupnosti 22
19 Service a continuity management 22
Tento dokument ustanovuje pravidlá pre partnerské firmy dodávajúce OT infraštruktúru a softvér pre MH Teplárenský Holding, a.s. . Dokument je určený vedeniu partnerských spoločností, ich zamestnancom a subdodávateľom.
MHTH – MH Teplárenský Holding, a.s. OT – Operational Technology
SW – Software HW – Hardware
OS – Operating system FW – Firewall
AD – Active directory
HMI – Human Machine Interface
Dodávateľ - partnerská firma dodávajúca OT infraštruktúru a softvér pre MH Teplárenský Holding, a.s. RTO – Recovery Time Objective
RPO – Recovery Point Objective
NDA – Non-disclosure agreement. Zmluva o mlčanlivosti. IS – Informačný systém
RS – Riadiaci systém
Nová sieťová infraštruktúra sa pripája na existujúcu sieťovú infraštruktúru MHTH len v miestach na to určených a podľa definovaných pravidiel. Pripojenie do sieťovej infraštruktúry MHTH je možné len po podpise zmluvy o kybernetickej bezpečnosti. Vytváranie ostrovných riešení je zakázané.
V rámci dodávky je možné dodať len manažovateľné L2/L3 switche s nasledujúcimi vlastnosťami:
• Rozhranie pre manažment cez SSH
• Podpora RSPAN
• Podpora SNMP V3 pre pripojenie na centrálny monitoring (viď Kapitola 16.2)
• Podpora RSTP
• Podpora „stackingu“ viacerých prepínačov (switchov)
• Podpora štandardu 802.1x
• Podpora syslogu a napojenia na centrálne sledovanie logovacích hlásení (viď Kapitola 16)
• Podpora RADIUS servera pre manažment užívateľov
• Podpora „port security“ funkcionality
• Možnosť vzdialenej aktualizácie firmware
• Podpora protokolov CDP alebo LLDP
• Možnosť konfigurácie aspoň 250 rôznych VLAN
• Podpora agregácie liniek
• Downlink porty s rýchlosťou 100/1000Mbps
• Uplink porty s rýchlosťou 1000Mbps (v prípade predpokladaných prenosov veľkého objemu dát s rýchlosťou 10Gbps)
• Vyhotovenie, stupeň ochrany a celková odolnosť vyhotovenia switchu musia zodpovedať náročnosti prostredia, v ktorom bude switch umiestnený
• V prípade použitia switchu, pre zariadenia využívajúce industriálne protokoly (Profinet a pod.) je nutné aby bola zaručená ich natívna podpora samotným switchom
• Je možné dodať len zariadenia, na ktoré je od výrobcu deklarovaná podpora po dobu ich použitia v spoločnosti MHTH, takisto na zariadenia musí byť zakúpeny support od výrobcu na možnosť sťahovania nových verzií firmware ak ich výrobca neposkytuje bezplatne na stiahnutie
Nakoľko routre nie sú bežnou súčasťou OT infraštruktúry, tak je ich dodávku nutné dopredu odkonzultovať s Oddelením rozvoja a prevádzky infraštruktúry, ktoré musí takúto dodávku schváliť.
Zariadenia na prevod signálu z optického na metalický kábel resp. „vice versa“ môžu byť použité len v technológii pri koncových zariadeniach. Ukončenie optického sieťového kábla musí byť priamo na switchi resp, opto paneli v racku pomocou optického gbic korešpondujúcim typom portu a optického kábla. Môžu sa použiť iba gbic alebo DAC káble, ktoré sú podporované výrobcami na zariadeniach do ktorých sa budú pripájať. Prevodník musí byť v racku pevne uchytený.
4.4.1 Optické sieťové káble
Dodávané optické sieťové káble musia spĺňať nasledovné požiadavky:
• Multi-mode kábel musí byť typu OM3 alebo vyšší. Konkrétny typ musí zohľadňovať požadovanú prenosovú rýchlosť a dĺžku kábla resp. komunikačnej trasy.
• Single-mode kábel musí byť typu OS1 pre vnútorné a OS2 pre vonkajšie použitie Finálne riešenie návrhu optickej siete musí prejsť schvaľovacím procesom zo strany MHTH.
4.4.2 Metalické sieťové káble
Metalické sieťové káble musia byť kategórie Cat6 a vyššej.
Ak je predmetom dodávky bezdrôtová sieť potom dodávateľ musí spolupracovať pri návrhu a realizácii s Oddelením rozvoja a prevádzky infraštruktúry. Bez súhlasu tohto oddelenia nie je možné dodať bezdrôtovú sieť.
4.5.1 WLAN
Iné komunikačné protokoly než IP verzie 4 alebo vyššej musia byť schválené Oddelením rozvoja a prevádzky infraštruktúry. Nové infraštruktúry musia podporovať výhradne tento protokol. Iné protokoly
musia byť odfiltrované, aby sa do siete skupiny mohli dostať iba IP protokoly. Umiestnenie prístupových bodov a vysielací výkon musia byť zvolené tak, aby pokrývali iba želanú oblasť.
Používanie bezdrôtových extenderov/bridge-ov je povolené iba ak sú počas rádiového prenosu implementované šifrovanie pripojenia a techniky overovania rovnakej úrovne zabezpečenia ako na access pointe, ku ktorému sa extender/bridge pripája. Preklad sieťových adries (NAT) nie je na prístupových bodoch povolený.
4.5.2 Bluetooth
Používanie Bluetooth na komunikáciu medzi jednotlivými časťami OT systémov je zakázané.
Konfiguráciu dodávaných komponentov sieťovej infraštruktúry bude vykonávať MHTH v spolupráci s dodávateľom a na základe jeho špecifikácie. Konfigurácia musí zodpovedať bezpečnostným
požiadavkám zo strany MHTH.
Zapojenie sieťovej infraštruktúry, vrátane kabeláže, bude vykonávať dodávateľ podľa platnej projektovej dokumentácie. V prípade zapájania v serverovniach alebo vyhradených miestnostiach MHTH, bude toto zapojenie vykonávané pod dohľadom zodpovednej osoby, ktorú určí MHTH.
Zonáciu a segmentáciu sietí určuje MHTH na základe podkladov dodaných dodávateľom. Podklady musia obsahovať sieťový diagram a typy a počty plánovaných pripojených zariadení. Riešenie musí byť
navrhnuté s ohľadom na dobrú prax – PERA model.
4.8.1 VLAN
VLAN a ich adresné rozsahy sú určené zo strany MHTH podľa špecifických potrieb systému definovaných dodávateľom. VLAN sa poskytujú v najmenšom možnom rozsahu s minimálnymi rezervami. VLAN sú navrhované tak, aby sieť bola rozdelená na čo najmenšie logické celky, čo musí byť reflektované aj
Prestupy medzi rôznymi VLAN sú možné len na základe schválenej komunikačnej matice. Komunikačná matica obsahuje minimálne:
• Zdrojovú a cieľovú IP adresu
• Konkrétne porty a služby ktoré majú byť otvorené
• Smer komunikácie
• Zdôvodnenie nutnosti komunikácie
Komunikačnú maticu navrhuje dodávateľ a schvaľuje MHTH. Komunikačná matica musí obsahovať najmenší možný rozsah portov a IP adries nutný na správnu funkcionalitu systému. Vzor komunikačnej matice bude poskytnutý na vyžiadanie.
5 Komunikačné rozhrania a protokoly
MHTH vyžaduje použitie zabezpečených protokolov na komunikáciu medzi jednotlivými systémami. Taktiež komunikácia medzi jednotlivými komponentami systému musí byť zabezpečená. V prípade, že dodávateľ nie je schopný túto požiadavku splniť, musí požiadať o výnimku s tým, že navrhne alternatívne riešenie zabezpečenia komunikácie. V prípade, že daná komunikácia zabezpečuje prenos prihlasovacích údajov alebo informácii s vyššou klasifikáciou ako interné, tak v takom prípade nie je výnimku možné udeliť.
Súčasťou ponuky musí byť aj bloková komunikačná schéma poskytujúca nasledujúce informácie o rozhraniach medzi jednotlivými súčasťami systému:
• Smer komunikácie komunikačného rozhrania
• Typ prenášaných dát
• Použitý protokol
5.3 Zoznam obmedzených protokolov
Služba/Protokol | Popis |
FTP | Zakázané |
Telnet | Zakázané |
SMTP | Len pre interné e-mailové adresy za predpokladu použitia TLS/SSL s možnosťou overovania. Podlieha povoľovaciemu konaniu zo strany MHTH |
IMAP | Zakázané |
POP3 | Zakázané |
HTTP | Zakázané. Potrebné nahradiť HTTPS |
OPC DA | Zakázané. Potrebné nahradiť šifrovaným OPC UA. |
MQTT | Len šifrované na porte 8883. Nešifrovaná komunikácia na porte 1883 je zakázaná. |
Akákoľvek komunikácia smerom von zo siete MHTH je zakázaná. O výnimku je možné požiadať len na základe existujúcej zmluvy MHTH s partnerskou firmou, ktorá takúto komunikáciu umožňuje, alebo v prípade, že takáto komunikácia je priamo požadovaná zo strany MHTH v rámci dodávky. Spôsob a zabezpečenie takejto komunikácie určuje MHTH. V takýchto prípadoch je nutné požiadať a nechať si schváliť výnimku už vo fáze ponuky.
Akákoľvek komunikácia smerom do siete MHTH je zakázaná. O výnimku je možné požiadať len na základe existujúcej zmluvy MHTH s partnerskou firmou, ktorá takúto komunikáciu umožňuje, alebo v prípade, že takáto komunikácia je priamo požadovaná zo strany MHTH v rámci dodávky. Spôsob a zabezpečenie takejto komunikácie určuje MHTH. V takýchto prípadoch je nutné požiadať a nechať si schváliť výnimku už vo fáze ponuky.
Vzdialený prístup do siete MHTH je možný len na základe platnej zmluvy alebo v prípade plynutia doby záruky, avšak len v takom prípade, že takýto prístup je nevyhnutný na plnenie kontraktuálnych záväzkov zo strany dodávateľa. Spôsob a zabezpečenie takejto komunikácie určuje MHTH. Nutnou podmienkou je aj podpísanie zmluvy o Kybernetickej bezpečnosti medzi MHTH a dodávateľom.
Všetky servery v rámci dodávky musia byť virtualizované. Výnimka z tohto pravidla je možná len ak je objektívna príčina brániaca ich virtualizácii. Táto príčina musí byť riadne zdokumentovaná už v ponuke a podlieha súhlasu zo strany MHTH. Všetky fyzické servery musia byť umiestnené v serverovni určenej MHTH.
Automatické spúšťanie vymeniteľného média („Autorun”) musí byť deaktivované.
Na každom serveri musí byť implementované automatické uzamknutie interaktívnej relácie, uzamknutie relácie po preddefinovanej dobe nečinnosti (maximálne 10 minút). Uzamknutie je možné odstrániť iba po riadnom overení používateľa. V prípadoch, že nie je možné túto požiadavku splniť z objektívnych dôvodov (napríklad beh operátorskej vizualizácie na terminálovom servery),je nutné požiadať a nechať si schváliť výnimku už vo fáze ponuky.
Pri fyzických serveroch nesmie byť žiadna značka (tag) alebo označenie obsahujúce citlivé informácie (napr. informáciu o ILO mgmt.), ktoré nesmú byť viditeľné neoprávneným osobám.
Každý server môže disponovať, až na výnimky uvedené nižšie, len jedným sieťovým rozhraním. Ako komunikačný protokol je povolený len IP protokol verzie 4. Všetky ďalšie komunikačné protokoly musia byť vypnuté. Servery musia používať statické IP adresy. Na serveroch musí byť vypnuté smerovanie a nesmie byť zapnuté preposielanie paketov. Všetky nevyžadované sieťové rozhrania musia byť vypnuté.
Zoznam výnimiek pre viac sieťových rozhraní:
• Zabezpečenie redundantného pripojenia fyzického servera do siete. Takéto pripojenie je však možné len po jednej VLAN.
• Zabezpečenie aplikačnej redundancie pomocou dedikovanej VLAN.
• VLAN použitá na zabezpečenie redundancie medzi dvoma servermi musí byť úplne izolovaná.
• Zabezpečenie komunikácie pomocou industriálnych protokolov (napr. Profinet)
Nainštalované a spustené služby môžu byť len tie, ktoré sú vyžadované pre prevádzku. Kontá služieb používané na tento účel musia mať pridelené minimálne oprávnenia tak aby služba mohla fungovať. Kontá služieb nesmú mať povolenia interaktívne sa prihlásiť na server.
Kontá s lokálnymi alebo lokálnymi správcovskými oprávneniami (koreňové, správcovské, kontá správcov domén atď.) sa nesmú používať na spúšťanie aplikácií.
Služby, ktoré vyžadujú overenie a požadujú aby boli meno a heslo uložené v nezašifrovanom texte sa nesmú používať a musia byť nahradené zabezpečenými službami. Protokoly sa musia používať v ich najbezpečnejších verziách v dobe nasadenia systému do prevádzky.
Konfigurácia povolených služieb servera musí byť jasne a zrozumiteľne zdokumentovaná. Pred uvedením do prevádzky a po inštalácii všetkých aplikácií MHTH skontroluje a zdokumentuje, či neobsahujú nepovolené služby. V prípade, že budú takéto služby identifikované musí ich dodávateľ, ešte pred uvedením diela do prevádzky, na vlastné náklady odstrániť.
Oprávnenia systému súborov sa musia nastaviť podľa princípu najnižších oprávnení alebo „need to know“.
Iba správcovia systému, správcovia kybernetickej bezpečnosti a systémové kontá môžu dostať právo na zapisovanie do súborov operačného systému servera.
Údaje musia byť udržiavané štruktúrovaným spôsobom, pričom systémové súbory a údajové súbory musia byť uložené v oddelených oblastiach.
Aplikácie musia byť nainštalované na inú partíciu ako je systémová, tak aby nemohlo dôjsť k jej neželanému zaplneniu.
Virtuálne prostredie a inštaláciu virtuálneho servera zabezpečuje a vykonáva MHTH podľa špecifikácií dodaných dodávateľom. Špecifikácia musí obsahovať minimálne nasledovné parametre:
• Typ a verzia operačného systému
• Počet vCPU
• Veľkosť RAM
• Veľkosť úložiska podľa jednotlivých partícií
• VLAN do ktorej má byť server pripojený
• Požadovaná IP adresa na rezerváciu v DHCP
• Požadované výnimky pre AV a FW pokiaľ sú schválené MHTH
• Zoznam užívateľov a ich rolí
• Zoznam štandardných služieb a rolí servera, vrátane ich konfigurácie, ktoré majú byť nainštalované
Špecifikácia požiadaviek na virtuálny server v nasledovnom rozsahu musí byť už súčasťou ponuky:
• Typ a verzia operačného systému
• Počet vCPU
• Veľkosť RAM
• Veľkosť úložiska podľa jednotlivých partícií
• Počet sieťových rozhraní
• Požadované výnimky pre AV a FW
• Zoznam štandardných služieb a rolí servera, vrátane ich konfigurácie, ktoré majú byť nainštalované
• Zoznam inštalovaného SW vrátane databázových serverov.
Fyzické servery bude inštalovať MHTH podľa požiadaviek dodávateľa. Zapojenie serverov, vrátane nutnej kabeláže, bude vykonávať dodávateľ podľa platnej projektovej dokumentácie. V prípade zapájania v serverovniach alebo vyhradených miestnostiach MHTH, bude toto zapojenie vykonávané pod dohľadom zodpovednej osoby, ktorú určí MHTH.
Špecifikácia od dodávateľa musí obsahovať minimálne nasledovné parametre:
• Typ a verzia operačného systému
• Veľkosť úložiska podľa jednotlivých partícií
• VLAN do ktorej má byť server pripojený
• Požadovaná IP adresa na rezerváciu v DHCP
• Požadované výnimky pre AV a FW pokiaľ sú schválené MHTH
• Zoznam užívateľov a ich rolí
• Zoznam štandardných služieb a rolí servera, vrátane ich konfigurácie, ktoré majú byť nainštalované Špecifikácia fyzického servera v nasledovnom rozsahu musí byť už súčasťou ponuky:
• Typ a verzia operačného systému
• Počet a typ CPU
• Veľkosť RAM
• Veľkosť úložiska podľa jednotlivých partícií
• Počet sieťových rozhraní
• Požadované výnimky pre AV a FW
• Zoznam štandardných služieb a rolí servera, vrátane ich konfigurácie, ktoré majú byť nainštalované
• Zoznam inštalovaného SW vrátane databázových serverov.
7 Databázy a databázové servery
V prípade, že dodávaný systém potrebuje využívať databázy, tak tieto databázy musia byť umiestnené na databázovom servery ktorý určí MHTH. Použitie dedikovaného databázového servera je možné len v nasledovných prípadoch:
• Aplikačný SW vyžaduje pre bezproblémový beh inštaláciu na rovnaký server ako je databázový server a táto podmienka je uvádzaná výrobcom.
• Existuje technické obmedzenie, ktoré to neumožňuje, prípadne výrobca to nedovoľuje. V takom prípade musí byť musí byť obmedzenie v ponuke riadne zdokumentované a dodávateľ musí požiadať o schválenie výnimky.
7.2 Preferovaný dadabázový server
V MHTH je ako databázový server preferovaný Microsoft SQL Server.
V prípade, že súčasťou dodávky je aj databáza, ktorá môže bežať na externom databázovom servery, tak je nutné jej umiestnenie prekonzultovať s MHTH už vo fáze ponuky, nakoľko pre niektoré typy databázových serverov existujú centrálne riešenia, ktoré sú uprednostňované pred stand-alone riešeniami. Umiestnenie databázy bude ovplyvnené parametrami ako je požadovaná veľkosť a očakávaná záťaž read/write prístupov.
Všetky databázové servery musia mať manažment užívateľov v Active Directory, ktoré určí MHTH. Všetky databázové servery sú spravidla virtualizované vo virtuálnom prostredí MHTH a inštalované na serverový operačný systém. Inštalácia databázového servera spolu s aplikačným SW na jeden server je povolená len v prípade, že ide o nutnú podmienku na bezproblémový beh aplikačného SW udávanú jeho výrobcom. V takom prípade je nutné požiadať o výnimku už pri ponuke. Táto skutočnosť musí byť zdokumentovaná v ponuke a aj vo finálnej dokumentácii.
Špecifikácia požiadaviek na virtuálny databázový server v nasledovnom rozsahu musí byť súčasťou ponuky:
• Typ a verzia operačného systému
• Počet vCPU
• Veľkosť RAM
• Veľkosť úložiska podľa jednotlivých partícií
• Počet sieťových rozhraní
• Požadované výnimky pre AV a FW
• Zoznam štandardných služieb a rolí servera, vrátane ich konfigurácie, ktoré majú byť nainštalované
Databázové servery, ktorých licenčný model by vyžadoval licencovanie celého virtuálneho prostredia, nie sú spravidla povolené. Prípadnú výnimku a náhradnú možnosť implementácie je nutné dohodnúť pred podaním finálnej ponuky.
Každá klientská stanica môže disponovať (až na výnimky uvedené nižšie), len jedným sieťovým rozhraním. Ako komunikačný protokol je povolený len IP protokol verzie 4. Všetky ďalšie komunikačné protokoly musia byť vypnuté. Procesne kritické klientské stanice musia používať statické IP adresy. Na staniciach musí byť vypnuté smerovanie a nesmie byť zapnuté preposielanie paketov. Všetky nevyžadované sieťové rozhrania musia byť vypnuté.
Zoznam výnimiek:
• Zabezpečenie redundantného pripojenia fyzickej klientskej stanice do siete. Takéto pripojenie je však možné len do jednej VLAN.
• Zabezpečenie aplikačnej redundancie pomocou dedikovanej VLAN. VLAN použitá na zabezpečenie redundancie medzi dvoma klientskými stanicami musí byť úplne izolovaná.
• Zabezpečenie komunikácie pomocou industriálnych protokolov (napr. Profinet)
Nainštalované a spustené služby môžu byť len tie, ktoré sú vyžadované pre prevádzku. Kontá služieb používané na tento účel musia mať pridelené minimálne oprávnenia tak aby služba mohla fungovať. Kontá služieb nesmú mať povolenia interaktívne sa prihlásiť na server.
Kontá s lokálnymi alebo lokálnymi správcovskými oprávneniami (koreňové, správcovské, kontá správcov domén atď.) sa nesmú používať na spúšťanie aplikácií.
Služby, ktoré vyžadujú overenie a požadujú aby boli meno a heslo uložené v nezašifrovanom texte sa nesmú používať a musia byť nahradené zabezpečenými službami. Protokoly sa musia používať v ich najbezpečnejších verziách v dobe nasadenia systému do prevádzky.
Konfigurácia povolených služieb servera musí byť jasne a zrozumiteľne zdokumentovaná. Pred uvedením do prevádzky a po inštalácii všetkých aplikácií MHTH skontroluje a zdokumentuje, či neobsahujú nepovolené služby. V prípade, že budú takéto služby identifikované musí ich dodávateľ, ešte pred uvedením diela do prevádzky, na vlastné náklady odstrániť.
Oprávnenia systému súborov sa musia nastaviť podľa princípu najnižších oprávnení alebo „need to know“.
Iba správcovia systému, správcovia kybernetickej bezpečnosti a systémové kontá môžu dostať právo na zapisovanie do súborov operačného systému servera.
Údaje musia byť udržiavané štruktúrovaným spôsobom, pričom systémové súbory a údajové súbory musia byť uložené v oddelených oblastiach.
Inštalácia databázových serverov na klientské stanice je spravidla zakázaná. Výnimku tvoria len databázové servery, ktoré sú neoddeliteľnou súčasťou aplikačného SW a sú súčasťou inštalačného balíka. Takáto výnimka musí byť zo strany MHTH schválená už vo fáze ponuky a riadne zdokumentovaná. Takáto inštalácia podlieha rovnakým pravidlám ako inštalácia na serverový operačný systém. Databázové servery musia mať manažment užívateľov v Active Directory, ktoré určí MHTH.
Preferované riešenie vizualizácie riadiaceho systému pre operátorov na velíne je použitie virtuálneho terminálového servera. V prípade, že terminálový server nie je možné použiť, tak pracovné stanice poskytujúce túto službu musia byť virtualizované.
Pre vytvorenie nových operátorských pracovísk je nutné použiť tenkého/zero klienta, ktorý bude sprostredkovávať užívateľskú reláciu s príslušným serverom/pracovnou stanicou pomocou protokolu RDP alebo HTTPS. Preferovaná konfigurácia tenkého/zero klienta je stiahnutie si konfigurácie pri štarte zo siete (PXE Boot).
Každý dodávaný SW musí byť legálny, v prípade open-source riešení zabezpečené legálne použitie pre komerčné účely, dodaný spolu s inštalačnými súbormi v použitej verzii, platnou dokumentáciou od výrobcu a podrobným návodom na inštaláciu vrátane potrebnej konfigurácie.
9.2 Operačný systém a firmware
9.2.1 MS Windows
Všetky zariadenia s operačným systémom na báze MS Windows musia byť pripojené do Active Directory, ktoré určí MHTH. MS Windows musí byť dodaný v poslednej známej LSTC verzii a pred odovzdaním musí mať nainštalované všetky bezpečnostné a funkčné záplaty vydané výrobcom do dátumu odovzdania diela. Inštaláciu záplat vykoná dodávateľ a MHTH ju bude validovať.
9.2.2 Unix/Linux
Všetky zariadenia s operačným systémom na báze Unix/Linux musia mať manažment užívateľov v Active Directory, ktoré určí MHTH. Unix/Linux musí byť dodaný v poslednej známej LTS verzii a pred odovzdaním musí mať nainštalované všetky bezpečnostné a funkčné záplaty vydané výrobcom do dátumu odovzdania diela. Inštaláciu záplat vykoná dodávateľ a MHTH ju bude validovať.. V MHTH je preferovanou distribúciou Debian alebo Ubuntu.
9.2.3 Iné OS
Všetky zariadenia s iným operačným systémom ako na báze MS Windows alebo Unix/Linux, musia mať manažment užívateľov v Active Directory, ktoré určí MHTH. Operačný systém musí byť dodaný
v poslednej známej stabilnej verzii a pred odovzdaním musí mať nainštalované všetky bezpečnostné a funkčné záplaty vydané výrobcom do dátumu odovzdania diela. Inštaláciu záplat vykoná dodávateľ a MHTH ju bude validovať.
9.2.4 Firmware
Dodávané komponenty obsahujúce firmware musia byť pri odovzdávaní diela aktualizované na aktuálnu stabilnú verziu FW s aplikovanými bezpečnostnými záplatami. Inštaláciu záplat vykoná dodávateľ a MHTH ju bude validovať.
9.3 Aktualizácie OS a firmware
OS a firmware, musí umožňovať aplikáciu bezpečnostných a funkčných aktualizácií, patchov a service packov vydaných výrobcom, bez toho aby to negatívne ovplyvnilo záruku na dodané dielo aj v prípade, že tieto aktualizácie nevykoná dodávateľ.
Aplikačný SW musí byť dodaný v poslednej stabilnej verzii, alebo prípadne v takej verzii, aby výrobca garantoval jeho podporu (minimálne vydávanie bezpečnostných záplat) po dobu minimálne 5 rokov od dátumu odovzdania do prevádzky. Medzi aplikačný SW sa radia aj databázové servery.
9.4.1 Aktualizácie aplikačného SW
Aplikačný SW musí umožňovať aplikáciu bezpečnostných a funkčných aktualizácií, patchov a service packov vydaných výrobcom, bez toho aby to negatívne ovplyvnilo záruku na dodané dielo aj v prípade, že tieto aktualizácie nevykoná dodávateľ. Táto požiadavka sa týka aj OS na ktorom aplikačný SW beží a podporných služieb.
9.4.2 Human Machine Interface
Aplikačný SW poskytujúci funkcionalitu HMI alebo inej vizualizácie slúžiacej na sledovanie alebo riadenie výrobných procesov musí umožňovať tzv. „Kiosk mód“ kde prístup na operačný systém hosťujúci aplikačný SW je umožnený len oprávneným používateľom. Neoprávnení používatelia nesmú mať možnosť akokoľvek interagovať s OS alebo inými aplikáciami.
9.4.3 Kompatibilita s hypervisorom
Dodávateľ musí garantovať kompatibilitu dodávaného aplikačného SW s hypervisorom používaným v MHTH, tak aby bola umožnená virtualizácia. Informácia o type a verzii je dostupná pre zapísaných uchádzačov na vyžiadanie a podlieha podpísaniu NDA.
HW musí byť dodaný v takej verzii aby jeho výrobca garantoval dostupnosť kompatibilných náhradných dielov po dobu minimálne 10 rokov od dátumu odovzdania do prevádzky.
Dodávateľ musí pre dodávané HW komponenty dodať náhradné diely v počte 25% pre každý jednotlivý typ komponentu pričom minimálny počet je 1. V prípade, že je dodaný len 1 náhradný komponent, tak je nutné zabezpečiť výmenu chybného HW v nasledujúci pracovný deň.
Pri sieťovej a automatizačnej technike sa komponentom rozumie najmenšia možná súčasť, ktorá je výrobcom identifikovaná ako užívateľsky vymeniteľný diel. Komponentom je napríklad: I/O karta na PLC, gbic, atd
Pre prípad výpočtovej techniky sa komponentom rozumie celé PC/Server a prípadné periférie ako sú monitory, klávesnice a pod.
V rámci dodávky môžu byť používané len produkty, ktoré sú riadne licencované na daný účel. Licenčný model musí byť riadne zdokumentovaný. Dodávateľ je povinný dodať všetky licencie nutné na správnu funkcionalitu a udržateľnosť dodávaného systému. Všetky licencie musia byť zaregistrované cez centrálny licenčný mail box MHTH. Táto informácia bude poskytnutá dodávateľovi po uzatvorení zmluvy a podpísaní NDA.
Všetky dodávané licencie vrátane „maintenance“ a „support“ zmlúv s výrobcom produktu musia byť vo výlučnom vlastníctve MHTH. Pri odovzdávaní diela a ani po jeho odovzdaní nesmie v rámci dodávaného systému zostať žiadny HW a SW, ktorý by nebol správne licencovaný a vo výlučnom vlastníctve MHTH.
Pri dodávke licencií od tretích strán je nutné aby prípadná „maintenance“ a „support“ zmluva bola priamo medzi MHTH a treťou stranou, alebo aspoň umožňovala neobmedzený priamy kontakt medzi MHTH a treťou stranou (výrobcom alebo jeho oficiálnym distribútorom) bez nutnosti sprostredkovania kontaktu pomocou dodávateľa systému.
Licencie MS Windows pre virtuálne servery a klientov sú zabezpečované zo strany MHTH. V prípade fyzických serverov a klientských staníc, tieto licencie dodáva dodávateľ v rámci dodávky systému. Požadované verzie OS na báze MS Windows a ich licenčný model podliehajú schváleniu zo strany MHTH.
Všetky dodávané systémy musia byť v čo najvyššej možnej miere zabezpečené voči neoprávneným zásahom a zneužitiu.
Všetky servery a klientské stanice musia mať nainštalovaný antivírusový SW používaný v MHTH. Dodávateľ musí garantovať kompatibilitu s aktuálnym AV SW používaným v MHTH. V prípade, že pre správny beh dodávaného SW sú nutné výnimky v AV nastavení, tak je potrebné tieto výnimky uviesť už v ponuke a nechať si ich schváliť MHTH. Informácia o type a verzii je dostupná pre zapísaných uchádzačov na vyžiadanie a podlieha podpísaniu NDA.
Licencie pre AV zabezpečuje MHTH.
Lokálny firewall musí zostať aktivovaný a všetky pridané prestupy musia byť riadne zdokumentované a odsúhlasené MHTH. Pre zariadenia s operačným systémom na báze MS Windows bude použitý integrovaný firewall a pre zariadenia s operačným systémom na báze Unix/Linux je nutné použiť nftables alebo iptables alebo firewalld.
Dodávateľ je povinný definovať plán záloh a údržby jednotlivých databáz tak, aby vyhovovala podmienkam dostupnosti a požiadavkám vyplývajúcim z DRP/ARP (viď kapitola 19). Plán záloh a údržby podlieha schváleniu MHTH.
Zálohovanie serverov bude vykonávané centrálnou službou v kompetencii MHTH. Pred uvedením do prevádzky je dodávateľ povinný v súčinnosti s MHTH validovať funkčnosť automatických záloh.
Dodávateľ je povinný definovať plán záloh a údržby jednotlivých klientských staníc tak, aby vyhovovala podmienkam dostupnosti a požiadavkám vyplývajúcim z DRP/ARP (viď kapitola 19). Plán záloh a údržby podlieha schváleniu MHTH.
Pred uvedením do prevádzky, musí dodávateľ poskytnúť MHTH aktuálne zálohy všetkých klientských staníc v elektronickej podobe v takom formáte aký bude odsúhlasený zo strany MHTH.
Dodávateľ je povinný definovať plán záloh a údržby jednotlivých databáz tak, aby vyhovovala podmienkam dostupnosti a požiadavkám vyplývajúcim z DRP/ARP (viď kapitola 19). Plán záloh a údržby podlieha schváleniu MHTH.
Dodávateľ je povinný definovať plán záloh a údržby jednotlivých sieťových komponentov tak, aby vyhovovala podmienkam dostupnosti a požiadavkám vyplývajúcim z DRP/ARP (viď kapitola 19). Plán záloh a údržby podlieha schváleniu MHTH.
Zálohovanie konfigurácie sieťových komponentov je v zodpovednosti MHTH.
Automatizačné komponenty ako sú napríklad PLC, konfigurovateľné frekvenčné meniče a podobne musia umožňovať zálohovanie konfigurácie. V prípade, že na zálohovanie je nutný špecializovaný SW, tak musí byť (spolu s licenciou, ak je nutná) súčasťou dodávky.
Dodávateľ je povinný definovať plán záloh a údržby automatizačných komponentov tak, aby vyhovovala podmienkam dostupnosti a požiadavkám vyplývajúcim z DRP/ARP (viď kapitola 19). Plán záloh a údržby podlieha schváleniu MHTH.
Pred uvedením do prevádzky, musí dodávateľ poskytnúť MHTH aktuálne zálohy všetkých komponentov v elektronickej podobe.
Všetky zariadenia a systémy sa musia vedieť synchronizovať pomocou protokolu NTP. Zdroj času určí MHTH.
Kryptografické prostriedky sa používajú na zabezpečenie:
a) dôvernosti údajov,
b) integrity údajov,
c) autentizácie odosielateľa (digitálny podpis),
d) nepopierateľnosti vykonanej činnosti (non-repudiation).
Kryptografické prostriedky sa používajú najmä na ochranu citlivých údajov:
a) prenášaných cez nezabezpečené prostredie (napr. internetová alebo e-mailová komunikácia),
b) uložených na lokálnych diskoch (koncové stanice, zdieľané úložiská údajov a pod.),
c) prenosných zariadeniach (notebooky, tablety, smartfóny a pod.),
d) prenosných médiách (CD, DVD, USB a pod.).
Použitý šifrovací algoritmus musí byť vhodne zvolený tak, aby zabezpečil dostatočnú úroveň ochrany údajov. Úroveň zabezpečenia údajov vyplýva z ich citlivosti, resp. klasifikačného stupňa.
Výber použitej kryptografickej metódy závisí najmä na:
a) posúdení rizík spojených s ochranou aktíva,
b) požadovanej úrovni ochrany aktíva,
c) technických možnostiach prevádzkovaných systémov a
d) ekonomickej náročnosti opatrenia vzhľadom na hodnotu chráneného aktíva.
Minimálne požiadavky kryptografickej ochrany aktív podniku sú definované nasledovne:
a) šifrovací algoritmus symetrického šifrovania: AES-256,
b) šifrovací algoritmus asymetrického šifrovania: RSA,
c) dĺžka kryptografického kľúča RSA: najmenej 2048 bitov,
d) exspirácia kryptografického kľúča: 1 rok,
e) funkcia používaná na hashovanie: SHA-256. Nasadenie kryptografických prostriedkov vykonáva:
a) zamestnanec dodávateľa v prípade externe vyvíjaného alebo nasadzovaného IS alebo RS,
b) špecialista/administrátor úseku informačných technológií MHTH v prípade interných aplikácií alebo nástrojov.
Správu nasadených kryptografických prostriedkov vykonáva špecialista/administrátor úseku informačných technológií MHTH.
O prípadných výnimkách a súvisiacich technických informáciách pre oblasť kryptovania, rozhoduje MHTH na základe interných štandardov a podkladov dodaných dodávateľom.
MHTH požaduje dodržiavať min. Odporúčania dobrej praxe v oblasti kryptografických prostriedkov, uvedených tu:
xxxxx://xxx.xxxxx.xx/xxxxxxxx/xxxxxx_xxxxx/Xxxxxxxxx%00xxxxxxxxx%00xx%00xxxxxxxxxxxxxx%00xx goritmy.pdf
16 Bezpečnostné logovanie a monitoring
Systémy musia byť konfigurované tak aby logovali všetky bezpečnostne relevantné udalosti definované nižšie.
Systémy, ktoré logujú udalosti, sa musia synchronizovať prostredníctvom vopred dohodnutého referenčného času.
Logy musia byť chránené pred neoprávneným prístupom a modifikáciou.
Ak logy obsahujú klasifikované informácie, potom môže byť zabezpečený prístup len osobám disponujúcim potrebnou autorizáciou vlastníka informácie.
Logovacie zdroje musia byť nakonfigurované tak, aby sa logovacie hlásenia, dali vytvoriť minimálne pre nasledovné bezpečnostne závažné udalosti:
• úspešné a zamietnuté pokusy o prihlásenia ako aj odhlásenia pre administrátorské aj bežné účty
• vytvorenie, zmena, zablokovanie, odblokovanie a vymazanie účtov a rolí v aplikáciách,
• zmeny hesla a/alebo zmeny certifikátov,
• zmeny oprávnení (napr. používateľské práva, oprávnenia k objektom, členstvo v skupinách),
• spúšťanie a ukončovanie procesov,
• zmeny v časovej službe,
• zmeny v nastaveniach logovania (špeciálne deaktivovanie logovania).
• všetky ostatné udalosti, ktoré osoby zodpovedné za logovací zdroj považujú za dôležité,
• chyby vzniknuté na systéme.
Okrem bezpečnostne relevantných udalostí sa musí logovať vlastná funkcia logovacieho zdroja. Všetky logy by mali byť zapisované do logovacieho mechanizmu operačného systému (Windows event log alebo Unix/Linux syslog).
16.1.1 Štruktúra logovacích hlásení
Logovacie hlásenia musia obsahovať nasledovné údaje o udalostiach: časovú značku, identifikačné znaky udalosti a opis bezpečnostne významnej udalosti.
Okrem toho by mali byť zahrnuté nasledovné udalosti: stupeň závažnosti udalosti, kategória (napr. informácia, chyba, výstraha, ...).
Logovacie hlásenia nesmú obsahovať heslá, ich „hashe“ alebo akúkoľvek formu autentifikácie používateľa.
16.1.2 Sledovanie logovacích hlásení
Dodávateľ je povinný v rámci projektu spolupracovať s Oddelením kybernetickej bezpečnosti, s ktorým sa dohodne na pripojení do systémov pre kontinuálne monitorovanie hrozbieb, príp. zasielaní logov, ktoré sú vyprodukované dodávanými systémami na systémy, ktoré v rámci MHTH centrálne spracúvajú logovacie hlásenia.
Servery, klientské stanice a sieťová infraštruktúra musí byť napojená na nástroj centrálneho monitoringu používaného v MHTH. Informácia o požiadavkách na spôsob pripojenia je dostupná pre zapísaných uchádzačov na vyžiadanie a podlieha podpísaniu NDA.
16.2.1 Servery
Každý server bude monitorovaný príslušným klientom centrálneho monitoringu. MHTH poskytne základnú šablónu monitorovaných parametrov, ktorú dodávateľ upraví tak aby klient vedel vyhodnotiť všetky neštandardné stavy indikujúce poruchu alebo stavy smerujúce k poruche.
16.2.2 Klientské stanice
Každá klientská stanica bude monitorovaná príslušným klientom centrálneho monitoringu. MHTH poskytne základnú šablónu monitorovaných parametrov, ktorú dodávateľ upraví tak aby klient vedel vyhodnotiť všetky neštandardne stavy indikujúce poruchu alebo stavy smerujúce k poruche.
16.2.3 Sieťové komponenty
Všetky switche, routre a prípadne iné konfigurovateľné komponenty musia byť napojené na centrálny monitoring pomocou protokolu SNMP V3.
16.2.4 Ostatné komponenty
Pokiaľ niektorý s dodávaných systémových komponentov nie je uvedený v predchádzajúcich podkapitolách a umožňuje napojenie na centrálny monitoring pomocou protokolu SNMP V3, tak takýto komponent musí byť napojený tiež.
17 Access a identity management
Vytváranie nových lokálnych prístupov je zakázané. Heslá do zabudovaných lokálnych prístupov musia byť pred odovzdaním diela zmenené tak, aby ich jediným držiteľom bola zodpovedná osoba v MHTH. Dodávateľ nesmie mať po odovzdaní projektu prístup k týmto heslám. Vyžaduje sa princíp RBAC (Role- based access control), teda vytvárania rolí na základe špecifických požiadaviek na prístupové oprávnenia pre každú rolu zvlášť tak, aby každý užívateľ mal iba ten level oprávnení potrebných na vykonanie vyžadovaných pracovných činností.
17.2 Vytváranie používateľov a skupín v AD
Všetci používatelia a roly v AD sú vytvárane zástupcom MHTH na základe požiadaviek dodaných zo strany dodávateľa, ktoré podliehajú predchádzajúcemu schváleniu zo strany MHTH.
17.3 Autentifikácia používateľov
Autentifikácia používateľov dodávaných systémov musí byť vykonávaná centrálne za pomoci Active Directory, ktoré určí MHTH. Všetky systémy, na ktorých sa vyžaduje manažment používateľov musia, pre tento účel, používať Active Directory. V prípade nemožnosti splniť túto požiadavku je nutné požiadať a nechať si schváliť výnimku už vo fáze ponuky.
Prístup k informáciám, ktoré dodávaný systém spracováva alebo ukladá musí byť nevyhnutne podmienený autentifikáciou a autorizáciou. Pre autorizáciu k dátam v rámci systému platia nasledovné pravidlá.
Autorizácia používateľov je vykonávaná na základe ich role, ktorú na danom systéme plnia. Tieto role sa delia na systémové a aplikačné role. Minimálne delenie rolí je nasledovné:
• Administrátor operačného systému
Takýto účet je autorizovaný na vykonávanie administratívnych zásahov do systému. Takýto administrátor nesmie mať oprávnenie spravovať, resp. používať aplikácie, ktoré môžu byť prevádzkované na systéme.
• Používateľ operačného systému
Táto rola môže byť pridelená používateľovi, ktorý má oprávnenie spravovať súbory a nastavenia aplikácie na úrovni operačného systému. Tento používateľ nesmie mať administrátorské oprávnenia na systém.
• Systémový používateľ
Táto rola môže byť pridelená používateľovi, na základe ktorého sa v rámci operačného systému alebo v rámci aplikácie spúšťa služba, ktorá vyžaduje neinteraktívnu identifikáciu a autentifikáciu používateľa. Tento používateľ môže mať oprávnenie na vykonávanie administratívnych alebo aplikačných úloh, ktoré sa vykonávajú automaticky. Tento používateľ nesmie byť použitý na interaktívne prihlásenie do systému alebo aplikácie.
• Aplikačný administrátor
Táto rola môže byť pridelená používateľovi, ktorý má oprávnenie spravovať aplikáciu. Takýto používateľ nesmie mať oprávnenie na bežné používane aplikácie. Taktiež nesmie mať oprávnenie na správu používateľov, rolí a oprávnení v rámci aplikácie
• Aplikačný administrátor oprávnení
Táto rola môže byť pridelená používateľovi, ktorý má v rámci aplikácie oprávnenie spravovať používateľské účty a role, prideľovať a odoberať oprávnenia pre používateľov a role. Takýto používateľ nesmie mať oprávnenie na bežné používane aplikácie.
• Aplikačný používateľ
Táto rola môže byť pridelená používateľovi, ktorý aplikáciu používa na účely, pre ktoré bola aplikácia vytvorená. Tento používateľ nesmie mať oprávnenia na správu aplikácie a ani na správu používateľov
Manažment jednotlivých rolí je na základe členstva užívateľských účtov v skupinách Active Directory.
Pokiaľ v špecifickom zadaní nie je uvedené inak, tak pre dodávaný systém musí dodávateľ vedieť garantovať minimálne 99.85% dostupnosť aj za predpokladu, že dodávaný systém využíva už existujúcu infraštruktúru MHTH ako je napríklad sieť alebo hypervisor. Pod systémom sa rozumie OT softvér alebo OT infraštruktúra alebo kombinácia oboch. Dostupnosť sa vždy vyhodnocuje ako dostupnosť celku a nie jeho jednotlivých častí.
Dostupnosť riadiaceho systému je počítaná podľa nasledovného vzorca:
[%]
𝑇𝑠−𝑇𝑛
= (
𝑇𝑠
∗ 100)
Ts – obdobie, počas ktorého má byť systém dostupný. Do tohto obdobia sa nezapočítavajú plánované odstávky
Tn – obdobie, počas ktorého pre samostatný závod, resp. samostatnú prevádzku objednávateľ (MHTH) nemohol systém využívať z dôvodu jeho poruchy vrátane poruchy jeho komponentov.
Doby a obdobia sa počítajú na celé (aj začaté) minúty a dostupnosť sa vyjadrí v percentách zaokrúhlene na dve desatinne miesta.
Do doby nedostupnosti riadiaceho systému Tn sa nezapočítava doba od vzniku danej poruchy do začatia prác na odstránení poruchy v prípade, že MHTH neumožnil dodávateľovi bezodkladne po požiadaní previesť odstránenie poruchy na riadiacom systéme.
Do doby nedostupnosti, v zmysle tohto dokumentu, sa taktiež nezapočítava doba nedostupnosti, ktorá bola preukázateľne spôsobená infraštruktúrou alebo systémom mimo rozsahu dodávky. Dôkazné bremeno je v takomto prípade na strane dodávateľa.
Nedostupnosť sa v rámci záruky bude vyhodnocovať za kalendárny mesiac.
Ak systém nebude za ktorékoľvek vyhodnocovaných období spĺňať podmienky dostupnosti, musí dodávateľ, v rámci záruky a bez nároku na finančnú odmenu, navrhnúť a zrealizovať nápravné opatrenie.
19 Service a continuity management
Dodávateľ musí v súčinnosti MHTH vypracovať plány obnovy z havárií systému, ktoré budú definovať, kedy nastala havária systému, a upravovať postup v takomto prípade.
Všetky DRP/ARP (Disaster / Application Recovery Plans) musia obsahovať nasledovné témy, ku ktorým musí dodávateľ pripraviť vstupy:
• krátky opis aplikácií / služby systému,
• opis architektúry systému aplikácie / služby, napr.:
- fyzická lokalita systémových komponentov,
- názov servera,
- názov databázy, inštancia databázy,
- inštancia middleware,
- rozhrania s ostatnými aplikáciami alebo systémami,
- fyzická lokalita zálohovania údajov alebo inštalačných médií a
- čísla servisných zmlúv.
• Kontaktné informácie na dodávateľa vrátane zástupcov,
• Dopad havárie systému na technologický proces
• Havarijný plán: informácie o havárii systému a aktivácii tímu zodpovedného za reakciu pri havárii.
• Detailný postup pri obnove aplikácie / služby
Pokiaľ v špecifickom zadaní nie je uvedené inak, tak pre dodávaný systém je zo strany MHTH požadované RTO 3 hodiny a RPO 24 hodín.
Dodávateľ musí dodať v rámci projektu aj komplexné testovacie scenáre spolu s návodom na testovanie systému. Takto sa zabezpečí možnosť overenia funkcionality systému po havárií rovnako ako aj pri zmenách na systéme.
Validácia navrhnutých DRP/ARP je vykonávaná a dokumentovaná MHTH za súčinnosti dodávateľa, tak aby bola overená ich vykonateľnosť v rámci požadovaných RTO/RPO.
Pri validácii DRP/ARP bude overená aj kompletnosť dodaných testovacích scenárov.
Úspešná validácia vykonateľnosti DRP/ARP spolu s úspešným testom funkčnosti je nutná podmienka na odovzdanie systému do prevádzky.
Minimálne jedenkrát za rok musí prebehnúť skúška či je zabezpečené, že systémy OT sa dajú efektívne obnoviť. Testy budú vykonávať zodpovední pracovníci MHTH. V rámci trvania záruky bude dodávateľ počas týchto testov poskytovať súčinnosť a supervíziu. V prípade odhalenia nedostatkov počas pravidelného testu počas trvania záruky, je dodávateľ povinný v rámci tejto záruky vykonať nápravné opatrenia, tak aby nedostatky boli odstránené. Validácia odstránenia nedostatkov sa potvrdí opätovným vykonaním testu.
Za plánovanie a dokumentáciu testov zodpovedá MHTH. Za kompletnosť a dodanie vykonateľnej postupnosti krokov zodpovedá dodávateľ
Všetky racky a skrine, v ktorých je umiestnená akákoľvek časť OT systému alebo infraštruktúry musia mať implementovanú signalizáciu prístupu/otvorenia dverí, tak aby bolo možné monitorovať každý prístup.
Tato informácia musí byť zaslaná ako aj do lokálneho riadiaceho systému, tak aj to nadradeného riadiaceho systému. Ďalšou alternatívou je pripojenie tejto signalizácie na centrálny monitoring.
MHTH štandard s detailnými požiadavkami bude dostupný pre zapísaných uchádzačov na vyžiadanie a podlieha podpísaniu NDA.
Na udelenie výnimky voči požiadavkám tohto dokumentu je nutný jednomyseľný súhlas Oddelenia kybernetickej bezpečnosti, Oddelenia rozvoja a prevádzky infraštruktúry a Oddelenia rozvoja a prevádzky riadiacich systémov. Udelenie výnimky nie je nárokovateľné.
Žiadosť o udelenie výnimky a príslušnú správu o výnimke musí žiadateľ priložiť už k ponuke na dodávaný systém a taktiež do systémovej resp. prevádzkovej dokumentácie. Musí byť zabezpečené, že dokumentácia o výnimke bude v prípade zmeny úloh alebo zodpovedností odovzdaná príslušnému
nástupcovi. Výnimky môžu byť udelené na dobu určitú alebo na dobu neurčitú. Výnimky týkajúce sa informačnej bezpečnosti sú určované vždy na dobu určitú. Pre výnimky udelené na dobu určitú musí žiadateľ zabezpečiť, že skôr ako uplynie stanovená lehota výnimky, odchýlka bude odstránená. Po uplynutí stanoveného obdobia výnimka stráca platnosť.
Pokiaľ je povolenie výnimky spojené s prídavnými opatreniami, ktoré určí ktorékoľvek zo schvaľujúcich oddelení, žiadateľ musí zabezpečiť aby boli v stanovenom čase realizované všetky opatrenia, ktoré sú pre schválenie záväzné. V prípade nedodržania výnimka stráca platnosť.
Žiadosť na udelenie výnimky by mala obsahovať najmenej:
• Údaje o zadaní a systéme ktorého sa výnimka týka
• Detaily o žiadateľovi
- meno a priezvisko,
- telefónne číslo,
- e-mailovú adresu.
• Opis výnimky a v prípade potreby zoznam dotknutých systémov.
• Uvedenie kapitoly (kapitol) z tohto dokumentu, ktorej sa žiadosti o udelenie výnimky týka.
• Detaily o dotknutých údajoch alebo informáciách
- klasifikácia,
- opis,
- informácia, či sa spracovávajú osobné údaje.
Žiadosti o výnimky je možné posielať na mail box Oddelenia kybernetickej bezpečnosti: xx@xxxx.xx