Smlouva o dílo – Implementace systému Extended Detection and Response (XDR)

Smlouva o dílo – Implementace systému Extended Detection and Response (XDR)

Číslo smlouvy Objednatele: 68591/2023-SŽ-GŘ-O8 Číslo smlouvy Zhotovitele: SML/2023/101

uzavřená podle ustanovení § 2586 a násl. zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „Občanský zákoník“ nebo „OZ“).

Objednatel: Správa železnic, státní organizace

zapsaná v obchodním rejstříku vedeném Městským soudem v Praze pod sp. zn.

A 48384

Praha 1 - Nové Město, Dlážděná 1003/7, PSČ 110 00 IČO 70994234, DIČ CZ70994234

zastoupená Bc. Xxxxx Xxxxxxxx, MBA, generálním ředitelem (dále též jen „Objednatel“ nebo „SŽ“)

Zhotovitel: ALEF NULA, a. s.

zapsaná v obchodním rejstříku vedeném Městským soudem v Praze, oddíl B, vložka 2727

Xxxxxxxxx 000/00, 000 00 Xxxxx XXX 61858579, DIČ CZ61858579

Bankovní spojení: XXX Číslo účtu: XXX

Zastoupená Ing. Xxxxxxx Xxxxxx, předsedou představenstva (dále též jen „Zhotovitel“ nebo „Dodavatel“)

(dále jednotlivě též jen „Strana“ nebo společně „Strany“ a „Smlouva“)

Tato Smlouva byla uzavřena na základě výsledku zadávacího řízení veřejné zakázky s názvem

„Implementace systému Extended Detection and Response (XDR)“, ev. č. veřejné zakázky ve Věstníku veřejných zakázek: Z2023-028763, č.j. veřejné zakázky 40198/2023-SŽ-GŘ-O8 (dále jen „Veřejná zakázka“ a „Zadávací řízení“) Objednatelem jako zadavatelem ve smyslu zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „ZZVZ“), neboť nabídka Dodavatele podaná na Veřejnou zakázku (dále jen „Nabídka“) byla Objednatelem vyhodnocena jako ekonomicky nejvýhodnější.

Jednotlivá ustanovení této Smlouvy tak budou vykládána s ohledem a v souladu se zadávacími podmínkami Veřejné zakázky. V případě kolize ustanovení obsažených v jednotlivých dokumentech smluvní dokumentace mají přednost ustanovení obsažená v následujících dokumentech v uvedeném pořadí (pokud není výslovně uvedeno jinak):

1) Vlastní text Smlouvy;

2) Přílohy č. 1 až 4 Smlouvy;

3) Příloha č. 5 Smlouvy – Zvláštní obchodní podmínky pro Zakázky v oblasti ICT (dále jen

„ZOP“);

1/13

Správa železnic, státní organizace

zapsána v obchodním rejstříku vedeném Městským soudem v Praze, spisová značka A 48384

Sídlo: Xxxxxxxx 0000/0, 000 00 Xxxxx 0

IČ: 709 94 234 DIČ: CZ 709 94 234

xxx.xxxxxxxxxxxxxx.xx

4) Příloha č. 6 Smlouvy – Obchodní podmínky ke Smlouvě o dílo (dále jen „OOP“);

5) Ostatní dokumenty zadávací dokumentace Veřejné zakázky či zmiňované ve Xxxxxxx.

Pokud nevyplývá ze Smlouvy jinak, mají pojmy s velkými počátečními písmeny význam definovány v ZOP, nebo OOP. Pro vyloučení jakýchkoliv pochybností Strany uvádějí, že pokud je ve Smlouvě obsažen článek se shodným názvem jako v ZOP, OOP nebo jiném smluvním dokumentu, neznamená to, že by článek Smlouvy plně nahrazoval příslušné články v jiných smluvních dokumentech, pokud není výslovně uvedeno jinak; obdobné platí pro vztahy mezi jinými smluvními dokumenty.

1 Účel Smlouvy

1.1 Objednatel jako subjekt povinný v souladu s ustanoveními § 3 písm. c) a d) zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), ve znění pozdějších předpisů (dále také „ZoKB“), musí provádět bezpečnostní opatření (§ 5 ZoKB) v rozsahu nezbytném pro zajištění kybernetické bezpečnosti informačního systému kritické informační infrastruktury a komunikačního systému kritické informační infrastruktury. Jedním ze způsobů, jak naplnit tyto povinnosti, je implementace řešení pro automatizovanou detekci a reakci na bezpečnostní incidenty v síťovém prostředí a na koncových zařízeních organizace SŽ, známé jako Extended Detection and Response (XDR).

1.2 Účelem této Smlouvy je tak zejména provedení Díla, tj. provedení Předmětu díla a poskytnutí Souvisejících plnění v takovém rozsahu a takovým způsobem, aby minimálně po dobu trvání Smlouvy došlo k naplnění bezpečnostních požadavků, jejichž naplnění je provedením Díla sledováno.

1.3 Účelem této Smlouvy je to, aby bylo Xxxx Xxxxxxxxxxxx provedeno a po dobu trvání Smlouvy udržováno funkční v souladu s požadavky vyplývajícími z:

1.3.1 právních předpisů;

1.3.2 Xxxxxxx a jejích příloh;

1.3.3 zadávací dokumentace Xxxxxxx xxxxxxx;

1.3.4 Nabídky a

1.3.5 Interních předpisů SŽ (dále jen „Interní předpisy“), přičemž se za Interní předpisy pro účely této Smlouvy považují interní předpisy SŽ, se kterými byl Xxxxxxxxxx prokazatelně seznámen. Součástí zadávací dokumentace Veřejné zakázky je interní předpis s názvem „Provozní politika prvků v působnosti systému řízení bezpečnosti informací“.

2 Předmět Smlouvy

2.1 Předmětem této Smlouvy je závazek Xxxxxxxxxxx provést na svůj náklad a nebezpečí pro Objednatele řádně a včas Dílo a závazek Objednatele Xxxx převzít a zaplatit Zhotoviteli Xxxx díla a příslušnou DPH, a to vše za podmínek stanovených v této Smlouvě.

2.2 Předmětem díla je poskytnutí vymezených činností za účelem dodávky, implementace a podpory řešení pro automatizovanou detekci a reakci na bezpečnostní incidenty v síťovém prostředí a na koncových zařízeních organizace SŽ, známé jako Extended Detection and Response (XDR). Bližší požadavky na Předmět díla jsou vymezeny zejména, nikoliv však výlučně, v části 2 a části 4 přílohy č. 1 Specifikace plnění této Smlouvy (dále jen „Příloha č. 1“).

2.3 Provedení Díla spočívá v provedení následujících oblastí dílčích činností ze strany Zhotovitele podrobně definovaných v části 4 Přílohy č. 1:

Fáze 1 Fáze 1.a

2.3.1 Před-implementační analýza dle části 4.1.1 Přílohy č. 1

Fáze 1.b

2.3.2 Instalace a konfigurace řešení dle části 4.1.2 Přílohy č. 1

Fáze 2 Fáze 2.a

2.3.3 Optimalizace bezpečnostní / detekční politiky řešení dle části 4.1.3 Přílohy č. 1

Fáze 2.b

2.3.4 Napojení na platformu Log management / SIEM dle části 4.1.4 Přílohy č. 1

Fáze 3

2.3.5 Školení dle části 4.1.5 Přílohy č. 1

Fáze 4

2.3.6 Technická podpora servisního týmu sž uvedená v části 4.2.1 Přílohy č. 1

2.3.7 Údržba řešení dle části 4.2.2 Přílohy č. 1

Fáze 5

2.3.8 Konzultace a rozvojové aktivity dle části 4.3 Přílohy č. 1.

3 Místo plnění

3.1 Místem plnění Smlouvy je především sídlo Objednatele a sídla jednotlivých organizačních složek Objednatele, nebo jakákoliv jiná místa, pokud je to potřebné či vhodné za účelem provedení Díla.

3.2 Přípravné práce je Xxxxxxxxxx oprávněn realizovat na svém vlastním technickém vybavení, což však nezakládá jakýkoliv nárok Zhotovitele na navýšení Xxxx díla v souvislosti s následnou realizací Díla u Objednatele.

4 Doba plnění

4.1 Doba trvání Smlouvy činí 5 let a 295 dnů (dále jen „doba trvání Smlouvy“) ode dne účinnosti Smlouvy. Tato Xxxxxxx však nepozbyde účinnosti dříve, než za 5 let a 85 dnů od ukončení fáze F1.b podle přílohy č. 3 Smlouvy (dále jen „Harmonogram“).

4.2 Harmonogram předpokládá pro zahájení plnění fáze F1.b připravenost virtualizační platformy na straně Objednatele, přičemž tato podmínka bude splněna prohlášením Objednatele o připravenosti virtualizační platformy vůči Zhotoviteli.

4.3 Doba trvání Smlouvy nemá vliv na existenci práv a povinností Stran, která mají vzhledem ke své povaze a okolnostem trvat i po konci doby trvání Smlouvy.

4.4 Pokud není stanoveno jinak, je Zhotovitel povinen provádět Dílo v termínech uvedených v závazném harmonogramu realizace Díla obsaženém v Harmonogramu.

4.5 Žádná ze Stran není oprávněna jednostranně měnit termíny uvedené v Harmonogramu.

5 Cena díla

5.1 Celková cena za splnění závazku Zhotovitele provést Dílo v rozsahu dle Smlouvy, tj. Cena díla, je uvedena pod položkou Xxxxxxxxx cena celkem v příloze č. 2 Smlouvy (dále jen „Příloha č. 2“).

5.2 Ceny, a to jak jednotkové ceny, tak nabídková cena celkem, obsažené v Příloze č. 2. Nabídková cena, jsou uvedeny jako maximální, nejvýše přípustné, nepřekročitelné a zahrnující veškeré náklady Zhotovitele nutné k řádnému a včasnému provedení Díla, resp. příslušného dílčího plnění (např. správní a místní poplatky, vedlejší náklady, náklady spojené s dopravou do místa plnění, včetně nákladů souvisejících s celními poplatky a s provedením všech zkoušek a testů prokazujících dodržení předepsané kvality a parametrů Předmětu plnění dle Smlouvy, náklady na licence apod. jsou všechny zahrnuty v cenách obsažených v Příloze č. 2).

5.3 Součástí Ceny díla jsou i náklady na dodávky a služby, které v zadávací dokumentaci Xxxxxxx xxxxxxx, Nabídce ani ve Xxxxxxx a jejích přílohách nejsou výslovně uvedeny, ale Xxxxxxxxxx jakožto odborník ví nebo má vědět, že jsou nezbytné pro řádné a včasné provedení Díla. Zhotovitel nese veškeré náklady nutně nebo účelně vynaložené při plnění závazku ze Smlouvy včetně správních poplatků.

5.4 Ceny obsažené v Příloze č. 2 jsou uvedeny bez DPH. V případě změny zákonné sazby DPH není třeba uzavírat dodatek ke Smlouvě, ledaže o to Objednatel požádá.

5.5 Zhotovitel odpovídá za to, že sazba DPH je stanovena v souladu s platnými právními předpisy.

5.6 Změna Ceny díla dle části 5 odst. 19.2 OOP se nepřipouští.

6 Platební podmínky

6.1 Zhotovitel je oprávněn doručit Objednateli Výzvu k úhradě v následujících platebních milnících, v níže definovaných výších a za níže vymezených podmínek:

6.1.1 První platební milník: Výzva k úhradě ve výši jednotkové ceny za položku v Příloze č. 2: Fáze 1 - Náklady na licence nabízeného řešení NDR, Náklady na technické podpory výrobce nabízeného řešení NDR (60 měsíců), Náklady na licence nabízeného řešení EDR, Náklady na technické podpory výrobce nabízeného řešení EDR (60 měsíců), Náklady na hardware, Náklady na technické podpory výrobce hardware (60 měsíců), Před-implementační analýza, Instalace a konfigurace řešení dle přílohy č. 1 Smlouvy, a to nejdříve po akceptaci (bez výhrad) Fáze 1 (tedy Fáze 1.a a Fáze 1.b), která je tvořena činnostmi uvedenými v části 4.1.1 a 4.1.2 Přílohy č. 1;

6.1.2 Druhý platební milník: Výzva k úhradě ve výši jednotkové ceny za položku v Příloze č. 2: Fáze 2 - Optimalizace bezpečnostní / detekční politiky řešení, Napojení na platformu Log management / SIEM, a to nejdříve po akceptaci (bez výhrad) Fáze 2 (tedy Fáze 2.a a Fáze 2.b), která je tvořena činnostmi uvedenými v části 4.1.3 až 4.1.4 Přílohy č. 1;

6.1.3 Třetí platební milník: Výzva k úhradě ve výši jednotkové ceny za položku v Příloze č. 2: Fáze 3 - Školení (technického servisního týmu Zadavatele SŽ a týmu Security Operations Center), která je tvořena činnostmi uvedenými v části

4.1.5 Přílohy č. 1.

6.2 Zhotovitel je dále oprávněn doručit Objednateli Výzvu k úhradě za poskytování služeb Technická podpora servisního týmu SŽ dle čl. 4.2.1. Přílohy č. 1 a čl. 11 této Smlouvy, a Údržba řešení dle čl. v části 4.2.2. Přílohy č. 1 této Smlouvy, a to opakovaně po dobu trvání Smlouvy po uplynutí každého 1 měsíce ode dne akceptace (bez výhrad) Fáze 2.a. Každá Výzva k úhradě dle předchozí věty může být vystavena ve výši jednotkové ceny za

položku dle Přílohy č. 2 této Smlouvy: Technická podpora servisního týmu zadavatele a Údržba řešení.

6.3 Zhotovitel je dále oprávněn doručit Objednateli Výzvu k úhradě po akceptaci (bez výhrad) každého plnění na základě Objednávky Konzultací a rozvojových aktivit dle čl. 12 této Smlouvy, a to ve výši součinu počtu MD dle skutečně provedených MD (nejvýše dle Objednávky) a ceny za jednu MD dle příslušné položky ceny Konzultace a rozvojové aktivity uvedené Příloze č. 2 této Smlouvy.

6.4 Výzva k úhradě musí být fakturou nebo daňovým dokladem. Kromě náležitostí účetního či daňového dokladu musí být Výzva k úhradě označena registračním číslem projektu: CZ.06.01.01/00/22_005/0000104. Pokud je Výzva k úhradě hrazena z více zdrojů, budou na ní uvedena všechna čísla projektů. Objednatel je oprávněn čísla projektu aktualizovat v průběhu trvání této Smlouvy a Zhotovitel je povinen tuto skutečnost akceptovat a zohlednit v rámci prováděné fakturace.

6.5 Výzvu k úhradě doručí Zhotovitel Objednateli jedním z následujících způsobů:

6.5.1 V listinné podobě na adresu:

Správa železnic, státní organizace Centrální finanční účtárna Čechy Náměstí Xxxx Xxxxxxx 217

530 02 Pardubice

6.5.2 V elektronické podobě na adresu: xXxxxxxxxxXXX@xxxxxxxxxxxxxx.xx

6.5.3 prostřednictvím datové schránky: uccchjm

6.6 Splatnost každé Výzvy k úhradě se sjednává na 60 kalendářních dnů od jejího doručení Objednateli. V případě, že Výzva k úhradě nebude mít odpovídající náležitosti, je Objednatel oprávněn ve lhůtě splatnosti ji vrátit Zhotoviteli s vytknutím nedostatků, aniž by se dostal do prodlení se splatností. Lhůta splatnosti počíná běžet znovu od okamžiku doručení opravené či doplněné Výzvy k úhradě Objednateli.

6.7 Zhotovitel, poskytovatel zdanitelného plnění, je povinen bezprostředně, nejpozději do 2 (slovy: dvou) pracovních dnů od zjištění svého úpadku, popř. od vydání rozhodnutí správce daně, že je Zhotovitel nespolehlivým plátcem dle § 106a zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů (dále jen „ZDPH“), oznámit takovou skutečnost prokazatelně Objednateli, příjemci zdanitelného plnění. Porušení této povinnosti je Xxxxxxxx považováno za podstatné porušení Smlouvy.

6.8 Zhotovitel se zavazuje, že bankovní účet jím určený pro zaplacení jakéhokoliv závazku Objednatele na základě Smlouvy bude od data podpisu Smlouvy do ukončení její platnosti zveřejněn způsobem umožňujícím dálkový přístup ve smyslu § 96 odst. 2 ZDPH, v opačném případě je Zhotovitel povinen sdělit Objednateli jiný bankovní účet řádně zveřejněný ve smyslu § 96 ZDPH.

6.9 Strany se dohodly na tom, že Xxxxxxxxxx není oprávněn činit jednostranná započtení svých pohledávek vzniklých na základě Smlouvy či v souvislosti s ní vůči jakýmkoliv pohledávkám Objednatele. Pohledávky a nároky Zhotovitele vzniklé na základě Smlouvy či v souvislosti s ní nesmějí být Zhotovitelem postoupeny třetím osobám, zastaveny, nebo s nimi nesmí být jinak disponováno bez předchozího písemného souhlasu Objednatele (zahrnuje i zákaz Zhotovitele postoupit Smlouvu). Jakýkoliv právní úkon učiněný Xxxxxxxxxxxx v rozporu s tímto ustanovením bude považován za podstatné porušení Smlouvy.

6.10 Zhotovitel se rovněž zavazuje zajistit řádné a včasné plnění finančních závazků vůči svým Poddodavatelům, prostřednictvím kterých bude realizovat Dílo, resp. jeho část dle této Smlouvy. Za řádné a včasné plnění dle předcházející věty se považuje plné uhrazení Poddodavatelem řádně vystavených faktur za předmět smlouvy, resp. jeho část, a to vždy do 60 kalendářních dnů od obdržení platby ze strany Objednatele za konkrétní plnění předmětu smlouvy, resp. jeho části.

7 Akceptační řízení

7.1 Akceptačnímu řízení dle části 8 ZOP a tohoto článku Smlouvy podléhají Fáze definované v čl. 2 odst. 2.3.1 až 2.3.7. této Smlouvy, tj. Fáze 1.a, Fáze 1.b, Fáze 2.a, Fáze 2.b, Fáze 3 a Fáze 4. Pro vyloučení všech pochybností Strany výslovně uvádějí, že Fáze 1.a, Fáze 1.b, Fáze 2.a, Fáze 2.b, Fáze 3 a Fáze 4 podléhají samostatnému Akceptačnímu řízení.

7.2 Každá Fáze plnění podléhají samostatnému Akceptačnímu řízení se považuje za ukončenou akceptací (bez výhrad) posledního dílčího plnění uvedeného pro příslušnou Fázi v části 4 Přílohy č. 1 této Smlouvy. Akceptační kritéria pro každou dílčí část jednotlivých Fází vyplývají z části 4 Přílohy č. 1 této Smlouvy, kdy Xxxxxxxxx předá Objednateli všechny části plnění uvedené v kategorii „Výstupy“. U Fáze 4 předá Dodavatel Objednateli vždy do 5 dnů od skončení příslušného měsíce poskytování služeb vždy měsíční výkaz shrnující poskytnutí dané služby za tento měsíc.

7.3 Zhotovitel bere na vědomí, že v rámci Předmětu díla může dojít k upřesnění Předmětu díla, resp. Akceptačních kritérií jednotlivých Fází. Vzhledem ke skutečnosti uvedené v předchozí větě nemohou být veškerá Akceptační kritéria vymezena zcela vyčerpávajícím způsobem. Xxxxxxxxxx proto bere na vědomí skutečnosti uvedené v tomto odstavci a zavazuje se v tomto ohledu postupovat v souladu s principy „best practice“ a zohledňovat veškeré připomínky Objednatele, které lze s ohledem na účel Smlouvy považovat za oprávněné. Zhotovitel dále bere na vědomí, že vzhledem ke skutečnostem uvedeným v tomto odstavci mohou být v rámci Akceptačního řízení vzneseny Objednatelem výhrady, jejichž povaha bude bránit akceptaci a jejichž důsledkem tak může být prodloužení doby Akceptačního řízení. Objednatel se zavazuje poskytnout Zhotoviteli součinnost při projednání připomínek k Předmětu díla i ve fázích přípravy.

7.4 Akceptačnímu řízení dle části 8 ZOP a tohoto článku Smlouvy podléhají rovněž práce provedené na základě Objednávek Konzultací a rozvojových aktivit dle článku 12 Smlouvy. Akceptační kritéria vyplývají ze specifikace prací uvedených v Objednávce.

7.5 Posuzování jakýchkoliv Akceptačních kritérií je nutno provádět s ohledem na účel Smlouvy.

8 Licenční ujednání

8.1 Pokud jsou výstupy dílčích činností ze strany Zhotovitele podrobně definované v části 4 Přílohy č. 1 této Smlouvy, Autorským dílem, uplatní se čl. 6.2. ZOP.

8.2 Zhotovitel prohlašuje a zavazuje se, že je a bude plně oprávněn disponovat právy duševního vlastnictví týkajícími se Díla, včetně práv autorských, a zavazuje se zajistit řádné a nerušené užívání Díla Objednatelem, včetně zajištění souhlasů všech nositelů práv duševního vlastnictví. Zhotovitel je povinen Objednateli uhradit jakékoli majetkové a nemajetkové újmy, vzniklé v důsledku toho, že by Objednatel nemohl Dílo nebo jakoukoli jeho část užívat řádně a nerušeně.

8.3 Zhotovitel se zavazuje, že při provádění Díla neporuší práva třetích osob, která těmto osobám mohou plynout z práv k duševnímu vlastnictví, a to po celou dobu trvání autorských práv k Dílu. Za případné porušení této povinnosti, a to i nastalé v průběhu užívání Díla Objednatelem, bude vůči takovým třetím osobám odpovědný výhradě Zhotovitel. Pokud budou práva třetích osob váznout na podkladech, materiálech a dalších

předmětech, které Zhotoviteli poskytne Objednatel bez toho, aby jej na tyto skutečnosti upozornil, ponese odpovědnost za případné porušení práv třetích osob Objednatel.

9 Školení

9.1 Objednatel požaduje provedení školení ze strany Zhotovitele, jehož parametry jsou podrobněji vymezeny v čl. 4.1.5 Přílohy č. 1 této Smlouvy.

10 Helpdesk

10.1 Zhotovitel se zavazuje nejpozději do dne účinnosti Smlouvy založit a po celou dobu trvání Smlouvy udržovat v provozu Helpdesk, a to za podmínek dle části 10 ZOP.

10.2 Zhotovitel se zavazuje zajišťovat Helpdesk v Režimu 1 ve smyslu části 10 ZOP.

10.3 Helpdesk bude provozován ve třetí úrovni (L3) podpory ve smyslu části 10 ZOP.

11 Technická podpora servisního týmu SŽ a Údržba řešení

11.1 Zhotovitel se zavazuje v souladu s částí 4.2.1 a 4.2.2. Přílohy č. 1 této Smlouvy poskytovat Objednateli Technickou podpora servisního týmu SŽ a Údržbu řešení, a to ode dne akceptace (bez výhrad) Fáze 2 po dobu 60 měsíců.

11.2 Technická podpora servisního týmu SŽ a Údržba řešení spočívá zejména v přijímání hlášení o Incidentech přes Helpdesk a jejich následném vyřešení v souladu s podmínkami této Smlouvy.

11.3 Způsob nahlášení Incidentu je stanoven v části 11 ZOP, přičemž Ohlašovatel určí kategorii Incidentu dle odst. 1.1.19 ZOP. Určení kategorie Incidentu může být změněno, pokud Zhotovitel prokáže, že kategorie Incidentu je jiná.

11.4 Incidenty a Požadavky budou řešeny podle servisního modelu B1 vymezeného v části 12 ZOP.

12 Služby Konzultace a rozvojové aktivity

12.1 Zhotovitel se zavazuje poskytovat Služby konzultace a rozvojové aktivity na vyžádání, které jsou blíže vymezeny v části 4.3 Přílohy č. 1 této Smlouvy.

12.2 Maximální souhrn Služeb konzultace a rozvojových aktivit na vyžádání činí 50 MD za celou dobu trvání Smlouvy ode dne účinnosti Smlouvy.

12.3 Objednatel v případě zájmu o provedení prací v rámci Služeb konzultace a rozvojových aktivit na vyžádání doručí Zhotoviteli objednávku prostřednictvím e-mailu Kontaktních osob uvedených v čl. 14 této Smlouvy se specifikací požadovaných prací v části 4.3 Přílohy č. 1 této Smlouvy, termínem provedení těchto prací a předpokládanou časovou náročností vyjádřenou v MD (dále jen „Objednávka“).

12.4 Zhotovitel se zavazuje bez zbytečného odkladu projednat s Objednatelem své případné připomínky k Objednávce, přičemž je povinen postupovat v souladu s principy „best practice“ a s ohledem na účel Smlouvy. Objednatel je povinen oprávněné připomínky Zhotovitele zohlednit v obsahu Objednávky.

12.5 V případě, že Zhotovitel (již) nemá žádné oprávněné připomínky k Objednávce, je povinen Objednávku nejpozději do 3 pracovních dnů písemně přijmout prostřednictvím e-mailu Kontaktních osob uvedených v čl. 14 této Smlouvy. Přijmutím Objednávky vzniká Zhotoviteli povinnost provést v Objednávce specifikované práce, a to při dodržení stanovených termínů a stanovené časové náročnosti vyjádřené v MD.

12.6 Na provedení prací dle Objednávky a s tím souvisejícího práva a povinnosti Stran se v rozsahu, v jakém je to možné, použijí ustanovení této Smlouvy. Zhotovitel je tak především, nikoliv však výlučně, povinen předložit provedené práce k Akceptačnímu řízení

a poskytnout ve vztahu k těmto pracím Objednateli licenci či jiná práva z duševního vlastnictví v rozsahu dle čl. 7.1 této Smlouvy.

13 Účast poddodavatelů a realizační tým

13.1 Zhotovitel je oprávněn plnit tuto Smlouvu výlučně prostřednictvím Poddodavatelů uvedených v příloze č. 4 této Smlouvy – Seznam poddodavatelů.

13.2 Před zapojením nového Poddodavatele do plnění Smlouvy musí být Objednateli předložen nový seznam poddodavatelů, který bude tvořit přílohu č. 4 této Smlouvy, a tento seznam musí být Objednatelem písemně schválen. Tím nejsou dotčeny dodatečné podmínky pro změnu Poddodavatele, jehož prostřednictvím Zhotovitel prokazoval kvalifikaci ve Veřejné zakázce, uvedené v části 13 ZOP.

13.3 Pravidla pro realizační tým se řídí částí 14 ZOP

14 Komunikace stran

14.1 Každá ze Stran jmenuje Kontaktní osoby, které budou vystupovat jako zástupci Stran a prostřednictvím kterých bude probíhat veškerá komunikace předpokládaná touto Smlouvou nebo ZOP. Kontaktní osoby zastupují Stranu ve smluvních a technických záležitostech souvisejících s plněním předmětu Smlouvy, zejména podávají a přijímají informace o průběhu plnění Smlouvy (dále jen „Kontaktní osoby“).

14.2 Kontaktními osobami za Objednatele jsou:

• ve věcech smluvních: XXX, XXX, XXX

• ve věcech technických: XXX, XXX, XXX

• ve věcech kybernetické bezpečnosti: XXX, XXX, XXX

Kontaktními osobami za Zhotovitele jsou:

• ve věcech smluvních: XXX, XXX, XXX

• ve věcech technických: XXX, XXX, XXX

• ve věcech kybernetické bezpečnosti: XXX, XXX, XXX

14.3 Každá ze Stran má právo změnit jí jmenované Kontaktní osoby, musí však o každé změně vyrozumět písemně druhou Stranu. Změna Kontaktních osob je vůči druhé Straně účinná okamžikem, kdy o ní byla písemně vyrozuměna; v případě změny Kontaktní osoby není třeba uzavírat dodatek ke Smlouvě.

15 Smluvní pokuty

15.1 Cenou pro účely stanovení výše smluvních pokut dle části 16 ZOP a části 20 OOP se rozumí Cena díla, není-li výslovně stanoveno jinak.

16 Ukončení smluvního vztahu

16.1 Strany výslovně sjednávají, že Objednatel může do okamžiku akceptace (bez výhrad) Fáze 3 odstoupit od Smlouvy na základě zákonných či ve Smlouvě a jejích přílohách vymezených důvodů rovněž ve vztahu ke všem již akceptovaným dílčím plněním, tj. zejména ve vztahu k plněním v rámci Fáze 1 a Fáze 2.

16.2 Objednatel je oprávněn odstoupit od Smlouvy, pokud dojde k významné změně ovládání Dodavatele podle § 71 a násl. zákona č. 90/2012 Sb., o obchodních korporacích, ve znění pozdějších předpisů, nebo změně vlastnictví zásadních aktiv, využívaných Dodavatelem k plnění Smlouvy a změně oprávnění nakládat s těmito aktivy, či dojde ke změně ekvivalentní změnám výše uvedeným a tato změna bude Objednatelem vyhodnocena jako riziko bezpečnosti informací, které nelze odstranit jiným opatřením; toto ustanovení se uplatní i pro případ, že Xxxxxxxxx o takových změnách dopředu a včas neinformuje Objednatele.

16.3 Dodavatel se zavazuje dle pokynů Objednatele v souvislosti s ukončením smluvního vztahu založeného touto Smlouvou (z jakéhokoliv důvodu) provádět činnosti spočívající v součinnosti při ukončení této Smlouvy (exit plán), a to při přípravě a předání novému Dodavateli, nebo Objednateli.

16.4 Činnosti dle čl. 16.3 této Smlouvy budou provedeny v souladu s výstupem před- implementační analýzy dle čl. 4.1.1 Přílohy č. 1 této Smlouvy a jsou již zahrnuty v Ceně díla.

16.5 Dodavatel se zavazuje součinnost dle článku 16.3 této Xxxxxxx poskytovat s odbornou péčí, zodpovědně a do doby úplného převzetí novým dodavatelem, nebo Objednatelem.

16.6 Nesplnění kteréhokoliv požadavku na technické funkcionality řešení uvedené v kapitole 2.3.4. Přílohy č. 1 této Smlouvy bude to považováno za hrubé porušení povinností a bude důvodem pro odstoupení od této Smlouvy.

16.7 Další pravidla pro ukončení smluvního vztahu stanoví část 18 ZOP.

17 Kybernetická bezpečnost

17.1 Zhotovitel se zavazuje k zachovávání požadavků kybernetické bezpečnosti zejména dle části 20 ZOP.

17.2 Zhotovitel je významným dodavatelem, zavazuje se tedy i k zachovávání požadavků kybernetické bezpečnosti dle části 20 ZOP vztahujících se k významným dodavatelům.

18 Ochrana osobních údajů

18.1 Pokud bude v rámci plnění této Smlouvy docházet ke zpracování osobních údajů, zavazuje se Zhotovitel dodržovat opatření dle části 21 ZOP.

19 Ochrana důvěrných informací

19.1 Zhotovitel se zavazuje k ochraně důvěrných informací dle části 22 ZOP.

20 Střet zájmů, povinnosti Zhotovitele v souvislosti s konfliktem na Ukrajině

20.1 Zhotovitel prohlašuje, že není obchodní společností, ve které veřejný funkcionář uvedený v ust. § 2 odst. 1 písm. c) zákona č. 159/2006 Sb., o střetu zájmů, ve znění pozdějších předpisů (dále jen „Zákon o střetu zájmů“), nebo jím ovládaná osoba vlastní podíl představující alespoň 25 % účasti společníka v obchodní společnosti, a že žádní poddodavatelé, jimiž prokazoval kvalifikaci v zadávacím řízení na zadání Veřejné zakázky, nejsou obchodní společností, ve které veřejný funkcionář uvedený v ust. § 2 odst. 1 písm. c) Zákona o střetu zájmů nebo jím ovládaná osoba vlastní podíl představující alespoň 25 % účasti společníka v obchodní společnosti.

20.2 Zhotovitel prohlašuje, že on, ani žádný z jeho poddodavatelů nebo jiných osob, jejichž způsobilost byla využita ve smyslu evropských směrnic o zadávání veřejných zakázek, nejsou osobami:

20.2.1 dle článku 5k nařízení Rady (EU) č. 833/2014 ze dne 31. července 2014 o omezujících opatřeních vzhledem k činnostem Ruska destabilizujícím situaci na Ukrajině, ve znění pozdějších předpisů, jimž se zakazuje zadat nebo dále plnit jakoukoli veřejnou zakázku nebo koncesní smlouvu spadající do oblasti působnosti směrnic o zadávání veřejných zakázek, jakož i čl. 10 odst. 1, 3, odst. 6 písm. a) až e), odst. 8, 9 a 10, článků 11, 12, 13 a 14 směrnice 2014/23/EU, čl. 7 písm. a) až d), článku 8, čl. 10 písm. b) až f) a h) až j) směrnice 2014/24/EU, článku 18, čl. 21 písm. b) až e) a g až i), článků 29 a 30 směrnice 2014/25/EU a čl. 13 písm. a) až d), f) až h) a j) směrnice 2009/81/ES a hlavy VII nařízení Evropského parlamentu a Rady (EU, Euratom) 2018/1046,

20.2.2 dle článku 2 nařízení Rady (EU) č. 269/2014 ze dne 17. března 2014, o omezujících opatřeních vzhledem k činnostem narušujícím nebo ohrožujícím územní celistvost, svrchovanost a nezávislost Ukrajiny, ve znění pozdějších předpisů, a dalších prováděcích předpisů k tomuto nařízení Rady (EU) č. 269/2014 (dále jen „Sankční seznamy“).

20.3 Je-li Zhotovitelem sdružení více osob, platí podmínky dle odstavce 20.1 a 20.2 této Smlouvy také jednotlivě pro všechny osoby v rámci Zhotovitele sdružené, a to bez ohledu na právní formu tohoto sdružení.

20.4 Přestane-li Zhotovitel nebo některý z jeho poddodavatelů nebo jiných osob, jejichž způsobilost byla využita ve smyslu evropských směrnic o zadávání veřejných zakázek, splňovat podmínky dle tohoto článku Smlouvy, oznámí tuto skutečnost bez zbytečného odkladu, nejpozději však do 3 pracovních dnů ode dne, kdy přestal splňovat výše uvedené podmínky, Objednateli.

20.5 Zhotovitel se dále zavazuje postupovat při plnění této Smlouvy v souladu s Nařízením Rady (ES) č. 765/2006 ze dne 18. května 2006 o omezujících opatřeních vzhledem k situaci v Bělorusku a k zapojení Běloruska do ruské agrese proti Ukrajině, ve znění pozdějších předpisů, a dalších prováděcích předpisů k tomuto nařízení Rady (EU) č. 269/2014.

20.6 Zhotovitel se dále ve smyslu článku 2 nařízení Rady (EU) č. 269/2014 ze dne 17. března 2014, o omezujících opatřeních vzhledem k činnostem narušujícím nebo ohrožujícím územní celistvost, svrchovanost a nezávislost Ukrajiny, ve znění pozdějších předpisů, zavazuje, že finanční prostředky ani hospodářské zdroje, které obdrží od Objednatele na základě této Smlouvy a jejích případných dodatků, nezpřístupní přímo ani nepřímo fyzickým nebo právnickým osobám, subjektům či orgánům s nimi spojeným uvedeným v Sankčních seznamech, nebo v jejich prospěch.

20.7 Ukáží-li se prohlášení Zhotovitele dle odstavce 20.1 a 20.2 této Smlouvy jako nepravdivá nebo poruší-li Zhotovitel svou oznamovací povinnost dle odstavce 20.4. nebo povinnosti dle odstavců 20.5 nebo 20.6 této Smlouvy, je Objednatel oprávněn odstoupit od této Smlouvy. Zhotovitel je dále povinen zaplatit za každé jednotlivé porušení povinností dle předchozí věty smluvní pokutu ve výši 5 % procent z Ceny díla (Cena bez DPH) sjednané dle této Smlouvy. Ustanovení § 2004 odst. 2 Občanského zákoníku a § 2050 Občanského zákoníku se nepoužijí.

21 Přímé platby poddodavatelům

21.1 Zhotovitel je povinen uhradit své závazky vůči poddodavatelům ve sjednané výši za sjednaných podmínek.

21.2 Objednatel si v souladu s § 106 ZZVZ vyhrazuje možnost úhrady splatných částek odpovídajícím plněním poskytnutých ze strany poddodavatele, a to na základě písemné žádosti poddodavatele, jestliže je Zhotovitel v prodlení s úhradou příslušné částky poddodavateli po dobu nejméně 30 dnů.

21.3 Poddodavatel může Objednatele požádat o úhradu splatné částky pouze za takové plnění, které již bylo poskytnuto.

21.4 Přímá platba poddodavateli bude Objednatelem provedena na základě oznámení vystaveného poddodavatelem Objednateli, které bude obsahovat informaci o výši částky, která má být přímo uhrazena poddodavateli (dále jen „částka k úhradě“) a podloženou kopii faktury vystavené poddodavatelem Zhotoviteli se všemi zákonem požadovanými náležitostmi. Nedílnou součástí faktury bude i kopie dokladu o existujícím závazku mezi Zhotovitelem a poddodavatelem, výše sjednané ceny (případně cen dílčích plnění) ve vazbě na plnění předmětu této Smlouvy a informace o tom, kdy byla částka, kterou měl Xxxxxxxxxx poddodavateli uhradit, splatná.

21.5 Částka k úhradě nesmí být vyšší než částka odpovídající skutečně poskytnutému plnění.

21.6 Objednatel informuje Xxxxxxxxxxx bez zbytečného odkladu o skutečnosti, že obdržel oznámení poddodavatele k přímé úhradě poddodavateli. V případě, že Zhotovitel do

10 dnů ode dne obdržení této informace od Objednatele neprokáže, že tvrzení uváděná poddodavatelem v žádosti o přímou platbu jsou nesprávná, má se za to, že s provedením přímé úhrady poddodavateli souhlasí.

21.7 Splatnost částky k úhradě činí 60 dnů ode dne doručení žádosti poddodavatele k přímě úhradě. Objednatel je oprávněn před uplynutím lhůty splatnosti vrátit oznámení, které neobsahuje požadované náležitosti nebo obsahuje nesprávné údaje. Objednatel je rovněž oprávněn vrátit poddodavateli oznámení v případě, že Xxxxxxxxxx prokázal, že tvrzení poddodavatele uvedená v oznámení jsou nesprávná. Oprávněným vrácením oznámení přestává běžet lhůta splatnosti.

21.8 V případě, že částka k úhradě již byla uhrazena Zhotoviteli, Objednatel ji uhradí poddodavateli, a následně bude o částku k úhradě snížena celková odměna Zhotovitele, a to formou započtení proti pohledávce nebo pohledávkám Zhotovitele vzniklých na základě plnění této Smlouvy. O zápočtu proti pohledávce Zhotovitele musí Objednatel Zhotovitele písemně informovat. Není-li již budoucí platba, kterou by Objednatel mohl započíst proti své pohledávce vůči Zhotoviteli, představuje částka k úhradě výši smluvní pokuty za nesplnění povinnosti dle čl. 21.1 této Smlouvy a Xxxxxxxxxx se zavazuje tuto smluvní pokutu uhradit nejpozději do 15 dnů ode dne doručení výzvy k zaplacení.

22 Další povinnosti Zhotovitele

22.1 Zhotovitel je povinen uchovat veškerou dokumentaci související s plněním Smlouvy na veřejnou zakázku včetně účetních dokladů minimálně do 31. 12. 2035.

22.2 Zhotovitel je povinen minimálně do 31. 12. 2035 poskytovat požadované informace a dokumentaci související s plněním Smlouvy zaměstnancům nebo zmocněncům pověřených orgánů (Centra, Ministerstvo pro místní rozvoj ČR, Ministerstvo financí ČR, Evropská komise, Evropský účetní dvůr, Nejvyššího kontrolního úřadu, příslušného orgánu finanční správy a dalších oprávněných orgánů státní správy) a je povinen vytvořit výše uvedeným osobám podmínky k provedení kontroly vztahující se k realizaci projektu a poskytnout jim při provádění kontroly součinnost.

22.3 Zhotovitel je povinen při plnění předmětu plnění Smlouvy dodržovat pracovněprávní předpisy, a to zejména, nikoliv však výlučně, předpisy upravující mzdy zaměstnanců, pracovní dobu, dobu odpočinku mezi směnami, placené přesčasy, bezpečnost práce apod. Zhotovitel je dále povinen zajistit férové pracovní podmínky a odpovídající úroveň bezpečnosti práce pro všechny osoby podílející se na plnění Smlouvy. Zhotovitel se zavazuje výše uvedené zajistit i u svých poddodavatelů.

22.4 Plnění povinností dle čl. 22.3 Xxxxxxx je Zhotovitel povinen prokázat kdykoli do 5 pracovních dnů od doručení písemné výzvy Objednatele, a to prostřednictvím všech potřebných dokladů dle aktuálních právních předpisů, resp. též s příslušnými výstupy ze mzdového a účetního systému Zhotovitele.

23 Závěrečná ujednání

23.1 Strany berou na vědomí, že tato Xxxxxxx podléhá uveřejnění v registru smluv podle zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv, ve znění pozdějších předpisů (dále jen

„ZRS“), a současně souhlasí se zveřejněním údajů o identifikaci Stran, předmětu Xxxxxxx, jeho ceně či hodnotě a datu uzavření této Smlouvy.

23.2 Zaslání Smlouvy správci registru smluv k uveřejnění v registru smluv zajišťuje obvykle Objednatel. Nebude-li tato Smlouva zaslána k uveřejnění a/nebo uveřejněna prostřednictvím registru smluv, není žádná ze Stran oprávněna požadovat po druhé Straně náhradu škody ani jiné újmy, která by jí v této souvislosti vznikla nebo vzniknout mohla.

23.3 Strany výslovně prohlašují, že údaje a další skutečnosti uvedené v této Smlouvě, vyjma částí označených ve smyslu následujícího odstavce této Smlouvy, nepovažují za obchodní tajemství ve smyslu ustanovení § 504 Občanského zákoníku (dále jen

„obchodní tajemství“), a že se nejedná ani o informace, které nemohou být v registru smluv uveřejněny na základě ustanovení § 3 odst. 1 ZRS.

23.4 Jestliže Strana označí za své obchodní tajemství část obsahu Smlouvy, která v důsledku toho bude pro účely uveřejnění Smlouvy v registru smluv znečitelněna, nese tato Strana odpovědnost, pokud by Smlouva v důsledku takového označení byla uveřejněna způsobem odporujícím ZRS, a to bez ohledu na to, která ze stran Smlouvu v registru smluv uveřejnila. S částmi Smlouvy, které druhá Strana neoznačí za své obchodní tajemství před uzavřením této Smlouvy, nebude Objednatel jako s obchodním tajemstvím nakládat a ani odpovídat za případnou škodu či jinou újmu takovým postupem vzniklou. Označením obchodního tajemství ve smyslu předchozí věty se rozumí doručení písemného oznámení druhé Strany Objednateli obsahujícího přesnou identifikaci dotčených částí Smlouvy včetně odůvodnění, proč jsou za obchodní tajemství považovány. Druhá Strana je povinna výslovně uvést, že informace, které označila jako své obchodní tajemství, naplňují současně všechny definiční znaky obchodního tajemství, tak jak je vymezeno v ustanovení § 504 Občanského zákoníku, a zavazuje se neprodleně písemně sdělit Objednateli skutečnost, že takto označené informace přestaly naplňovat znaky obchodního tajemství.

23.5 Osoby uzavírající tuto Smlouvu za Strany souhlasí s uveřejněním svých osobních údajů, které jsou uvedeny v této Smlouvě, spolu se Xxxxxxxx v registru smluv. Tento souhlas je udělen na dobu neurčitou.

23.6 Tato Smlouva je vyhotovena v elektronické podobě, přičemž obě Strany obdrží její elektronický originál opatřený elektronickými podpisy. V případě, že tato Smlouva z jakéhokoli důvodu nebude vyhotovena v elektronické podobě, bude sepsána ve třech vyhotoveních, přičemž jedno vyhotovení obdrží Dodavatel a dvě vyhotovení Objednatel.

23.7 Veškerá práva a povinnosti Stran vyplývající ze Smlouvy se řídí českým právním řádem.

23.8 Smluvní vztahy neupravené Xxxxxxxx se řídí Občanským zákoníkem a dalšími právními předpisy.

23.9 Všechny spory vznikající ze Smlouvy a v souvislosti s ní budou dle vůle Stran rozhodovány soudy České republiky, jakožto soudy výlučně příslušnými.

23.10 Je-li nebo stane-li se jakékoli ustanovení Smlouvy neplatným, nezákonným nebo nevynutitelným, netýká se tato neplatnost a nevynutitelnost zbývajících ustanovení Smlouvy. Strany se tímto zavazují nahradit do 5 (slovy: pěti) pracovních dnů po doručení výzvy druhé Strany jakékoli takové neplatné, nezákonné nebo nevynutitelné ustanovení ustanovením, které je platné, zákonné a vynutitelné a má stejný nebo alespoň podobný obchodní a právní význam.

23.11 Smlouvu lze měnit pouze písemnými dodatky.

23.12 Tato Smlouva nabývá platnosti okamžikem podpisu poslední ze Xxxxx. Je-li Smlouva uveřejňována v registru smluv, nabývá účinnosti dnem uveřejnění v registru smluv, jinak je účinná od okamžiku uzavření.

Přílohy

1. Specifikace plnění této Smlouvy

2. Specifikace nabídkové ceny

3. Harmonogram

4. Seznam poddodavatelů

5. Zvláštní obchodní podmínky pro Zakázky v oblasti ICT

6. Obchodní podmínky ke Smlouvě o dílo

7. Realizační tým

8. Platforma 2.0

Za Objednatele: Za Dodavatele:

digitálně podepsáno dne digitálně podepsáno dne

20. 10. 2023 25. 10. 2023

…………………………………………………… …………………………………………………

Xx. Xxxx Xxxxxxx, MBA Ing. Xxxxx Xxxxx

generální ředitel předseda představenstva

Klasifikace: Veřejný dokument

Příloha č. 1 zadávací dokumentace pro zadávací řízení „Implementace systému Extended Detection and Response (XDR)“

Technická specifikace

0/34

Správa železnic, státní organizace

zapsána v obchodním rejstříku vedeném Městským soudem v Praze, spisová značka A 48384

Sídlo: Dlážděná 1003/7, 110 00 Praha 1

IČ: 709 94 234 DIČ: CZ 709 94 234

www.spravazeleznic.cz

Obsah

1 Seznam zkratek 2

2 Úvod 6

2.1 Záměr SŽ v oblasti systému Extended Detection and Response 6

2.2 Předmět plnění veřejné zakázky 9

2.3 Parametry poptávaného řešení 12

2.3.1 Network Detection and Response 12

2.3.2 Endpoint Detection and Response 13

2.3.3 Lokality určené k provozu komponent XDR 13

2.3.4 Požadavky na technické funkcionality řešení 14

2.3.5 Požadavky na specifikaci virtualizačních prostředků SŽ 25

2.3.6 Dodávka hardwarových a softwarových prostředků 26

2.4 Oblasti, které nejsou předmětem plnění veřejné zakázky 27

3 Současný stav a popis prostředí 28

4 Požadavky na plnění 29

4.1 Jednorázové projektové činnosti 29

4.1.1 Před-implementační analýza 29

4.1.2 Instalace a konfigurace řešení 30

4.1.3 Optimalizace bezpečnostní / detekční politiky řešení 30

4.1.4 Napojení na platformu Log management / SIEM 31

4.1.5 Školení 31

4.2 Průběžné služby dodavatele řešení 32

4.2.1 Technická podpora servisního týmu SŽ 32

4.2.2 Údržba řešení 32

4.3 Konzultace a rozvojové aktivity 34

5 Fáze plnění a akceptační milníky 34

1 Seznam zkratek

Níže uvedená tabulka obsahuje seznam zkratek a pojmů použitých v rámci této Technické specifikace.

Přehled zkratek a pojmů:

Zkratka	Popis
API	Rozhraní pro programování aplikací (Application Programming Interface)
APT	Pokročilé a trvalé kybernetické hrozby.
ARP	Protokol používaný pro identifikaci a rozlišení zařízení v síti.
CPU	Procesorová jednotka informačního systému.
CSV	Jednoduchý souborový formát určený pro výměnu tabulkových dat
ČD	České dráhy.
DC	Datové centrum.
DLL	Dynamicky volaná knihovna aplikace, nebo jiného druhu spustitelného kódu.
DNS	Systém správy doménových jmen, slouží k převodu jmenných záznamů na adresy informačních systémů a evidenci dalších podpůrných informací
Dodavatel	Subjekt, který se v rámci zadávacího řízení uchází o realizaci veřejné zakázky
EDR	Endpoint Detection and Response je nástroj pro detekci kybernetických hrozeb v prostředí koncových zařízení, podporu jejich vyšetřování a reakce.
EPP	Platformy pro ochranu koncových bodů (EPP) umožňují nasazení agentů nebo senzorů pro zabezpečení spravovaných koncových bodů, včetně stolních počítačů, notebooků, serverů a mobilních zařízení.
FPS	Počet síťových spojení (flows) uskutečněná za časovou jednotku jedné sekundy.
Gbps	Parametr specifikující objem datových bitů (v miliardách) přenesených v síti za danou časovou jednotku (sekunda).
HA	Režim vysoké dostupnosti (High Availability), např. prostřednictvím redundance
HTTP	HTTP (Hypertext Transfer Protocol) je internetový protokol určený pro komunikaci s WWW servery
HW	Hardware označuje veškeré fyzicky existující technické vybavení informačních a komunikačních systémů.
ICAP	Protokol ICAP (Internet Content Adaptation Protocol) je určen k přenesení zpracování internetového obsahu na vyhrazené servery.
IMAP	Komunikační protokol pro přenos elektronické pošty.
IOC	Indikátor kompromitace (Indicator of Compromise, IOC) je ve forenzním světě důkaz, který v kybernetickém prostředí naznačuje, že došlo k narušení kybernetické bezpečnosti

IP	IP je zkratka pro "internetový protokol", což je soubor pravidel, jimiž se řídí formát dat odesílaných prostřednictvím internetu nebo místní sítě.
IS/ICT	Informační systémy a informační a kumunikační technologie.
JSON	JavaScript Object Notation je způsob zápisu dat nezávislý na počítačové platformě, určený pro přenos dat, která mohou být organizována v polích nebo agregována v objektech
LDAP	Definovaný protokol pro ukládání a přístup k datům na adresářovém serveru.
Mbps	Parametr specifikující objem datových bitů (v milionech) přenesených v síti za danou časovou jednotku (sekunda).
MD	Člověkoden, pracovní čas jedné osoby odpovídající jednomu pracovnímu dni, tedy typicky 8 hodin (man-day)
MS AD	Adresářová služba vyvýjená společnostní Microsoft.
NDR	Network Detection and Response je nástroj pro detekci kybernetických hrozeb v prostředí sítě, podporu jejich vyšetřování a reakce
NTP	Protokol pro syschronizaci systémového času.
On- premise	On-premise software je takový software, který lze instalovat a provozovat v prostorách organizace, která jej využívá
OpenIOC	Standardizovaný formát pro popis stop a artefaktů, s nimiž se setkáváme v průběhu vyšetřování kybernetických bezpečnostních událostí.
OS	Operační Systém
OT	Operational technology (OT) je hardware a software, který zjišťuje nebo způsobuje změny prostřednictvím přímého monitorování a/nebo řízení průmyslových zařízení, prostředků, procesů a událostí.
PCAP	Packet Capture neboli PCAP je aplikační programovací rozhraní, které zachycuje živá data síťových paketů z vrstev 2-7 modelu OSI.
PID	Identifikační číslo procesu.
POP3	Komunikační protokol pro přenos elektronické pošty.
PROXY	Prostředník mezi klientem a cílovým počítačem, překládá klientské požadavky a vůči cílovému počítači vystupuje sám jako klient.
RAM	Operační paměť informačního systému.
RAT	Remote Access Tool – druh škodlivého kódu, který umožňuje vzdálené ovládání napadeného systému
s2s VPN	Site to site VPN
SLA	Dohoda o úrovni poskytovaných služeb (Service Level Agreement)
SMTP	Komunikační protokol pro přenos elektronické pošty.
SOC	Kybernetické bezpečnostní dohledové centrum.
SPAN	SPAN (Switched Port Analyzer) je vyhrazený port na přepínači, který přebírá zrcadlenou kopii síťového provozu z přepínače a odesílá ji na místo určení
SSL	Secure Sockets Layer, počítačový protokol, který zajišťuje bezpečnost dat odesílaných přes internet pomocí šifrování.
STIX	Jazyk a serializační formát používaný k výměně zpravodajských informací o kybernetických hrozbách.
SW	Software

SŽ	Správa železnic, státní organizace
TAXII	Formát, v němž jsou předávány zpravodajské údaje o hrozbách.
TCP	Jedná se o stavový a spolehlivý síťový komunikační protokol.
UDP	Jedná se o síťový komunikační protokol užívaná především k zasílání nestavovách datových rámců.
URL	Uniform Resource Locator (URL), označovaný jako webová adresa, je odkaz na webový zdroj, který určuje jeho umístění v počítačové síti a mechanismus jeho vyhledávání
USB	Univerzální sériové rozhraní informačního systému
vCPU	Virtuální procesorová jednotka informačního systému.
WAN	Wide Area Network je v informatice počítačová síť, která pokrývá rozlehlé geografické území
WEB	Rozhraní aplikace, nebo jiného informačního systému, které je přístupné prostřednictvím internetového prohlížeče nebo jeho alternativ.
WebUI	Grafické uživatelské rozhraní přístupné prostřednictvím internetového prohlížeče.
XDR	Extended Detection and Response je nástroj pro detekci kybernetických hrozeb, podporu jejich vyšetřování a reakce; systém funguje na základě shromažďování a korelace dat z různých bodů, jako jsou sítě, servery a pracovní stanice
XML	Extensible Markup Language je obecný značkovací jazyk, který byl vyvinut a standardizován konsorciem W3C
YARA	Programovací jazyk, fungují tak, že definuje řadu proměnných, které obsahují vzory nalezené ve vzorku škodlivého kódu.

Seznam zkratek pro specifické aplikace SŽ:

Zkratka	Popis
ASVC	Automatické stavění vlakových cest
DŘT	Dispečerská řídicí technika
DDTS	Dálková diagnostika technologických systémů
CDP	Centrální dispečerské pracoviště
CDS	Centrální dispečerský systém
DŽDC	Dispečer železniční dopravní cesty
DŽIN	Dispečer železniční infrastruktury
ED	Elektro dispečer
GVD	Grafikon vlakové dopravy
SSZT	Správa sdělovací a zabezpečovací techniky
ST	Správa tratí
SŽE	Správa železniční energetiky

TechDS	Technologický a dohledový systém
TDS	Technologická datová síť
TDCDP	Traťový dispečer dálkového ovládání zabezpečovacího zařízení na CDP
VS	Vlakové soupravy

2 Úvod

Tento dokument je přílohou a nedílnou součástí zadávací dokumentace k veřejné zakázce s názvem „Implementace systému Extended Detection and Response (XDR)“ (dále jen „veřejná zakázka“), pro organizaci Správa železnic, státní organizace (dále jen „SŽ“). Dokument popisuje technické a jiné požadavky SŽ kladené na veřejnou zakázku.

2.1 Záměr SŽ v oblasti systému Extended Detection and Response

SŽ očekává zavedení platformy, která umožní detekovat kybernetické bezpečnostní hrozby a podpoří vznikající proces Security Operations Center, který je budován v rámci interního týmu organizace SŽ. Požadovaná bezpečnostní platforma musí umožnit identifikaci nebezpečných projevů v síťovém provozu, jehož analýzu bude řešení provádět na základě pasivního odposlechu a bez jeho jakéhokoli ovlivnění a na koncových zařízeních prostřednictvím softwarového agenta. Řešení musí poskytovat funkcionality umožňující automatizaci mnoha kroků a procesů v rámci vyšetřování a reakcí na incident s cílem snížit zatížení specialistů, kteří by jinak museli pracovat s mnoha bezpečnostními technologiemi zvlášť a tím by byla snížena jejich efektivita.

Řešení XDR by mělo identifikovat čtyři hlavní typy kybernetických bezpečnostních rizik:

1. Neznámý malware:

o Externí útočníci, kteří využívají moderní, dosud neznámý, škodlivý kód k napadení a ovládnutí zařízení v síti SŽ.

2. Cílené útoky:

o Externí útočníci, kteří využívají sociální inženýrství, exploity, útoky hrubou silou nebo jiné techniky ke kompromitaci aplikací nebo koncových bodů, krádeži legitimních uživatelských pověření, vytvoření Command & Control, pohybu útočníka infrastrukturou (laterální pohyb) a krádeži, manipulaci nebo zničení dat.

3. Útoky zasvěcených osob:

o Zaměstnanci nebo smluvní partneři se dopouštějí různých způsobů chování, včetně neoprávněného přístupu k souborům a datům, jejich krádeže, manipulace s nimi, užívání neschválených nástrojů a dalších nebezpečných postupů.

4. Rizikové chování:

o Také dobře míněné, ale lehkomyslné chování zaměstnanců může vystavit organizaci SŽ útoku. Takové rizikové chování zahrnuje např. sdílení uživatelských účtů, zpřístupnění citlivých dat

neoprávněným uživatelům, umožnění vzdáleného přístupu ke koncovým bodům organizace SŽ a další.

Uvažované řešení by mělo zajistit reakci na stoupající nebezpečné napadení organizace SŽ kybernetickým útokem realizovaným externím či interním útočníkem, a to minimálně tím, že bude splňovat níže specifikované funkcionality nebo vlastnosti:

• Zajišťovat neustále sběr informací o chování zařízení v chráněných částech sítě pomocí komponent řešení NDR, popisovat toto chování v podobě metadat a ukládat tato metadata pro účely provádění dodatečné analýzy.

• Zajišťovat neustále sběr informací o chování zařízení, zabezpečených softwarovým agentem EDR, popisovat toto chování v podobě metadat a ukládat tato metadata pro účely provádění dodatečné analýzy.

• Metadata musí být možné zaznamenávat tzv. neselektivně, tedy o veškerém dění a nikoli jen o detekovaném podezřelém chování

o toto má napomoci při aktivním hledání hrozeb (tzv. huntingu), jejichž charakteristika není výrobcem definována jako nebezpečné chování;

o slouží pro tvorbu specifických detekčních use-case, odhalování aktivit interního útočníka a krádeže informací;

o umožní zpětné prozkoumání vektorů průniku a zaznamenaných indikátorů kompromitace (tzv. IOC).

• Provádět detekci bezpečnostních kybernetických událostí v reálném čase v chráněných částech sítě a na zabezpečených koncových zařízeních

o malware a nebezpečný kód;

o specifický obsah (obsahová analýza);

o nebezpečná, podezřelá nebo specifická aktivita;

o reputační riziko komunikujících stran.

• Detekci bezpečnostních kybernetických událostí provádět pomocí vyhledávání signatur, heuristickou analýzou, vyhledáváním typického chování (behaviorální analýza) a detekcí pomocí detonace na sandboxu tzv. virtuálním provedením

o součástí dodávaného řešení musí být kontinuální služba aktualizace signatur/definice chování malware/aktualizace pravidel sandboxu;

o řešení musí umožnit definici vlastních detekčních pravidel.

• Provádět automatickou retrospektivní analýzu a detekci bezpečnostních kybernetických událostí v zaznamenaných metadatech o chování chráněných částí sítě

o výrobcem získané signatury jsou automaticky prověřovány v zaznamenaných a uložených metadatech;

o takto jsou odhalovány hrozby na které v okamžiku jejich realizace neexistovala signatura pro jejich odhalení.

Systém musí poskytovat jednotné uživatelské webové rozhraní pro práci specialistů s dodávaným řešením. Rozhraní musí umožnit rychlé zkoumání události dostupností kontextu v podobě záznamů o relevantním síťovém provozu, chování na koncovém zařízení a dalších souvisejících událostech/alertech – jak typově (stejný typ události/alertu na jiném aktivu), tak z hlediska stejných IP adres a dalších dostupných indikátorů.

2.2 Předmět plnění veřejné zakázky

Předmětem veřejné zakázky je dodávka, implementace a podpora řešení pro automatizovanou detekci a reakci na bezpečnostní incidenty v síťovém prostředí a na koncových zařízeních organizace SŽ, známé jako Extended Detection and Response (XDR). XDR nástroje poskytují sdruženou funkcionalitou vycházející z Network Detection and Response (NDR) a Endpoint Detection and Response (EDR), přičemž oba tyto nástroje jsou vzájemně úzce integrovány a poskytují své funkcionality v rámci jednotného uživatelského rozhraní a dalších vzájemných integrací, které podporují činnosti týmu Security Operations Center.

SŽ očekává nabídku na technické řešení, které bude do prostředí SŽ naimplementováno a po implementaci provozováno po dobu 5 let, přičemž po celou dobu bude řešení pokryto potřebnou licencí, technickou podporou výrobce a budou aktivovány všechny předplatné výrobce nezbytné k zajištění chodu řešení a splnění požadovaných funkcionalit. Spolu s dodávkou řešení, očekává SŽ také poskytování služby technické podpory od Dodavatele, a to na celou specifikovanou dobu provozu technického řešení.

Dodávané řešení musí splňovat následující požadavky na funkcionality – NDR:

• Záznam informací o síťové komunikaci v podobě, která umožní pozdější analýzu.

• Analýza síťového provozu probíhá pro veškerý síťový provoz a bez ohledu na použité komunikační protokoly a monitorována jsou tedy všechna probíhající spojení na všech síťových portech.

• Pro účely podpory aktivního vyhledávání kybernetických hrozeb (tzv. hunting) je po řešení požadována podpora obsahové analýzy:

o tedy bude možné definovat vlastní pravidla pro analýzu a detekci obsahu přenášeného v obsahu síťové komunikace, jako je např. v těle zpráv elektronické pošty, v přenášených souborech, v obsahu uloženém v kompozitních souborech (archívy, komprimované soubory, vnořené dokumenty);

o pro výše uvedené druhy obsahu bude řešení generovat a ukládat popisná metadata;

o bude možné pracovat s metadaty popisujícími obsahové části síťového provozu a pokládat do nich strukturované dotazy.

• Systém je schopný detekovat také malware skrytý hluboko v přenášeném obsahu, jako je např. v těle zpráv elektronické pošty, v přenášených souborech, v obsahu uloženém v kompozitních souborech (archívy, komprimované soubory, vnořené dokumenty).

• Funkcionalita analýzy a záznamu síťového provozu pracuje nad zrcadleným provozem sítě.

• Pravidla pro analýzu provozu umožní definovat podmínky odkazující se na přenášený obsah a parametry aplikační vrstvy – například:

o odhalit přenášené soubory, kde koncovky soborů nesouhlasí s obsahem;

o nebo čísla typických portů nesouhlasících s typem rozpoznaného komunikačního protokolu.

• Podpora monitorování provozu na rozhraních Ethernet s rychlostmi dle specifikací parametrů SPAN rozhraní v kapitole „2.3. Parametry poptávaného řešení“ Technické specifikace.

• Umožňuje definovat pravidla hledající souběh událostí nebo posloupnost událostí v síťovém provozu a generovat upozornění (alerty), a to kontinuální analýzou okamžitého dění i analýzou již uložených historických záznamů o provozu zpětně.

Dodávané řešení musí splňovat následující požadavky na funkcionality – EDR:

• Záznam informací o chování koncových zařízení v podobě, která umožní pozdější analýzu

o probíhá pro veškeré chování koncového zařízení a bez ohledu na to, zda je detekováno kybernetické nebezpečí;

o záznam informací o chování koncových zařízení probíhá díky softwarovému agentu, který je instalovaný na SŽ určených pracovních stanicích a serverech.

• Pravidla pro analýzu provozu umožní definovat podmínky odkazující se na:

o spuštění a ukončení procesů,

o souborové manipulace,

o manipulace s registry,

o síťových spojení včetně URL pro http spojení,

o DNS překladů,

o Manipulace s USB médii a přenosy souborů na ně,

o Windows události (Windows Events).

• Umožňuje definovat pravidla hledající události v chování koncových zařízení, generovat upozornění (alerty), a to kontinuální analýzou okamžitého dění i analýzou již uložených historických záznamů o chování zpětně.

• Umožňuje používat připravené nebo definovat a spouštět vlastní reakční činnosti na koncových zařízeních (automaticky, poloautomaticky, manuálně), které umožní alespoň:

o obohacovat informace relevantní k detekovaným událostem:

▪ získat otisk paměti běžícího procesu / celého systému,

▪ získat ze zařízení podezřelý soubor,

▪ získat aktuální směrovací nebo ARP tabulku,

o reagovat v případě zaznamenaného bezpečnostního ohrožení:

▪ odhlásit uživatele,

▪ ukončit proces,

▪ izolovat koncové zařízení, přičemž nesmí být zamezeno další vyšetřování a ovládání zařízení z rozhraní nástroje EDR.

• Oprávnění spouštět připravené činnosti (tasky) je možné řídit pro konkrétní analytiky nebo skupinu analytiků.

Dodávané řešení musí splňovat následující požadavky na funkcionality – XDR:

• Systém poskytuje jednotné webové uživatelské rozhraní pro analýzu zaznamenaného provozu a chování koncových zařízení, vyhodnocování detekovaných událostí a parametrizace řešení.

• Nedílnou součástí řešení musí být možnost řízení přístupových oprávnění k jednotlivým modulům systému a zpracovávaným/zaznamenaným metadatům. V rámci řízení přístupových oprávnění požaduje SŽ minimálně:

o Umožnit přístup k detekovaným událostem XDR operátorům pracoviště Security Operations Center, přičemž jim nebudou zpřístupněna uložená metadata, která nejsou související s detekovanou událostí.

o Umožnit, vybrané skupině analytiků přístup ke všem uloženým popisným informacím (metadatům), aby bylo možné provádět aktivní vyhledávání nebezpečných jevů (tzv. hunting).

• K dispozici jsou historické informace o síťovém provozu a chování koncových zařízení s určenou dobou retence pro následnou analýzu, přičemž tato data musí být chráněna před narušením jejich integrity.

• Detekce malware je prováděna pomocí vyhledávání signatur, heuristickou analýzou, vyhledáváním anomálního chování (behaviorální analýza) a detekcí na sandboxu virtuálním provedením.

• Součástí dodávky je kontinuální služba aktualizace signatur/definice chování malware/aktualizace pravidel sandboxu.

Nabízené řešení musí v oblasti otevřenosti platformy splňovat následující požadavky:

• Dokumentované aplikační rozhraní pro zákaznické integrace s dalšími bezpečnostními komponentami, HTTP & XML nebo JSON API rozhraní. Přístupné informace musejí zahrnovat:

o Aktiva zaznamenaná ve sledovaném prostředí,

o Vygenerované události,

o Uložená metadata.

• Předpřipravené integrační vazby na aplikace typu Log Management a SIEM pro následující kategorie událostí:

o Kybernetické bezpečnostní události detekované ve sledovaném prostředí.

o Auditní log řešení NDR a EDR,

o Systémový log řešení NDR a EDR.

• Být připravené na aktivní dohled systémem provozního monitoringu Zabbix.

Všechny komponenty řešení požaduje SŽ provozovat v režimu on-premise (tedy ve své vlastní infrastruktuře). Tento požadavek vychází z potřeby nepřetržité možnosti sbírat metadata, ukládat je a vyhodnocovat bezpečnostní události i v situaci, kdy je vlivem provozní nedostatečnosti nebo působením kybernetické hrozby nedostupná internetová konektivita.

Přípustná integrace s online / CLOUD službami je pouze pro aktualizační služby a získávání informací o hrozbách. V případě nedostupnosti internetové konektivity umožní řešení manuální dodání aktualizací pro XDR řešení.

Není přípustné předávat data z prostředí SŽ ke zpracování k výrobci nabízeného řešení, pokud tuto aktivitu manuálně a pouze pro konkrétní vyšetřování neiniciuje pracovník SŽ.

2.3 Parametry poptávaného řešení

SŽ požaduje implementaci řešení Extended Detection and Response (XDR):

• Do síťového prostředí s požadavkem na analýzu síťového provozu o výkonnostní kapacitě specifikované v kapitole Technické specifikace s názvem „Lokality určené k provozu komponent XDR“, ve sloupci „Provoz (Mbps)“, tedy maximálně 10Gbps.

• Na minimálně 10000 koncových zařízení typu pracovní stanice a servery.

• S celkovou požadovanou retencí historických metadat o chování sítě a koncových zařízení po dobu minimálně 30 dní.

• Schopností uložit metadata relevantní k detekovaným bezpečnostním událostem po dobu alespoň 12 měsíců.

• Zajištěním vysoké dostupnosti na úrovni centrální management konzole pro účely zpracování alertů generovaných chráněným prostředím. Vysoká dostupnost musí být řešena způsobem automatického přenesení funkcionality tzv. Active / Standby nebo Active / Active na úrovni dodávané technologie.

2.3.1 Network Detection and Response

Zavedení nástroje Network Detection and Response se očekává do vybraných míst síťového prostředí SŽ, konkrétně do míst v síťové infrastruktuře, která jsou

chráněna firewallem externího perimetru SŽ, avšak budou určena jako vstupně/výstupní body infrastruktury nebo jinak exponovaná síťová prostředí.

Takovými místy v síťovém prostředí typicky jsou:

• Spojnice vnitřních sítí a externího perimetrového firewallu.

• Místa zakončující propojení datových center a sítí uživatelské WAN.

• Místa připojení významných administrativních objektů do sítě uživatelské WAN.

• Síťová propojení k třetím stranám (dodavatelé, servisní partneři, společnosti skupiny ČD).

• Místa propojující prostředí IT a technologické prostředí OT (Operational Technology), která jsou situována do oblastních ředitelství a centrálních dispečerských pracovišť SŽ.

2.3.2 Endpoint Detection and Response

Předmětem zabezpečení koncových zařízení nástrojem EDR jsou především zařízení SŽ, která jsou provozována v jejích vnitřních sítích, ale která umožňují mobilitu a mohou se tak pohybovat také v prostředí internetu.

Nástroj EDR, který bude instalován na vybraná koncová zařízení, nesmí být v kolizi s nástroji Endpoint Protection Platform (EPP), které SŽ provozuje – tedy aktuálně užívaným nástrojem výrobce F-Secure.

2.3.3 Lokality určené k provozu komponent XDR

SŽ požaduje řešení zabezpečení síťového provozu systémem Network Detection and Response, které pokryje až 20 lokalit v rámci České republiky, které jsou uvedené v následující tabulce. Stejné lokality bude možné využívat pro potřeby instalace podpůrných komponent řešení Endpoint Detection and Response.

Sloučené řešení Extended Detection and Response bude disponovat centrálním rozhraním pro správu a analytické činnosti realizované pracovištěm Security Operations Center (SOC) SŽ. Centrální pracoviště bude situováno v lokalitě Praha.

Typ lokality	Adresa lokality	Počet zařízení (IP adres)	Provoz (Mbps)*	Provoz (Fps)*	Rozhraní SPAN	Přípojka do WAN (Gbps)
Datové centrum	Praha	700	3600	3750	1G/UTP i SFP	2x10
Datové centrum	Brno	200	400	417	1G/SFP	2x 1
Datové centrum	Plzeň	600	800	833	1G/UTP	2x 1 2x 10
Datové centrum Dispečerské pracoviště	Přerov	400	400	417	1G/UTP	1
Oblastní ředitelství	Ostrava	500	100	104	1G/SFP	2x 1
Oblastní ředitelství	Brno	200	100	104	viz. DC Brno *	2x 1
Oblastní ředitelství	Jihlava	200	100	104	1G/UTP	1

Oblastní ředitelství	Praha	200	100	104	1G/UTP	1
Oblastní ředitelství	Praha	900	100	104	1G/UTP	1
Oblastní ředitelství	Hradec Králové	700	500	521	1G/UTP	1
Oblastní ředitelství	Pardubice	500	300	313	N/A	2
Oblastní ředitelství	Plzeň	50	200	208	viz. DC Plzeň *	2 x 1
Oblastní ředitelství	České Budějovice	400	100	104	1G/UTP	2x1
Oblastní ředitelství	Ústí nad Labem	600	200	208	1G/UTP	2x1
Dispečerské pracoviště	Praha	300	100	104	1G/SFP	2x1
Organizační jednotka	Brno	500	200	208	viz. DC Brno *	2x 1
Organizační jednotka	Olomouc	900	800	833	1G/UTP	10
Technologická sdělovací místnost	Praha	400	600	625	1G/UTP	2x1
Technologická sdělovací místnost	Praha	100	400	417	1G/SFP	1
Externí subjekt	Olomouc	50	700	729	1G/UTP	1

*Lokality, které mají u parametru „Rozhraní SPAN“ uvedeno „viz. DC“, budou monitorovány v rámci zařízení umístěného do náležícího datového centra. Proto je nezbytné, aby NDR sonda umístěná v daném DC počítala také s kapacitou sííového provozu takto označených dalších lokalit.

*Uvedené provozní hodnoty odpovídají momentálním hodnotám zaznamenaným měřením v referenčním pracovním dni, jsou navýšené o 25 % a zaokrouhleny na horní hodnoty. FPS jsou odvozeny od vzorku komunikací zachycených v centrální lokalitě SŽ a korelovány s právě zaznamenaným objemem provozu v Mbps. Z odpovídajícího referenčního poměru Mbps/Fps byly dopočítány všechny ostatní lokality.

2.3.4 Požadavky na technické funkcionality řešení

Všechny parametry požadované v tomto dokumentu jsou pro dodavatele závazné a SŽ vyžaduje jejich naplnění.

Požadavky na vybrané funkcionality poptávaného řešení, které SŽ vyžaduje splnit technickými prostředky, a u nichž dodavatel musí popsat způsob, kterým jím nabízené řešení naplní daný požadavek, jsou specifikovány v tabulce, která tvoří přílohu č. 19 zadávací dokumentace. Nedílnou přílohou Zadávací dokumentace je dotazník „TS_XDR_dotazník.xlsx“, ve kterém dodavatel potvrdí připravenost nabízeného řešení splnit vybrané požadavky a vyplní způsob, kterým je každý požadavek naplněn.

SŽ upozorňuje, že nesplnění kteréhokoliv požadavku na technické funkcionality řešení uvedeného v této kapitole Technické specifikace povede k vyloučení dodavatele ze zadávacího řízení. V případě, že bude nesplnění takového požadavku odhaleno až v průběhu provádění plnění, bude to považováno za hrubé porušení povinností dle přílohy č. 6 zadávací dokumentace – Závazného vzoru smlouvy a bude důvodem pro odstoupení od této smlouvy.

2.3.4.1 Požadavky na Network Detection and Response

Id	Oblast NDR	Požadovaná funkcionalita řešení NDR
1	Detekce	Možnost importu detekčních pravidel s podporou formátů YARA a zdrojů specifikace TAXII/STYX.
2	Detekce	Analýza síťového provozu v rámci systému se provádí pro veškerý síťový provoz bez ohledu na použité komunikační protokoly, a proto jsou sledována a analyzována všechna probíhající spojení na všech síťových portech.
3	Detekce	Možnost importu úplného záznamu síťové komunikace ve formátu PCAP pro kontrolu, popis a hloubkovou analýzu.
4	Detekce	Import popisu hrozeb od třetích stran a vlastních, které mohou být dodány ve formátech STIX, TAXII, CSV (podpora ThreatConnect).
5	Detekce	Detekce protokol.	malwaru	přenášeného	přes	jakýkoli	nešifrovaný
6	Detekce	Podpora spolupráce s řešeními SSL Visibility pro kontrolu provozu přenášeného přes šifrované připojení.
7	Detekce	Detekce zpětných volání malwaru Command & Control.
8	Detekce	Detekce projevů nástrojů pro vzdálený přístup (RAT).
9	Detekce	Detekce pokusů o zneužití zranitelností na dálku prostřednictvím sítě.
10	Detekce	Definice výjimek pro vyloučení určité komunikace z inspekce daným pravidlem.
11	Detekce	Detekce malwaru zabaleného i hluboko v obsahu (v archivech a dalších složených dokumentech).
12	Detekce	Identifikace spojení využívajících neočekávané nebo neznámé protokoly (např. nesoulad portů a protokolů).
13	Detekce	Obsahová analýza pro detekci exfiltrace informací s možností nasazení v prostředí se značkami (klasifikátory) i bez nich (např. pomocí regulárních výrazů obsahových pravidel, vzorových šablon atp.).
14	Detekce	Funkce obsahové analýzy detekuje informace přenášené i hluboko v obsahu, bez ohledu na hloubku vložení a bez ohledu na formát souboru.
15	Detekce	Možnost definovat vlastní pravidla detekce nad libovolným typem přenášeného obsahu, charakteristikami chování nebo posloupností událostí v síti.

16	Detekce	Systém bude schopen aplikovat aktualizované signatury na historický síťový provoz uložený v popisných metadatech po dobu požadované retence, aby našel nyní známý malware, který nebyl v minulosti detekován.
17	Detekce	Detekce malwaru se provádí pomocí (všech níže specifikovaných způsobů): - signatur a pravidel, - heuristické analýzy, - vyhledávání typického chování (behaviorální analýza), - detekce v sandboxu pomocí virtuálního spuštění (detonace), - detekce anomálií.
18	Detekce	Detonace/virtuální spuštění podezřelého obsahu, který mohl být zachycen v jakémkoli místě dohledované sítě, v místním sandboxu s podrobným výstupem výsledku detonace v jednotné konzoli bezpečnostního analytika.
19	Detekce	Detekce anomálií pomocí modelů strojového učení a případné generování alarmů pro významné anomálie.
20	Detekce	Pravidla analýzy provozu umožňují definovat podmínky vztahující se k přenášenému obsahu a parametrům aplikační vrstvy, například detekovat přenášené soubory, u nichž koncovky soborů neodpovídají obsahu nebo typická čísla portů neodpovídající typu detekovaného komunikačního protokolu.
21	Detekce	Možnost definovat pravidla pro vyhledávání shody událostí nebo posloupnosti událostí v síťovém provozu a generovat výstrahy průběžnou analýzou okamžitých událostí a analýzou již uložených historických záznamů o provozu zpětně.
22	Detekce	Systém musí klasifikovat události podle MITRE ATT&CK frameworku uvedením odpovídající techniky a/nebo taktiky útočníka. Vlastní pravidla lze definovat tak, aby také používala kategorie MITRE ATT&CK frameworku.
23	Detekce	Retrospektivní analýza všech zaznamenaných údajů o chování sítě, která odhalí sled událostí vedoucích k projevům kybernetického incidentu.
24	Detekce	Možnost definovat pravidla (komunikační matice) pro vyhodnocení oprávněnosti odchozí komunikace vůči definovaným kritickým informačním systémům pomocí kombinací parametrů: - IP adresa/seznam IP adres/rozsah adres,

		- Skutečný typ detekovaného protokolu (nezávisle na definovaném čísle portu TCP/UDP), - Čísla portů (TCP/UDP).
25	Detekce	Schopnost systému identifikovat specifické komunikační protokoly vyskytující se v provozu organizace SŽ. Schopnost zahrnout takto identifikovaný protokol do definice detekčních pravidel.
26	Detekce	Podpora detekce síťového provozu ve spolupráci s PROXY systémy, které podporují protokol ICAP (Internet Content Adaptation Protocol).
27	Vyšetřování	Vestavěná funkce pro vyšetřování, shromažďování stop a generování zprávy o incidentu.
28	Vyšetřování	Průběžné zaznamenávání informací o síťové komunikaci ve formě, která umožňuje pozdější analýzu (metadata).
29	Vyšetřování	Export úplného záznamu, předem popsaných síťových komunikací, ve formátu PCAP pro další zkoumání.
30	Vyšetřování	Pro následnou analýzu jsou k dispozici historické informace o provozu se stanovenou dobou uchování.
31	Vyšetřování	Systém podporuje efektivitu vyšetřování tím, že dokáže automatizovaně spojovat jednotlivé bezpečnostní události, které mají společnou příčinu, do jedné události (incidentu).
32	Vyšetřování	Možnost průběžně zaznamenávat a zpětně analyzovat informace o všech síťových aktivitách (všechny níže uvedené): - IP adresy a jejich zeměpisná poloha, - identity uživatelů (např. e-mailové adresy pro rozhraní SMTP/POP3/IMAP a web-mail nebo uživatelská jména pro jiné protokoly), - čísla portů, - skutečný typ zjištěného protokolu, - parametry rozpoznaných komunikačních protokolů (například hlavičky SMTP, HTTP, …), - typ přenášených souborů (minimálně excel, word, powerpoint, pdf, exe, msi, obrazové formáty, archivní a kompresní formáty, včetně vnořených), - HASH přenášených souborů, - velikost přenášených souborů, - název a přípona přenesených souborů,

		- informace o tom, že soubor je zašifrovaný, a obecně informace o entropii obsahu souborů, - čas a délku spojení, - objem přenesených dat.
33	Vyšetřování	Extrakce obsahu souborů zachycených při jejich pohybu po síti pro forenzní účely pomocí systémové konzoly.
34	Vyšetřování	Zaznamenané informace o provozu umožňují vyhledávat spojení podle libovolného atributu popisujícího spojení nebo pomocí logického výrazu s relačními operátory odkazujícími na atributy spojení.
35	Vyšetřování	Vestavěná podpora pro řízení životního cyklu tiketů pro distribuci úkolů mezi uživatele systému/vyšetřovatele.
36	Vyšetřování	Geolokace komunikujících stran.
37	Vyšetřování	Možnost vlastní definice geolokačních tabulek IP adres (pro geolokaci privátní IP segmentů).
38	Vyšetřování	V oblasti detekce a vyšetřování Advanced persistent threats (APT) musí systém splňovat požadavek na viditelnost stop daného útoku a dostupnost forenzních dat ze všech zachytitelných fází útoku APT (podle fází cyber-kill-chain).
39	Vyšetřování	Systém přiřazuje informace o uživatelském účtu k zaznamenanému síťovému spojení.
40	Reakce	Schopnost automatizace pracovních postupů při nápravě kybernetických incidentů: - plně automatická reakce definovaná bezpečnostní politikou pro síťový provoz, - podporované metody: DROP při in-line zapojení, nebo TCP. Reset pro out-of-band připojení.
41	Reakce	Schopnost ukončit spojení na základě detekce.
42	Reakce	Schopnost umísit škodlivý email do karantény.

43	Reakce	Systém musí být schopen spouštět vyšetřovací nebo nápravné úlohy na koncových bodech prostřednictvím integrace s řešením EDR.
44	Rozhraní	Zdokumentované aplikační rozhraní pro integraci s dalšími bezpečnostními komponentami. Upřednostňujte rozhraní API http a XML nebo JSON.
45	Rozhraní	Předpřipravené integrační vazby na aplikace typu SIEM.
46	Rozhraní	Systém poskytuje webové uživatelské rozhraní pro analýzu zaznamenaného provozu bezpečnostními specialisty, které bude součástí jednotného uživatelského rozhraní.
47	Rozhraní	Dashboard a možnosti jeho úprav pro grafické zobrazení informací a podpory rozhodovacího procesu (alert triage).
48	Rozhraní	Možnost detailního řízení přístupových práv pro více úrovní pracovníků SOC (analytici, operátoři, IT podpora, forenzní analytici, vyšetřovatelé).
49	Rozhraní	Možnost napojení na ActiveDirectory/LDAP pro autentizaci uživatelů systému.
50	Rozhraní	Jednotné uživatelské rozhraní pro veškerou analytiku, vyšetřování a reakci.
51	Rozhraní	Systém musí podporovat integraci s: - Komponenty pro detekci APT útoků na koncových zařízeních (EDR), způsobem plné integrace v řešení Extended Detection and Response (XDR).
52	Ostatní	Systém je platforma pro forenzní analytiku, detekci, vyšetřování a řízení reakcí na zaznamenané kybernetické události.
53	Ostatní	Systém musí být po hardware stránce dimenzován tak, že dodaný hardware bude umožňovat zpracování síťového provozu až do velikosti 10 Gbps.
54	Ostatní	Celková požadovaná retence všech historických dat o chování sítě v délce 30 dnů.
55	Ostatní	Metadata relevantní k detekovaným bezpečnostním událostem musí řešení uložit po dobu 12 měsíců.
56	Ostatní	Systém musí podporovat práci v hierarchickém režimu (včetně selektivní správy práv k informacím) pro případné budoucí zapojení podřízených organizací do bezpečnostního dohledu. Požadavek zahrnuje jednotné rozhraní pro vyšetřování, konfiguraci bezpečnostní politiky a správu řešení u všech podřízených organizací, vlastní rozhraní pro správu v každé

		podřízené organizaci a datová úložiště v každé podřízené organizaci.
57	Ostatní	Generování reportů dle předpřipravených šablon.
58	Ostatní	Tvorba a generování zákaznicky definovaných reportů.
59	Ostatní	Možnost nastavení automatického generování a odesílání reportů na emailové adresy.
60	Ostatní	Systém monitoruje svůj vnitřní chod a drží historické informace o událostech týkající se vlastního chodu a problémů.
61	Ostatní	Podpora instalace jednotlivých komponent řešení do virtuálního prostředí (VMware).
62	Ostatní	Funkcionalita analýzy a záznamu síťového provozu pracuje nad zrcadleným provozem sítě.
63	Ostatní	Podpora monitorování provozu na rozhraních Ethernet s rychlostmi 100Mbps, 1Gbps, 10Gbps a 25Gbps.
64	Ostatní	Obsahuje službu průběžné aktualizace signatur/definic chování a aktualizace pravidel sandboxu z komerčního zdroje.
65	Ostatní	Všechny komponenty řešení je možné provozovat v prostředí SŽ.

2.3.4.2 Požadavky na Endpoint Detection and Response

Id	Oblast EDR	Požadovaná funkcionalita systému
1	Detekce	Systém bezpečnostního monitorování koncových zařízení (stanic a serverů) s funkcionalitou EDR.
2	Detekce	Pokročilá detekce hrozeb: - detekce škodlivého kódu jeho rozpoznáním podle vzorů pro obsah, - detekce škodlivého kódu pomocí pravidel popisující chování, - detekce projevů činnosti útočníka na koncovém bodě, - analýza běžících procesů na stanici a jejich ohodnocení z hlediska činností, které provádějí nebo by mohly provádět.

3	Detekce	Systém bude kontinuálně zaznamenávat činnosti na koncových bodech v podobě metadat v těchto oblastech: - spuštění a ukončení procesů, - souborové manipulace, - manipulace s registry, - síťových spojení včetně URL pro http spojení, - DNS překladů, - manipulace s USB médii a přenosy souborů na ně, - Windows události (Windows Events).
4	Detekce	Systém bude možné napojit na vlastní nebo otevřené zdroje informací o hrozbách ve formátech JSON, CSV a STIX.
5	Detekce	Systém bude umožňovat import popisu IOC ve formátu OpenIOC a YARA.
6	Detekce	Systém musí klasifikovat události podle MITRE ATT&CK frameworku uvedením odpovídající techniky a/nebo taktiky útočníka.
7	Detekce	Vlastní pravidla lze definovat tak, aby také používala kategorie MITRE ATT&CK frameworku.
8	Detekce	Systém musí rozpoznat zranitelnosti nainstalovaného software na koncových bodech.
9	Vyšetřování	Systém umožní zhodnocení hrozby integrací na službu Virus Total nebo obdobnou službu.
10	Vyšetřování	Události budou zaznamenávány do centrálního úložiště v reálném čase a budou zpětně dostupné s časovou retencí požadovanou v technické specifikaci SŽ.
11	Vyšetřování	Systém musí být schopen nalézt soubor na disku koncového bodu dle: - obsahu, - hashe, - názvu, - velikosti, - koncovky, - času vytvoření/modifikace, - kombinace výše uvedeného.
12	Vyšetřování	Systém bude umožňovat vyhledávání souboru i pro smazané soubory.

13	Vyšetřování	Systém bude umožňovat vyhledávání souboru na souborovém systému, logickém i fyzickém disku v jejich využité (obsazené/alokované) i nevyužité části.
14	Vyšetřování	Systém bude pro běžící procesy schopen zaznamenat: - otevřené sokety, - souborové manipulace, - informace o DLL, které byly dynamicky přilinkovány včetně informace, zda byly injektovány, - obsazený virtuální adresní prostor, - identitu, pod kterou byl proces spuštěn.
15	Vyšetřování	Systém musí být schopen na vyžádání – nebo jako součást automatické reakce – získat informace o okamžitém stavu koncového bodu minimálně v oblastech: - Přihlášení uživatelé, - Vystavená síťová spojení, - Běžící procesy, - Seznam zavedených lokálních správců, - Seznam nainstalovaného software, - Seznam nainstalovaných důvěryhodných certifikátů, - Čas od spuštění počítače, - Stav antiviru, - Stav firewallu, - Seznam do paměti nahraných ovladačů, - Seznam klíčů a hodnot autorun v registrech, - Výpis obsahu DNS a APR vyrovnávacích pamětí, - HW inventář, - Obsah směrovací tabulky, - Seznam aktivních síťových rozhraní.
16	Vyšetřování	Systém bude umožňovat vyhledávání v metadatech dle libovolného parametru události (například jméno procesu, jméno rodiče, PID, hash, jméno souboru, jméno klíče v registrech, IP adresa serveru, URL spojení).

17	Vyšetřování	V případě potřeby musí být systém schopný spustit rozšířené úlohy zjišťující stav koncového bodu v oblasti: - získání historie navštívených stránek webového prohlížeče, - získání záznamu síťového provozu koncového bodu, - získání obrazu logického disku nebo fyzického disku, - získání obrazu paměti.
18	Vyšetřování	Systém musí být schopný zobrazit činnosti určitého procesu ve vztahu k: - souborovým manipulacím, - manipulacím s registry, - síťovým spojením, - spuštěným podprocesům, - to vše graficky na časové ose.
19	Vyšetřování	Systém musí umožnit přístup ke koncovému bodu pomocí sezení v reálném čase (konzolový přístup) pro účely vyšetřování a reakce.
20	Reakce	Systém umožní provedení akce na koncovém bodě nebo bodech odesláním úlohy k provedení a také interakcí s koncovým bodem v reálném čase.
21	Reakce	Automatizace reakce na incidenty automatickým nebo polo- automatickým spouštěním akcí (nachystaných výrobcem i uživatelem definovaných) na koncových bodech v případě výskytu určitého alarmu, který se ke koncovému bodu vztahuje.
22	Reakce	Ochrana koncového bodu zabráněním spuštění procesu dle hash nebo výrazu YARA.
23	Reakce	Systémová správa podporovaná na koncovém bodu prostřednictvím nástroje EDR: - správa uživatelů (přidání, odebrání, povolení, zablokování, - instalace a odinstalace aplikací, - změna nastavení operačního systému (například zapnutí firewallu a antivirového systému).
24	Reakce	Forenzní analýza: - vzdáleně – získáním obrazu paměti určitého procesu, - vzdáleně – získáním obrazu celé paměti, - vzdáleně – získáním obrazu disku.

25	Reakce	Systém musí umožnit na stanici: - Smazat soubor, - Ukončit proces, - Síťová izolace koncového bodu (při zachování komunikace systému s EDR řešením), - Modifikace/mazání obsahu registrů, - Instalace a odinstalace aplikací a záplat, - Odhlášení uživatele, - Zapnutí a vypnutí firewallu, - Restartování, vypnutí a hibernace koncového bodu.
26	Reakce	Systém musí být schopen automatického spuštění vybrané akce jako automatické odpovědi na určitý alert.
27	Reakce	Schopnost agenta systému provádět více akcí současně.
28	Reakce	Systém musí umožnit zobrazení běžících procesů na koncovém bodě v reálném čase a základní manipulaci s nimi – například jejich ukončení a získání obrazu paměti procesu.
29	Reakce	Systém musí umožnit zobrazení vzdáleného souborového systému koncového bodu a základní manipulace se soubory – například získání souboru, smazání souboru.
30	Reakce	Automatizace vybraných reakcí na incidenty (dle definovaných a schválených scriptů).
31	Reakce	Automatickým spouštěním akcí (nachystaných i uživatelem definovaných) na koncových bodech v případě výskytu určitého alarmu, který se ke koncovému bodu vztahuje.
32	Rozhraní	Dokumentované standardizované aplikační rozhraní pro zákaznické integrace s dalšími bezpečnostními komponentami. Preferujeme http & XML nebo JSON API rozhraní.
33	Rozhraní	Předpřipravené integrační vazby na aplikace typu SIEM.
34	Rozhraní	Systém musí podporovat integraci s: - Komponenty pro detekci APT útoků na síťovém provozu (NDR), způsobem plné integrace v řešení Extended Detection and Response (XDR).
35	Rozhraní	Jednotné uživatelské rozhraní pro analytiku, vyšetřování a reakci společnou pro prostředí sítě i koncových bodů.
36	Rozhraní	Alerty generované systémem musí být zobrazovány v centrální konzoli řešení XDR.

37	Rozhraní	Systém disponuje jednotným rozhraním pro správu, detekci, vyšetřování a reakci, které je součástí poptávaného řešení Extended Detection and Response.
38	Ostatní	Systém bude napojen na zdroj aktualizovaných informací o hrozbách (threat-intelligence) a bude z toho zdroje provádět pravidelně aktualizace.
39	Ostatní	Systém musí podporovat koncové body s operačními systémy: - Windows 7 a výše, - Windows Server 2008 R2 a výše, - Linux CentOS 6 a výše, - RedHat Enterprise Linux 6 a výše, - macOS 10.11 a výše.
40	Ostatní	Na koncových stanicích musí agentská část využívat zanedbatelnou část zdrojů – agent by neměl překročit po většinu času jednotky (max. 4%) využití CPU.
41	Ostatní	Agent systému musí být odolný proti odinstalování a pokusům jej zastavit nebo poškodit.
42	Ostatní	Odinstalace agentů musí vyžadovat zvláštní autentizaci (heslo pro odinstalaci).
43	Ostatní	Systém musí být schopný zaznamenávat metadata o chování koncových bodů, alerty a výsledky úloh i pro koncové body, které jsou dočasně mimo síť, jejich uchováním na koncovém bodě až do jejich odeslání do systému alespoň po dobu 5 dní.

2.3.5 Požadavky na specifikaci virtualizačních prostředků SŽ

V souvislosti se schválenou strategií IS/ICT SŽ, konkrétně cílem zajištění dlouhodobého koncepčního a efektivního rozvoje IS/ICT, požaduje SŽ využití možností jeho hardwarové a virtualizační platformy pro jednotlivé komponenty poptávaného řešení.

Pro veškeré prostředky, které je možné provozovat v platformě SŽ, vyplní dodavatel specifikaci technických požadavků na platformu SŽ, a to do připraveného listu „Specifikace HW požadavků“ v XDR dotazníku, který je nedílnou součástí zadávací dokumentace (Příloha č. 19).

SŽ limituje celkové požadavky na výpočetní výkon a kapacitu, který je připravena pro účely projektu nabídnout na:

Parametr výkonu a kapacity

Maximální dostupná hodnota

Počet vCPU	1240
Kapacita RAM	3600 GB
Kapacita disků	99000 GB

2.3.6 Dodávka hardwarových a softwarových prostředků

Výjimkou, kdy není nutné využití platformy SŽ, jsou samozřejmě komponenty řešení, které virtualizaci neumožňují. V takovém případě uvede dodavatel veškeré náklady na hardware, který je součástí dodávaného řešení a nebude provozován v platformě SŽ, do své cenové kalkulace.

Pokud bude součástí nabízeného řešení také dodávka technických a programových prostředků, bude dodavatel povinen respektovat následující omezení:

Dne 17. prosince 2018 vydal Národní úřad pro kybernetickou a informační bezpečnost (dále jen „NÚKIB“) na základě zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů, ve znění pozdějších předpisů (dále jen „ZoKB“) Varování, č. j. 3012/2018NÚKIB-E/110, kde uvedl, že: „Použití technických nebo programových prostředků následujících společností, včetně jejich dceřiných společností, představuje hrozbu v oblasti kybernetické bezpečnosti:

− Huawei Technologies Co., Ltd, Šen-čen, Čínská lidová republika

− ZTE Corporation, Šen-čen, Čínská lidová republika“.

Dne 4. ledna 2019 vydal Národní úřad pro kybernetickou a informační bezpečnost Metodiku k varování ze dne 17. prosince 2018 (dále jen „metodika“), kde jsou mj. určeny i postupy pro aktualizaci analýzy rizik. V souladu s vydanou metodikou provedla SŽ analýzu rizik související s předmětnou veřejnou zakázkou na služby, jak je jeho povinností podle § 5 a § 8 vyhlášky č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat, ve znění pozdějších předpisů. V návaznosti na to SŽ identifikovala rizika spojená s výše uvedenými technickými a programovými prostředky jako neakceptovatelná a současně opatření k jejich zvládání, kterým je nepřipuštění použití těchto prostředků v rámci plnění veřejné zakázky.

SŽ tak na základě varování NÚKIB, navazující metodiky a provedené analýzy rizik, ve spojení s § 4 odst. 4 ZoKB, nepřipouští v rámci plnění veřejné zakázky použití technických nebo programových prostředků společností (výrobců), které jsou uvedené v současné době platném varování NÚKIB jako hrozba v oblasti kybernetické bezpečnosti.

2.4 Oblasti, které nejsou předmětem plnění veřejné zakázky

Pro vyloučení pochybností SŽ uvádí, že následující oblast není předmětem plnění této veřejné zakázky:

• Výběr, dodávka a implementace síťových aktivních prvků nezbytných pro zajištění monitoringu síťového provozu v lokalitách, kde není aktuálně k dispozici dostatečný zdroj zrcadleného síťového provozu.

• Výběr, dodávka a implementace dodatečných nástrojů pro inspekci šifrovaného síťového provozu.

• Výběr, dodávka a implementace nástroje pro distribuci instalačního balíčku řešení EDR na koncová zařízení SŽ.

3 Současný stav a popis prostředí

Současný stav ICT prostředí SŽ je popsán v přiložených dokumentech:

- Analýza prostředí – architektura (Příloha č. 2 zadávací dokumentace)

- Analýza prostředí – sítě (Příloha č. 3 zadávací dokumentace)

- Platforma 2.0 - souhrn podporovaných infrastrukturních služeb, technologií a architektonických principů, která definuje základní rámec pro návrh řešení ICT (Příloha č. 4 zadávací dokumentace)

4 Požadavky na plnění

SŽ očekává dodávku komplexního řešení, která bude sestávat z jednorázových projektových činností, dodávky nástroje se souvisejícími technickými komponenty a průběžných služeb dodavatele řešení.

4.1 Jednorázové projektové činnosti

Jednorázové projektové činnosti jsou nedílnou součástí dodávaného řešení, jsou zahrnuty mezi akceptační milníky a je k nim vázána etapizace dodávky a fakturace.

4.1.1 Před-implementační analýza

1	Před-implementační analýza
Popis	Před-implementační analýza popisuje způsob a podmínky nasazení technologie Extended Detection and Response do prostředí SŽ. Dokument musí popisovat charakteristiku dodávaného technického řešení, popis jednotlivých jeho komponent, navrhovaný způsob zapojení do prostředí SŽ a samozřejmě způsob integrace na technologie využívané pracovištěm Security Operations Center. Dokument musí mít charakter detailní technické specifikace pro všechny uvažované implementační postupy, na jejichž předběžném schválení závisí umožnění provádět technické zásahy do prostředí SŽ.
Výstupy	Výstupem tohoto kroku bude dokument obsahující alespoň: • Popis dodávaného technického řešení a jeho komponent • Návrh architektury dodávaného řešení v prostředí SŽ • Detailní popis implementačních kroků • Detailní technická specifikace o Umístění technologií o Napájení o Síťové segmenty pro správu technologie o IP adresace o HW požadavky na virtualizační platformu SŽ o Požadavky na síťové prostupy o Požadavky na přístup do internetu o Požadavky na vzdálený přístup pro správu technologie o Požadavky na systémový monitoring • Postup napojení řešení na technologie pracoviště SOC o Log management / SIEM • Požadované součinnosti na SŽ

• Návrh akceptačních testů

• Katalog projektových rizik a návrh způsobu jejich ošetření

• Specifikace kroků, součinností dodavatele a jejich rozsah v MD, při ukončení projektu (exit plán), které budou součástí poskytované služby

• Detailní harmonogram implementace řešení

4.1.2 Instalace a konfigurace řešení

2	Instalace a konfigurace řešení
Popis	V této části projektu dojde k dodání, instalaci a konfiguraci všech komponent technického řešení Extended Detection and Response, které naplní požadavky předmětu veřejné zakázky a naplní specifika projektu uvedená v dokumentu před-implementační analýza.
Výstupy	Výstupem tohoto kroku bude funkční technické řešení Extended Detection and Response, které bude: • Obsahovat všechny potřebné licence, předplatné a technické podpory výrobce. • Dodáno s nezbytným hardwarem pro komponenty, které není vhodné provozovat ve virtuálním prostředí SŽ. • Nasazeno na všech požadovaných lokalitách. • V souladu se schválenou architekturou. • Zcela funkční pro výkon funkce Extended Detection and Response, tak jak SŽ požaduje v této Technické specifikaci. • Napojeno na systémový monitoring SŽ (výše specifikovaný Zabbix). • Schopno vyhovět definovaným akceptačním testům v rozsahu požadovaném SŽ.

4.1.3 Optimalizace bezpečnostní / detekční politiky řešení

3	Optimalizace bezpečnostní / detekční politiky řešení
Popis	V této části projektu bude dodavatelem provedeno vyhodnocení účinnosti nasazeného řešení Extended Detection and Response, upravena bezpečnostní / detekční politika a zdokumentovány všechny provedené konfigurační úpravy, které vedou k vyšší efektivitě detekce pro analytický tým SOC SŽ.
Výstupy	Výstupem tohoto kroku bude funkční technické řešení Extended Detection and Response, které bude mít upravenu bezpečnostní / detekční politiku tak, že bude minimalizován objem falešných detekcí, které by musel analytický tým SOC zpracovávat. SŽ požaduje provedení alespoň následujících činností: • Zohlednění reálných dostupných IP adresací SŽ v detekčních politikách. • Upřesnění konkrétních druhů validních aktiv SŽ zaznamenaných v komunikacích, které jsou důležité pro fungování detekčních pravidel (DNS, SMTP, WEB, NTP, PROXY, MS AD).

• Aplikace výjimek, které doporučí SŽ.

Všechny upravené konfigurace budou zdokumentovány a předány jako výstup této části projektu.

4.1.4 Napojení na platformu Log management / SIEM

4	Napojení na platformu Log management / SIEM
Popis	V této části projektu bude dodavatelem provedeno napojení technického řešení Extended Detection and Response na systém pro ukládání a zpracování logů (Log management) a systém SIEM, pro detekci bezpečnostní událostí spojených s platformou XDR, nebo událostmi, které řešení XDR vygeneruje.
Výstupy	Výstupem tohoto kroku bude návrh a dokumentace vhodných bezpečnostních scénářů pro platformu SIEM (use-cases), tedy návrh situací a kombinace stavů, které je nad prostředím XDR vhodné sledovat. Jedná se zejména o tyto situace: • Nestandardní pokusy o přístup k prostředí XDR. o do systémového prostředí o do aplikačních rozhraní WebUI o do aplikačních rozhraní API • Pokus o manipulaci s daty uloženými v prostředí XDR. • Změna systémového času, která může znamenat narušení schopnosti detekovat kybernetické bezpečnostní události. Výstupem tohoto kroku bude také funkční technické řešení Extended Detection and Response, které bude: • Napojeno na technologii Log management. o auditní logy technologie XDR o systémové logy technologie XDR a souvisejících operačních systémů o bezpečnostní logy technologie XDR a souvisejících operačních systémů o všechny logy budou zdokumentované pro účely jejich zpracování v technologii Log management SŽ • Napojeno na technologii Security Information and Event Management / SIEM).

V této části projektu bude dodavatelem provedeno zaškolení technického servisního týmu SŽ a týmu Security Operations Center SŽ. Cílem je přenesení znalostí o správě dodaných nástrojů a předání rutinní správy na tým SŽ. Druhé specifické školení by se mělo hlouběji zaměřit na školení práce s XDR řešením, jehož odběratelem bude pracoviště SOC SŽ.

Popis

Školení

5

4.1.5 Školení

Výstupy

Výstupem tohoto kroku bude realizované školení se zaměřením na využívání a správu technického řešení Extended Detection and Response:

• Prezenční školení servisního týmu SŽ složeného z minimálně 8 osob, které bude mít časovou dotaci alespoň 3 MD. Toto školení bude zaměřeno zejména na:

o komponenty systému

o konfigurační parametry komponent

o ladění výkonnostních a kapacitních parametrů řešení

o troubleshooting

o update a upgrade.

• Prezenční školení týmu SOC SŽ v prostorách výrobce zakončené certifikací účastníků. SŽ nominuje 4 pracovníky a bude požadovat naplnění časové dotace alespoň 3 MD. Toto školení bude zaměřeno zejména na:

o užívání nástroje XDR

o tvorba a úprava detekčních pravidel

o vyšetřování a analýza událostí

o aktivní vyhledávání kybernetických hrozeb.

4.2 Průběžné služby dodavatele řešení

4.2.1 Technická podpora servisního týmu SŽ

	Technická podpora servisního týmu SŽ
Popis	Technická podpora bude řízena dle parametrů uvedených ve zvláštních obchodních podmínkách SŽ, konkrétně ustanovením kapitoly „12. SERVISNÍ MODELY“. SŽ požaduje plnění v parametrech servisního modelu „B1 Závažný“. SŽ požaduje provoz Help Desku dodavatele, který bude provozován v režimu odpovídajícím specifikaci uvedené ve zvláštních obchodních podmínkách SŽ, konkrétně ustanovením kapitoly „10. HELPDESK“. SŽ požaduje plnění Help Desku v režimu „Režim 1“ a úrovni „L3“.
Výstupy	Výstupem tohoto bude poskytnutí služby dle parametrů požadovaných SŽ a definovaných v servisní smlouvě s dodavatelem.

Dodavatel zajistí pravidelnou údržbu všech komponent dodaného řešení, a to včetně bezpečnostní údržby. Cílem je, aby byl zajištěn provoz řešení v aktuálních verzích produktu, které budou považovány za stabilní a bezpečné. Dodavatel zajistí aplikaci výrobcem vydávaných opravných balíčků, nových funkcionalit a bezpečnostních záplat.

Popis

Údržba řešení

4.2.2 Údržba řešení

	• Aktivní sledování a využívání nových postupů v oblasti zabezpečení systémů a komunikací • Průběžné aplikování bezpečnostních oprav od výrobců • Sběr podkladů pro aktualizaci dokumentace / evidence aktiv SŽ • Pravidelná profylaxe.
Výstupy	Výstupem tohoto bude poskytnutí služby dle parametrů požadovaných SŽ a definovaných v servisní smlouvě s dodavatelem.

4.3 Konzultace a rozvojové aktivity

	Konzultace a rozvojové aktivity
Popis	Dodavatel poskytne SŽ služby konzultace na vyžádání. Maximální souhrn těchto služeb bude činit 50 MD za celou dobu trvání smlouvy, čerpání bude probíhat dle konkrétních potřeb SŽ. Jedná se o rozvojové aktivity, které budou souviset především ve změnami v prostředí SŽ, které mohou mít dopad na provoz řešení NDR.
Výstupy	Výstupem tohoto bude poskytnutí služby konzultace na vyžádání podle potřeb SŽ.

5 Fáze plnění a akceptační milníky

Plnění musí být dodáno v níže uvedených fázích. Každá z níže uvedených fází (tj. každý řádek níže uvedené tabulky) musí být SŽ separátně akceptována nejpozději v termínu uvedeném v Harmonogramu. SŽ akceptuje výstupy dané Fáze, jestliže je dodavatel provedl v šíři a kvalitě požadované v zadávací dokumentací této veřejné zakázky. V opačném případě je dodavatel povinen napravit nedostatky dodávky.

Fáze	Popis	Kapitola obsahující požadavky
Fáze 1	Jednorázové projektové činnosti: - Před-implementační analýza - Instalace a konfigurace řešení	4.1.1 4.1.2
Fáze 2	Jednorázové projektové činnosti: - Optimalizace bezpečnostní / detekční politiky řešení - Napojení na platformu Log management / SIEM	4.1.3 4.1.4
Fáze 3	Jednorázové projektové činnosti: - Školení	4.1.5
Fáze 4	Průběžné služby dodavatele řešení: - Technická podpora servisního týmu SŽ - Údržba řešení	4.2.1 4.2.2
Fáze 5	Konzultace a rozvojové aktivity	4.3

Draft

Příloha č. 3 zadávací dokumentace – Analýza prostředí – architektura

Dokument se neuveřejňuje

Správa železnic, státní organizace

zapsána v obchodním rejstříku vedeném Městským

Sídlo: Dlážděná 1003/7, 110 00 Praha 1

IČO: 709 94 234 DIČ: CZ 709 94 234

Draft

Příloha č. 3 zadávací dokumentace – Analýza prostředí – sítě Dokument se neuveřejňuje

Správa železnic, státní organizace Sídlo: Dlážděná 1003/7, 110 00 Praha 1

zapsána v obchodním rejstříku vedeném MěstskýmIČO: 709 94 234 DIČ: CZ 709 94 234

SPECIFIKACE NABÍDKOVÉ CENY

HARMONOGRAM PLNĚNÍ

Fáze	Popis	Zahájení	Ukončení
F1.a	Před-implementační analýza	od účinnosti smlouvy	do 85 dnů
F1.b	Instalace a konfigurace řešení	od ukončení F1.a a připravenosti virtualizační platformy na straně Zadavatele	do 125 dnů
F2.a	Optimalizace bezpečnostní / detekční politiky řešení	od ukončení F1.b	do 85 dnů
F2.b	Napojení na platformu Log management / SIEM	od ukončení F2.a	do 85 dnů
F3	Školení	od ukončení F2.a	do 85 dnů
F4.a	Technická podpora servisního týmu zadavatele	od ukončení F2.a	do 5 let
F4.b	Údržba řešení	od ukončení F2.a	do 5 let
F5	Konzultace a rozvojové aktivity	od účinnosti smlouvy	do ukončení smlouvy

1/1

Správa železnic, státní organizace

zapsána v obchodním rejstříku vedeném Městským soudem v Praze, spisová značka A 48384

Sídlo: Dlážděná 1003/7, 110 00 Praha 1

IČ: 709 94 234 DIČ: CZ 709 94 234

www.szdc.cz

Příloha č. 4 Smlouvy

Seznam poddodavatelů

Účastník:

Obchodní firma/jméno ALEF NULA, a. s.

Sídlo/místo podnikání Pernerova 691/42, 186 00 Praha IČO 61858579

Zastoupen Ing. Milanem Zinkem, předsedou představenstva

který podává nabídku na nadlimitní sektorovou veřejnou zakázku s názvem „Implementace systému Extended Detection and Response (XDR)“, č.j. 40198/2023-SŽ-GŘ-O8, tímto předkládá v souladu s § 105 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, seznam poddodavatelů, s jejichž pomocí předpokládá plnění veřejné zakázky.

Identifikace poddodavatelů dodavatele1			Část plnění veřejné zakázky, které má dodavatel v úmyslu zadat poddodavateli (specifikace a procentuální podíl)
1.	Obchodní firma / jméno a příjmení	DATOR3 Services, a. s.	Před-implementační analýza – 60% Konfigurační řešení – 60% Optimalizace bezpečnostní / detekční politiky řešení – 60% Napojení na platformu Log management / SIEM – 60% Školení – 60 %
	Sídlo / Místo podnikání	Stýblova 253/13, 149 00 Praha 4
	Identifikační číslo	25788612
	Prostřednictvím poddodavatele prokazována kvalifikace	ANO

1 V případě více poddodavatelů zkopíruje dodavatel tabulku tolikrát, kolikrát bude třeba.

1/1

Správa železnic, státní organizace

zapsána v obchodním rejstříku vedeném Městským soudem v Praze, spisová značka A 48384

Sídlo: Dlážděná 1003/7, 110 00 Praha 1

IČO: 709 94 234 DIČ: CZ 709 94 234

www.spravazeleznic.cz

Příloha č. 6.1 Smlouvy

Zvláštní obchodní podmínky pro Zakázky v oblasti ICT

OBSAH

1. VÝKLAD POJMŮ 2

2. DOBA A MÍSTO PLNĚNÍ 7

3. PRÁVA A POVINNOSTI OBOU STRAN 7

4. POVINNOSTI DODAVATELE 7

5. POVINNOSTI OBJEDNATELE 8

6. LICENČNÍ UJEDNÁNÍ 8

7. ZDROJOVÝ KÓD A DOKUMENTACE 11

8. AKCEPTAČNÍ ŘÍZENÍ 12

9. ŠKOLENÍ 13

10. HELPDESK 13

11. NAHLÁŠENÍ INCIDENTU 15

12. SERVISNÍ MODELY 15

13. ÚČAST PODDODAVATELŮ 16

14. REALIZAČNÍ TÝM 17

15. KOMUNIKACE STRAN 17

16. SMLUVNÍ POKUTY 17

17. ZÁRUKA ZA JAKOST A PRÁVA Z VADNÉHO PLNĚNÍ 19

18. UKONČENÍ SMLUVNÍHO VZTAHU 20

19. ZMĚNY SMLOUVY A ZMĚNOVÉ ŘÍZENÍ 21

20. KYBERNETICKÁ BEZPEČNOST 22

21. OCHRANA OSOBNÍCH ÚDAJŮ 25

22. OCHRANA DŮVĚRNÝCH INFORMACÍ 26

1/27

Správa železnic, státní organizace

zapsána v obchodním rejstříku vedeném Městským soudem v Praze, spisová značka A 48384

Sídlo: Dlážděná 1003/7, 110 00 Praha 1

IČ: 709 94 234 DIČ: CZ 709 94 234

www.spravazeleznic.cz

1. VÝKLAD POJMŮ

1.1. Akceptační kritéria představují podmínku anebo vlastnost výstupu provádění Plnění dle Smlouvy, která musí být splněna, aby bylo Plnění dle Smlouvy provedeno, přičemž Akceptační kritéria jsou uvedena v Příloze Smlouvy, která obsahuje specifikaci Plnění (dále jen

„Specifikace Plnění“).

1.2. Akceptační protokol je protokol, který jsou zavázáni podepsat Objednatel i Dodavatel po provedení všech nezbytných činností v rámci Akceptačního řízení, potvrzující provedení výstupu provádění Plnění anebo výsledek Testů výstupů provádění Plnění. Protokol je připravený ze strany Dodavatele a následně upravený a vyplněný Objednatelem. Akceptační protokol obsahuje:

a. specifikaci provedeného Plnění;

b. Akceptační kritéria;

c. informace o průběhu Testů, jsou-li prováděny;

d. další informace a dokumenty nezbytné pro provedení Akceptačního řízení provedeného Plnění.

1.3. Akceptační řízení je postupné provedení akceptačních procesů a podepsání Akceptačního/ch protokolu/ů pro Plnění dle Smlouvy.

1.4. Aktualizace je dílčí změna verze Software, zpravidla odstraňující zranitelnosti či drobné nedostatky Software většinou neprojevující se navenek uživatelům, v IT obvykle označovaná jako „patch“ nebo „security update“ (v rámci IT se také často označuje jako změna třetí číslice v čísle verze Software, tedy např. 4.1.1. na 4.1.2.). Aktualizace představuje takovou změnu Software, která není Modernizací ani Zásadní modernizací.

1.5. Autorské dílo znamená dílo ve smyslu § 2 Autorského zákona; zejména nikoliv však výlučně Software, Databáze a jakékoliv výstupy předávané Objednateli na základě Smlouvy, které splňují podmínky stanovené v § 2 Autorského zákona.

1.6. Autorský zákon znamená zákon č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpisů.

1.7. Čas nahlášení Incidentu představuje časový údaj, vyjadřující datum a čas, kdy byl Incident nahlášen Dodavateli způsobem stanoveným ve Smlouvě, tj. vytvořením ticketu v Helpdesku, vytěžením emailu z emailového serveru Objednatele a jeho vložením do Helpdesku jako ticketu anebo ukončením telefonátu.

1.8. Data jsou jakékoliv údaje či informace vznikající v souvislosti s Plněním dle Smlouvy.

1.9. Databáze znamená databázi splňující požadavky na Autorská díla, databázi ve smyslu § 88 Autorského zákona a jakoukoliv jinou Autorským zákonem neupravenou databázi.

1.10. Doba vyřešení je pro každou kategorii Incidentů uvedena ve Smlouvě a znamená rozdíl mezi časem nahlášení Incidentu a dodáním řešení. Do Doby vyřešení Incidentu se nezapočítává doba, po kterou nemůže Dodavatel řešit Incident z důvodu:

a. neobdržení podkladů a informací vyžádaných Dodavatelem, které jsou nezbytně nutné pro lokalizaci nebo replikaci Incidentu, od Objednatele;

b. řešení Incidentu u třetí osoby (vyjma Poddodavatele), jejíž součinnost je dle Smlouvy povinen zajistit Objednatel (např. poskytovatele služeb podpory IT prostředí Objednatele anebo systémů, na které je Software napojen);

c. neposkytnutí jiné nezbytně nutné součinnosti Objednatele vyžádané Dodavatelem v souladu s těmito ZOP či Smlouvou a souvisejícími přílohami.

1.11. Doba zahájení řešení incidentu (RTI) je Doba, která uplyne od času nahlášení Incidentu Ohlašovatelem prostřednictvím Helpdesku a okamžikem předání řešení Incidentu na skupinu řešitelů.

1.12. Dodavatel označuje rovněž Poskytovatele, Zhotovitele či Prodávajícího v závislosti na typu uzavřené Smlouvy.

1.13. Dokumentace znamená část specifikace Předmětu Smlouvy, která představuje jednotlivé dokumenty popisující Předmět Smlouvy a zacházení s ním, jako jsou uživatelská dokumentace, administrátorská dokumentace, bezpečnostní dokumentace, a také jakoukoliv jinou dokumentaci vytvářenou anebo poskytovanou Dodavatelem v rámci provádění Plnění. Dokumentace musí být vždy vyhotovena a předána Objednateli v elektronické podobě (pokud je vyhotovována v listinné podobě, pak Dodavatel předá Objednateli elektronickou kopii takové Dokumentace).

1.14. Dostupnost znamená stav Software, v průběhu kterého je, anebo by v případě poskytování řádné a včasné součinnosti ze strany Objednatele za podmínek dle Smlouvy byl možný řádný provoz Software v celém jeho rozsahu nebo jeho podstatné části, přičemž Software se považuje za Dostupný, je-li přístupný a použitelný pro všechny uživatele Software.

1.15. Důvěrné informace znamenají informace, které jsou zpracovávány, ukládány nebo poskytovány v IT prostředí Objednatele, včetně Dat Objednatele, veškeré údaje a informace související s těmito informacemi, s technickým vybavením, komunikačními prostředky a programovým vybavením IT prostředí Objednatele a s objekty, ve kterých jsou tyto systémy umístěny, zaměstnanci nebo dodavateli podílejícími se na provozu, rozvoji, správě nebo bezpečnosti IT prostředí Objednatele. Mezi Důvěrné informace nepatří informace, které jsou veřejně přístupné.

1.16. FOSS licence znamená Free Open Source Software licence.

1.17. GDPR znamená nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů).

1.18. GUI znamená grafické uživatelské rozhraní.

1.19. Hardware znamená veškeré hmotné součásti počítačových systémů a veškeré související vybavení hmotné povahy spolu se vším příslušenstvím, a včetně veškeré související dokumentace.

1.20. Informační či komunikační systém znamená informační či komunikační systém kritické informační infrastruktury Objednatele ve smyslu § 2 b) ZKB nebo jiný informační či komunikační systém, na který se vztahuje ZKB.

1.21. Incident představuje neplánované přerušení fungování Předmětu Smlouvy, jakékoliv jeho části anebo Plnění dle Smlouvy, omezení kvality fungování Předmětu Smlouvy a souvisejícího Plnění, anebo jakoukoliv prokazatelnou nefunkčnost Předmětu Smlouvy a souvisejícího Plnění. Incident se projevuje zejména selháním oproti funkčnosti a funkcionalitě specifikované v Příloze Smlouvy Specifikace Plnění, anebo obvyklé pro Předmět Smlouvy. Vada je vždy Incidentem a jde tak o podmnožinu pojmu Incident. Za dobu trvání Incidentu se považuje doba od Času nahlášení Incidentu Ohlašovatelem do vyřešení Incidentu, které bude Ohlašovatelem nebo jeho nadřízeným uživatelem potvrzeno vhodným způsobem v Helpdesku, byl-li Incident vyřešen.

Kategorizace incidentů dle důležitosti, zohledňující naléhavost a dopad Incidentu:

A) Vysoká – ohrožení kritických procesů a činností na straně Objednatele

B) Střední – Zásadní vliv na důležité procesy a činnosti Objednatele

C) Nízká – standardní řešení v efektivním režimu

1.22. Instalace znamená provedení veškerých činností nezbytných k zprovoznění Hardware nebo Software vč. jeho Aktualizací, Modernizací či Zásadních modernizací poskytnutých v rámci Plnění dle Smlouvy v IT prostředí Objednatele, a to na platformě určené Objednatelem.

1.23. ISDS znamená informační systém datových schránek ve smyslu zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů.

1.24. Interní předpisy znamenají interní předpisy Objednatele, jejichž seznam včetně znění daných interních předpisů, jsou-li relevantní z hlediska Plnění, je uveden v Příloze Smlouvy Seznam interních předpisů.

1.25. Insolvenční zákon znamená zákon č. 182/2006 Sb., o úpadku a způsobech jeho řešení (insolvenční zákon), ve znění pozdějších předpisů.

1.26. IT prostředí Objednatele znamená veškerý Hardware ve vlastnictví Objednatele a Software, ve vztahu k němuž je Objednatel nositelem potřebných oprávnění, nebo Hardware a Software využívaný Objednatelem na základě jiného právního titulu než Smlouvy. Jedná se zejména o servery, diskové pole a stanice, aplikace třetích osob, pasivní a aktivní datová infrastruktura (kabeláže, switche, VPN linky apod.). Podrobná specifikace IT prostředí Objednatele je uvedena v Příloze Smlouvy Platforma Správy železnic a v Příloze Smlouvy Specifikace Plnění.

1.27. Kvalifikovaná osoba je člen Realizačního týmu, kterým Dodavatel prokazoval splnění kvalifikačních předpokladů v rámci Veřejné zakázky.

1.28. Kybernetický bezpečnostní incident je narušení bezpečnosti informací v informačních systémech nebo narušení bezpečnosti služeb anebo bezpečnosti a integrity sítí elektronických komunikací podle § 7 ZKB v důsledku Kybernetické bezpečnostní události.

1.29. Kybernetická bezpečností událost je událost podle § 7 ZKB, která může způsobit narušení bezpečnosti informací v informačních systémech nebo narušení bezpečnosti služeb anebo bezpečnosti a integrity sítí elektronických komunikací.

1.30. Modernizace je změna verze Software, která zpravidla představuje výraznější zásah do dílčí funkcionality Software, přepracováním jeho vybrané funkcionality či doplnění funkcionality nové, zvýšení kompatibility Software s jinými prvky informačních a komunikačních technologií, či jinou optimalizaci funkce Software nad rámec Aktualizace, zpravidla v IT označovaná jako „update“ (v rámci IT se také často označuje jako změna druhé číslice v čísle verze Software, tedy např. 4.1. na 4.2.).

1.31. NÚKIB znamená Národní úřad pro kybernetickou a informační bezpečnost.

1.32. Občanský zákoník znamená zákon č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů.

1.33. Obchodní podmínky znamenají obchodní podmínky Objednatele, v posledním znění ke dni podání nabídky do Veřejné zakázky či aktualizace těchto Obchodních podmínek provedené v souladu se Smlouvou po dobu jejího trvání.

1.34. Objednatel je Správa železnic, státní organizace, IČO 70994234, se sídlem Praha 1 – Nové Město, Dlážděná 1003/7, PSČ 110 00, zapsaná v obchodním rejstříku vedeném Městským soudem v Praze pod sp. Zn. A 48384.

1.35. Ohlašovatel znamená uživatel Předmětu Smlouvy; případně osoba určená Objednatelem dle vymezení parametrů Helpdesk

a. pro úroveň L1 Helpdesku uživatele Software;

b. pro úroveň L2 Helpdesku osoby určených Objednatelem dle jeho potřeb zajišťující úroveň L1 podpory;

c. pro úroveň L3 Helpdesku člen Realizačního týmu určeného Dodavatelem dle jeho potřeby zajišťující úroveň L2 podpory.

1.36. Opční právo představuje vyhrazenou změnu závazku v souladu s ustanovením § 100 odst. 3 ZZVZ ze Smlouvy spočívající v pořízení dalšího obdobného Plnění od vybraného uchazeče v rámci zadávacího řízení Veřejné zakázky, tj. od Dodavatele dle Smlouvy.

1.37. Osobní údaje znamenají osobní údaje ve smyslu GDPR, včetně zvláštních kategorií osobních údajů ve smyslu článku 9 a rozsudků ve smyslu článku 10 GDPR.

1.38. Pracovní den (PD) znamená kterýkoliv den, kromě soboty a neděle a dnů, na něž připadá státní svátek nebo ostatní svátek podle platných a účinných právních předpisů České republiky.

1.39. Plnění představuje plnění, které tvoří Předmět Smlouvy a k němuž se váže povinnost Dodavatele toto plnění Objednateli poskytovat. Plnění je blíže specifikované ve Smlouvě a v Příloze Smlouvy Specifikace Plnění.

1.40. Poddodavatel znamená kteroukoli třetí osobu realizující poddodávky pro Dodavatele v souvislosti s Předmětem Smlouvy. Poddodavatelé mohou být výslovně uvedeni v Příloze Smlouvy Poddodavatelé.

1.41. Požadavek znamená žádost ze strany Objednatele o službu nebo její podporu předaná v souladu se Smlouvou Dodavateli, která nemá příčinu v chybovém stavu, tj. není incidentem.

Kategorizace Požadavků dle důležitosti:

A) Vysoká – řešení je pro Objednatele kritické

B) Střední – řešení neovlivňuje využívání hlavních funkcí služby

C) Nízká – řešení výrazně neovlivňuje procesy Objednatele

1.42. Produkční prostředí znamená IT prostředí Objednatele v ostrém provozu běžně přípustnou uživatelům Software, vyjma Testovacího prostředí.

1.43. Provozovatel znamená provozovatel ve smyslu § 2 písm. g) ZKB.

1.44. Předmět Smlouvy znamená dle typu Smlouvy Software nebo Hardware, přičemž parametry a vlastnosti Předmětu Smlouvy jsou blíže specifikovány v Příloze Smlouvy Specifikace Plnění.

1.45. Převzetí poskytování plnění je předání znalostí Dodavateli a praktické seznámení se Dodavatele s podmínkami poskytování služeb. Pokud dochází k převzetí poskytování podpory, jsou podmínky pro Převzetí poskytování plnění uvedeny ve Smlouvě a v Příloze Smlouvy Specifikace Plnění.

1.46. Příloha Smlouvy je dokument, který tvoří nedílnou součást Smlouvy a obsahuje bližší specifikaci smluvních podmínek.

1.47. Reakce znamená kvalifikovanou a konkrétní odpověď na nahlášení Incidentu nebo na jiný požadavek, ve formě a způsobem dále definovanými v Příloze Smlouvy Specifikace Plnění.

1.48. Reakční doba je pro každou kategorii Incidentů uvedena v Příloze Specifikace Plnění a představuje dobu od Času nahlášení Incidentu do doručení Reakce Objednateli nebo Ohlašovateli.

1.49. Realizační tým znamená osoby uvedené v příloze Smlouvy Realizační tým, kterými Dodavatel prokazoval splnění kvalifikačních předpokladů v rámci Veřejné zakázky a další osoby (zaměstnanci Dodavatele či Poddodavatele), prostřednictvím nichž Dodavatel provádí Plnění dle Smlouvy.

1.50. Recovery Point Objective (RPO) je parametr, který vyjadřuje maximální ztrátu dat uživatelů při havárii systému a následné obnově.

1.51. Recovery Time Objective (RTO) je parametr, který vyjadřuje dobu nutnou k obnově chodu služby do akceptované úrovně provozu.

1.52. Helpdesk je Software provozovaný Dodavatelem nebo Objednatelem sloužící ke komunikaci Stran v průběhu provádění Plnění dle Smlouvy, v rámci něhož bude evidován postup Dodavatele při provádění Plnění dle Smlouvy a zároveň bude sloužit jako kontaktní místo Dodavatele pro nahlašování požadavků, otázek, odpovědí a další zaznamenávání průběhu provádění Plnění dle Smlouvy.

1.53. Servisní model je standardizovaný model provozu a podpory aplikace, systému nebo instance služby.

1.54. SLA znamená úroveň kvality Plnění představující dohodu o úrovni poskytovaných ICT služeb dle Smlouvy.

1.55. Software znamená veškeré programové vybavení a další Autorská díla, stejně jako další věci či jiné majetkové hodnoty, které s programovým vybavením souvisí a jsou určeny ke společnému užívání s tímto programovým vybavením, tj. zejména Databáze, GUI, zvukové nahrávky, videa, obrázky, fotografie apod., včetně veškeré související dokumentace a updatů a upgradů tohoto programového vybavení, avšak s výjimkou Hardware a Databází.

1.56. Standardní Software znamená Software, který je distribuován pod standardními licenčními podmínkami více třetím osobám. Mezi Standardní software patří:

a. Software renomovaných výrobců, jenž je na trhu běžně dostupný, tj. nabízený na území České republiky alespoň dvěma (2) na sobě nezávislými a vzájemně se neovládajícími subjekty, a který je v době uzavření Smlouvy prokazatelně užíván v produkční prostředí nejméně u pěti (5) na sobě nezávislých a vzájemně nepropojených subjektů.

b. Software, u kterého je s ohledem na jeho (i) marginální význam, (ii) nekomplikovanou propojitelnost či (iii) oddělitelnost a nahraditelnost v IT prostředí bez nutnosti vynakládání větších prostředků (více než 50.000 Kč/rok) zajištěno, že další rozvoj Software jinou osobou než tvůrcem/distributorem takového Software je možné provádět bez toho, aby tím byla dotčena práva autorů takovéhoto Softwaru, neboť nebude nutné zasahovat do Zdrojových kódů takovéhoto Softwaru anebo proto, že případné nahrazení takovéhoto Softwaru nebude představovat výraznější komplikaci a náklad na straně Objednatele.

c. Software, jehož API („Application Programming Interface“) pokrývá všechny moduly a funkcionality Software, je dobře dokumentované, umožňuje zapouzdření Software a jeho adaptaci v rámci měnících se podmínek IT prostředí Objednatele a Software bez nutnosti zásahu do Zdrojových kódů Softwaru, a Dodavatel poskytne Objednateli právo užít toto rozhraní pro programování aplikací ve stejném rozsahu, jako Software.

d. Software, o kterém to stanoví Smlouva.

1.57. Smlouva uzavřená na základě zadávacího řízení Veřejné zakázky vztahující se k ICT, která se řídí těmito ZOP.

1.58. Testy se rozumí provádění testovacího užívání Předmětu Smlouvy v Testovacím prostředí prostřednictvím simulace ostrého provozu v Produkčním prostředí a reálných situací a Testovacích scénářů.

1.59. Testovací prostředí znamená virtuální či fyzickou kopii Předmětu Smlouvy anebo IT prostředí Objednatele určenou Objednatelem k provádění Testů.

1.60. Vada kategorie A znamená kritickou vadu, která má zásadní dopad na základní funkce Plnění, má jakýkoli vliv na kvalitu a bezpečnost dat a výsledky jejich zpracování anebo způsobuje výpadky Plnění.

1.61. Vada kategorie B znamená vadu umožňující provoz základních funkcí Plnění, zároveň nemá vliv na kvalitu ani na bezpečnost dat a výsledky zpracování anebo hrozí, že by mohla způsobit výpadek Plnění.

1.62. Vada kategorie C znamená vadu, která není Vadou kategorie A anebo B (např. špatná grafická úprava aplikace, špatný pravopis u nápovědy apod.).

1.63. Veřejná zakázka je zakázka realizovaná na základě smlouvy mezi Objednatelem a Dodavatelem, jež byla uzavřena na základě zadávacího řízení dle ZZVZ nebo výběrového řízení dle vnitřních předpisů Objednatele.

1.64. VKB znamená vyhlášku č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti), ve znění pozdějších předpisů.

1.65. Výkaz znamená dokument obsahující souhrnnou evidenci poskytnutého Plnění za období vymezené ve Smlouvě nebo v Příloze Smlouvy Specifikace Plnění. Výkaz je vystavován zpětně za vymezené období.

1.66. Výpadek znamená neplánované přerušení provozu Předmětu smlouvy či jakékoliv jeho podstatné části, při kterém je tento celek či v příslušná část nedostupná pro uživatele (není dostupný). Za Výpadek se pro účely této Smlouvy nepovažuje Výpadek způsobený z důvodů způsobených třetími osobami, jejichž součinnost anebo bezvadné poskytování služeb je povinen zajistit Objednatel (poskytovatel služeb podpory IT prostředí Objednatele a informačních systémů, na které je Software napojen).

1.67. Újma znamená vždy újmu na jmění (škodu) ve smyslu § 2894 odst. 1 Občanského zákoníku a dále vždy i nemajetkovou újmu ve smyslu § 2894 odst. 2 Občanského zákoníku. Toto ustanovení je výslovným ujednáním o povinnosti stran odčinit nemajetkovou újmu v případech porušení povinností dle těchto ZOP a Smlouvy.

1.68. Významný dodavatel znamená Dodavatel, který je Provozovatelem, jakož i každý, kdo s Objednatelem vstupuje do právního vztahu, který je významný z hlediska bezpečnosti Informačního či komunikačního systému ve smyslu § 2 odst. M) VKB.

1.69. Významná změna znamená změna, která má nebo může mít vliv na kybernetickou bezpečnost a představuje vysoké riziko, např.

a. změny pravidel ochranných systémů aplikačních firewallů a pravidel přepínání a směrování v sítích,

b. změny autentizačních mechanismů,

c. přidání, změna nebo odebrání služeb, informačních systémů/aplikací nebo ochranných systémů,

d. změny, které umožňují sdílení informací, služeb nebo zdrojů mimo provozní prostředí,

e. změny opatření pro zajištění bezpečnosti vzdáleného přístupu,

f. zavedení skriptů pro automatické přihlášení,

g. migrace dat do jiné Databáze, apod. ve smyslu § 2 odst. O) VKB.

1.70. Zadávací dokumentace je souborem dokumentů obsahujících zadávací podmínky, sdělované nebo zpřístupňované účastníkům zadávacího řízení na Veřejnou zakázku.

1.71. Zásadní modernizace je podstatná změna/rozšíření funkčnosti nebo změna koncepce Software, přinášející podstatné změny pro chování Software vůči uživatelům, zpravidla v IT označovaná jako „upgrade“ (v rámci IT se také často označuje jako změna v čísle verze Software, tedy např. 4 na 5).

1.72. Zdrojový kód znamená zápis kódu počítačového programu (Softwaru) v programovacím jazyce, který je uložen v jednom nebo více editovatelných souborech, čitelný, opatřený komentáři vysvětlujícími jednotlivé jeho části alespoň ve standardu obvyklém pro open source projekty a procesy, ve spustitelném formátu odpovídajícím programovacímu jazyku a Produkčnímu prostředí, včetně ověřeného a podrobného postupu nezbytného pro sestavení plně funkčního strojového kódu, a v podobě, aby jej bylo možné zkompilovat do strojového kódu bez nutnosti provedení jiných úprav než kompilace v souladu s postupem k sestavení.

1.73. ZKB znamená zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), ve znění pozdějších předpisů.

1.74. ZOP znamená tento dokument, tedy zvláštní obchodní podmínky, které definují další parametry a upřesňují konkrétní podmínky a specifické požadavky Objednatele.

1.75. ZZVZ znamená zákon č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů.

1.76. Není-li výslovně uvedeno jinak nebo nevyplývá-li něco jiného z povahy věci, mají pojmy, které nejsou definovány v těchto ZOP, význam uvedený v Obchodních podmínkách či Smlouvě a jejích přílohách.

1.77. Ustanovení ZOP mají přednost před ustanoveními Obchodních podmínek, pokud jsou ustanovení těchto dokumentů v rozporu, uplatní se ustanovení uvedené v ZOP. Ustanovení Smlouvy mají přednost před ustanoveními Obchodních podmínek i ZOP.

2. DOBA A MÍSTO PLNĚNÍ

2.1. Provádění Plnění bude zahájeno ode dne nabytí účinnosti Smlouvy, není-li ve Smlouvě stanoveno jinak.

2.2. Plnění nebo dílčí části Plnění bude Dodavatel provádět v termínech sjednaných ve Smlouvě či definovaných v Příloze Smlouvy Specifikace Plnění nebo Harmonogram.

2.3. Místem provádění Plnění jsou místa umístění IT prostředí Objednatele (tj. Testovací prostředí a Produkční prostředí), není-li ve Smlouvě anebo Příloze Smlouvy Specifikace Plnění výslovně stanoveno jinak. Popis IT prostředí Objednatele obsahuje Příloha Smlouvy Platforma Správy železnic.

2.4. Služby budou poskytovány formou vzdáleného přístupu k IT prostředí Objednatele, není-li ve Smlouvě stanoveno jinak. Objednatel se zavazuje umožnit Dodavateli vzdálený přístup k IT prostředí Objednatele. Objednatel je oprávněn monitorovat a logovat přístupy Dodavatele do IT prostředí Objednatele, jakož i veškerou další aktivitu Dodavatele významnou z hlediska bezpečnosti Informačního či komunikačního systému za účelem posouzení souladu plnění Smlouvy s pravidly uvedenými v těchto ZOP, zejm. pak čl. 20. ZOP a Dodavatel se zavazuje Objednateli za tímto účelem poskytnout veškerou nutnou součinnost. Vzdálený přístup k IT prostředí Objednatele může být Objednatelem okamžitě odepřen v případě Kybernetické bezpečnostní události ve smyslu § 7 ZKB či porušení povinností stanovených v Interních předpisech.

2.5. Dodavatel bere na vědomí, že přístup k IT prostředí Objednatele:

a. je udělován fyzickým osobám Dodavatele, jakož i pro konkrétní zařízení, na základě výslovného požadavku Dodavatele a Objednatel je oprávněn dle svého uvážení přístup neudělit či kdykoli odebrat;

b. je poskytován na základě principů “need to know” a “deny by default”; a

c. je poskytován za podmínky dodržování veškerých bezpečnostních opatření a požadavků Objednatele.

3. PRÁVA A POVINNOSTI OBOU STRAN

3.1. Strany se zavazují postupovat v souladu s veškerými obecně závaznými právními předpisy a prohlašují, že Smlouva je v souladu s těmito právními předpisy. Pokud se v průběhu trvání Smlouvy některé její ustanovení dostane do rozporu s kogentním ustanovením obecně závazného právního předpisu, platí příslušné ustanovení právního předpisu s tím, že zbývající ustanovení Smlouvy zůstávají v platnosti.

3.2. Strany jsou v průběhu Plnění povinny postupovat v souladu s Interními předpisy Objednatele, pokud jsou jednoznačně specifikovány v Příloze Smlouvy Seznam Interních předpisů. Podpisem Smlouvy Dodavatel prohlašuje, že měl možnost se seznámit s Interními předpisy Objednatele, jejichž seznam je uveden v Příloze Smlouvy Seznam interních předpisů, a dále bere na vědomí, že Interní předpisy mohou být přiměřeným způsobem jednostranně měněny či jinak doplňovány Objednatelem, přičemž každá nová verze je pro Dodavatele závazná vždy ode dne, kdy se s ní seznámil či měl prokazatelnou možnost se s nimi seznámit. Rozsah Interních předpisů může být Objednatelem jednostranně rozšířen o další dokumenty stanovující jeho interní procesy.

4. POVINNOSTI DODAVATELE

4.1. Dodavatel se zavazuje provádět pro Objednatele Plnění osobně, tj. prostřednictvím svých zaměstnanců, členů Realizačního týmu a prostřednictvím svých Poddodavatelů za podmínek stanovených ve Smlouvě a těchto ZOP. V případě, že je požadavek na složení Realizačního týmu uveden ve Smlouvě, je Dodavatel povinen provádět Plnění výhradně prostřednictvím členů Realizačního týmu, kterými prokázal splnění kvalifikace v průběhu zadávacího řízení na Veřejnou zakázku.

4.2. Dodavatel se během poskytování Plnění pro Objednatele zavazuje informovat Objednatele o Významné změně ovlivnění nebo ovládání Dodavatele podle ust. § 71 a násl. zákona č. 90/2012 Sb., o obchodních korporacích, ve znění pozdějších předpisů (dále jen „ZOK“), nebo změně vlastnictví zásadních aktiv, využívaných Dodavatelem k plnění Smlouvy a změně oprávnění nakládat s těmito aktivy.

4.3. Dodavatel se zavazuje poskytovat v rámci Plnění veškerou součinnost nezbytnou k provádění Plnění, zejména, nikoliv však výlučně:

a. poskytovat Plnění dle Smlouvy ve vysoké kvalitě s odbornou péčí odpovídající podmínkám sjednaným ve Smlouvě;

b. poskytovat Plnění dle Smlouvy alespoň v závazných parametrech kvality dle Smlouvy a SLA, a to zejména dodržování stanoveného servisního modelu dle článku 12.2. ZOP;

c. upozorňovat Objednatele včas na všechny hrozící vady svého Plnění či potenciální Výpadky či jiné výpadky Plnění, jakož i poskytovat Objednateli veškeré informace, které jsou pro Plnění potřebné;

d. zajistit v souladu s podmínkami Smlouvy poskytnutí Dokumentace, a to rovněž vždy při každé Aktualizaci nebo jiné změně Předmětu smlouvy, nestanoví-li Objednatel jinak;

e. počínat si při provedení Plnění tak, aby nedošlo k infikaci Software, Standardního software nebo IT prostředí Objednatele virem či jiným škodlivým kódem (malware apod.) způsobujícím narušení zabezpečení Software a Standardního software za účelem jeho poškození či jiného narušení běhu;

f. bez zbytečného odkladu oznamovat Objednateli všechny Kybernetické bezpečnostní události a Kybernetické bezpečnostní incidenty s potenciálním negativním dopadem na Objednatele;

g. bez zbytečného odkladu na výzvu Objednatele předat Data, provozní údaje a informace ve formátu předem odsouhlaseném Objednatelem (zpravidla ve formátu daného prostředí, který umožňuje jejich nasazení „as is“ do prostředí), které má k dispozici v souvislosti s plněním Smlouvy a poskytnout Objednateli za tímto účelem veškerou nezbytnou součinnost; tato Data musí být po dobu poskytování Plnění dle Smlouvy uložena u Dodavatele a mohou být Dodavatelem užívána v souladu se Smlouvou a příslušnými právními předpisy, avšak pouze v nezbytném rozsahu. Dodavatel se zavazuje dodržovat přiměřená technická a organizační opatření k ochraně těchto Dat. Veškerá Data jsou vlastnictvím Objednatele, není-li ve Smlouvě výslovně stanoveno jinak. Toto ustanovení se uplatní obdobně i na jiná data poskytnutá Objednatelem Dodavateli.

h. plnit Interní předpisy Objednatele a jeho pokyny v oblasti likvidace Dat (ať už Dat na papírových médiích, Dat zpracovávaných elektronicky nebo prostřednictvím jakýchkoli dalších nosičů Dat) a případně dále na výzvu Objednatele bez zbytečného odkladu zlikvidovat Data v souladu s těmito pravidly a pokyny.

5. POVINNOSTI OBJEDNATELE

5.1. Objednatel je povinen zajistit Testovací a Produkční prostředí pro činnost Dodavatele v rámci IT prostředí Objednatele, pokud je to nezbytné pro provádění Plnění. Zajištění prostředí zahrnuje zajištění vzdáleného přístupu personálu Dodavatele do IT prostředí Objednatele, v přiměřeném rozsahu odpovídajícího možnostem Objednatele a Zadávací dokumentaci a při respektování bezpečnostních pravidel Objednatele, zejména bezpečnostní dokumentace, která je součástí Interních předpisů. Objednatel je povinen zajistit fungování Dodavatelem vytvořeného Testovacího prostředí, na kterém bude Software Testován, a Produkčního prostředí, na kterém Software poběží v ostrém provozu, přičemž všechna prostředí budou umístěna na IT prostředí Objednatele, není-li ve Smlouvě stanoveno jinak.

6. LICENČNÍ UJEDNÁNÍ

6.1. Software

6.1.1. V případě, že je Software Autorské dílo vznikající v průběhu Plnění, Dodavatel postupuje na Objednatele oprávnění k výkonu majetkových práv autorských k takovému Autorskému dílu (ve formě strojového i Zdrojového kódu) tak, aby Objednatel byl oprávněn takové Autorské dílo užít v maximálním možném rozsahu včetně oprávnění k provádění změn a předání novému dodavateli.

6.1.2. Dodavatel prohlašuje, že Autorské dílo dle článku 6.1.1. ZOP bylo vytvořeno zaměstnanci či Poddodavateli jako zaměstnanecké dílo ve smyslu § 58 odst. 1 a 7 Autorského zákona, a že je oprávněn k postoupení výkonu majetkových práv v souladu s tímto článkem a má k takovému postoupení náležité souhlasy, přičemž Dodavatel se zavazuje na požádání Objednatele neprodleně předložit nebo jinak vhodným způsobem zpřístupnit dokumenty prokazující rozsah oprávnění Dodavatele.

6.1.3. Objednatel je dále oprávněn postoupit oprávnění k výkonu majetkových práv na jakoukoli další třetí osobu dle volby Objednatele a udělovat licence a podlicence, s čímž Dodavatel výslovně souhlasí; pro zamezení pochybnostem je Dodavatel povinen podniknout veškeré kroky k získání náležitých oprávnění tak, aby mohl oprávnění k výkonu majetkového práva postoupit na Objednatele v souladu s tímto článkem. S povinností převodu oprávnění k výkonu majetkových práv se pojí povinnost předání Zdrojového kódu dle čl. 7 ZOP.

6.1.4. Dodavatel dále prohlašuje, že má svolení autora/ů k zásahům do Autorského díla dle článku 6.1.1. ZOP ve smyslu § 58 odst. 4 Autorského zákona a tato svolení se vztahují na jakékoliv třetí osoby, jež budou vykonávat autorská majetková práva k tomuto Autorskému dílu.

6.1.5. Dodavatel dále prohlašuje, že vyloučil oprávnění autorů dle ustanovení § 58 odst. 3 Autorského zákona i vůči všem budoucím vykonavatelům autorských majetkových práv k Autorskému dílu dle článku 6.1.1. ZOP.

6.1.6. Dodavatel dále převádí veškerá zvláštní práva pořizovatele k Databázím pořízeným v průběhu provádění Plnění. Nedojde-li z jakéhokoliv důvodu k převodu práva dle předchozí věty, uděluje Dodavatel Objednateli oprávnění k vytěžování a zužitkování celého obsahu takové Databáze nebo její kvalitativně nebo kvantitativně podstatné části a právo udělit jinému oprávnění k výkonu tohoto práva.

6.1.7. K ostatním majetkovým hodnotám, které spadají pod pojem Software a zároveň nespadají pod definici Autorského díla, uděluje Dodavatel Objednateli oprávnění v rozsahu dle článku 6.1.8. ZOP. Ustanovení článku 6.2. ZOP tímto nejsou dotčena.

6.1.8. Nevznikne-li Objednateli z jakéhokoliv důvodu ke kterékoliv části Software oprávnění k výkonu autorských majetkových práv, uděluje Dodavatel Objednateli k dotčené části množstevně a územně neomezenou výhradní licenci ke všem známým způsobům užití, a to na dobu trvání autorských majetkových práv. Objednatel je oprávněn k dotčené části Software udělovat licence, tyto dále postoupit a udělovat podlicence třetím osobám. Objednatel je oprávněn dotčené části upravovat, zpracovávat, spojovat s jinými díly a jinak zasahovat do osobnostních autorských práv. Dodavatel odpovídá za zajištění těchto souhlasů.

6.1.9. Dodavatel není oprávněn pro účely vývoje Software použít software licencovaný pod FOSS licencemi, jejichž podmínky by stanovovaly Objednateli povinnost sdělovat nebo jinak šířit Software nebo jeho části včetně Zdrojových kódů třetím osobám, nebo umožnit jim změny, úpravy či jiné zásahy do Software nebo jeho části.

6.1.10. Dodavatel se zavazuje nahradit veškerou Újmu, která vznikne Objednateli v důsledku nesplnění jakýchkoliv povinností dle článku 6.1. ZOP. V případě, že jakákoliv třetí osoba bude uplatňovat vůči Objednateli jakékoliv nároky spojené se Softwarem nebo jeho částí v důsledku domnělého porušení svých autorských práv, zavazuje se Dodavatel hradit nároky, které Objednatel účelně vynaložil na ochranu zájmů Objednatele v této věci (včetně právního zastoupení), a to až do právního vyřešení nároků třetích osob; tímto není dotčena povinnost dle první věty tohoto bodu.

6.2. Standardní Software

6.1.1. V případech, kdy je součástí Předmětu Smlouvy dodání Standardního Software, Dodavatel poskytuje nevýhradní licenci, čímž se rozumí nevýhradní nevýlučné oprávnění Autorské dílo užít v souladu s dalšími podmínkami článku 6.2. ZOP, přičemž nevýhradní licence je poskytována Objednateli dále za následujících podmínek, není-li ve Smlouvě či v Příloze Smlouvy Specifikace Plnění stanoveno výslovně jinak:

a. Nevýhradní oprávnění k výkonu práva užít (licenci, resp. podlicenci) Autorské dílo včetně práva užít další Autorská díla a vytěžovat a zužitkovat Databáze, jež jsou určeny ke společnému užívání se Standardním Software a za tímto

účelem jsou společně distribuovány, a to všemi způsoby odpovídajícími účelu, pro který jsou taková Autorská díla, resp. Databáze, určeny, a to na dobu trvání majetkových práv autorských, nebo alespoň na dobu trvání Smlouvy.

b. Dodavatel je povinen zajistit poskytnutí podpory (subscription/license maintenance) Standardního software, tj. zajistit poskytování nejnovějších verzí Standardního software získaných z důvěryhodných zdrojů Objednateli a dalších služeb v souladu se standardními licenčními podmínkami Standardního Software, na dobu trvání majetkových práv autorských, pokud je to možné, jinak alespoň na dobu trvání Smlouvy.

c. Dodavatel je povinen poskytnout Objednateli o zajištění oprávnění ke Standardnímu software písemné prohlášení a na výzvu Objednatele tuto skutečnost prokázat.

d. Oprávnění musí vždy umožňovat Objednateli používání Standardního software pro interní potřeby Objednatele a jemu podřízených složek, organizací, částí nebo s ním propojených právnických osob.

6.1.2. Licence se vztahuje ve stejné míře jako k Standardnímu Software na:

a. Aktualizaci, Modernizaci a Zásadní modernizaci;

b. Dokumentaci specifikovanou v Příloze Smlouvy Specifikace Plnění;

c. Dokumentaci nad rámec Dokumentace dle předchozího bodu;

d. právo zužitkovat a vytěžovat Databáze, pokud jde o jiné Databáze než dle Smlouvy; a pokud tyto souvisí a jsou vhodné či nezbytné k naplnění účelu a předmětu Smlouvy

e. loga či jiné předměty duševního vlastnictví, které se Standardním Software souvisí a jsou vhodné či nezbytné k užití spolu se Standardním Software.

6.1.3. Je-li Standardní Software nebo Dokumentace vytvářena, upravována anebo jinak modifikována pro potřeby Objednatele, je Objednateli v takovém případě udělována licence k takto pro Objednatele vytvořeným či modifikovaným částem Standardního Software nebo Dokumentace, včetně práva dané části jakkoliv měnit, udělit podlicenci nebo licenci zcela či z části postoupit a použít takové části Standardního software či Dokumentace k jakémukoliv účelu, v jakémkoliv množství, na jakémkoliv území, jakýmkoliv způsobem a na dobu trvání majetkových práv autorských, a to vše i prostřednictvím třetí osoby.

6.1.4. Pokud se jedná o Standardní Software a Dodavatel není oprávněn udělit alespoň nevýhradní licenci, pak se Dodavatel zavazuje udělit či zajistit udělení nevýhradního oprávnění k výkonu práva užít (licenci, resp. podlicenci) veškerá Autorská díla a k výkonu práva vytěžovat a zužitkovat Databáze, a to všemi způsoby odpovídajícími účelu, pro který je takové Autorské dílo, resp. Databáze, určeno, a to alespoň na dobu trvání Smlouvy. Dodavatel je povinen zajistit poskytnutí podpory Standardního Software dle tohoto článku, tj. zajistit poskytování nejnovějších verzí Standardního Software Objednateli získaných z důvěryhodných zdrojů a dalších služeb v souladu s jeho standardními licenčními podmínkami, na dobu trvání Smlouvy. Dodavatel je povinen poskytnout Objednateli písemné prohlášení o zajištění oprávnění ke Standardnímu Software a na výzvu Objednatele tuto skutečnost prokázat. Oprávnění dle tohoto článku musí vždy umožňovat Objednateli používání Standardního Software pro interní potřeby Objednatele a jemu podřízených složek, organizací, částí nebo s ním propojených právnických osob.

6.1.5. V ostatních parametrech se udělení licence řídí licenčními podmínkami výrobce Standardního Software.

6.1.6. Ustanovení čl. 6.1. ZOP a 6.3. ZOP a jeho podčlánků se pro Standardní Software nepoužijí.

6.3. Software vztahující se k Hardware

6.1.1. V případech, kdy je k řádnému užívání dodaného Hardware potřebný určitý Software, je Dodavatel povinen poskytnout/zajistit Objednateli jako součást plnění a za cenu zahrnutou v ceně Hardware, oprávnění užít tento Software v rozsahu, způsoby a za účelem obvyklým ve vztahu k Hardware, se kterým je spojen, nejméně však za podmínek dle Přílohy Smlouvy Specifikace Plnění.

6.1.2. Ustanovení čl. 6.1. ZOP a jeho podčlánků a 6.2. ZOP a jeho podčlánků se pro Software vztahující se k Hardware nepoužijí.

6.4. Odměna za poskytnutí oprávnění dle článku 6 ZOP je zahrnuta v Ceně za Plnění dle Smlouvy.

7. ZDROJOVÝ KÓD A DOKUMENTACE

7.1. Zdrojový kód bude předáván Objednateli na datovém nosiči vždy na konci Akceptačního řízení, nebo za podmínek stanovených ve Smlouvě, zejména pokud bude smluvní vztah ukončen bez provedení Akceptačního řízení.

7.2. Na datovém nosiči dat musí být viditelně označeno „Zdrojový kód“ s označením části Modifikace a jeho verze a den předání Zdrojového kódu. O předání nosiče dat bude oběma Smluvními stranami sepsán a podepsán písemný předávací protokol.

7.3. Povinnost Dodavatele předávat Zdrojový kód se přiměřeně použije i pro jakékoliv opravy, změny, doplnění, upgrade nebo update Zdrojového kódu v rámci následného provádění Plnění anebo v rámci záručních oprav. Zdrojový kód musí obsahovat podrobný popis a komentář každého zásahu do Zdrojového kódu.

7.4. Objednatel nebude v průběhu provádění Plnění sám anebo prostřednictvím jiných osob zasahovat do Zdrojového kódu nasazeného anebo fungujícího v Produkčním prostředí či Testovacím prostředí.

7.5. Dodavatel je povinen předat Objednateli příslušnou Dokumentaci a Zdrojový kód ve standardní podobě (to nejméně v kvalitě obvyklé pro open source projekty), vždy obsahující následující:

a. Kompletní Zdrojové kódy celého díla.

b. Uživatelskou příručku obsahující konkrétní popis uživatelského prostředí, funkcí a postupů pro zaškolení zaměstnanců.

c. Administrátorskou příručku, popisující všechny parametry, které lze konfigurovat a popis dopadů změny konfigurace do systému.

d. Technickou dokumentaci systému, pakliže se jedná o vícevrstvou architekturu, popis každé vrstvy zvlášť:

(i) Datová vrstva – popis datové vrstvy, čili tabulek v databázi včetně vazeb mezi tabulkami a včetně E-R schémat.

(ii) Aplikační vrstva – popis jádra systému, jeho funkcí, služeb a rozhraní. Dokumentace musí obsahovat kompletní popis architektury jádra systému, výčet a podrobný popis všech jeho funkcí, přehled a popis služeb, které jádro poskytuje dalším komponentám systému, modulům a knihovnám.

(iii) Prezentační vrstva – Dokumentace systému musí obsahovat drátové modely všech obrazovek uživatelského rozhraní včetně popisu funkcí prvků každé obrazovky.

e. Popis konfigurace provozního prostředí systému (serverová strana i klientská strana)

f. Dokumentace musí obsahovat soupis všech požadavků na nastavení hardwarových a softwarových komponent běhového prostředí jako jsou:

(i) mapování souborových systémů

(ii) požadavky na operační paměť a procesory

(iii) konfigurační parametry jednotlivých podpůrných Softwarových prostředků (např. specifika pro nastavení databáze, aplikačního serveru, webového serveru apod.)

g. Objednatel požaduje, aby tato Dokumentace byla ve formátech XML DocBook (zdrojové) a PDF (export z XML zdroje pro snadnou distribuci uživatelům) nebo případně v jiném formátu, který Objednatel schválí po vzájemné dohodě s Dodavatelem. Všechny Dokumentace musí být verzované, opatřené seznamem autorů, přehledem změn

h. jednotlivých verzí a musí být obsahově úplné pro tu část systému, kterou popisují. Řešení musí obsahovat návod na používání systému (uživatelský manuál) a popis systému – jeho vlastností, strukturu projektu, použité technologie (technická dokumentace). Součástí řešení je i Dokumentace a automaticky generovaná dokumentace (Javadoc). Součástí Dokumentace musí být zip archiv se zdrojovými soubory řešení a programátorskou dokumentací.

7.6. V případě jakýchkoli pochybností o správnosti předání Zdrojového kódu se bude uvedené posuzovat podle svého účelu, tedy zejména následné možnosti provádět samostatně či prostřednictvím třetích osob opravy, změny, doplnění, upgrady nebo updaty Zdrojového kódu. Za nesprávné předání se přitom považuje takové předání, které v důsledku vede ke znemožnění či podstatnému ztížení práce se Zdrojovým kódem ve výše uvedeném smyslu.

8. AKCEPTAČNÍ ŘÍZENÍ

8.1. Předání a převzetí Předmětu Smlouvy, včetně předání a převzetí výstupů provádění Plnění, dokumentů majících charakter výstupů Předmětu Plnění a Zdrojových kódů, probíhá na základě Akceptačního řízení, tj. postupným provedením akceptačních procesů a podepsáním Akceptačního/ch protokolu/ů.

8.2. Akceptační řízení zahrnuje porovnání skutečných vlastností Provádění Plnění se specifikací Plnění dle Smlouvy a Akceptačními kritérii. Podrobnější rozsah Akceptačních kritérií je součástí Přílohy Smlouvy Specifikace Plnění.

8.3. Plnění dle Smlouvy a jakékoliv jeho části, které podléhají Akceptačnímu řízení, jsou provedeny skončením Akceptačního řízení dotčené části Plnění, v případě Plnění jako celku skončením Akceptačního řízení Plnění jako celku.

8.4. Na Akceptační řízení se uplatní následující pravidla:

a. Dodavatel je povinen písemně informovat Objednatele nejméně čtrnáct (14) dní předem o termínu předání výstupu k Akceptačnímu řízení nedohodnou-li se Strany jinak;

b. Dodavatel předá Objednateli výstup provádění Plnění k realizaci Akceptačního řízení; Akceptační řízení může být zahájeno pouze v případě, že výstup provádění Plnění, který je předmětem takového Akceptačního řízení, je umístěn v Produkčním anebo Testovacím prostředí nebo byl jiným způsobem Dodavatelem skutečně předán Objednateli a ten se s ním mohl seznámit; Objednatel na žádost Dodavatele potvrdí převzetí výstupů k Akceptačnímu řízení v Helpdesku, e-mailem, anebo prostřednictvím ISDS; převzetím k Akceptačnímu řízení anebo potvrzením ve smyslu tohoto článku je zahájeno Akceptační řízení;

c. po provedení všech nezbytných činností v rámci Akceptačního řízení se Objednatel i Dodavatel zavazují podepsat příslušný protokol potvrzující provedení výstupu provádění Plnění anebo výsledek Testů výstupů provádění Plnění připravený Dodavatelem a upravený a vyplněný Objednatelem (Akceptační protokol). Akceptační protokol obsahuje:

(i) specifikaci provedeného Plnění;

(ii) Akceptační kritéria;

(iii) informace o průběhu Testů, jsou-li prováděny;

(iv) další informace a dokumenty nezbytné pro provedení Akceptačního řízení provedeného Plnění nebo jeho části.

d. v případě nutnosti opakování činností v rámci Akceptačního řízení v důsledku uvedení výroku „Neakceptováno“ v Akceptačním protokolu Dodavatel Objednateli opět předá výstup k opětovnému provedení činností v rámci Akceptačního řízení (další kolo Akceptačního řízení) a Dodavatel připraví nový Akceptační protokol vztahující se k dalšímu kolu Akceptačního řízení;

e. je-li součástí Plnění několik výstupů, pak každý z takových výstupů podléhá samostatnému Akceptačnímu řízení;

f. Akceptační řízení konkrétního výstupu končí a výstup se považuje za provedený podpisem Akceptačního protokolu Objednatelem s uvedeným výrokem „Akceptováno“ nebo odstraněním vytčených vad výstupu v případě vyznačení „Akceptováno s výhradou“ a potvrzením odstranění takových vytčených vad Objednatelem na Akceptačním protokolu, který obsahoval vytčené vady.

8.5. Objednatel je povinen po provedení ověření kvality výstupu v rámci Akceptačního řízení Dodavateli podepsat Akceptační protokol a akceptovat výstup provádění Plnění, případně oznámit Dodavateli vady výstupu provádění Plnění, které brání jeho provedení včetně určení kategorie vady A, B, C.

8.6. Výstupy provádění Plnění jsou způsobilé k akceptaci Objednatelem, pokud:

a. naplňují Akceptační kritéria a nevykazují žádné vady, pak Objednatel vyznačí na Akceptačním protokolu „Akceptováno“; nebo

b. naplňují Akceptační kritéria a vykazují vady, které nebrání tomu, aby výstup provádění Plnění sloužil svému účelu bez významnějších omezení pro Objednatele (zejména organizačních, časových, nákladových apod.), anebo v případě Software při Testech či provozu v souhrnu nevykazují více vad, než připouští Akceptační kritéria, pak Objednatel vyznačí na Akceptačním protokolu „Akceptováno s výhradou“.

V jiných případech vyznačí Objednatel na Akceptačním protokolu „Neakceptováno“.

8.7. V případě splnění Akceptačních kritérií je Objednatel povinen do 30 dnů od zahájení akceptačního řízení vyznačit na Akceptačním protokolu výrok „Akceptováno“. V případě nesplnění Akceptačních kritérií Objednatel vyznačí do 30 dnů od zahájení akceptačního řízení na Akceptačním protokolu výrok „Neakceptováno“ a uvede všechna Akceptační kritéria, která považuje za nesplněná s uvedením, v čem spočívá jejich nesplnění. Objednatel není povinen výše uvedené lhůty dodržet, dojde-li k prodloužení akceptačního řízení z důvodu na straně Dodavatele.

8.8. Pokud Objednatel akceptuje výstup provádění Plnění svým podpisem a vyznačením výroku

„Akceptováno s výhradou“, které na Akceptačním protokolu uvede společně s uvedením vad, které nebrání akceptaci, zavazuje se Dodavatel k odstranění těchto vad ve lhůtách výslovně stanovených v Akceptačním protokolu, a pokud nejsou takové, pak lhůtách přiměřených stanovených Objednatelem v rámci odstraňování vad vyznačených v Akceptačním protokolu s výrokem „Akceptováno s výhradou“ postupují Strany dle předchozích ustanovení tohoto článku až do odstranění všech vad vyznačených v Akceptačním protokolu s výrokem

„Akceptováno s výhradou“.

8.9. V případě neschválení výstupu provádění Plnění vyznačením na Akceptačním protokolu

„Neakceptováno“ odstraní Dodavatel vady uvedené v Akceptačním protokolu ve lhůtách výslovně stanovených v Akceptačním protokolu Objednatelem, a pokud nejsou takové, pak lhůtách přiměřených. Do odstranění vad bránících akceptování je výstup provádění Plnění považován za neakceptovaný (neprovedený). Po odstranění vad uvedených v Akceptačním protokolu Dodavatel předá znovu výstup provádění Plnění Objednateli k dalšímu kolu Akceptačního řízení a Objednatel postupuje obdobně podle předchozích ustanovení tohoto článku a specifickými podmínkami Akceptačního řízení uvedenými v tomto článku.

8.10. Akceptační řízení se užije i na akceptaci a schválení výkazů či reportů, je-li jejich pravidelné zasílání Objednateli součástí Plnění.

Akceptační řízení však bude v takovém případě probíhat pouze následovně:

a. výkaz a report, včetně všech jeho součástí, se považuje za akceptovaný doručením Dodavateli sdělení Objednatele, že Objednatel jej považuje za úplný a správný, a souhlasí s vystavenou fakturou; nebo

b. marným uplynutím lhůty pro posouzení úplnosti a správnosti faktury, která se týká stejného období jako výkaz a report, bez vznesení připomínek ze strany Objednatele.

9. ŠKOLENÍ

9.1. Dodavatel provede zaškolení příslušných zaměstnanců Objednatele pro Software nebo Hardware v termínu dle Smlouvy, a pokud takový termín není, pak v termínu určeném Objednatelem po dohodě s Dodavatelem.

9.2. Součástí školení je i poskytnutí Dokumentace pro provedení školení a komplexní administraci Software nebo užívání Hardware tak, aby na základě Dokumentace byli účastníci školení absolvující školení schopni samostatně (bez zásahů Dodavatele) ovládat Software nebo Hardware.

9.3. Účelem provedení školení je seznámení účastníků školení se Softwarem nebo Zařízením do té míry, aby jej byli schopni samostatně užívat v souladu se svým pracovním zařazením u Objednatele.

9.4. Požadavek na školení bude stanoven ve Smlouvě. Pokud Smlouva či její Příloha obsahuje požadavek na provedení školení, provede Dodavatel seznámení zaměstnanců Objednatele s Předmětem smlouvy za podmínek, jež jsou uvedeny v tomto článku.

9.5. Dodavatel je dále povinen provést v přiměřeném rozsahu školení příslušných zaměstnanců Dodavatele a dalších osob podílejících se na poskytování Plnění dle Smlouvy za účelem splnění povinností dle čl. 20. ZOP. Tuto skutečnost je povinen na vyžádání Objednateli prokázat.

10. HELPDESK

10.1. Dodavatel se zavazuje:

10.1.1. nejpozději do dne účinnosti Smlouvy založit a po celou dobu trvání Smlouvy udržovat v provozu Helpdesk (včetně úhrady případných licenčních poplatků za aplikaci Helpdesk) a udělit náležitá oprávnění k přístupu do Helpdesku Ohlašovatelům a dalším pověřeným uživatelům dle pokynů Objednatele, včetně Objednatelem určeného počtu přístupů. Helpdesk bude fungovat prostřednictvím webové adresy, elektronické pošty nebo telefonního čísla;

nebo

10.1.2. po celou dobu trvání Smlouvy užívat Helpdesk provozovaný Objednatelem.

10.2. Provozovatele Helpdesk stanoví Smlouva. Pokud Smlouva provozovatele Helpdesk nestanoví, má se za to, že provozovatelem Helpdesk je Dodavatel. V případě, že provozovatelem bude Objednatel, poskytne Dodavateli nezbytnou součinnost k řádnému užívání Helpdesk včetně případného poskytnutí licencí.

10.3. Dodavatel se zavazuje zajistit Helpdesk v jednom z následujících režimů, který je vymezen ve Smlouvě:

a. Režim 1:

7x24, tj. dvacet čtyři (24) hodin sedm (7) dní v týdnu prostřednictvím přímého přístupu do Helpdesku na webové adrese určené Dodavatelem/Objednatelem dle provozních podmínek aplikace Helpdesk, případně prostřednictvím přímého datového propojení Helpdesků Objednatele a Dodavatele.

b. Režim 2:

7x24, tj. dvacet čtyři (24) hodin sedm (7) dní v týdnu prostřednictvím elektronické pošty na adrese určené Dodavatelem.

c. Režim 3:

5×8, tj. v pracovních dnech v době od 9:00 do 17:00 na telefonním čísle určeném Dodavatelem.

10.4. Helpdesk v režimu 1 dle článku 10.3. ZOP zahrnuje mimo jiné příjem a evidenci Požadavků, oznámení o potřebě součinnosti Objednatele a dalších zpráv, potvrzování jejich přijetí, předávání jednotlivých úkolů odpovědným osobám, sledování stavu, průběhu a procesu prací a dalších zpráv, informování o stavu řešení, vytváření přehledů a statistik, a to přes přehledné webové rozhraní. Je-li Helpdesk provozován Dodavatelem musí být zabezpečen tak, aby odpovídal požadavkům vyplývajících ze ZKB a Interních předpisů. Výstupem ze Helpdesku je záznam o veškerých úkonech Helpdesku ve formě přehledného logu, jež umožňuje vyhledávání a uchovávání záznamů tak, aby byly naplněny požadavky ZKB a Interních předpisů na takové záznamy.

10.5. Helpdesk bude dostupný pouze pro Objednatele a Ohlašovatele.

10.6. Helpdesk je provozován v některé z těchto úrovní podpory, která je vymezena ve Smlouvě:

a. první úroveň (L1) – nahlášení Incidentu Ohlašovatelem je prováděno nahlášením Objednateli či pověřené osobě Objednatele, který Incident vyhodnotí a případně předá incident jako Incident Dodavateli do druhé úrovně podpory;

b. druhá úroveň (L2) – nahlášení Incidentu Ohlašovatelem Dodavateli v případě, že Incident nebyl vyřešen v první úrovni podpory – je prováděno nahlášením Ohlašovatelem přes Helpdesk Dodavateli;

c. třetí úroveň (L3) – nahlášení Incidentu eskalační úrovni podpory Dodavatele nebo nahlášení Dodavatelem třetí osobě, která je oprávněna anebo schopna vyřešit Incident, pokud nebyl vyřešen v druhé úrovni podpory – je prováděno nahlášením Ohlašovatelem přes Helpdesk eskalační úrovni Dodavatele anebo Dodavatelem třetí osobě.

10.7. Ohlašovatelem s přístupem do Helpdesk je

a. pro úroveň L1 Helpdesk uživatele Software nebo Hardware;

b. pro úroveň L2 Helpdesk osoby určených Objednatelem dle jeho potřeb zajišťující úroveň L1 podpory;

c. pro úroveň L3 Helpdesk člen Realizačního týmu určeného Dodavatelem dle jeho potřeby zajišťující úroveň L2 podpory.

11. NAHLÁŠENÍ INCIDENTU

11.1. Hlášení o Incidentu Dodavateli bude provedeno Ohlašovatelem, a to přímým zadáním Incidentu do Helpdesk, odesláním emailu nebo telefonátem na kontaktní číslo Helpdesk, přičemž Ohlašovatel je povinen uvést popis Incidentu, a to v následujícím rozsahu:

a. krátký a rámcově výstižný název Incidentu;

b. identifikace části Předmětu Plnění, které se Incident týká;

c. určení prostředí (Testovací prostředí, Produkční prostředí);

d. detailní popis Incidentu, průvodních jevů a všech významných souvisejících informací;

e. kategorii Incidentu (A, B, C);

f. identifikaci Ohlašovatele.

11.2. V případě, že některá z náležitosti dle čl. 11.1. ZOP chybí nebo je nedostatečná, může si Dodavatel vyžádat její doplnění od Ohlašovatele; tato skutečnost však nemá vliv na určení Času nahlášení Incidentu, ledaže bez tohoto doplnění hlášení Incidentu postrádá informaci natolik podstatnou, že bez ní objektivně nelze přistoupit k řešení Incidentu.

11.3. Je-li Incident nahlašován zadáním Incidentu do Helpdesku, pak se za Čas nahlášení Incidentu považuje čas vytvoření ticketu v Helpdesku. Je-li Incident nahlašován písemně na e-mailovou adresu, pak se za Čas nahlášení Incidentu považuje čas odeslání e-mailu z e-mailového serveru Ohlašovatele, nebo v případě hlášení Incidentu telefonicky čas ukončení telefonického hovoru. Dodavatel je povinen prokazatelným způsobem bezodkladně potvrdit přijetí nahlášení Incidentu, a to vždy prostřednictvím Helpdesk. Nepotvrdí-li Dodavatel přijetí Incidentu, nemá to vliv na Čas nahlášení Incidentu.

11.4. Dodavatel se zavazuje po dobu poskytování Plnění evidovat všechny nahlášené Incidenty a způsob jejich řešení, včetně časových údajů o průběhu řešení jednotlivých Incidentů ve Výkazech.

11.5. Není-li v Servisní smlouvě, jejích přílohách anebo Technické specifikaci stanoveno jinak, ustanovení článku 11. ZOP se použijí přiměřeně i na nahlášení a evidování Požadavků; v takovém případě se za Čas nahlášení Incidentu považuje Čas nahlášení Požadavku.

12. SERVISNÍ MODELY

12.1. Servisní model představuje standardizovaný model provozu a podpory aplikace, systému nebo instance služby.

12.2. Pokud je součástí Smlouvy zajištění provozu a podpory Software nebo Hardware, je ve smlouvě vymezen jeden z níže uvedených servisních modelů:

Servisní model	Dostupno st	Doba provozu		Doba zpracová ní Incidentu	Doba řešení Incident kategori e A	Doba řešení Incident kategori e B	RT O	RP O	Doba zpracová ní Požadavk u	Doba řešení Požadavk u kategorie A	Doba řešení Požada vku katego rie B
A1		7x2	(0-				4	< 5
Kritický	99.5%	4	24)	1 hod	2 hod	2 hod	hod	min	1 PD	1 PD	3 PD
A2		7x1	(6-				4	< 5
Kritický	99.5%	2	18)	1 hod	2 hod	2 hod	hod	min	1 PD	1 PD	3 PD
A3			(7-				4	< 5
Kritický	99.5%	5x8	15)	1 hod	2 hod	2 hod	hod	min	1 PD	1 PD	3 PD
A4		7x2	(0-				4	< 5
Kritický	99.5%	4	24)	1 hod	4 hod	12 hod	hod	min	1 PD	2 PD	5 PD
A5			(7-				4	< 5
Kritický	99.5%	5x8	15)	1 hod	4 hod	12 hod	hod	min	1 PD	2 PD	5 PD

(0

B1

7x2

-

48

30

Závažný

98.0%

4

24)

1 PD

2 PD

3 PD

hod

min

2 PD

3 PD

5 PD

B2

7x1

(6-

48

30

Závažný

98.0%

2

18)

1 PD

2 PD

3 PD

hod

min

2 PD

3 PD

5 PD

B3

(7-

48

30

Závažný

98.0%

5x8

15)

1 PD

2 PD

3 PD

hod

min

2 PD

3 PD

5 PD

C1

5x1

(6-

96

24

Normální

97.0%

2

18)

1 PD

3 PD

6 PD

hod

hod

3 PD

7 PD

10 PD

C2

(7-

96

24

Normální

97.0%

5x8

15)

1 PD

3 PD

6 PD

hod

hod

3 PD

7 PD

10 PD

D

(7-

96

24

Minoritní

94.0%

5x8

15)

2 PD

10 PD

14 PD

hod

hod

5 PD

10 PD

14 PD

12.3. Doba řešení incidentu a Požadavku kategorie C je pro veškeré servisní modely stanovena na 15 PD.

12.4. Do měření úrovně Dostupnosti nejsou započítávány:

a. dočasné vyřazení Software z provozu na základě předchozí dohody Objednatele a Dodavatele (odstávka),

b. pravidelná vyřazení Software z provozu Dodavatelem v časech sjednaných ve Smlouvě nebo její příloze (servisní okna),

c. smluvními stranami předem dohodnutý časový úsek za účelem instalace upgrade,

d. výpadky Software způsobené Objednatelem přímo v důsledku jím provedených zásahů do Software, které nebyly Dodavatelem předem schváleny,

12.5. Nedostupnost Software dle článku 12.3. ZOP se nepovažuje za nedosažení sjednaných parametrů dostupnosti dle Smlouvy a nebude započítána do výpočtu dle článku 12.6. a 12.7. ZOP.

12.6. Nestanoví-li Smlouva jinak, bude Dostupnost Software měřena na základě následujícího vzorce:

𝐷𝑜𝑠𝑡𝑢𝑝𝑛𝑜𝑠𝑡 (%) = 𝐷𝑜𝑏𝑎 𝑝𝑟𝑜𝑣𝑜𝑧𝑢 − 𝐷𝑜𝑏𝑎 𝑣ý𝑝𝑎𝑑𝑘𝑢 × 100

𝐷𝑜𝑏𝑎 𝑝𝑟𝑜𝑣𝑜𝑧𝑢

12.7. Doba výpadku Software je časový úsek z Doby provozu v hodinách, kdy je služba nedostupná, a počítá se podle následujícího vzorce:

kde:

𝑛

𝐷𝑜𝑏𝑎 𝑣ý𝑝𝑎𝑑𝑘𝑢 = ∑ 𝑇𝑖

𝑖

∑ je celková doba všech výpadků Software za vyhodnocované období Ti je doba jednotlivého výpadku Software

12.8. Doba Provozu Software definovaná pro účely tohoto článku je celková doba provozu Software v hodinách za vyhodnocované období, kterým je kalendářní měsíc.

13. ÚČAST PODDODAVATELŮ

13.1. Poddodavatele, jejichž prostřednictvím Dodavatel prokazoval kvalifikaci ve Veřejné zakázce, je Dodavatel povinen využívat při plnění Smlouvy po celou dobu jejího trvání v rozsahu, v jakém jimi prokazoval kvalifikaci. Poddodavatele, jimiž Dodavatel prokazoval kvalifikaci ve Veřejné zakázce, lze vyměnit pouze s předchozím listinným souhlasem Objednatele, který může být dán výlučně za předpokladu, že tyto osoby budou nahrazeny osobami splňujícími kvalifikaci požadovanou ve Veřejné zakázce ve stejném rozsahu jako nahrazované osoby.

13.2. Dodavatel se zavazuje, že při poskytování plnění pro Objednatele budou všichni Poddodavatelé, které Dodavatel využívá k poskytnutí plnění dle Smlouvy, dodržovat veškeré požadavky vyplývající ze Smlouvy a Příloh Smlouvy. Dodavatel odpovídá za to, že jeho Poddodavatelé nebudou jednat v rozporu s ujednáními Smlouvy a jejími Přílohami, kterou mezi sebou uzavřel Dodavatel a Objednatel.

13.3. Významný dodavatel je oprávněn využít k Plnění dle Smlouvy Poddodavatele neuvedené ve Smlouvě jen v případě, že to Smlouva výslovně připouští, a to za podmínek v ní uvedených. Nestanoví-li Smlouva jinak, podléhají jednotliví Poddodavatelé Významného dodavatele předchozímu písemnému schválení ze strany Objednatele. Dodavatel může ke schválení navrhnout nebo do Plnění Smlouvy zapojit pouze takové Poddodavatele, kteří nejsou v rozporu s požadavky Objednatele na Významného dodavatele.

14. REALIZAČNÍ TÝM

14.1. Pokud je takový požadavek součástí Zadávací dokumentace, je Dodavatel povinen předat Objednateli seznam osob, které budou členy Realizačního týmu, který se bude podílet na Plnění dle Smlouvy. Členy Realizačního týmu lze měnit pouze s předchozím listinným souhlasem Objednatele, který může být dán výlučně za předpokladu, že tyto osoby budou nahrazeny osobami splňujícími kvalifikaci požadovanou ve Veřejné zakázce ve stejném rozsahu jako nahrazované osoby. Při změně Realizačního týmu není nutné uzavírat listinný dodatek ke Smlouvě a Dodavatel je povinen vypracovat a předat Objednateli v listinné podobě aktualizované znění seznamu členů Realizačního týmu. Tento článek se týká pouze Veřejných zakázek, které požadují provádění Plnění prostřednictvím Realizačního týmu.

14.2. Dodavatel se zavazuje provádět Plnění prostřednictvím členů Realizačního týmu uvedených v Příloze Smlouvy Realizační tým tak, aby jednotliví členové Realizačního týmu, kteří jsou Kvalifikovanými osobami, prováděli činnosti na pozici dle jejich odbornosti (kvalifikace), které odpovídají tomu, pro jakou pozici prokazovali kvalifikaci v rámci Veřejné zakázky, a v rozsahu, který takové pozici běžně odpovídá.

14.3. Každá Kvalifikovaná osoba musí po celou dobu provádění Plnění splňovat kvalifikaci uvedenou v nabídce Dodavatele a zároveň minimální technické kvalifikační předpoklady kladené na pozici, kterou daná osob zastává dle Zadávací dokumentace.

14.4. Nebude-li se Kvalifikovaná osoba řádně podílet na provádění Plnění v rozsahu stanoveném Smlouvou, např. v důsledku ukončení její spolupráce s Dodavatelem nebo její dlouhodobé absence (zejména dlouhodobá nemoc pravděpodobně překračující délku jednoho měsíce), je Dodavatel povinen neprodleně namísto Kvalifikované osoby zahájit provádění Plnění Náhradní kvalifikovanou osobou a nejpozději do tří (3) pracovních dnů ode dne, kdy taková situace nastala, informovat Objednatele o této skutečnosti.

14.5. Pokud Objednatel nesouhlasí s osobou Náhradní kvalifikované osoby, je oprávněn žádat Dodavatele o její výměnu za jinou osobu se stejnou kvalifikací navrženou Dodavatelem, čemuž je Dodavatel povinen vyhovět.

15. KOMUNIKACE STRAN

15.1. Objednatel a Dodavatel si pro vzájemnou komunikaci ohledně Smlouvy zvolí kontaktní osoby, jejichž seznam uvedou ve Smlouvě.

15.2. Jsou-li naplněny podmínky článku 20.1. ZOP, vykonává kontaktní osoba na straně Dodavatele povinnosti kontaktní osoby pro kybernetickou bezpečnost vyplývající z článku 20. ZOP, nebo je pro plnění takových povinností Dodavatel povinen určit zvláštní kontaktní osobu ve Smlouvě (v takovém případě obě Strany zvolí kontaktní osobu pro kybernetickou bezpečnost, která má na starosti komunikaci týkající se článku 20. ZOP).

15.3. Strany si navzájem oznámí jakékoliv změny v kontaktních osobách, přičemž taková změna je účinná uplynutím sedmého (7.) dne po jejím doručení.

15.4. Není-li ve Smlouvě výslovně stanovena jiná forma pro doručování dokumentů anebo jiných právních jednání, lze takové dokumenty a jednání doručit v elektronické formě na emailovou adresu příslušné kontaktní osoby, prostřednictvím datové zprávy zaslané v rámci ISDS, anebo v listinné podobě.

16. SMLUVNÍ POKUTY

16.1. Poruší-li Dodavatel některou ze svých povinností stanovených v Příloze Smlouvy Specifikace Plnění, zejména pak pokud poruší SLA, resp. stanovený servisní model dle článku 12.2. ZOP, je Objednatel oprávněn požadovat zaplacení smluvní pokuty ve výši stanovené v článku 16.2.

ZOP, pokud nejsou ve Smlouvě výslovně zakotveny jiné sankce, které vylučují aplikaci článku

16.2. ZOP.

16.2. Objednateli vzniká vůči Dodavateli právo na zaplacení smluvní pokuty:

a. poruší-li Dodavatel svoji povinnost řádně a včas provést Plnění ve výši 0,01 % z celkové ceny Plnění (dále jen „Cena“) za každý započatý den prodlení až do řádného splnění této povinnosti;

b. poruší-li Dodavatel svoji povinnost řádně a včas provést jakoukoliv část Plnění ve výši 0,02 % z ceny takové části Plnění za každý započatý den prodlení až do řádného splnění této povinnosti; v případě, že by smluvní pokuty dle čl. 16.2. písm. a. a čl. 16.2. písm.

b. ZOP měly běžet vůči Dodavateli zároveň, vzniká za takové období Objednateli nárok pouze dle čl. 16.2. písm. a.

c. poruší-li Dodavatel povinnost udělit nebo zajistit Objednateli ze strany třetí osoby/třetích osob udělovaná oprávnění v rozsahu práv duševního vlastnictví ve výši 5

% z Ceny za každé jednotlivé porušení;

d. poruší-li Dodavatel povinnost řádně a včas předat Objednateli Zdrojový kód a veškerou související Dokumentaci, ve výši 0,05 % z Ceny za každý započatý den prodlení;

e. poruší-li Dodavatel některou z povinností týkající se účasti Poddodavatelů anebo Realizačního týmu, ve výši 2 % z Ceny za každé jednotlivé porušení povinnosti;

f. poruší-li Dodavatel svoji povinnost dodržet sjednanou Dobu vyřešení Incidentu, ve výši:

(i) ve výši 0,003 % z Ceny v případě každé započaté hodiny/den prodlení nad rámec sjednané Doby vyřešení v případě každého Incidentu kategorie A;

(ii) ve výši 0,003 % z Ceny v případě každé započaté hodiny/den prodlení nad rámec sjednané Doby vyřešení v případě každého Incidentu kategorie B;

(iii) ve výši 0,001 % z Ceny v případě každé započaté hodiny/den prodlení nad rámec sjednané Doby vyřešení v případě každého Incidentu kategorie C;

g. v případě prodlení nad rámec sjednané lhůty pro odstranění vad v Produkčním prostředí:

(i) Vada kategorie A ve výši 0,003 % z Ceny za každou započatou hodinu/den v případě každé Vady;

(ii) Vada kategorie B ve výši 0,003 % z Ceny za každou započatou hodinu/den v případě každé Vady;

(iii) Vada kategorie C ve výši 0,001 % z Ceny za každou započatou hodinu/den v případě každé Vady;

h. v případě prodlení nad rámec sjednané lhůty pro odstranění vad v Testovacím prostředí:

(i) Vada kategorie A ve výši 0,05 % z Ceny za každý započatý pracovní den v případě každé Vady; a

(ii) Vada kategorie B ve výši 0,01 % z Ceny za každý započatý pracovní den v případě každé Vady;

i. V případě, že Dodavatel nedodrží Dostupnost stanovenou servisním modelem dle článku 12. ZOP, ve výši dle tabulky uvedené níže v závislosti na míře nedodržení požadované Dostupnosti:

Výše poklesu Dostupnosti oproti stanovené Dostupnosti servisním modelem je	Výše smluvní pokuty
Do 2 %	3 % z ceny poskytovaného Plnění odpovídající vyhodnocovanému období dle čl. 12.8 ZOP
2 do 5 %	5 % z ceny poskytovaného Plnění odpovídající vyhodnocovanému období dle čl. 12.8 ZOP

5 do 10 %	8 % z ceny poskytovaného Plnění odpovídající vyhodnocovanému období dle čl. 12.8 ZOP
10 % a více	16 % z ceny poskytovaného Plnění odpovídající vyhodnocovanému období dle čl. 12.8 ZOP

j. v případě prodlení Dodavatele reagovat na Požadavek Objednatele v době řešení incidentu uvedené v článku 12.2. ZOP ve výši z 0,007 z % Ceny za každý jednotlivý případ;

k. ve výši a za podmínek dle článku 20 ZOP v oblasti kybernetické bezpečnosti;

l. ve výši a za podmínek dle článku 21 ZOP v oblasti ochrany osobních údajů;

m. ve výši a za podmínek dle článku 22 ZOP v oblasti ochrany důvěrných informací; nebo

n. poruší-li Dodavatel svoji povinnost dle čl. 13.2. ZOP nebo 13.3. ZOP, ve výši 2 % z Ceny za každé jednotlivé porušení.

16.3. Pro smluvní pokuty stanovené v čl. 16.2. písm. f. a g. ZOP platí, že je-li lhůta pro splnění stanovena v hodinách, je smluvní pokuta počítána za každou započatou hodinu, je-li lhůta pro splnění stanovena ve dnech či pracovních dnech, je smluvní pokuta počítána za každý započatý den.

16.4. Zaplacením smluvních pokut není dotčeno právo Objednatele na náhradu újmy v plném rozsahu.

16.5. Smluvní pokuta je splatná do 30 dnů ode dne doručení písemné výzvy Objednatele k jejímu uhrazení. Objednatel je oprávněn započíst nárok na zaplacení smluvní pokuty, i pokud ještě není splatný, proti jakémukoliv nároku Dodavatele na peněžité plnění vyplývajícímu ze Smlouvy.

16.6. Za každý den prodlení s úhradou Smluvní pokuty je Objednatel oprávněn požadovat po Dodavateli úhradu úroků z prodlení ve výši stanovené obecně závaznými právními předpisy.

17. ZÁRUKA ZA JAKOST A PRÁVA Z VADNÉHO PLNĚNÍ

17.1. Společná ustanovení

17.1.1. Dodavatel uděluje Objednateli záruku za jakost Plnění a všech jeho částí na dobu dvou (2) let ode dne akceptace výstupu Plnění.

17.1.2. Objednatel je oprávněn Vady, které se vyskytnou v průběhu záruční doby, nahlásit Zhotoviteli bez zbytečného odkladu od okamžiku, kdy je zjistil. Lhůta bez zbytečného odkladu činí vždy nejméně devadesát (90) dnů.

17.1.3. Dodavatel odpovídá za vady zjevné, skryté i právní, které měl výstup provádění Plnění v době akceptace Objednatelem, a dále za ty, které se na něm vyskytnou v záruční době, a zavazuje se, vedle dalších nároků Objednatele, je bezplatně odstranit.

17.1.4. Dodavatel neodpovídá za vady, pokud byly způsobeny zásahem do takových výstupů Plnění ze strany Objednatele nebo jím pověřené osoby, případně jiných dodavatelů Objednatele.

17.1.5. Objednatel je povinen oznámit vady Plnění Dodavateli prostřednictvím Helpdesku, nebude-li Stranami dohodnuto jinak.

17.1.6. Dodavatel neodpovídá za vady Plnění vzniklé:

a. provozováním Díla Objednatelem v rozporu s Dokumentací;

b. neoprávněným nebo neodborným zásahem či nesprávným užitím Díla Objednatelem;

c. vadami IT prostředí Objednatele.

17.2. Záruka vztahující se k Software

17.1.1. Pokud výrobce Standardního Software poskytuje záruku za jakost, pak Dodavatel postupuje takovou záruku za jakost Objednateli. To nezbavuje Dodavatele povinnosti poskytnout Objednateli vlastní záruku za jakost ve smyslu tohoto článku.

17.1.2. V době trvání záruční doby je Dodavatel povinen odstraňovat vady ve lhůtách uvedených v tabulce níže. Lhůty stanovené v hodinách běží pouze v pracovní dny osm (8) hodin denně v době od 9:00 do 17:00 hodin (režim 5x8). Lhůty stanovené v hodinách se mimo dobu uvedenou v předchozí větě staví a pokračují dále v běhu během další bezprostředně následující doby počítání. Strany pro zamezení pochybnostem prohlašují, že toto se netýká lhůt stanovených v pracovních dnech ani počítání doby prodlení v rámci výpočtu smluvních pokut.

Produkční prostředí

Kategorie vady Lhůta k odstranění počítaná od nahlášení vady

Objednatelem Vada kategorie A – kritická do 4 hodin1

Vada kategorie B – střední do 17:00 třetího pracovního dne od nahlášení vady2 Vada kategorie C – nízká do 17:00 pátého pracovního dne od nahlášení vady3

Testovací prostředí

Kategorie vady Lhůta k odstranění počítaná od nahlášení vady

Objednatelem

Vada kategorie A – kritická do 17:00 druhého pracovního dne od nahlášení vady4 Vada kategorie B – střední do 17:00 pátého pracovního dne od nahlášení vady5 Vada kategorie C – nízká do 17:00 desátého pracovního dne od nahlášení vady6

17.3. Záruka vztahující se k Hardware

17.1.1. Poskytuje-li výrobce anebo Dodavatel kterékoliv části Hardware na své výrobky anebo služby záruku za jakost delší, než je záruka za jakost dle tohoto článku, zavazuje se Dodavatel udělit Objednateli nebo na Objednatele postoupit danou záruku za jakost tak, aby Objednatel byl oprávněn po skončení záruky za jakost uplatnit nároky ze záruky za jakost bez nutnosti součinnosti ze strany Dodavatele.

17.1.2. Zjevné vady Hardware a dalších hmotných věcí je Objednatel povinen u Dodavatele reklamovat v rámci Akceptačního řízení. V případě, že Objednatel zjistí vady hmotných věcí po akceptaci, je povinen tyto vady bez zbytečného odkladu reklamovat u Dodavatele.

17.1.3. V případě, že odstranění reklamovaných vad bude trvat déle než dva (2) pracovní dny, zavazuje se Dodavatel poskytnout Objednateli náhradní Hardware či jinou náhradní hmotnou věc po dobu trvání odstranění reklamované vady, nedohodnou- li se Strany jinak.

18. UKONČENÍ SMLUVNÍHO VZTAHU

18.1. Obecně k odstoupení od Smlouvy:

a. Strany sjednávají, že vznikne-li Objednateli nárok na odstoupení od Smlouvy, může podle své volby odstoupit od Smlouvy v celém rozsahu či jen od některé části Plnění určené Objednatelem.

b. Strany se dohodly na vyloučení použití § 1978 odst. 2 Občanského zákoníku, který stanoví, že marné uplynutí dodatečné lhůty stanovené k plnění může mít za následek odstoupení od této Smlouvy bez dalšího.

c. Dodavatel nemá právo odstoupit od Smlouvy v případě nevhodných příkazů Objednatele či poskytnutí nevhodné věci Objednatelem dle § 2595 Občanského zákoníku.

18.2. Objednatel je oprávněn odstoupit od Smlouvy, v případě, že:

1 Lhůta je stanovena v hodinách.

2 Lhůta je stanovena ve dnech.

3 Lhůta je stanovena ve dnech.

4 Lhůta je stanovena v hodinách.

5 Lhůta je stanovena ve dnech.

6 Lhůta je stanovena ve dnech.

a. Dodavatel je v prodlení s plněním dle Smlouvy či jakékoliv části Plnění déle než 30 dnů a nezjedná nápravu ani do 15 dnů od doručení písemného oznámení Objednatele o takovém prodlení.

b. Dodavatel je v prodlení s Plněním dle Smlouvy déle než 60 dnů, a to i bez nutnosti zaslání předchozího upozornění.

c. Nastane některý ze zákonem stanovených případů a zejména v případech podstatného porušení povinností Dodavatele stanovených ve Smlouvě. Za podstatné porušení povinností Dodavatele se považuje zejména:

(i) Dodavatel je opakovaně v prodlení s prováděním Plnění dle Smlouvy;

(ii) prohlášení Dodavatele učiněné na základě Smlouvy se ukáže jako nepravdivé;

(iii) Dodavatel bez upozornění a relevantního odůvodnění nepoužil k Plnění člena Realizačního týmu, ač k tomu byl povinen; nebo

(iv) Dodavatel poruší některou z povinností uvedenou v čl. 20. ZOP opakovaně nebo závažným způsobem.

d. Dodavatel poruší kteroukoliv svoji povinnost dle Smlouvy jiným než podstatným způsobem a ve lhůtě 15 dnů od doručení písemného oznámení Objednatele toto své porušení nenapraví.

e. Dodavatel poruší svou povinnost dle čl. 13.2. ZOP nebo čl. 13.3. ZOP nebo Poddodavatel Dodavatele poruší některou z povinností vyplývající z požadavků dle čl.

13.2. ZOP;

f. Dodavatel podá insolvenční návrh jako dlužník ve smyslu § 98 Insolvenčního zákona nebo insolvenční soud nerozhodne o insolvenčním návrhu na Dodavatele do šesti (6) měsíců od zahájení insolvenčního řízení, nebo insolvenční soud vydá rozhodnutí o úpadku Dodavatele ve smyslu § 136 Insolvenčního zákona;

g. je přijato rozhodnutí o povinném nebo dobrovolném zrušení Dodavatele (vyjma případů sloučení nebo splynutí);

h. okolnost vylučující povinnost k náhradě újmy kterékoli ze Stran trvá déle než 30 dnů; a

i. dojde k Významné změně dle čl. 4.2. ZOP;

j. dojde k Významné změně kontroly nad Dodavatelem nebo změny kontroly nad zásadními aktivy využívanými Dodavatelem k plnění Smlouvy, přičemž kontrolou se zde rozumí vliv, ovládání či řízení dle ust. § 71 a násl. ZOK, či ekvivalentní postavení;

k. dojde k Významné změně ovlivnění nebo ovládání Dodavatele podle ust. § 71 a násl. ZOK nebo změně vlastnictví zásadních aktiv, využívaných Dodavatelem k plnění Smlouvy a změně oprávnění nakládat s těmito aktivy, či dojde ke změně ekvivalentní těmto změnám a tato změna bude Objednatelem vyhodnocena jako riziko bezpečnosti informací, které nelze odstranit jiným opatřením; toto ustanovení se uplatní i pro případ, že Dodavatel o takových změnách dopředu a včas neinformuje Objednatele.

18.3. Dodavatel je oprávněn odstoupit od Smlouvy pouze v případech jejího podstatného porušení,

18.4. jestliže:

a. Objednatel nezaplatil jakoukoli dlužnou částku za Plnění dle Smlouvy řádně a včas a toto porušení nenapravil ani do 60 dnů ode dne obdržení písemné výzvy k nápravě; nebo

b. Objednatel poruší jinou povinnost dle Smlouvy podstatným způsobem a ve lhůtě 60 dnů ode dne obdržení písemné výzvy k nápravě toto své porušení nenapraví.

18.5. Dodavatel není oprávněn odstoupit od Smlouvy ve vztahu k části Plnění, za kterou mu již bylo Objednatelem zaplaceno.

19. ZMĚNY SMLOUVY A ZMĚNOVÉ ŘÍZENÍ

19.1. Není-li ve Smlouvě nebo jejích Přílohách stanoveno jinak, může být Smlouva měněna nebo zrušena pouze v listinné podobě, a to v případě změn Smlouvy číslovanými dodatky, který musí být podepsány oběma Stranami a uzavřeny v souladu se ZZVZ.

19.2. Pokud je ve Smlouvě upraveno Opční právo, vyhrazuje si Objednatel v souladu s ustanovením

§ 100 odst. 3 ZZVZ vyhrazenou změnu závazku z této Smlouvy spočívající v pořízení dalšího obdobného Plnění od vybraného účastníka v rámci zadávacího řízení Veřejné zakázky, tj. od Dodavatele dle Smlouvy. Předmětem plnění Opčního práva je poskytnutí dalšího obdobného Plnění dle Smlouvy tak, jak bylo podrobně vymezeno včetně dalších zákonných náležitostí

vyhrazené změny závazku dle § 100 odst. 3 ZZVZ v Zadávací dokumentaci předmětné Veřejné zakázky.

19.3. Objednatel je oprávněn do uplynutí tří (3) let od nabytí účinnosti Smlouvy kdykoliv uplatnit toto Opční právo, a to i opakovaně do vyčerpání limitů Opčního práva definovaných v Zadávací dokumentaci. Vyhrazená změna závazku ze Smlouvy bude Stranami projednána v rámci jednacího řízení bez uveřejnění dle § 66 ZZVZ, které bude zahájeno Objednatelem v souladu s tímto ustanovením, a jehož výsledkem bude uzavření listinného dodatku k této Smlouvě či uzavření nové smlouvy mezi Objednatelem nebo Dodavatelem.

20. KYBERNETICKÁ BEZPEČNOST

20.1. Tento článek se uplatní v případě, kdy tak výslovně stanoví Smlouva, pokud je Předmětem Smlouvy Informační či komunikační systém, pokud má Plnění dopad na Informační či komunikační systém, nebo pokud je Smlouva uzavřena s Významným dodavatelem či Provozovatelem. Zda je Dodavatel Významným dodavatelem či Provozovatelem, stanoví Smlouva. Na jiné Smlouvy a vztahy se neuplatní, ledaže se Dodavatel stane významným dodavatelem či Provozovatelem v průběhu plnění Smlouvy. V takovém případě se na něj čl.

20. uplatní v rozsahu v jakém to po něm lze spravedlivě požadovat.

20.2. Dodavatel se při plnění Smlouvy zavazuje postupovat v souladu se ZKB, VKB a souvisejícími právními předpisy, dodržovat zásady bezpečnosti informací, Interní předpisy Objednatele a z nich vyplývající povinnosti týkající se bezpečnostních opatření, provozní řády prostor Objednatele, rozhodnutí, opatření obecné povahy, či jiný správní akt NÚKIB či jiného správního orgánu anebo závazné podmínky pro Objednatele stanovené orgánem veřejné moci ukládající Objednateli další povinnosti ve smyslu ZKB a VKB, včetně upozorňování a zajištění hlášení Kybernetických bezpečnostních událostí a Kybernetických bezpečnostních incidentů Objednateli, jakož i další bezpečnostní politiky, metodiky a postupy, se kterými byl Objednatelem seznámen.

20.3. Dodavatel je povinen seznámit se s bezpečnostními požadavky Objednatele uvedenými ve Smlouvě, jejích přílohách, těchto ZOP, Interních předpisech Objednatele a seznámit s nimi osoby podílející se na plnění Smlouvy dle potřeby s ohledem na charakter jejich plnění s přihlédnutím k zajištění bezpečnosti informací. Kontaktní osoba Dodavatele je povinna splnění povinnosti dle předchozí věty Objednateli potvrdit do 30 dnů od uzavření Smlouvy. Pokud je to potřebné, je Dodavatel povinen provést školení bezpečnostních požadavků dle tohoto odstavce a dále je provádět v pravidelných intervalech, nejméně 1x ročně. Dodavatel je také povinen aktivně vynucovat dodržování takových bezpečnostních požadavků dotčenými osobami na straně Dodavatele. Za porušení těchto pravidel osobami uvedenými v tomto odstavci odpovídá Dodavatel tak, jako by je porušil sám.

20.4. Není-li ve Smlouvě ujednáno jinak, je Dodavatel povinen vytvořit, pravidelně aktualizovat a vynucovat vůči osobám podílejícím se, byť i nepřímo, na předmětu Smlouvy:

a. politiku řízení přístupu, na základě které přidělí oprávnění k výkonu činností jednotlivým rolím svých fyzických osob (přístup pro více osob na jednom účtu je nežádoucí a lze pouze se souhlasem Objednatele) podílejících se na plnění Smlouvy (zaměstnanci, programátoři podnikatelé apod.) v nejmenším možném a nutném rozsahu tak, aby měli přístup k aktivům Objednatele pouze ty osoby, které takový přístup skutečně potřebují k výkonu činností týkajících se předmětu Plnění dle Smlouvy; není-li ve Smlouvě ujednáno jinak, je Dodavatel dále povinen průběžně monitorovat a zaznamenávat přístupy všech osob účastnících se na Plnění dle Smlouvy, jakož i vyhodnocovat oprávněnost těchto přístupů (logování přístupů) a tuto sovu povinnost v politice řízení přístupu zohlednit;

b. politiku zvládání Kybernetických bezpečnostních událostí a Kybernetických bezpečnostních incidentů obsahující činnosti, role, odpovědnosti a pravomoci k rychlému a účinnému zvládání Kybernetických bezpečnostních událostí a Kybernetických bezpečnostních incidentů.

20.5. Kontaktní osoba Dodavatele je povinna před započetím Plnění, nejpozději však do 30 dnů od uzavření Smlouvy, určit a popsat veškerá dotčená primární i podpůrná aktiva na straně Dodavatele potřebná pro plnění Smlouvy. Dodavatel je povinen při nakládání s veškerými aktivy (dotčenými aktivy Dodavatele a Objednatele) postupovat tak, aby chránil jejich důvěrnost, dostupnost a integritu a zavést přiměřená opatření na jejich ochranu. Dodavatel je povinen řídit rizika spojená s Plněním dle Smlouvy minimálně dle standardů požadovaných normou ISO 27001 a případně dle Interních předpisů, pokud obsahují závazná pravidla pro řízení rizik. Dodavatel je povinen bez zbytečného odkladu po uzavření Smlouvy kontaktní

osobu Objednatele informovat o způsobu řízení rizik a o zbytkových rizicích souvisejících s Plněním Smlouvy a následně v pravidelných intervalech informovat o změnách.

20.6. Dodavatel je povinen zaslat kontaktní osobě Objednatele bez zbytečného odkladu všechna hlášení o událostech, která mají charakter Kybernetické bezpečnostní události nebo Kybernetického bezpečnostního incidentu včetně případů porušení zabezpečení Osobních údajů, vždy bez zbytečného odkladu, nejpozději však do tří (3) hodin po jejich zjištění, a sdělit Objednateli opatření, která již provedl ve vztahu k této Kybernetické bezpečnostní události anebo Kybernetickému bezpečnostnímu incidentu, případně zvolí jinou formu dohodnutou mezi Objednatelem a Dodavatelem určenou ke včasnému hlášení Kybernetické bezpečnostní události nebo Kybernetického bezpečnostního incidentu a/nebo již učiněných opatření. Dodavatel je povinen veškeré Kybernetické bezpečnostní události a Kybernetické bezpečnostní incidenty zaznamenávat a po nezbytně dlouhou dobu uchovávat. Dodavatel je povinen poskytnout Objednateli veškerou nezbytnou součinnost k detekci, vyhodnocení či řešení Kybernetické bezpečností události nebo Kybernetického bezpečnostního incidentu, a to včetně případné realizace nutných opatření dle pokynů Objednatele. Zapříčinil-li Dodavatel Kybernetický bezpečnostní incident nebo podílel-li se na jeho vzniku, provede analýzu příčin Kybernetického bezpečnostního incidentu a navrhne opatření za účelem zamezení jeho opakování v budoucnu. Dodavatel je povinen ohlásit každou jednotlivou Kybernetickou bezpečnostní událost nebo Kybernetický bezpečnostní incident jedním z následujících způsobů:

a. e-mailem na adresu kontaktní osoby uvedené ve Smlouvě nebo

b. telefonicky na telefonní číslo kontaktní osoby uvedené ve Smlouvě nebo

c. ohlášením do Helpdesku Objednatele.

20.7. Dodavatel je povinen pravidelně alespoň čtvrtletně předkládat Objednateli zprávu o počtu a druhu útoků a Kybernetických bezpečnostních událostí a Kybernetických bezpečnostních incidentů, které zaznamenal ve spojení s Plněním a/nebo Předmětem Smlouvy.

20.8. Dodavatel se zavazuje poskytnout Objednateli veškerou součinnost nezbytnou k tomu, aby Objednatel řádně naplňoval právní povinnosti stanovené ZKB, VKB a Interními předpisy. Zejména se Dodavatel zavazuje poskytnout Objednateli součinnost směřující k zavedení a provádění bezpečnostních opatření podle ZKB, VKB a Interních předpisů a řešení Kybernetických bezpečnostních událostí a Kybernetických bezpečnostních incidentů. Jestliže Dodavatel při plnění Smlouvy zjistí či jako odborník mohl a měl zjistit rozpor ustanovení Interních předpisů se ZKB, VKB anebo rozhodnutím či jiným pokynem NÚKIB v souladu se ZKB, je povinen takový rozpor Objednateli neprodleně ohlásit a poskytnout Objednateli součinnost k jeho odstranění.

20.9. V případě, že dojde k jakémukoliv rozporu mezi Dodavatelem a třetí osobou, která není jeho Poddodavatelem a je dodavatelem Software nebo jiných technologií dotčených plněním povinností Dodavatele dle této Smlouvy, je Dodavatel povinen tuto skutečnost bez zbytečného odkladu oznámit Objednateli. Dodavatel je dále povinen poskytovat Objednateli nutnou součinnost pro jednání s těmito třetími osobami a sám se těchto jednání účastnit, nebo na základě žádosti Objednatele jednat s těmito třetími osobami napřímo.

20.10. Objednatel má právo v souladu s ustanoveními § 2593 Občanského zákoníku prostřednictvím určených osob kdykoli kontrolovat plnění Smlouvy u Dodavatele a jeho případných Poddodavatelů, a to i prostřednictvím třetí osoby; předchozí věta se uplatní obdobně v případě kontroly některé ze Stran ze strany kontrolního orgánu ve smyslu zákona č. 255/2012 Sb., kontrolní řád, ve znění pozdějších předpisů.

20.11. Objednatel má právo prostřednictvím určených osob provádět v pravidelných intervalech (1x ročně, není-li ve Smlouvě ujednáno jinak), jakož i v případě důvodného podezření na závažné porušení povinností Dodavatele dle těchto ZOP, v případě Kybernetických bezpečnostních incidentů a/nebo v jiných případech vyžadovaných ZKB a/nebo VKB, audit kybernetické bezpečnosti, tj. dodržování bezpečnosti informací dle Interních předpisů, ZKB a VKB u Dodavatele a jeho případných Poddodavatelů, a to i prostřednictvím třetí osoby. V rámci auditu kybernetické bezpečnosti je Objednatel oprávněn zejména porovnávat zjištěné skutečnosti s bezpečnostní dokumentací Objednatele a nad rámec obvyklý u auditu kybernetické bezpečnosti dále provádět následující činnosti:

a. nehlášená návštěva u Dodavatele v místě umístění členů Realizačního týmu či jiných osob podílejících se na plnění Smlouvy v rozsahu tří (3) hodin vždy nejčastěji čtyřikrát (4x) za rok; a

b. nehlášený telefonát s členem Realizačního týmu, který má přístup do Informačního či komunikačního systému, zahrnující konkrétní dotazy na zabezpečení a jiné aspekty informační bezpečnosti dotčeného Informačního či komunikačního systému.

20.12. Dodavatel je povinen umožnit Objednateli provedení kontroly a auditu kybernetické bezpečnosti a zajistit (i smluvně) právo na provedení této kontroly a auditu kybernetické bezpečnosti u svých případných Poddodavatelů, jakož i veškerou další součinnost nezbytnou pro provedení auditu. Kontrolu a audit kybernetické bezpečnosti může rovněž provést i třetí osoba pověřená Objednatelem. Průběh takového auditu je doložen např. auditní zprávou či jiným obdobným dokumentem. Případné náklady na straně Dodavatele na provedení auditu jsou součástí Ceny za Plnění dle Smlouvy. Dodavatel je oprávněn rozporovat výsledky auditu kybernetické bezpečnosti do 7 pracovních dnů od oznámení výsledku auditu kybernetické bezpečnosti. Dodavatel může rozporovat a) existenci vytčeného porušení či hrozby; b) že porušení či hrozba byla Dodavatelem již odstraněna. V obou případech uvede skutečnosti a důkazy k podpoře svých tvrzení. Objednatel je v takovém případě povinen takové připomínky vypořádat. V případě, že Objednatel na svém zjištění setrvá, je Dodavatel povinen se tímto auditem řídit.

20.13. Pokud audit kybernetické bezpečnosti odhalí jakékoliv podstatné porušení či hrozbu takového porušení, je Dodavatel povinen napravit nedostatky vč. přijetí případných dalších bezpečnostních opatření a o tomto informovat Objednatele, pokud se jedná o Významného dodavatele, je povinen napravit nedostatky bezodkladně a informovat Objednatele do 7 dnů.

20.14. Je-li součástí předmětu Plnění správa síťové infrastruktury a/nebo jejích prvků (aktivních či pasivních), je Dodavatel povinen za součinnosti oprávněných osob na straně Objednatele:

a. provádět analýzy topologie sítě či skenování aktivních částí předmětu Plnění;

b. zabezpečit vhodnými technickými prostředky přenos Dat a informací; a

c. realizovat bezpečnostní opatření pro odstranění nebo blokování síťových spojení, která neodpovídají požadavkům na ochranu integrity komunikační sítě.

20.15. Významný dodavatel je dále povinen:

a. poskytnout Objednateli veškeré potřebné informace a součinnost v procesu řízení a evidence změn v souladu s § 11 VKB dle potřeb Objednatele (zejm. při posouzení, zda je změna Významnou změnou, analýze souvisejících rizik, přijímání opatření za účelem snížení všech nepříznivých dopadů spojených se změnami, aktualizaci bezpečnostní dokumentace, souvisejícím testováním, zajištění možnosti navrácení do původního stavu a provedení dalších činností dle VKB);

b. strpět a poskytnout Objednateli veškerou potřebnou součinnost v případě nutnosti provést penetrační testování;

c. zpracovat