SMLOUVA na Systém pro správu zranitelností (číslo smlouvy Objednatele: 803-2017-13330, S 2017-0119) Smluvní strany: Česká republika – Ministerstvo zemědělství se sídlem: Těšnov 65/17, 110 00, Praha 1 – Nové Město IČO: 00020478, DIČ: CZ00020478 bank....

SMLOUVA na Systém pro správu zranitelností

(číslo smlouvy Objednatele: 000-0000-00000, S 2017-0119)






Smluvní strany:



Česká republika – Ministerstvo zemědělství

se sídlem: Těšnov 65/17, 110 00, Praha 1 – Nové Město

IČO: 00020478, DIČ: CZ00020478

bank. spojení: Česká národní banka, č. účtu: 0000000/0710

jednající: Xx. Xxxxx Xxxxxx, ředitel odboru informačních a komunikačních technologií

(dále také jako „Objednatel“ nebo „MZe“ nebo „Zadavatel“)



a



"[DOPLNÍ ÚČASTNÍK]"

se sídlem: "[DOPLNÍ ÚČASTNÍK]"

IČO: "[DOPLNÍ ÚČASTNÍK]" , DIČ: "[DOPLNÍ ÚČASTNÍK]"

společnost zapsaná v obchodním rejstříku vedeném "[DOPLNÍ ÚČASTNÍK]" ,

oddíl "[DOPLNÍ ÚČASTNÍK]" , vložka "[DOPLNÍ ÚČASTNÍK]"

bank. spojení: "[DOPLNÍ ÚČASTNÍK]" , č. účtu: "[DOPLNÍ ÚČASTNÍK]"

jejímž jménem jedná: "[DOPLNÍ ÚČASTNÍK]"

(dále také jako „Poskytovatel“, „Zhotovitel“ nebo „Dodavatel“)



dnešního dne uzavřely na základě výsledku výběrového řízení Objednatele, s názvem „Systém pro správu zranitelností “ tuto smlouvu v souladu s ustanovením § 26 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“) a dále v souladu s ustanovením § 1746 odst. 2 za použití § 2358 a násl. zákona č. 89/ 2012 Sb., občanský zákoník, v platném znění (dále jen „občanský zákoník“)

(dále jen „Smlouva“).













Smluvní strany, vědomy si svých závazků v této Smlouvě obsažených a s úmyslem být touto Smlouvou vázány, dohodly se na následujícím znění Smlouvy:



I. Úvodní ustanovení

  1. Objednatel prohlašuje, že:

    1. je ústředním orgánem státní správy, jehož působnost a zásady činnosti jsou stanoveny zákonem č. 2/1969 Sb., o zřízení ministerstev a jiných ústředních orgánů státní správy České republiky, ve znění pozdějších předpisů, a

    2. splňuje veškeré podmínky a požadavky v této Smlouvě stanovené a je oprávněn tuto Smlouvu uzavřít a řádně plnit závazky v ní obsažené.

  2. Poskytovatel prohlašuje, že:

    1. je právnickou osobou řádně založenou a existující podle "[DOPLNÍ ÚČASTNÍK]" právního řádu, resp. oprávněně podnikající fyzickou osobou způsobilou k právním úkonům,

    2. splňuje veškeré podmínky a požadavky v této Smlouvě stanovené a je oprávněn tuto Smlouvu uzavřít a řádně plnit závazky v ní obsažené, a

    3. ke dni podpisu této Smlouvy není v úpadku ani v likvidaci, a že návrh na zahájení insolvenčního řízení vůči Poskytovateli nebyl zamítnut pro nedostatek jeho majetku, a zavazuje se udržovat toto prohlášení v pravdivosti a Objednatele bezodkladně informovat o všech skutečnostech, které mohou mít dopad na pravdivost, úplnost nebo přesnost předmětného prohlášení a o změnách v jeho kvalifikaci, kterou prokázal v rámci své nabídky na plnění Xxxxxxx zakázky (jak je tento pojem definován v odst. 4 tohoto článku).

  3. Poskytovatel dále prohlašuje, že je subjektem oprávněným k poskytování služby Systém pro správu zranitelností v souladu s podmínkami zadavatele tak, jak je podrobně specifikována v Přílohách č. 1, č. 4 a č. 5 této Smlouvy (dále jen „Služba VULN“). Poskytovatel prohlašuje, že je schopen a oprávněn řádně poskytovat plnění, jež je předmětem této Smlouvy.

  4. Objednatel oznámil dne 24.11.2017 oznámením zadávacího řízení svůj úmysl zadat prostřednictvím elektronického tržiště podlimitní veřejnou zakázku s názvem „Systém pro správu zranitelností “ (dále jen „Veřejná zakázka“). Na základě vyhodnocení zadávacího řízení byla pro plnění Veřejné zakázky vybrána nabídka Poskytovatele.



II. Účel Smlouvy

  1. Účelem této Smlouvy je zajištění řešení Systému pro správu zranitelností, a to formou služby dle specifikace v této smlouvě především v Přílohách č. 1, č. 4 a č. 5

  2. Poskytovatel touto Smlouvou garantuje Objednateli splnění zadání uvedené Veřejné zakázky a všech z toho vyplývajících podmínek a povinností podle zadávací dokumentace Veřejné zakázky (dále jen „Zadávací dokumentace“). Tato garance je nadřazena ostatním podmínkám a garancím uvedeným v této Smlouvě. Pro vyloučení jakýchkoliv pochybností to znamená, že:


    1. v případě jakékoliv nejistoty ohledně výkladu ustanovení této Smlouvy budou tato ustanovení vykládána tak, aby v co nejširší míře zohledňovala účel Veřejné zakázky vyjádřený v tomto ustanovení a dále v Zadávací dokumentaci,

    2. v případě chybějících ustanovení této Smlouvy budou použita dostatečně konkrétní ustanovení Zadávací dokumentace,

    3. Poskytovatel je vázán svou nabídkou předloženou Objednateli v rámci zadávacího řízení na zadání Veřejné zakázky, která se pro úpravu vzájemných vztahů vyplývajících z této Smlouvy použije subsidiárně.


III. Předmět Smlouvy

  1. Předmětem této Smlouvy je závazek Poskytovatele poskytovat plnění sestávající ze služby zajištění řešení Systém pro správu zranitelností, a to v souladu s Přílohou č. 1, č. 4 a č. 5 této Smlouvy (dále jen také jen „Služba VULN“).

IV. Místo plnění

  1. Místem plnění Smlouvy jsou datová centra a prostředí objednatele, jejichž adresy jsou uvedeny v Příloze č. 2 Smlouvy.



V. Doba plnění

  1. Poskytovatel se zavazuje poskytovat Objednateli plnění dle této Smlouvy pouze na základě protokolárního zahájení, a to ode dne podpisu takového protokolu do doby ukončení účinnosti smlouvy. Protokolárním zahájením plnění se rozumí zahájení poskytování Služby VULN, v místě plnění v souladu s Přílohou č. 2 této Smlouvy, na základě smluvními stranami oboustranně podepsaného předávacího protokolu, nejpozději však do 45 dnů od nabytí účinnosti Smlouvy.



VI. Cena

  1. Celková cena za poskytování Služby VULN Poskytovatelem dle této Smlouvy za celou dobu plnění dle článku V. této Smlouvy činí [doplní účastník] bez DPH, z toho DPH [doplní účastník], tj. [doplní účastník] s DPH a je blíže stanovena v Příloze č. 3 Smlouvy.

  2. Úhrada ceny za poskytování Služby VULN dle této Smlouvy bude Objednatelem Poskytovateli hrazena průběžně, a to v úhradách za Služby VULN poskytnuté v jednotlivých kalendářních měsících, a to vždy ve výši měsíční ceny uvedené v Příloze č. 3 Smlouvy, případně její alikvotní částí, viz článek VII. odst. 2) této Smlouvy.

  3. Veškerá peněžitá plnění vyplývající z této Smlouvy budou stranami hrazena v souladu s platebními podmínkami v článku VII. Smlouvy.

  4. Celková cena za 48 měsíců i jednotlivá měsíční cena uvedené v Příloze č. 3 Smlouvy jsou stanoveny jako ceny nejvýše přípustné a zahrnují veškeré náklady Poskytovatele na plnění dle této Smlouvy.

  5. Objednatel neposkytuje jakékoliv zálohy.



VII. Platební podmínky

  1. Poskytovatel se zavazuje vystavovat faktury za plnění dle této Smlouvy vždy do 10 dní od konce fakturovaného kalendářního měsíce tak, aby byly Objednateli doručeny vždy současně s příslušným Reportem (jak je tento pojem definován v čl. VIII. Xxxxxxx), za uplynulý kalendářní měsíc, který bude přílohou faktury.

  2. V případě, že poskytování/ukončení Služby VULN bude zahájeno/ukončeno v průběhu kalendářního měsíce, vzniká Poskytovateli právo fakturovat pouze alikvotní část měsíční ceny za prokazatelně uskutečněné plnění.

  3. Veškeré faktury vystavené na základě této Smlouvy jsou splatné ve lhůtě 30 dní od jejich doručení Objednateli a musí obsahovat identifikační údaje Poskytovatele a Objednatele, jejich bankovní spojení a čísla účtů, číslo DMS Smlouvy, den vystavení a lhůtu splatnosti, výši fakturované částky, kontaktní osoby Objednatele a Poskytovatele. Poskytovatel se zavazuje bez zbytečného odkladu daňový doklad řádně doručit Objednateli. Faktury musí splňovat všechny náležitosti daňového dokladu ve smyslu příslušných zákonných ustanovení, zejména § 29 zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů, a taktéž přílohy dle této Smlouvy. Faktura má formu obchodní listiny ve smyslu ustanovení § 435 občanského zákoníku. Přílohou každé faktury bude vždy příslušný Report schválený Objednatelem.

  4. Nebude-li daňový doklad obsahovat Smlouvou ujednané náležitosti nebo přílohy nebo v nich nebudou správně uvedené údaje, je Objednatel oprávněn vrátit jej před uplynutím lhůty splatnosti Poskytovateli. V takovém případě se přeruší běh lhůty splatnosti a nová lhůta splatnosti počne běžet doručením opravené faktury a její přílohy.

  5. Platby peněžitých částek se provádí bankovním převodem na účet druhé smluvní strany uvedený ve faktuře. Smluvní strany se dohodly a souhlasí, že úhradou daňového dokladu – faktury Objednatelem se rozumí odeslání částky v daňovém dokladu – faktuře Poskytovatelem požadované ve prospěch bankovního účtu Poskytovatele uvedeného na faktuře.



VIII. Způsob poskytování Služby VULN

  1. Poskytovatel se zavazuje:

    1. poskytovat Službu VULN na profesionální úrovni a s péčí řádného hospodáře odpovídající podmínkám sjednaným v této Smlouvě; dostane-li se Poskytovatel do prodlení s povinností poskytovat Službu VULN řádně bez zavinění Objednatele či v důsledku okolností vylučujících odpovědnost za škodu po dobu delší 5 dnů, je Objednatel oprávněn zajistit plnění dle této Smlouvy po dobu prodlení Poskytovatele jinou osobou; v takovém případě nese náklady spojené s náhradním plněním Poskytovatel

    2. poskytovat Službu VULN v kvalitě definované  Service Level Agreements („SLA“) v Příloze č. 1 této Smlouvy,

    3. na své náklady a s péčí řádného hospodáře podporovat, spravovat a udržovat veškeré technické prostředky, které jsou součástí předmětu plnění,

    4. poskytovat Objednateli pravidelné reporty (dále jen „Reporty“), ze kterých bude zřejmé, v jakém rozsahu a v jaké kvalitě byla Služba VULN v daném vyhodnocovacím období poskytována.

  1. Reporty budou vypracovávány vždy pro vyhodnocovací období 1 kalendářního měsíce. Reporty musí být Objednateli doručeny vždy společně s příslušnou fakturou za uplynulý měsíc, ke kterému se daný Report vztahuje, a to nejpozději do 10 dní od ukončení daného měsíce.

  2. Reporty budou obsahovat zejména:

    1. popis úkonů prováděných v rámci Služby VULN,

    2. stav zranitelností za dané vyhodnocovací období,

    3. stav shody konfigurací za dané vyhodnocovací období,

    4. počet a popis úprav na technickém zařízení pro podporu Služby VULN za dané vyhodnocovací

    5. přehled úrovně poskytování Služby VULN s vyhodnocením případných incidentů v daném období

  3. Za účelem poskytování Služby VULN a pro příjem požadavků je Poskytovatel povinen používat po celou dobu poskytování Služby VULN středisko technické podpory (service desk) Objednatele, který je též měřícím bodem pro vyhodnocování úrovně služeb v souladu s parametry KPI, uvedenými v příloze č. 1 - Specifikace katalogových listů.

Kontaktní osoby:

Smluvní strana

Jméno a příjmení

Telefon

e-mail

Poskytovatel

[DOPLNÍ ÚČASTNÍK]

[DOPLNÍ ÚČASTNÍK]

[DOPLNÍ ÚČASTNÍK]

Objednatel

Xxxxx Xxxxx

HelpDesk

602492265

221 811 888

Xxxxx.Xxxxx@xxx.xx

xxxxxxxx@xxx.xx

  1. Reporty podléhají schválení Objednatelem. Nebyla-li Služba VULN poskytnuta řádně nebo včas, bude Report vyčíslovat příslušnou smluvní pokutu.

  2. Objednatel se zavazuje poskytnout Poskytovateli veškerou nezbytnou součinnost k řádnému plnění této Smlouvy.

  3. Poskytovatel se zavazuje poskytovat Službu VULN sám, nebo s využitím subdodavatelů, přičemž v takovém případě odpovídá Objednateli v takovém rozsahu a způsobem, jako kdyby poskytl tuto Službu VULN sám Poskytovatel.





IX. Přechod vlastnického práva a autorská práva

  1. Zahrnuje-li plnění dle této Smlouvy převod vlastnického práva k určité věci (např. hmotné nosiče dat, náhradní díly apod.), nabývá Objednatel vlastnické právo okamžikem předání věci Poskytovatelem Objednateli.

  2. Poskytovatel ručí za to, že Objednatel získá nejpozději k okamžiku účinnosti smlouvy, oprávnění užívat práva související s poskytováním Služby VULN a to především práva zakomponovaná či nahraná na prostředky pro podporu Služby VULN, přičemž platí, že cena za tato oprávnění, resp. práva je užívat, je již plně zahrnuta v ceně dle čl. VI. Smlouvy. Tudíž Poskytovatel zejména zajistí, aby Objednatel měl právo užívat počítačový program třetí strany v neomezeném časovém, množstevním a územním rozsahu a všemi v úvahu přicházejícími způsoby, je-li takový počítačový program součástí dodávaných a/nebo převedených věcí či poskytovaných Služeb a je-li chráněn právem z průmyslového nebo jiného duševního vlastnictví, přičemž platí, že cena za tato práva je již plně zahrnuta v ceně dle čl. VI. Smlouvy. V případě, že takový počítačový program nebo jiný předmět skutečně či domněle porušuje nebo poruší práva třetích osob, Poskytovatel odškodní a na vlastní náklady bude bránit Objednatele, pokud jej k tomu zmocní, proti všem nárokům z porušení vlastnických práv a práv duševního vlastnictví, uplatněných třetí osobou, které mohou vyplynout z užití plnění, a dále zaplatí vzniklou škodu a náklady, včetně nákladů právního zastoupení.

  3. Má-li být v souvislosti s plněním předmětu této Smlouvy Objednateli poskytnuto dílo Poskytovatele, které naplňuje znaky díla ve smyslu zákona č. 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), v platném znění, nebo je chráněno právem z jiného duševního vlastnictví, zavazuje se Poskytovatel udělit Objednatelovi nevýhradní oprávnění (dále jen „licence“) užívat takovéto dílo v neomezeném množstevním, územním a časovém rozsahu, a to všemi v úvahu přicházejícími způsoby. Přitom platí, že cena za licenci je již plně zahrnuta v ceně dle čl. VI. Smlouvy.

  4. Součástí licence je vždy i neomezené oprávnění Objednatele provádět bez dalšího jakékoliv modifikace, úpravy, změny takovéhoto díla a dle svého uvážení do něj bez dalšího zasahovat, zapracovávat do dalších autorských děl, apod., a to přímo nebo prostřednictvím třetích osob. Objednatel je bez potřeby jakéhokoliv dalšího svolení Poskytovatele nad rámec souhlasu Poskytovatele uděleného touto Smlouvou oprávněn udělit třetí osobě podlicenci k užití tohoto díla nebo svoje oprávnění k užití tohoto díla třetí osobě postoupit, avšak pouze za předpokladu, že tím bude docházet k užití tohoto díla v souladu s účelem, pro který bylo takové dílo vytvořeno. Objednatel není povinen licenci či podlicenci využít.


X. Smluvní pokuty a sankce

  1. V případě, že Poskytovatel bude v prodlení se zahájením poskytování Služby VULN dle této Smlouvy, vzniká Objednateli nárok na smluvní pokutu ve výši 10.000,- Kč bez DPH za každý započatý den takového prodlení. Maximální výše smluvní pokuty není limitována.

  2. V případě, že Poskytovatel nedodrží parametr SLA – KPI01 Odezva uvedený v Příloze č. 1 Smlouvy, vzniká Objednateli nárok na smluvní pokutu ve výši 0,1 % z měsíční ceny včetně DPH za poskytování plnění dle této Smlouvy za každou započatou minutu nad stanovenou tolerovanou míru měsíční nedostupnosti, tj. nad 0,1% za měsíc, rovněž platí i ujednání ohledně Slevy z ceny uvedené v KL VULN01 Odezva. Maximální výše smluvní pokuty není limitována.

  3. V případě, že Poskytovatel nedodrží parametr SLA – KPI02 Správa VULN odezvy Služby VULN uvedené v Příloze č. 1 Smlouvy, vzniká Objednateli nárok na smluvní pokutu ve výši 0,5 % z měsíční ceny včetně DPH za poskytování plnění dle této Smlouvy za každou započatou minutu takového prodlení, rovněž platí i ujednání ohledně Slevy z ceny uvedené v KL VULN02 Správa. Maximální výše smluvní pokuty není limitována.

  4. Poruší-li Poskytovatel povinnosti vyplývající z čl. XII. odst. 2 a odst. 3 této Smlouvy, je povinen zaplatit Objednateli smluvní pokutu ve výši 100.000,- Kč (slovy: sto tisíc korun českých) za každé porušení takové povinnosti.

  5. Za každý den prodlení Poskytovatele se splněním závazku předložit Objednateli pojistnou smlouvu podle čl. XII. odst. 8. vzniká Objednateli právo na smluvní pokutu ve výši 10.000,- Kč.

  6. Poruší-li Poskytovatel povinnosti vyplývající z čl. XIV. odst. 7 této Smlouvy, je povinen zaplatit Objednateli smluvní pokutu ve výši 100.000,- Kč (slovy: sto tisíc korun českých) za každé porušení takové povinnosti.

  7. Zaplacením smluvní pokuty dle této Smlouvy není dotčeno právo Objednatele na náhradu škody v celém rozsahu. Výše smluvních pokut se do výše náhrady škody nezapočítává.

  8. V případě prodlení Objednatele se zaplacením ceny za plnění Poskytovatele, vzniká Poskytovateli nárok na úrok z prodlení ve výši 0,01 % z dlužné částky za každý i započatý den prodlení. Tím není dotčen ani omezen nárok na náhradu vzniklé škody.

  9. Smluvní pokuta je splatná na základě písemné výzvy vystavené stranou oprávněnou, a to do 14 dnů ode dne jejího doručení druhé smluvní straně.


XX. Xxxxxxx informací

  1. Smluvní strany jsou si vědomy toho, že v rámci plnění závazků z této Smlouvy:

  1. si mohou vzájemně vědomě nebo opominutím poskytnout informace, které budou považovány za důvěrné (dále jen „důvěrné informace“),

  2. mohou jejich zaměstnanci a osoby v obdobném postavení získat vědomou činností druhé strany nebo i jejím opominutím přístup k důvěrným informacím druhé strany.

  1. Smluvní strany se zavazují, že žádná z nich nezpřístupní třetí osobě důvěrné informace, které při plnění této Smlouvy získala od druhé smluvní strany.


  1. Za třetí osoby podle tohoto článku se nepovažují:

  1. zaměstnanci smluvních stran a osoby v obdobném postavení,

  2. orgány smluvních stran a jejich členové,

  3. ve vztahu k důvěrným informacím Objednatele subdodavatelé Poskytovatele,

  4. ve vztahu k důvěrným informacím Poskytovatele, externí poskytovatelé Objednatele, a to i potenciální,

za předpokladu, že se podílejí na plnění této Smlouvy nebo na plnění spojeném s plněním dle této Smlouvy, důvěrné informace jsou jim zpřístupněny výhradně za tímto účelem a zpřístupnění důvěrných informací je v rozsahu nezbytně nutném pro naplnění jeho účelu a za stejných podmínek, jaké jsou stanoveny smluvním stranám v této Smlouvě.

  1. Bez ohledu na výše uvedená ustanovení se za důvěrné nepovažují informace, které:

  1. se staly veřejně známými, aniž by jejich zveřejněním došlo k porušení závazků přijímající smluvní strany či právních předpisů,

  2. měla přijímající strana prokazatelně legálně k dispozici před uzavřením této Smlouvy, pokud takové informace nebyly předmětem jiné, dříve mezi smluvními stranami uzavřené smlouvy o ochraně informací,

  3. jsou výsledkem postupu, při kterém k nim přijímající strana dospěje nezávisle a je to schopna doložit svými záznamy nebo důvěrnými informacemi třetí strany,

  4. mají být zpřístupněny, vyžaduje-li to zákon či jiný právní předpis včetně práva EU nebo závazné rozhodnutí oprávněného orgánu veřejné moci,

  5. po podpisu této Xxxxxxx poskytne přijímající straně třetí osoba, jež není omezena v takovém nakládání s informacemi.

  1. Za porušení povinnosti ochrany důvěrných informací smluvní stranou se považují též případy, kdy tuto povinnost poruší kterákoliv z osob uvedených v odst. 3 tohoto článku, které daná smluvní strana poskytla důvěrné informace druhé smluvní strany.

  2. Poruší-li Poskytovatel povinnosti vyplývající z této Smlouvy ohledně ochrany důvěrných informací, je povinen zaplatit Objednateli, smluvní pokutu ve výši 50.000,- Kč za každé porušení takové povinnosti.

  3. Bez ohledu na výše uvedená ustanovení se veškeré informace vztahující se k předmětu této Smlouvy a příslušné dokumentaci považují výlučně za důvěrné informace Objednatele a Poskytovatel je povinen tyto informace chránit v souladu s touto Smlouvou. Poskytovatel při tom bere na vědomí, že povinnost ochrany těchto informací podle tohoto článku XI. se vztahuje pouze na Poskytovatele.

  4. Za porušení ochrany důvěrných informací ze strany Objednatele nelze považovat zveřejnění informací dle zákona č. 106/1999 Sb., o svobodném přístupu k informacím, ve znění pozdějších předpisů, či dle jiných právních předpisů České republiky a Evropské unie, a to i dosud nevydaných, jimiž je Objednateli uložena povinnost k zveřejnění příslušných informací.

  5. Ukončení účinnosti této Smlouvy z jakéhokoliv důvodu se nedotkne ustanovení tohoto článku a jeho účinnost přetrvá i po ukončení účinnosti této Smlouvy.

  6. Poskytovatel je srozuměn s tím, že objednatel uveřejní dle § 219 odst. 1 zákona č. 134/2016 Sb., o zadávání veřejných zakázek (dále jen “ZZVZ“) na svém profilu, který se nachází na internetové adrese xxxxx://xxxxxxx.xxxxx.xx/xxxxxxx_xxxxxxx_0.xxxx (dále jen „profil“), tuto Smlouvu včetně všech jejích změn a dodatků. Dále je Poskytovatel srozuměn s tím, že dle § 219 odst. 3 ZZVZ Objednatel uveřejní na profilu výši skutečné uhrazené ceny za plnění veřejné zakázky. Poskytovatel tímto uděluje souhlas objednateli k uveřejnění všech podkladů, údajů a informací uvedených v tomto odstavci a těch, k jejichž uveřejnění je Objednatel povinen dle právních předpisů.

  7. Poskytovatel svým podpisem níže potvrzuje, že souhlasí s tím, aby obraz Smlouvy včetně jejích příloh a případných dodatků a metadata k této Smlouvě byla uveřejněna v registru smluv v souladu se zákonem č. 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ů (zákon o registru smluv). Smluvní strany se dohodly, že podklady dle předchozí věty odešle za účelem jejich uveřejnění správci registru smluv Objednatel; tím není dotčeno právo Poskytovatele k jejich odeslání

  8. Poskytovatel tímto uděluje souhlas Objednateli k uveřejnění všech podkladů, údajů a informací uvedených v tomto odstavci a těch, k jejichž uveřejnění vyplývá pro Objednatele povinnost dle právních předpisů.

XII. Odpovědnost smluvních stran

  1. V případě, že v rámci plnění dle této Smlouvy dojde za strany Poskytovatele k provedení díla, odpovídá Poskytovatel za toto provedení v rozsahu stanoveném platnými právními předpisy. V případě, že v rámci plnění dle této Smlouvy dojde za strany Poskytovatele k provedení díla, poskytuje Poskytovatel Objednateli záruku za jakost tohoto díla v délce 6 měsíců, není-li výrobcem poskytována na některou z použitých součástí záruka delší; v takovém případě se na tuto součást použije záruka v délce poskytované výrobcem.

  2. Poskytovatel se zavazuje odstranit veškerá data uložená na technických prostředcích využívaných k poskytování Služby VULN při ukončení platnosti této Smlouvy, a to za dozoru zástupce Objednatele.

  3. Poskytovatel se zavazuje zachovávat mlčenlivost a důvěrnost dat uložených na technických prostředcích využívaných k poskytování Služby VULN, především data týkající se zranitelnosti systémů objednatele a dále se zavazuje, že jakákoli data Objednatele, která by i neúmyslně získal při poskytování Služby VULN, nebudou zneužita a poskytnuta třetím osobám. V takovém případě se Poskytovatel zavazuje informovat Objednatele o těchto zjištěních.

  4. Každá ze stran nese odpovědnost za způsobenou škodu v rámci platných právních předpisů a této Smlouvy. Obě strany se zavazují k vyvinutí maximálního úsilí k předcházení škodám a k minimalizaci vzniklých škod.

  5. Žádná ze smluvních stran není odpovědná za škodu a není ani v prodlení, pokud k tomuto došlo v důsledku prodlení s plněním závazků druhé smluvní strany nebo v důsledku okolností vylučujících odpovědnost ve smyslu § 2913 odst. 2 občanského zákoníku.

  6. Smluvní strany se zavazují upozornit druhou smluvní stranu bez zbytečného odkladu na vzniklé okolnosti vylučující odpovědnost bránící řádnému plnění této Smlouvy. Smluvní strany se zavazují k vyvinutí maximálního úsilí k odvrácení a překonání okolností vylučujících odpovědnost.

  7. Poskytovatel se zavazuje uhradit veškeré škody, které Objednateli vzniknou v důsledku porušení povinnosti Poskytovatele dle této Smlouvy.

  8. Poskytovatel se dále zavazuje udržovat v platnosti a účinnosti po celou dobu poskytování plnění na základě této Smlouvy pojistnou smlouvu, jejímž předmětem je pojištění odpovědnosti za škodu způsobenou Poskytovatelem třetí osobě (Objednateli), a to tak, že limit pojistného plnění vyplývající z pojistné smlouvy, nesmí být nižší než 1.000.000,- Kč (slovy: jeden milion korun českých) za rok. Na požádání Objednatele kdykoli během účinnosti této Smlouvy je Poskytovatel povinen Objednateli takovou smlouvu do tří pracovních dnů předložit.



XIII.

Rozhodné právo

  1. Tato smlouva se řídí českým právem, a to zejména občanským zákoníkem a příslušnými právními předpisy souvisejícími, a zákonem č. 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ů.

  2. Smluvní strany se zavazují vyvinout maximální úsilí k odstranění vzájemných sporů vzniklých na základě této Smlouvy nebo v souvislosti s touto Smlouvou, včetně sporů o její výklad či platnost a usilovat o jejich vyřešení nejprve smírně prostřednictvím jednání oprávněných osob nebo pověřených zástupců. Tím není dotčeno právo smluvních stran obrátit se ve věci na příslušný obecný soud České republiky.

  3. Veškeré spory vyplývající z této Smlouvy budou řešeny soudy České republiky, přičemž v případě, že Poskytovatel má sídlo/bydliště mimo území České republiky (spory s mezinárodním prvkem), bude věcně a místně příslušným soudem vždy soud určený podle sídla Objednatele.



XIV.

Závěrečná ustanovení

  1. Tato Xxxxxxx nabývá platnosti dnem jejího podpisu oběma smluvními stranami. Smlouva nabývá účinnosti dnem 1. 1. 2018. Pokud nebude Smlouva do 1. 1. 2018 uveřejněna v registru smluv, nabývá Smlouva účinnosti 1. dne měsíce následujícího poté, co byla Smlouva uveřejněna v registru smluv. Xxxxxxx se uzavírá na dobu 48 měsíců běžící ode dne její účinnosti, včetně dne nabytí účinnosti.

  2. Objednatel má právo od této Smlouvy písemně odstoupit z důvodu jejího podstatného porušení Poskytovatelem, přičemž za podstatné porušení Smlouvy se považuje zejména, nikoli však výlučně:

  1. prodlení Poskytovatele s poskytováním plnění dle této Smlouvy po dobu delší než 15 dnů, pokud není příslušná část plnění, s níž je Poskytovatel v prodlení, Poskytovatelem splněna ani v dodatečné lhůtě poskytnuté Objednatelem, která nebude kratší než 10 dnů od doručení písemné výzvy Objednatele k jejímu splnění, a dále

  2. porušení jakékoli jiné povinnosti Poskytovatele vyplývající z této Smlouvy, které Poskytovatelem nebylo napraveno ani v dodatečné lhůtě poskytnuté Objednatelem, která nebude kratší než 10 dnů od doručení písemné výzvy Objednatele k odstranění takovéhoto porušení Poskytovatele.

  1. Odstoupení od této Xxxxxxx je účinné následujícím dnem po doručení písemného oznámení o odstoupení Poskytovateli.

  2. Smluvní strany se dohodly, že v případě odstoupení od této Smlouvy má Poskytovatel za podmínek Smlouvou stanovených nárok na zaplacení ceny za řádně a včas již poskytnuté plnění Objednateli.

  3. Objednatel je oprávněn tuto Smlouvu písemně vypovědět bez udání důvodů, a to s výpovědní dobou jednoho (1) měsíce ode dne doručení písemné výpovědi Poskytovateli, a to bez jakýchkoliv sankcí.

  4. Ukončením účinnosti této Smlouvy z jakéhokoli důvodu nejsou dotčena ustanovení Smlouvy týkající se udělené licence či podlicence ze strany Poskytovatele Objednateli a ostatních práv a nároků Objednatele vyplývajících z čl. IX. Smlouvy, nároků z odpovědnosti za škodu a nároků ze smluvních pokut, ustanovení o ochraně informací, ani další ustanovení a nároky, z jejichž povahy vyplývá, že mají trvat i po zániku účinnosti Smlouvy.

  5. Poskytovatel je podle ustanovení § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů, ve znění pozdějších předpisů (zákon o finanční kontrole) osobou povinnou spolupůsobit při výkonu finanční kontroly prováděné v souvislosti s úhradou zboží nebo služeb z veřejných výdajů.

  6. Poskytovatel se při plnění zavazuje dodržovat zásady bezpečnosti informací v souladu se zákonem č. 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ů, a vyhláškou č. 316/2014 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních a o stanovení náležitostí podání v oblasti kybernetické bezpečnosti (vyhláška o kybernetické bezpečnosti).

  7. Poskytovatel se zavazuje poskytnout Objednateli veškerou součinnost nezbytnou k tomu, aby Objednatel řádně naplňoval právní povinnosti stanovené zákonem o kybernetické bezpečnosti, vyhláškou o kybernetické bezpečnosti, vyhláškou č. 317/2014 Sb., o významných informačních systémech a jejich určujících kritériích, ve znění pozdějších předpisů. Zejména se Poskytovatel zavazuje poskytnout Objednateli součinnost směřující k zavedení a provádění bezpečnostních opatření podle uvedených právních předpisů.

  8. Započtení na pohledávky vůči Objednateli vzniklé z této Smlouvy se nepřipouští.

  9. Práva Objednatele vyplývající z této Smlouvy či jejího porušení se promlčují ve lhůtě 15 let ode dne, kdy právo mohlo být uplatněno poprvé.

  10. Poskytovatel přebírá podle § 1765 občanského zákoníku riziko změny okolností, zejména v souvislosti s cenou za poskytnuté plnění, požadavky na poskytování Služeb a podmínkami SLA.

  11. Tato Xxxxxxx představuje úplnou dohodu smluvních stran o předmětu této Xxxxxxx a nahrazuje veškerá předešlá ujednání smluvních stran ústní i písemná.

  12. Jakékoliv změny Smlouvy je možné činit výhradně formou písemných vzestupně číslovaných dodatků ke Smlouvě podepsaných oběma smluvními stranami.


  1. Smlouva je vyhotovena ve 4 stejnopisech, z nichž každá strana obdrží 2 stejnopisy. Nedílnou součást Smlouvy tvoří následující přílohy:

Příloha č. 1:

Specifikace katalogových listů

Příloha č. 2:

Místo plnění

Příloha č. 3:

Cena plnění

Příloha č. 4:

Popis technického řešení

Příloha č. 5:

Technická specifikace












Smluvní strany prohlašují, že si tuto Smlouvu přečetly, že s jejím obsahem souhlasí a na důkaz toho k ní připojují svoje podpisy.


Objednatel



V _____________ dne _____________

Poskytovatel



V _____________ dne _____________

.........................................................................

Česká republika – Ministerstvo zemědělství

Xx. Xxxxx Xxxxxx

ředitel odboru informačních a komunikačních technologií

.........................................................................

"[DOPLNÍ ÚČASTNÍK]"

"[DOPLNÍ ÚČASTNÍK]"



Příloha č. 1

Specifikace katalogových listů











Specifikace katalogových listů











Systém pro správu zranitelností











  1. Přehled základních pojmů

Termín

Význam

Celková měsíční cena

Součet paušálních měsíčních cen za katalogové listy, u kterých je placena paušální měsíční cena

Člověkoden

Představuje 8 hodin práce jednoho pracovníka

Helpdesk

Specializované oddělení Objednatele zajišťující komplexně uživatelskou podporu

ITSM

IT service management – řízení úrovně poskytovaných Služeb především, nikoliv však výhradně, v rozsahu doporučeném ITIL

KL

katalogový list

KPI

výkonnostní parametr, hodnotící parametr Služby

Maintenance

Služby a aktivity, poskytované výrobcem Systému nebo jeho komponent, potřebné pro udržení Systému v provozuschopném stavu v souladu s dohodnutými parametry a zajišťující kompatibilitu Systému s komponentami ICT Objednatele.

VULN

VULNerability Management – Správa zranitelností, zkratka použitá pro název služby

Objednatel, Zadavatel

osoba, která je jako Objednatel definovaná v záhlaví Xxxxxxx

Obnovení služby (fix time)

Je časová lhůta, ve které je Zhotovitel/Dodavatel povinen realizovat požadovanou činnost nebo obnovit parametry Služby, resp. Systému, na sjednanou úroveň s tím, že doba obnovení parametrů Služby, resp. Systému, je počítána od vzniku původního požadavku bez ohledu na změnu priority požadavku

Odezva (response time)

Je časová lhůta, ve které je Zhotovitel/Dodavatel povinen odpovědět na požadavek předaný prostřednictvím Service Desku Objednatele, a to buď odmítnutím, nebo přijetím požadavku

Pracovní den

každý den mimo sobot, neděl a státních svátků a ostatních svátků dle zákona č. 245/2000 Sb., o státních svátcích, o významných dnech a o dnech pracovního klidu, ve znění pozdějších právních předpisů

Pracovní doba nebo Kalendář

doba, kdy je Služba poskytována – od-do, které dny v týdnu, počet hodin pro potřeby výpočtu dostupnosti:

10x5 – Pracovní dny od 8:00 do 18:00 hodin

8x5 – Pracovní dny od 8:00 do 16:00 hodin

Provozní deník

dokumentace provozu služby způsobem předepsaným ve smlouvě

Rozhraní Systému

integrační a komunikační rozhraní Systému prezentované vnějším rozhraním hraničního (posledního) aktivního síťového prvku pod správou Zhotovitele/Dodavatele, tvořícího rozhraní mezi sítí Zhotovitele/Dodavatele a vnější komunikační infrastrukturou

Service Desk (SD)

Nástroj pro podporu řízení služeb

Servisní okno

časový interval definovaný Objednatelem a zakotvený v dokumentaci

SLA

sjednaná úroveň poskytované Služby

Služba/y

Služba/y podpory definovaná v jednotlivých KL

Smlouva

Smlouva na Systém pro správu zranitelností uzavřená mezi Objednatelem a Zhotovitelem/Dodavatelem

SW

software, aplikace – program, programové vybavení nebo jeho komponenta

Standardní SW (SSW)

softwarové vybavení třetích stran dodané v rámci Smlouvy, na základě kterého byl zhotoven Systém, které nebylo vyvinuto Zhotovitelem/Dodavatelem a není aplikační SW komponentou Systému vyvinutou v rámci Smlouvy

Systém

Systém pro podporu Služby VULN kombinace HW a SW poskytující platformu pro vykonávání Služby VULN

Poskytovatel/Zhotovitel/Dodavatel

osoba, která je jako Poskytovatel/Zhotovitel/Dodavatel definovaná v záhlaví Smlouvy







  1. Podmínky poskytování služeb Systému

    1. Obecné podmínky

Dodavatel je povinen bezplatně poskytnout součinnost pro Objednatele související s odbornými, zákonnými a jinými kontrolami a audity, které mohou být uplatňovány vůči Objednateli v souvislosti s dodávkou služeb a Systémem jako takovým.

Veškeré výkazy, podklady a dokumenty musí být ve formě, umožňující přezkoumatelnost a auditovatelnost ze strany kontrolních organizací, kterými se rozumí veškeré subjekty oprávněné provádět kontrolu jakkoliv týkající se plnění této Smlouvy na základě právního předpisu. Pokud je dokument, výkaz nebo jiný podklad, související s tímto dokumentem zpochybněn kontrolní organizací, je Dodavatel povinen poskytnout podklady, které budou kontrolním orgánem akceptovány. V případě, že Dodavatel nebude schopen tyto podklady dodat a/nebo tyto nebudou kontrolním orgánem akceptovány a pokud absence těchto dokumentů bude důvodem k udělení sankce vůči Objednateli, Dodavatel poskytne náhradu ve výši sankce, uplatněné vůči Objednateli, a to i po uplynutí účinnosti této Smlouvy, pokud se sankce bude týkat období trvání Smlouvy.

Dodavatel je před zahájením dodávky Služby Objednateli povinen dodat písemný seznam komponent Systému, které kategorizuje jako standardní software, krabicový software případně software třetích stran a takto označit i odpovídající položky konfigurační databáze Objednatele.

Všechny úpravy, funkcionality, programové kódy, konfigurace apod., které Dodavatel neoznačí jako standardní software a/nebo které vznikly v průběhu platnosti Smlouvy, jsou považovány za vlastnost Systému, kterou může Objednatel kdykoliv na základě vlastního uvážení využít v jiných informačních systémech a libovolně upravovat bez jakýchkoliv licenčních závazků vůči Dodavateli nebo třetím stranám. Tím nejsou dotčena práva Objednatele ani povinnosti Dodavatele dle Xxxxxxx.

Pokud je zjištěno podávání nepravdivých dat a výkazů Dodavatelem, je celé měřicí období, ve kterém bylo toto zjištěno, považováno za nesplněné ve všech parametrech, u kterých bylo toto pochybení zjištěno. Vyplývající slevy jsou aplikovány na každý parametr zvlášť v maximálním rozsahu stanoveném touto Smlouvou.

Dodavatel je povinen se řídit zákonnými, technickými a jinými požadavky, pravidly a doporučeními, souvisejícími se zajišťovanými službami, spravovanou nebo využívanou infrastrukturou a využívanými nebo poskytovanými službami, které nejsou předmětem tohoto dokumentu.

Ústní jednání v souvislosti s předmětem dodávky / plnění definovaným Smlouvou nemá povahu jakéhokoliv závazku.

    1. Dokumentace

Veškerá infrastruktura, která je předmětem dodávky Služeb a Služba samotná bude dokumentována. Dodavatel zajistí aktualizaci při každé změně, provedené Dodavatelem. Pokud dokumentace neexistuje, Dodavatel ji v potřebném rozsahu vytvoří. Dokumenty dokumentace mají v úvodní sekci seznam změn, ve kterém jsou stručně shrnuty změny provedené od předchozího vydání dokumentace. Dokumentace zahrnuje zejména, nikoliv však výhradně následující položky:

  • Instalační dokumentace

    • Popis architektury;

    • Komunikační matice komponent;

    • Instalované verze;

    • Licence;

    • Instalační postup;

  • Implementační dokumentace

    • Popis nastavení komponent VULN řešení;

    • Popis konfigurace zálohování VULN řešení;

    • Popis nastavení integrace se systémem SIEM

    • Popis nastavení integrace se systémem PIM

    • Popis nastavení konfigurace Provozního monitoringu

  • Uživatelská příručka

    • Popis uživatelského rozhraní VULN řešení z pohledu uživatele;

    • Popis uživatelských postupů při práci s VULN řešením;

  • Zajištění kontinuity provozu

    • Popis postupu obnovy ze zálohy;

    • Doporučení pro archivaci (datové komunikace po překročení onsite limitu);

    • Popis postupu v případě havárie jednotlivých komponent včetně postupu obnovy do provozního stavu;

    • Popis postupu vypnutí a opětovného zapnutí systému;



      1. Provozní deník

Dodavatel je povinen při poskytování Služeb dle tohoto KL vést Provozní deník. Provozní deník bude veden jeden pro celý Systém.

Dodavatel je povinen do Provozního deníku prostřednictvím záznamu zaznamenat minimálně následující události a to nejdéle do 4 hodin od provedení změny:

  • Provedení úkonů předepsaných v KL včetně identifikace příslušného KL;

  • Havarijní stavy, opravy, výměny komponent;

  • Anomálie a nestandardní stavy systémů, které mají dopad na plnění SLA;

  • Zprovoznění nového nebo dočasně odstaveného systému a/nebo odstavení systému;

  • Spuštění, vypnutí a restart systému;

  • Obnovení ze zálohy.

Každý záznam bude obsahovat minimálně následující informace:

  • Datum a čas pořízení záznamu;

  • Identifikace osoby pořizující záznam;

  • V případě událostí trvajících více než 1 hodinu také čas začátku a konce události;

  • Popis události.

  • Provedené úkony k události s uvedenými časy provedení

  • Zdůvodnění, na základě jakého požadavku byla činnost vykonána (např. ID záznamu v Service Desku Objednatele, číslo Smlouvy a příslušný KL).

Pro vyloučení pochybností se uvádí, že Provozní deník není systémovou dokumentací. Při realizaci změny se do Provozního deníku zapisuje, že byla provedena změna a její stručný popis. Popis změny, resp. nově vzniklý stav a konfigurace systému jsou detailně popisovány v systémové dokumentaci. Pro vyloučení pochybností se uvádí, že změnou se myslí jakákoliv změna ve smyslu „Change management“ podle ITIL.

Způsob vedení Provozního deníku je předepsán. Dodavatel je povinen vést Provozní deník v elektronické podobě, v systému Objednatele, určenému k vedení provozních deníků. Za tímto účelem poskytne Objednavatel přístup do tohoto systému. V případě nedostupnosti systému k vedení provozních deníků Objednavatele, vede Dodavatel deník předepsaným způsobem ve vlastní formě, na vyžádání nebo po obnovení dostupnosti systému je povinen jej předložit v elektronické, editovatelné formě, tak aby bylo možné záznamy strojově zpracovat.

Objednatel připouští vedení jednotného Provozního deníku pro všechny KL. V takovém případě každý záznam obsahuje také identifikaci KL, ke kterému se vztahuje.

    1. Změny v Systému provedené Objednatelem

Objednatel je oprávněn provádět změny (administrovat) v Systému pomocí standardního rozhraní Systému (např. přidávat/odebírat uživatele, přidávat/odebírat koncové body a skeny, konfigurovat Systém a operační systémy na kterých je Systémem provozován, zálohovat Systém, apod.) do míry, na kterou je Systém Dodavatelem nadimenzován na základě informací uvedených v Technické specifikaci. Tyto změny nijak neovlivní povinnosti Dodavatele dané katalogovými listy.

V případě jiných změn (např. instalace potřebného SW mimo Systém do infrastruktury Objednatele) realizovaných za účinnosti Smlouvy je Objednatel povinen nechat si takovouto změnu schválit Dodavatelem, který tak vyhodnotí dopady na funkčnost Systému. V případě neakceptace změny Dodavatelem, musí Dodavatel navrhnout jiné řešení, které bude mít na Systém stejný účinek. Provedení změn Objednatelem podle postupu schváleného Dodavatelem nezbavuje Xxxxxxxxxx povinností ze zajištění parametrů služeb definovaných v KL.

  1. Sleva z ceny a smluvní pokuty

Slevy z ceny za nedodržení celkové dostupnosti a za nedodržení Služby Obnova, vzniklé v souvislosti se stejným incidentem lze kumulovat.

Dodavatel není v prodlení s plněním povinnosti, na jejíž porušení se sleva z ceny nebo smluvní pokuta vztahuje, a to po dobu, pro kterou prokáže, že za porušení povinnosti Dodavatel neodpovídá (např. prokázána příčina ležící mimo Systém).

Uplatnění slevy z ceny nebo smluvní pokuty nemá vliv na povinnost poskytování Služeb ve sjednaných úrovních. Nárok na slevu z ceny Služeb nebo smluvní pokutu se nedotýká závazku Dodavatele splnit povinnost, se kterou je v prodlení (pokud je to vzhledem k povaze předmětné Služby objektivně možné).

Objednatel má právo v případě porušení parametrů definovaných katalogovými listy na slevy z ceny a na smluvní pokuty ve výši stanovené v jednotlivých katalogových listech.

    1. Uplatnění slevy z ceny služeb a možnost odstoupení od Xxxxxxx

Součet všech poskytnutých slev z ceny Služeb v daném měsíci se odečte od Celkové měsíční ceny všech poskytnutých Služeb za daný měsíc. Dodavatel má za daný měsíc nárok na zaplacení ceny za poskytnuté Služby pouze ve výši takto vypočteného rozdílu.

V případě, že součet všech poskytnutých slev z ceny poskytnutých Služeb v daném měsíci je vyšší než Celková měsíční cena poskytnutých Služeb za daný měsíc, bude neuplatněný nárok na slevu z ceny Služeb uplatněn v dalším měsíci.

V případě, že výše neuplatněné slevy z ceny Služeb převýší součet cen Služeb za následující měsíce až do konce trvání Smlouvy, je Objednatel oprávněn od Smlouvy odstoupit. Objednatel je současně oprávněn před odstoupením od Xxxxxxx vyúčtovat Dodavateli částku odpovídající výši neuplatněné slevy z ceny Služeb jako smluvní pokutu.

Odstoupení od smlouvy nemá vliv na výši uplatněné slevy ani smluvní pokutu.

  1. Vyhodnocování kvality poskytovaných služeb

    1. Měření Služeb

Objednatel bude provádět dostupnými prostředky kontrolu provádění činností dle katalogového listu. Pokud Objednatel identifikuje, že dotčená činnost nebyla vykonána nebo byla vykonána v rozporu s požadavky vyplývajícími ze Smlouvy, zaznamená tuto skutečnost do Service Desku Objednatele prostřednictvím přidělení incidentu Dodavateli. Pro katalogové listy kde je vyžadován report o plnění KPI, předkládá Dodavatel tento měsíční report, který musí obsahovat minimálně tyto položky:

Označení KL (katalogového listu); hodnota KPI/Priorita; popis úkonu; čas nahlášení incidentu; čas vyřešení incidentu; délka řešení požadavku v H; procento splnění SLA; počet incidentů dle KL sumárně; číslo ticketu v servisdesku Objednatele; jméno řešitele.

    1. Kategorie provozních stavů

Jsou definované následující kategorie provozních stavů:

Standardní provoz

Provoz na provozním nebo testovacím prostředí je bez omezení, Systém je plně funkční.

Servisní okno

Objednatelem předem definovaný a oznámený časový interval na provozním nebo testovacím prostředí, ve kterém může dojít ke snížení nebo omezení funkčnosti Systému nebo některé z jeho částí. Po jeho dobu Objednatel neuplatňuje slevy z ceny. O vyhlášení Servisního okna rozhoduje Objednatel.

    1. Stanovení priorit incidentů a požadavků a jejich SLA

Priority incidentů a požadavků stanovuje Objednatel.

      1. Priority pro provozní prostředí

Je-li tak definováno v příslušném KL, platí priority uvedené níže. Pro definici priority požadavků dle KL VULN01 a VULN02 se uplatní pravidla uvedená v předmětném KL, přičemž se uplatní parametry řešení požadavků uvedené v tabulce č 1. Priority pro provozní prostředí, a to v Prioritě definované pro vybranou oblast služby.



Tabulka 1 Priority pro provozní prostředí

Priorita

Definice priority požadavku

Parametry řešení požadavku

Priorita 1

Kritická

Některé nebo všechny části VULN řešení selhaly a jsou zcela nefunkční nebo je jejich funkčnost omezena tak, že je kritickým způsobem ovlivněna činnost VULN řešení.

Odezva: 4 hodiny

Obnovení služby: 1 pracovní den

Priorita 2

Vysoká

VULN řešení je funkční pouze částečně, VULN řešení je ovlivněno selháním nebo omezením některé z komponent nebo funkcí podporujících důležité činnosti VULN řešení.

Odezva: 8 hodin

Obnovení služby: 2 pracovní dny

Priorita 3

Střední

VULN řešení je funkční, závada nemá vliv na činnost VULN řešení. Vyskytují se nedostatky nepodstatné povahy, které způsobují například nekomfortnost obsluhy nebo zvyšující pracnost činností než v běžném provozu.

Odezva: 1 pracovní den

Obnovení služby: 3 pracovní dny

Priorita 4

Nízká

Bezpečnostní hrozba, která má dopad na VULN řešení

Odezva: 2 pracovní dny

Obnovení služby: 5 pracovních dnů

Priorita 5

Ostatní

Požadavkem je žádost o podání informace (dotaz, vysvětlení) nebo existence aktualizace či záplaty Systému.

Priorita požadavku zároveň zahrnuje situace, kdy některé funkce prokazatelně selhaly, ale nejsou v daný moment využívány nebo nemají žádný vliv na řádný chod Systému, za předpokladu, že řešení požadavku závisí na součinnosti třetí strany mimo vliv Dodavatele.

Odezva: 3 pracovní dny

Obnovení služby: 15 pracovních dnů

      1. Priority pro provoz Služby

Je-li tak definováno v příslušném KL, platí priority uvedené níže. Pro definici priority požadavků dle KL VULN01 a VULN02 se uplatní pravidla uvedená v předmětném KL, přičemž se uplatní parametry řešení požadavků uvedené v tabulce č 2. Priority pro provoz Služby, a to v Prioritě definované pro vybranou oblast Služby.

Tabulka 2 - Priority pro provoz Služby

Priorita

Definice priority požadavku

Parametry řešení požadavku

Priorita 1

Kritická

Byla zjištěna kritická zranitelnost nebo miskonfigurace koncového zařízení, u které hrozí s vysokou mírou pravděpodobnosti bezprostřední zneužití.

Reakce: ihned nebo nejpozději do 8 hodin.

Priorita 2

Vysoká

Pravidelná kontrola zranitelností a shody konfigurace systémem.

Reakce: 1 pracovní den

Priorita 3

Ostatní

Pravidelný reporting stavu zranitelností s doporučením.

Reakce: 10 pracovních dní





  1. Seznam katalogových listů

    1. VULN01 Odezva

Katalogový list Služby

Identifikace (ID)

VULN01

Název Služby

Odezva

Popis Služby

Zajištění odezvy technického řešení pro podporu Služby VULN.

Parametry

Název

KPI01 Odezva

Definice

Zajištění dostupnosti technického řešení pro podporu Služby

  • Obnovení funkcí VULN řešení či některé z jeho komponent podle priorit definovaných v 4.3.1 Priority pro provozní prostředí;

Parametry KPI

Kalendář Služby

8x5

Odezva

Viz 4.3.1 Priority pro provozní prostředí

Obnovení Služby

Viz 4.3.1 Priority pro provozní prostředí

Definice parametrů

Odezva Systému je definována následovně:

  1. Je možné se úspěšně přihlásit do všech komponent Systému.

    • Funkce přihlášení se do Systému se považuje za dostupnou, pokud se uživateli zobrazí kompletní uživatelské rozhraní Systému (dále jen „Odezva systému na přihlášení“) do 5 vteřin od potvrzení přihlašovacích údajů, kde tato doba zahrnuje pouze zpoždění zapříčiněné Systémem;

    • Pokud je Odezva Systému na přihlášení v intervalu od 5 do 10 vteřin, kde tato doba zahrnuje pouze zpoždění zapříčiněné Systémem, je tento stav považován za závadu v úrovni Priority 3;

    • Pokud je Odezva Systému na přihlášení delší než 10 vteřin, kde tato doba zahrnuje pouze zpoždění zapříčiněné Systémem, nebo pokud se není možné do Systému přihlásit, je tento stav považován za závadu v úrovni Priority 1;

  2. Po přihlášení do Systému jsou uživateli k dispozici všechny jemu přiřazené funkce/zdroje/role/účty/nástroje;

    • Pokud má uživatel po úspěšném přihlášení k dispozici pouze některé nikoliv všechny jemu přiřazené funkce/zdroje/role/účty/nástroje, jedná se o závadu v úrovni Priority 2;

    • Pokud uživatel nemá po úspěšném přihlášení k dispozici žádné jemu přiřazené funkce/zdroje/role/účty, jedná se o závadu v úrovni Priority 1;

  3. Funkce „management dashboard“ poskytuje přehled událostí na centrálním prvku řešení určenému ke správě a řízení systému.;

    • Funkce „management dashboard“ se považuje za dostupnou, pokud Systém poskytuje přehled posledních událostí zachycených systémem a dalších přehledů definovaných při implementaci, ne starších než je definováno dále po obnovení/znovunačtení příslušných apletů za předpokladu, že reálně probíhá síťová komunikace a to i v částech sítě ze kterých je sběr realizován. (dále jen „Odezva management dashboard“), kde tato doba zahrnuje pouze zpoždění zapříčiněné Systémem;

    • Pokud je Odezva management dashboard v intervalu od 10 do 30 minut, kde tato doba zahrnuje pouze zpoždění zapříčiněné Systémem, je tento stav považován za závadu v úrovni Priority 3;

    • Pokud je Odezva management dashboard delší než 30 min, kde tato doba zahrnuje pouze zpoždění zapříčiněné Systémem, je tento stav považován za závadu v úrovni Priority 2;

    • Pokud je Odezva management dashboard delší než 60 min, kde tato doba zahrnuje pouze zpoždění zapříčiněné Systémem, je tento stav považován za závadu v úrovni Priority 1;

  4. Funkce sledování zranitelností je funkční pro všechny dostupné dohlížené zdroje;

    • Funkce „sledování zranitelností“ se považuje za dostupnou, pokud Systém poskytuje aktuální statistiky o stavu zranitelností, počty skenovaných zdrojů, nalezené zranitelnosti, scoring, počty realizovaných autentizovaných skenů a dalších přehledů definovaných při implementaci, ne starších než je definováno dále po obnovení/znovunačtení příslušných apletů za předpokladu, že se jedná o sledované zdroje ve stavu standardního provozu (dále jen „Odezva dohledu zranitelností“), kde tato doba zahrnuje pouze zpoždění zapříčiněné Systémem;

    • Pokud je Odezva dohledu zranitelností v intervalu od 10 do 30 minut, kde tato doba zahrnuje pouze zpoždění zapříčiněné Systémem, je tento stav považován za závadu v úrovni Priority 3;

    • Pokud je Odezva dohledu zranitelností delší než 30 min, kde tato doba zahrnuje pouze zpoždění zapříčiněné Systémem, je tento stav považován za závadu v úrovni Priority 2;

    • Pokud je Odezva dohledu zranitelností delší než 60 min, kde tato doba zahrnuje pouze zpoždění zapříčiněné Systémem, je tento stav považován za závadu v úrovni Priority 1;

  5. Systém nemá zaznamenatelný vliv na odezvy činností realizovaných v rámci probíhající uživatelské relace;

    • Pokud je vliv Systému na odezvu činnosti realizované v rámci probíhající uživatelské relace zaznamenatelný (pomalé překreslování oken, zpoždění uživatelských vstupů, apod.), jedná se o závadu Priority 2;

  6. Systém provádí autentizované skeny koncových zařízení pomocí definovaného technického účtu;

    • Funkce autentizovaného skenu se považuje za dostupnou, pokud je prokazatelně zaznamenáno v logu koncového zařízení, že byl realizován přístup na toto zařízení definovaným technickým účtem v době probíhajícího skenu. Je vygenerován záznam s odpovídající informací obsahující požadované záznamy o zranitelnosti;

    • Funkce autentizovaného skenu se považuje za dostupnou, pokud systém využije pro autentizaci technický účet definovaný v konfiguraci nástroje nebo dostupný přes integraci s řešením PIM.

    • V opačném případě se jedná o závadu Priority 1;

  7. Systém audituje jak veškeré operace uživatelů, administrátorů v rámci Systému, tak i interní operace Systému samotného;

    • Funkce auditování operací se považuje za dostupnou, pokud je auditní záznam o operaci v Systému zaznamenán a zároveň dostupný ke kontrole do 5 vteřin po provedení příslušné činnosti, kde tato doba zahrnuje pouze zpoždění zapříčiněné Systémem;

    • V opačném případě se jedná o závadu Priority 3;

  8. Systém generuje reporty;

    • Funkce generování reportů se považuje za dostupnou, pokud reporty zobrazují kompletní data Systému a výstup reportu je k dispozici za adekvátní dobu s ohledem na složitost reportu;

    • V opačném případě se jedná o závadu Priority 3;

  9. Funkční HW.

  • Za funkční HW se považuje funkčnost všech HW komponent daného zařízení s dopadem i bez dopadu na funkčnost řešení jako celku. Částečné nebo celkové selhání se považuje za závadu, která musí být řešena v rámci Priority 2

Způsob výpočtu a měření

Jako směrodatné a závazné pro Dodavatele se pro měření uvedených parametrů odezvy Systému berou hodnoty naměřené dohledovým systémem Objednatele. V případné zjištění nedostupnosti, nefunkčnosti či omezení funkce Systému je tento stav zaznamenán do Service Desku Objednatele. Pracovníci Helpdesku Objednatele následně kontaktují kanálem, definovaným Smlouvou (email, telefon, Service Desk Objednatele), technickou podporu Dodavatele a o tomto kontaktování provedou záznam do tiketu v Service Desku Objednatele jako počátek nedostupnosti Služby.

Měřicí bod

Service Desk Objednatele.

Způsob dokladování

Měsíční report o plnění KPI.

Sleva z ceny

Jednorázová sleva z ceny ve výši 10.000,- Kč v případě porušení dohodnuté doby pro Obnovení služby viz tabulka Priorit v kapitole viz 4.3.1 Priority pro provozní prostředí a zároveň další sleva z ceny ve výši 2500 Kč za každou započatou hodinu nad dohodnutou dobu pro Obnovení služby viz tabulka Priorit v kapitole 4.3.1 Priority pro provozní prostředí. Tímto ujednáním není dotčen nárok na smluvní pokutu uvedený v článku X. Smluvní pokuty a sankce odst. 2, Smlouvy

Doplňující informace

Poznámka

-

Platební podmínky

Paušální měsíční cena podle Xxxxxxx.


    1. VULN02 Správa

Katalogový list Služby

Identifikace (ID)

VULN02

Název Služby

Správa zranitelností.

Popis Služby

Zajištění managementu zranitelností na koncových systémech Objednatele pomocí VULN řešení a další provozní činnosti.

Parametry

Název

KPI02 Správa VULN

Definice

Zajištění managementu zranitelností zahrnuje především, nikoliv však výhradně, následující činnosti:

  1. Generování výsledků, reportů a alertů, týkajících se zranitelnosti a shody nastavení informačního prostředí Objednatele

  2. Identifikace aktualizací relevantních k prostředí Objednatele, ověření jejich dopadů v prostředí Objednatele a jejich eskalace;

  3. Provoz a správa všech komponent VULN řešení (HW, SW, OS)

  4. Profylaktické činnosti

  5. Kontrola výkonnosti VULN řešení a návrh preventivních opatření s cílem předejít možným výpadkům, snížení výkonu v infrastruktuře IS Objednatele

  6. Sledování, testování a aplikace schválených aktualizací na Systém VULN

Parametry KPI

Kalendář Služby

8x5

Odezva systému

Viz 4.3.1 Priority pro provozní prostředí

Obnovení systému

Viz 4.3.1 Priority pro provozní prostředí

Reakce Služby

Viz 4.3.1 Priority pro provozní prostředí

Definice parametrů

  • Sledování, identifikace, posouzení dopadů, poskytnutí stanoviska k nasazení a aplikace kritických bezpečnostních aktualizací na koncových systémech. Kritická bezpečnostní aktualizace je aktualizace uvolněná výrobcem řešení pro produkční nasazení, která řeší kritickou bezpečnostní slabinu či zranitelnost řešení;

  • Sledování, identifikace, posouzení dopadů, poskytnutí stanoviska k nasazení a aplikace bezpečnostních aktualizací na koncových systémech. Bezpečnostní aktualizace je aktualizace uvolněná výrobcem řešení pro produkční nasazení, která řeší bezpečnostní slabinu či zranitelnost řešení. Dodavatel předloží nebo poskytne výstupy;

  • Sledování, identifikace, posouzení dopadů, poskytnutí stanoviska ke změně konfigurace na koncových systémech. Změna konfigurace aktualizace systémových nastavení koncového systému pro produkční nasazení, která řeší bezpečnostní slabinu či zranitelnost řešení v důsledku miskonfigurace;

  • Pravidelná kontrola a prohlídka systému VULN, jeho zařízení nebo komponent, vyhodnocení interních logů systému, jeho nastavení a konfigurací, jejich drobné úpravy a opravy, případně čištění a drobná údržba;

  • Sledování performance systému VULN a predikce možné změny jeho výkonových parametrů a možných dopadů do prostředí Objednatele;

  • Sledování, identifikace, posouzení dopadů, poskytnutí stanoviska k nasazení a aplikace aktualizací či záplat Systému VULN;

Způsob výpočtu a měření

Pro položky 1. a 2. uvedené v tomto KL Parametry/Definice platí, že Dodavatel Služby minimálně v intervalech, definovaných v Tabulce 2 - Priority pro provoz Služby, zajistí, aby Služba sledovala, vyhodnocovala dle Priority 2 a upozornila na kritické zranitelnosti dle Priority 1. Dále zajistí dle této tabulky souhrnné nálezy zranitelností dle Priority 3.


Pro položky 3. - 6. uvedené v tomto KL Parametry/Definice platí, že v případě vydání nové aktualizace/opravného balíku/nové verze SW výrobcem řešení VULN založí Dodavatel požadavek do Service Desku Objednatele informující o této skutečnosti. Dodavatel je povinen požadavek založit nejdéle do doby dané jako Odezva pro příslušnou prioritu požadavku, od vydání aktualizace výrobcem (např. zveřejnění na portálu výrobce, informační email výrobce, apod.).  Požadavek může rovněž založit Objednatel, pokud tuto skutečnost zjistí dříve, kdy následně Helpdesk Objednatele informuje o této skutečnosti domluveným kanálem (email, telefon, Sevice Desk Dodavatele) technickou podporu Dodavatele.

Do doby pro Obnovení služby dané prioritou požadavku počítané od okamžiku zveřejnění informace výrobcem musí Dodavatel poskytnout stanovisko pro vhodnost nasazení v prostředí Objednatele s identifikací možných dopadů, definovat způsob nasazení a provést aplikaci aktualizace či záplaty. Položk y 3.- 6. se řídí Prioritou č. 5 dle Tabulky 1 Priority pro provozní prostředí.

Měřící bod

Service Desk Objednatele

Způsob dokladování

Měsíční report o plnění KPI.

Sleva z ceny

1000 Kč za každý den nad dobu pro Obnovení Služby stanovenou prioritou požadavku. Tímto ujednáním není dotčen nárok na smluvní pokutu uvedený v článku X. Smluvní pokuty a sankce odst. 3, Smlouvy

Doplňující informace

Poznámka

-

Platební podmínky

Paušální měsíční cena podle Xxxxxxx.























Příloha č. 2

Místo plnění

Název datového centra

Adresa datového centra

Datové centrum Nagano

K Červenému dvoru 25/3156

130 00, Xxxxx 0 – Xxxxxxxxx

Datové centrum Chodov

V lomech 2339/1,

149 00 Praha 4 – Chodov

Sídlo Objednatele

Těšnov 17,

117 05 Praha 1







Příloha č. 3

Cena plnění

Produkt/služba

Cena v Kč bez DPH

Výše DPH v % a v Kč

Cena v Kč včetně DPH

Služba VULN

(za 1kalendářní měsíc)

[DOPLNÍ ÚČASTNÍK]

[DOPLNÍ ÚČASTNÍK]

[DOPLNÍ ÚČASTNÍK]

CELKOVÁ CENA

Služba VULN

(48 měsíců)

[DOPLNÍ ÚČASTNÍK]

[DOPLNÍ ÚČASTNÍK]

[DOPLNÍ ÚČASTNÍK]**

** (tato cena bude předmětem hodnocení)

Příloha č. 4

Popis technického řešení



Popis technického řešení











Systém pro správu zranitelností



Seznam obrázků



Seznam tabulek



  1. Účel dokumentu

Tento dokument obsahuje specifikaci a technické požadavky na řešení pro správu zranitelností, Ministerstva Zemědělství České republiky. Dokument tvoří přílohu smlouvy, která je součástí zadávací dokumentace veřejné zakázky „Systém pro správu zranitelností“ (dále také VULN řešení) a obsahuje představení požadovaného konceptu řešení, základní popis poptávaného řešení a požadavky závazné pro všechny potenciální uchazeče o zajištění realizace zakázky.

  1. Přehled základních pojmů

Termín

Význam

DB

Databáze

DC

Datové centrum

DNS

(Domain Name System) - hierarchický systém doménových jmen

DRP

Disaster recovery plan

HA

High Availability – režim vysoké dostupnosti (např. redundance)

HW

Hard-Ware, fyzické zařízení

ICT

Informační a komunikační technologie (Information and Communication Technologies)

VULN

Vulnerability Management Systém – Systém pro říení zranitelností

Objednatel/Zadavatel/MZe

Česká republika – Ministerstvo zemědělství

OS

Operační Systém

OSS

Organizační složka státu – organizace podřízená ministerstvu

PIM

Privileged Identity Management – Správa privilegovaných identit

SIEM

Security Information and Event Management - správa bezpečnostních informací a událostí

SLA

Servis Level Agreement – Dohoda o poskytované úrovni služeb

Smlouva

Smlouva na „Systém pro správu zranitelností“

SW

Software

Poskytovatel, Zhotovitel, Dodavatel

Subjekt, který je jako Poskytovatel/Zhotovitel/Dodavatel definován v záhlaví Xxxxxxx

Tabulka 3 - seznam zkratek a pojmů





  1. Aktuální stav

Informační prostředí MZe je tvořeno velkým množstvím informačních systémů a rozlehlou síťovou infrastrukturou, na které je závislý chod celé organizace. Každý z  prvků tohoto prostředí generuje komunikační toky představující výměnu dat různé úrovně s bezpečnostními a provozními dopady. Jednotlivé prvky infrastruktury a aplikační vrstva je zajištěna v oblasti poskytování veřejných služeb s ohledem na možné zranitelnosti smluvně. Zadavatel však nemá možnost sám zjišťovat aktuální stav zranitelností a aplikací patchů a kontrolovat tak úroveň faktické bezpečnosti ani plnění povinností vyplývajících ze smluv v oblasti správy zranitelností a shody nastavení. Monitoring v této oblasti byl řešen jen v interním prostředí, nyní je však již bez podpory. Také nejsou zcela nastaveny interní procesy pro vulnerability management systém s provazbou na nástroj poskytující informace o aktuálním stavu zranitelností a dále pak návazné na change a release management.

  1. Požadovaný stav a motivace

Jednotlivé prvky infrastruktury představují výrazný prvek v oběhovém systému organizace. Jejich narušení a kompromitace představuje výrazné riziko nejen pro instituce státní správy a to především vzhledem k narůstajícímu trendu bezpečnostních rizik vyskytujících se v kybernetickém prostředí. Toto riziko se vztahuje na všechny systémy, počínaje operačními systémy, databázemi, síťovými prvky až po jednotlivé podpůrné aplikace či komplexní informační systémy distribuované jako produkt, nebo vyvinuté na míru a přímo nebo nepřímo se tedy dotýká všech informačních systémů, včetně systémů potenciálně identifikovaných jako „Významný informační systém“ v rámci zákona č. 181/2014 Sb., zákon 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ů, který vychází mimo jiné i z normy ISO/IEC 27001. Jako jedno z opatření je zde doporučeno zavedení řešení pro správu zranitelností.

Zajištění správy zranitelností znamená zajistit jednotlivé související funkcionality, které mají zásadní dopady do oblasti bezpečnosti a provozu infrastruktury MZe. Jde především o tyto oblasti:

1, Sledování zranitelnosti infrastrukturních prvků.

2, Sledování zranitelnosti aplikací.

3, Pravidelný audit konfigurací

4, Získávaní bezpečnostních rekonfiguračních parametrů

5, Podpora pro proces patchování (opravy chyb) a update SW

6, Podpora pro proces rekonfigurací



Předmětem je tedy uskutečnění a naplnění veřejné zakázky s tímto obsahem:

  • realizace technického řešení např. dodávky, instalace, implementace, školení, poskytnutí časově neomezené licence nebo časově vymezené subscripce pro podporu poskytování služby pro správu zranitelností a další práva dle specifikace ve Smlouvě;

  • poskytnutí následné technické podpory výrobce hardware i standardních (generických) softwarových produktů tvořících součást technického řešení pro podporu služby správa zranitelností dle parametrů uvedených ve Smlouvě, zejména v technické specifikaci a v katalogovém listu na dobu 4 let;

  • poskytnutí služby sestávající z následné provozní, technické a metodické podpory dle parametrů uvedených ve Smlouvě, zejména v technické specifikaci a v katalogových listech na dobu 4 let.

  1. Popis požadovaného řešení

Tato kapitola obsahuje popis řešení, které je předmětem zakázky. Účelem kapitoly je poskytnout uchazeči ucelený přehled nad požadovaným řešením, ze kterého vyplývají konkrétní požadavky uvedené v další kapitole, které musí nabízené řešení splňovat.

    1. Celkový popis řešení

Zadavatel požaduje dodání managementu zranitelností formou služby s tím, že poskytovatel umístí technické prostředky nutné pro její realizaci v prostředí objednatele a to v souladu s požadavky definovanými touto smlouvou. Zařízení nepřechází do majetku objednatele na základě této smlouvy. Požadujeme pro technickou podporu služby nasazení centrálního řešení pro tři lokality (dvě datová centra a centrální sídlo MZe – interní prostředí), kdy zdroj informací o zranitelnostech a shody nastavení představují adresovatelné prvky v každém jednom fyzickém centru, přičemž produkční datová centra jsou propojená na L2 a redundantní HA. Celkově se jedná o 800 – 900 IP adres ve třech lokalitách s výhledem rozšiřitelnosti až na 1500 IP adres, přičemž zadavatel požaduje zajištění licencí i pro tuto rezervu s ohledem na rozvoj. Konkrétně by tedy šlo o tři skenovací engine schopné obsloužit počet prvků v uvedeném rozsahu a to jak z vnitřního tak vnějšího perimetru. Služba by měla obsahovat centrální prvek poskytující jednotnou správu a obsluhu celého systému pro správu zranitelností a shody nastavení minimálně dle technické specifikace viz příloha smlouvy.

V rámci služby požadujeme zajištění maintanace, implementace, instalace, školení a provozní podpory při udržitelnosti projektu 4 roky.

Provoz systému musí být naplánován a nastaven tak, aby byl minimalizován dopad do provozu a poskytování jednotlivých služeb a musí být schopen odhalit aktuální zranitelnosti a miskonfigurace na systémech a aplikacích používaných v prostředí zadavatele. Systém též musí být schopen aktualizovat sám sebe a databázi zranitelností.

V logickém schématu níže na úrovni L1, jsou zaneseny jednotlivé lokality, přičemž je nutné poznamenat, že tyto jsou dále členěny na L2 a L3. V hrubém řezu lze vyznačit oddělené DMZ (1 a 2) roztažené přes obě DC a Těšnov.























    1. Schéma



Obrázek 1





































    1. Skenovací engine

Technické řešení pro podporu služby musí obsahovat zařízení nebo systém, který umožnuje detekci zranitelností na vzdáleném ICT zařízení a to pomocí autentizovaného nebo neautentizovaného přístupu. Musí podporovat typy ICT zařízení používané v prostředí zadavatele, tak jak jsou uvedené v technické specifikaci. Scanovací engine by měl prověřovat ICT zařízení zadavatele jak z vnitřního tak i vnějšího perimetru. Mělo by se tedy jednat o tři skenovací zařízení, jedno umístěno v lokalitě Těšnov, druhé v lokalitě DC, třetí mimo vnitřní síťové prostředí zadavatele, tak jak je naznačeno červeně na Obrázku 1. Všechny závazné parametry skenovacích engine jsou uvedeny v příloze smlouvy č.3 Technická specifikace.

    1. Centrální management

Centrální management musí být systém nebo zařízení, určené pro správu a analýzu zranitelností a celého systému. Pomocí centrálního managementu dochází k nastavení systému, plánovaní skenů, provádění analytických činností, filtrování záznamů, změny scoringu, správě uživatelů, aktualizacím, provozováním reportingu, úpravám vizualizace a dashboardů a prezentaci dat o zranitelnostech a compliance konfigurace. Závazné parametry centrálního managementu jsou uvedeny v příloze smlouvy č.5 Technická specifikace.



    1. Ostatní technické požadavky

      1. Bezpečnostní monitoring

Služba VULN musí umožnit logovat veškeré aktivity prováděné administrátory a uživateli nad řešením. Všechny tyto logované záznamy jsou volitelně, v intervalech blízkých reálnému času přenášeny do systému pro bezpečnostní monitoring (SIEM) k jejich vyhodnocení a uložení na centrálním bezpečném místě pro případnou zpětnou analýzu. MZe používá SIEM typu Arcsight výrobce HP, se kterým musí být řešení pro případ integrace kompatibilní v části předávání a typu logů, tedy musí používat některý z typů protokolů pro předávání logů podporovaných tímto SIEM systémem. Případně mohou být tyto záznamy přístupné přímo v rozhraní systému.

      1. Provozní monitoring

Služba musí poskytnout údaje o svých stavech do provozního monitoringu MZe v návaznosti na SLA definované v Příloze č. 2 Specifikace katalogových listů, Smlouvy. Řešení musí poskytovat standardizované rozhraní pro vzdálený dohled stavu svých komponent – např. SNMP, nebo musí být jiným způsobem oznámen výpadek služby zadavateli.

      1. Zálohování a archivace

Řešení musí umožňovat pravidelné zálohy konfigurací jednotlivých komponent pro jejich obnovení v případě výpadku nebo selhání.

Zálohy dat musí být prováděny v intervalech požadované v závazných parametrech uvedených v příloze smlouvy č. 3 Technická specifikace a to pro dané období nebo objem a nesmí být nijak krácena kromě povolené agregace.

Řešení musí umožnit archivaci dat starších více než 6 měsíců, nebo přesahující požadovaný maximální objem z interního úložiště.

      1. Šifrování

Řešení musí splňovat minimální požadavky na kryptografické algoritmy definované v příloze „Příloha č. 3 k vyhlášce č. 316/2014 Sb.“ 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ů. Přičemž je nutné dodržet parametry pro jednotlivé protokoly dle interních požadavků Objednatele uvedené v tabulce 2 - Požadavky na kryptografii.





Tabulka 4 - Požadavky na kryptografii

Standard / protokol

Parametr

Požadované u nových zařízení a software

Poznámka

SSL/TLS

verze protokolu

3.1 (TLS 1.0)
3.3 (TLS 1.2)


velikost krátkodobého klíče

2048 bitů, podgrupa 256 bitů (DHE)
256 bitů (ECDHE)

Uplatňuje se pouze u ciphersuites s FS.

dohadování podpisového algoritmu - část hash

SHA-1 (možnost vypnout po 31.12.2016)
SHA-256
MD5 nesmí být akceptován

RFC 5246 kap. 7.4.1.4.1
týká se pouze TLS 1.2 a vyšších verzí, u nižších verzí protokolu se podpisový algoritmus nedohaduje

podpora forward secrecy

ano


ověření identity protistrany

RSA klíč 2048 bitů
ECC klíč 256 bitů


podporované eliptické křivky

prime256v1
secp384r1
xxxx000x0


posílání celého řetězu certifikátů (vyjma self-signed root) v ServerHello

vyžaduje se


podpora RFC 5746

ano
možnost vypnout renegociaci vyvolanou klientem

Secure Renegotiation

podpora RFC 7366

bude vyžadována od 1.1.2018

Encrypt-then-MAC

podpora RFC 7627

bude vyžadována od 1.1.2018

Session Hash and Extended Master Secret

symetrické šifrování

AES 128/256 bitů CBC
AES 128/256 bitů GCM

V případě 3DES se 168-bitovým klíčem je efektivní velikost klíče pouze 112 bitů.

velikost bloku sym. šifer

128 bitů a větší


zajištění integrity

HMAC-SHA1
HMAC-SHA256
AEAD


možnost selektivně zapnout/vypnout jednotlivé verze protokolu

ano


možnost selektivně zapnout/vypnout jednotlivé ciphersuites

ano


SSH

verze protokolu

2.0


symetrické šifrování

AES 128/256 bitů CBC
AES 128/256 bitů CTR
AES 128/256 bitů GCM

V případě 3DES se 168-bitovým klíčem je efektivní velikost klíče pouze 112 bitů.

zajištění integrity

HMAC-SHA1
HMAC-SHA256
AEAD


možnost selektivně zapnout/vypnout jednotlivé algoritmy pro dohadování klíčů, šifrování a zajištění integrity

ano


IPSec

verze IKE

1
2


podpora NAT-T

ano


enkapsulace

ESP
AH


dohadování klíče (MM i QM)

2048 bitů, podgrupa 256 bitů (DH)
256 bitů (ECDH)


symetrické šifrování (MM i QM)

AES 128/256 bitů CBC
AES 128/256 bitů GCM

V případě 3DES se 168-bitovým klíčem je efektivní velikost klíče pouze 112 bitů.

zajištění integrity (MM i QM)

HMAC-SHA1
HMAC-SHA256
AEAD


ověření identity protistrany

RSA klíč 2048 bitů
ECC klíč 256 bitů
PSK (min. entropie 256 bitů)


podpora QM PFS

ano


možnost nastavit politiky pro MM a QM s omezenou množinou kombinací enkapsulace a algoritmů pro dohadování klíčů, šifrování a zajištění integrity

ano


SNMP

verze SNMP

v3


podpora USM (v3)

ano


podpora TSM/TLS (v3)

nevyžaduje se; pokud je podporován, řídí se požadavky na TLS


podpora TSM/SSH (v3)

nevyžaduje se; pokud je podporován, řídí se požadavky na SSH


zajištění integrity (v3)

HMAC-SHA-96
HMAC192-SHA256


symetrické šifrování (v3)

AES-CFB-128


DNSSEC

autoritativní server

vyžaduje se


rekurzivní server (včetně forwarderu)

vyžaduje se


klient

vyžaduje se buď plná validace nebo zajištění integrity DNS komunikace (IPSec popř. TLS) z DNS klienta na rekurzivní server


podpora NSEC3

vyžaduje se


algoritmy podle RFC 3110

vyžaduje se


algoritmy podle RFC 5155

vyžaduje se


algoritmy podle RFC 5702

vyžaduje se


ZSK

RSA klíč 1024 bitů (max. 30 dní)
RSA klíč 2048 bitů (max. 2 roky)


KSK

RSA klíč 2048 bitů (max. 2 roky)
RSA klíč 4096 bitů (max. 10 roků)


DNS cookies

vyžaduje se; klíč serveru pro generování hodnot DNS cookies musí mít minimální entropii 128 bitů

RFC 7873; není součástí standardu DNSSEC

Trust anchor telemetry query

vyžaduje se u rekurzivních serverů; posílání telemetrického dotazu jednou za 24 hodin a možnost tuto funkci deaktivovat

draft-wkumari-dnsop-trust-management-01

IEEE 802.1AE
(MACsec)

IEEE 802.1AEbn
(GCM-AES-256)

vyžaduje se


IEEE 802.1AEbw
(64-bitové číslování paketů)

vyžaduje se v případech, kdy port či LAG s aktivním MACsec pracuje na rychlosti vyšší než 100 Gbps

hranice 100 Gbps stanovena výpočtem - při této rychlosti dojde k přetečení 32bitového čítače u nejmenších paketů (64B) za 60 sekund

WiFi

WEP
WEP2
WEP+
Dynamic WEP

nesmí být použit


WPA (TKIP)

nesmí být použit


WPA2 (AES+CCMP)

vyžaduje se


PSK

klíč s min. entropií 128 bitů


Key reinstallation mitigation

vyžaduje se

útoky známé jako "KRACK"

EAP-TLS

nesmí být použit

požadavky na TLS jsou uvedené v sekci SSL/TLS

PEAP-EAP-TLS

vyžaduje se pro WPA2-Enterprise

požadavky na vnější TLS (PEAP) i vnitřní TLS jsou uvedené v sekci SSL/TLS

PEAP-EAP-MSCHAPv2

nesmí být použit

požadavky na vnější TLS (PEAP) jsou uvedené v sekci SSL/TLS

HSRP/VRRP

HSRP MD5

nesmí být použit


VRRP AH

vyžaduje se


X.509

verze certifikátu

3


verze CRL

2


Signature Algorithm

sha1RSA
sha256RSA
sha512RSA
sha256ECDSA
sha512ECDSA


podporované velikosti klíče RSA

1024
2048
4096


podporované eliptické křivky

prime256v1
secp384r1
xxxx000x0


Authority Key Identifier

hash veřejné části klíče
identifikace certifikátu vydavatele (DN vydavatele a sériové číslo)


Subject Alternative Name

požadována podpora
musí se vyskytovat ve všech certifikátech, kde se identita ověřuje proti FQDN (např. webové servery)
atribut musí být zohledněn při validaci


Basic Constraints

požadována podpora
atribut musí být zpracovávaný jako kritický
atribut musí být zohledněn při validaci


Key Usage

požadována podpora
atribut musí být zpracovávaný jako kritický
atribut musí být zohledněn při validaci


Name Constraints

požadována podpora
atribut musí být označený a zpracovávaný jako kritický
atribut musí být zohledněn při validaci


Extended Key Usage

požadována podpora
atribut musí být zpracovávaný jako kritický
atribut musí být zohledněn při validaci


kontrola CRL

požadována podpora


kontrola OCSP

požadována podpora


Federovaná identita

podpora SAML 2.0

požadována podpora u role IdP a kombinace rolí IdP a SP (hub);
u role SP se požaduje podpora SAML 2.0 nebo WS-Federation


podpora WS-Federation

požadována podpora u role IdP a kombinace rolí IdP a SP (hub);
u role SP se požaduje podpora SAML 2.0 nebo WS-Federation


podpora metody GET (redirect)

vyžaduje se


podpora metody POST

vyžaduje se


podpora artifact binding

požadována podpora u role IdP a kombinace rolí IdP a SP (hub);
u role SP se podpora nevyžaduje


možnost definice vlastních claims/assertions

vyžaduje se


filtrace příchozích claims/assertions

vyžaduje se


kontrola audience na straně SP

vyžaduje se


hash algoritmus otisku podepisovaných dat

SHA256
SHA512


algoritmus podpisu

HMAC-SHA256
HMAC-SHA512
RSA (velikost modula min. 2048 bitů)
ECDSA (velikost klíče min. 256 bitů)

podpisy pomocí algoritmů HMAC jsou vyžadovány pouze u systémů používajících pro podpis tiketu sdílené tajemství

podporované eliptické křivky

prime256v1
secp384r1
xxxx000x0


minimální velikost zkráceného HMAC v podpisu XML

vyžaduje se uvádět HMAC v plné velikosti podle použité hash funkce;
ověřující strana musí odmítnout zkrácený HMAC




  1. Přehled Dalších požadavků

Objednatel v rámci výběrového řízení požaduje zajištění služby VULN s technickou podporou, která vyhovuje požadavkům uvedeným v této kapitole.

    1. Funkční požadavky

Součástí smlouvy je Technická specifikace Příloha 5 s tabulkou ve formátu Excel, která obsahuje seznam požadavků na funkcionalitu technické podpory služby VULN (dále jen „Tabulka požadavků“). Pokud je v Tabulce požadavků některý požadavek označen jako povinný, nebude nabídka, která takovému požadavku nevyhovuje, akceptována a bude vyřazena.

Tabulka požadavků je rozdělena celkem do sedmi částí:

  • Obecné požadavky

  • Požadavky na vlastnosti skenování

  • Požadavky na scoring, značkování a filtrace

  • Požadavky na vizualizaci

  • Požadavky na shodu nastavení

  • Požadavky na autentizaci, autorizaci a uživatelskou segregaci

  • Požadavky na reporting

Ve sloupci „Popis naplnění požadavku“ uvedeném v Tabulce požadavků uchazeč popíše způsob naplnění požadavku. Z obsahu samotného popisu musí být zřejmé, zda jsou stanovené funkční požadavky naplněny. Popis může být rozšířen o odkaz na příslušnou část dokumentace výrobce ve sloupci „Doplňující odkaz na externí zdroj“, který bude mít pouze účel upřesnění, informace o naplnění požadavku musí být zřejmá již ze samotného popisu.

Tabulku požadavků musí uchazeč pouze doplnit o informaci a to popis naplnění požadavku ve smyslu předchozích odstavců. Uchazeč je povinnen předat soubor v elektronické podobě pouze s doplněným svým obsahem dle popisu výše (modře podbarvené buňky). Zároveň je povinen zachovat veškerý obsah (zeleně podbarvené buňky), který mu nepřísluší měnit, zachovat formát a podobu tabulky, včetně formátu excelovského souboru.

Uchazeč garantuje, že jeho služba VULN splňuje všechny minimální povinné požadavky a rozumí se tím, že v rámci plnění, tedy součástí plnění, budou veškeré licence, vývojové/implementační práce, případně jiné části dodávky potřebné k naplnění tohoto požadavku.

    1. Rozsah

V této sekci je definován rozsah dodávaného řešení.

      1. End of sale and support (EOS)

Zadavatel požaduje dodat taková zařízení a technologie pro podporu služby, u něhož výrobce nevyhlásil EOS (end of sale and support) a je garantována minimálně pětiletá dostupnost náhradních dílů a podpora, včetně dostupnosti aktualizací SW/HW, od data akceptace Plnění.

      1. Komplexnost a životní cyklus

Zadavatel požaduje dodání technologie pro podporu služby včetně nových a nepoužitých zařízení. Zadavatel požaduje dodat kompletní plnění, včetně zařízení, veškerého potřebného programového vybavení a licencí, které umožní plnohodnotné fungování poptávané funkcionality pro podporu služby VULN. Řešení musí umožnit souběžné provozování všech komponent a funkcionalit bez negativních závislostí, tedy tak kdy jedna část, komponenta nebo funkcionalita je v provozním stavu pouze v případě, kdy je jiná část, komponenta nebo funkcionalita z provozu vyřazena nebo vypnuta. Předmět plnění veřejné zakázky musí být proveden plně v souladu s platnými právními předpisy, jakož i v souladu se všemi normami obsahujícími technické specifikace a technická řešení, technické a technologické postupy nebo jiná určující kriteria k zajištění, že materiály, výrobky, postupy a služby vyhovují účelu předmětu veřejné zakázky.

    1. Fáze realizace dodávky

Následuje popis jednotlivých fází plnění služby VULN.

      1. Instalace

Instalace technického řešení pro podporu služby VULN bude provedena do prostředí Objednatele, které pro tyto účely představují obě datová centra (geocluster DC Nagano a DC Chodov) a lokalitu Těšnov. Pokud řešení obsahuje fyzické komponenty musí umožnit umístění v rozvaděčových skříních typu RACK výrobce HP (19ti palcové), s podporou standarního typu napájení a musí být s tímto typem kompatibilní. Kompatibilitou je zde myšlen především rozměr zařízení, a umístění konektorů vzadu, přičemž zařízení musí být orientováno vzhledem k cirkulaci vzduchu (chlazení) v sousledném směru. Dále musí umožnit jejich propojení v této zadní části odpovídajícími komunikačními kabely s infrastrukturou zadavatele, jednak s odpovídajícím typem síťového rozhraní, dále mezi sebou a s centrální správou v rámci řešení pokud je vyžadováno, a také do management sítě pro správu zařízení, nebo případně přes dedikovaný fyzický port. Dodavatel zajistí fyzické umístění a instalaci všech HW komponent řešení do místa určení v prostředí Objednatele jako součást plnění VULN. SW prostředky dodané v rámci řešení budou instalovány v poslední verzi dostupné v době plnění. Dodavatel dále zajistí nasazení a aktivaci všech licencí a licenčních klíčů. Architektura instalovaného řešení pro podporu služby, včetně identifikace komponent, přehledu instalovaných verzí a použitých licencí a licenčních klíčů bude dokumentována.

      1. Implementace

V rámci fáze implementace bude Dodavatelem zajištěna konfigurace technického řešení pro podporu služby VULN tak, aby řešení vyhovovalo požadavkům uvedeným v Technické specifikaci.

Jako součást dodávky bude provedeno:

  • Konfigurace komponent VULN řešení;

  • Nastavení a konfigurace skenovacích engine;

  • Nastavení a konfigurace centrálního managementu;

  • Nastavení a konfigurace detekce zranitelností anomálií;

  • Nastavení a konfigurace compliance konfigurací;

  • Integrace řešení se systémem SIEM a PIM;

  • Integrace řešení do provozního a bezpečnostního monitoringu, provede Dodavatel na straně řešení, a to za součinnosti Objednatele za stranu dohledů;

  • Nastavení zálohování konfigurace a dat VULN řešení;

      1. Akceptační testy

V rámci závěrečné fáze je navržen testovací scénář, který může pokrývat následující oblasti a parametry řešení:

Tabulka 5 - Akceptační kriteria

Obecné požadavky

Ano / Ne / Částečně

Poznámka

Řešení musí být realizované produkty s integrovaným uživatelským rozhraním včetně dostupnosti výsledků testování systémově a administrativně snadno ovladatelným aplikačním prostředím.



Řešení musí být škálovatelné v prostředí síťové infrastruktury minimálně pro tři lokality a řádově stovky interních a externích/DMZ segmentů, s možností provádět volitelně testy z internetu nebo z vybraných interních síťových scannerů s podporou přístupu do VLANs.



Řešení musí být možno provozovat čistě jako on-premise, cloudové rozšíření jsou volitelná jen pro jednosměrnou komunikaci, tedy ve směru z cloudu do prostředí Objednatele, vlastní funkcionalita sběru a vyhodnocení zranitelností musí probíhat čistě v rámci on-premise architektury. Informace o zranitelnostech nejsou jakýmkoli způsobem zasílána mimo prostředí Objednatele.



Zcela bezagentní řešení, tj. bez nutnosti instalace SW kódu na infrastrukturu ICT.



Řešení musí umožňovat automatizované aktualizace všech SW komponent celé architektury řešení nejnovějšími dostupnými verzemi jednotlivých SW komponent po celou dobu platnosti subscribce.



Řešení musí umožňovat periodické automatické aktualizace databáze zranitelností a testovací aplikace (scanning engine) na všech skenovacích zařízení (interních i externích v internetu) garantovaná dodavatelem s 24hod reakcí na nově popsané zranitelnosti například na stránkách výrobců SW, nebo online databází zranitelností - xxx.xxxxx.xxx apod.



Řešení musí být integrovatelné se systémem HP Arcsight SIEM (import zranitelností) a CyberArk (využívání privilegovaných identit pro přístup na skenovaná zařízení a systémy)



Řešení musí umožňovat přenášení dat mezi jednotlivými komponenty řešení, především mezi centrálním managementem a skenery např. o zjištěných zranitelnostech a informace o testovaných zařízeních, pouze s použitím silného šifrování a to dle parametrů pro jednotlivé protokoly dle interních požadavků Objednatele uvedené v tabulce 2 – Požadavky na kryptografii v příloze 5. Popis technického řešení, Smlouvy.



Požadavky na vlastnosti skenování



Řešení musí umožňovat detekci zranitelností na vzdáleném ICT zařízení s podporou minimálně následujících operačních systémů: Windows desktop 7+ a Windows Server 2008+, RHEL, GNU/Linux distribuce; databází: Oracle, MS SQL Server, PostgreSQL; routerů a switchů s podporou pro IOS, NX-OS, Comware 5 a 7 výrobců HP, Cisco; aplikačních web serverů: Apache, WebSphere, MS IIS; a virtualizační platformy VMware. Dále pak pro Simple Network Management Protocol (SNMP), Secure Shell (SSH), Secure Shell (SSH) Public Key, Telnet, Web Site Form Authentication, Web Site HTTP Authentication, Web Site Session Authentication.



Řešení musí umožňovat pravidelné automatické, kontinuální (nepřetržité) i ad-hoc ruční spouštění testování zranitelností ICT zařízení v prostředí síťové infrastruktury, s možností výběru IP rozsahu nebo předdefinovaných skupin zařízení a s výběrem/úpravou profilu a zátěže testování - minimální požadovaná periodicita 1x denně přes celý IP rozsah v rámci dodávky. Řešení musí umožnit vizualizaci těchto rozvrhů v kalendáři v rámci GUI.



Řešení musí umožňovat automatizované inteligentní ověřování skutečných síťových služeb běžících na nalezených TCP/UDP portech (nikoliv pouze dle banneru a čísla portu).



Řešení musí umožňovat volbu intenzity testování (např. kolik IP adres a TCP/UDP portů testovat paralelně), rychlosti testování (např. port mapping speed, packet delay time) s minimalizací zátěže testovaných zařízení a síťové infrastruktury.



Řešení musí umožňovat nastavení minimalizace rizika výpadku testovaného zařízení nebo síťové služby, minimálně zákazem provádění invazivních testů, zákazem aplikace exploitů, DoS i DDoS útoků a password brute forcingu.



Řešení musí umožňovat automatické predikce nových zranitelností dle relevantních atributů: verze OS, verze síťových protokolů a verze aplikací na dříve testovaných systémech bez potřeby jejich nového otestování po zveřejnění nových typů zranitelností.



Řešení musí umožňovat automatizované testování zranitelností webových aplikací s podporou minimálně následujících technik a typů zranitelností: XSS, SQL injection, Blind SQL injection, web traversal, web crawling, source code disclosure a další ze seznamu aktuální verze OWASP TOP-10.



Řešení musí umožňovat provádět automatizované testy zranitelností zařízení, systémů i aplikací anonymně (bez přihlášení uživatele) a autentizovaně (pod účtem vybraného uživatele aplikace).



Řešení musí umožňovat testování dynamicky přidělovaných IP adres přes DHCP službu a sledování její historie a reportování pomocí „DNS name“ nebo „Host name“.



Řešení musí umožňovat testování překrývajících se IP adres a jejich individuálního sledování a reportování dle různých lokalit.



Řešení musí paraleně pracovat s IPv4 i IPv6, jedná se především o schopnost detekovat IPv6 systémy při skenování pomocí IPv4.



Řešení musí detekovat zranitelnosti v celém „IT stacku“. Například po objevení defaultního hesla, toto heslo využít pro další hlubší skeny a detekci souvisejících zranitelností.



Řešení musí umožňovat discovery scan, tedy zrychlené pravidelné automatické, kontinuální (nepřetržité) i ad-hoc ruční spouštění mapování síťové infrastruktury s identifikací OS, TCP a UDP portů a služeb a vyznačením nových, potvrzených a nepotvrzených zařízení. Minimální požadovaná periodicita 1x denně přes celý IP rozsah v rámci dodávky. Řešení musí umožnit vizualizaci těchto rozvrhů v kalendáři v rámci GUI.



Požadavky na scoring, značkování a filtrace



Řešení musí umožňovat automatickou aktualizaci tagů v Asset databázi dle těchto dynamických tagovacích pravidel.



Řešení musí umožňovat automatickou centralizaci všech nalezených aktivních systémů a jejich atributů: verze OS, verze aplikací, otevřené TCP a UDP porty a síťové protokoly do jednotné Asset databáze s možností definovat statické a dynamické hierarchické tagy (nálepky) a dle těchto tagů provádět filtrování aktiv, jejich testování i reportování výsledků.



Řešení musí umožňovat pro každou zjištěnou zranitelnost uvádět popis relevantních hrozeb, možného negativního dopadu na systém, odkazy na online zdroje nebo databáze zranitelnosti popisující danou zranitelnost (např. webovou stránku výrobce SW, xxx.xxxxx.xxx apod.) a popis odstranění zranitelnosti s uvedením http linku na patch výrobce nebo postup změny konfigurace systému.



Řešení musí umožňovat definici pravidel pro automatické a dynamické tagování aktivních systémů dle nalezených atributů po každém testu zranitelností, minimálně pro:



verzi operačního systému



verzi instalovaných aplikací



otevřené TCP a UDP porty



verzi síťových protokolů



verzi nalezených zranitelností.



Řešení musí umožňovat centralizované úpravy v databázi zranitelností, a to tak aby pro celý rozsah implementace bylo možné měnit hodnotu rizikovosti zranitelností, popis hrozeb, popis negativního dopadu a odstranění zranitelností nebo bylo možné vyjmout určité zranitelnosti z testování, a dále editovat CVSS Scoring (Common Vulnerability Scoring System).



Řešení musí upozornit na existenci odpovídajících opravných aktualizací na dříve testovaných systémech bez potřeby jejich nového otestování po zveřejnění těchto opravných aktualizací. Umožňuje tak automatické zohlednění „Zero-Day hrozeb“ a „Zero-Day zranitelností“ , tedy známých zranitelností, na které neexistuje opravná aktualizace v době jejich detekce v prostředí zadavatele. Systém tedy sám upozorňuje na opravné aktualizace vztahující se ke známým zranitelnostem v prostředí zadavatele.



Řešení musí umožňovat automatizovanou identifikaci všech zjištěných zranitelností ve výsledcích testování, včetně míry jejich rizikovosti, popisu příslušných TCP/UDP portů, protokolů, síťových služeb a aplikací na kterých byly detekovány.



Požadavky na vizualizaci



Řešení musí umožňovat filtrování výsledků mapování síťové infrastruktury dle platformy OS, otevřených TCP-IP portů, potvrzených/nepotvrzených zařízení, automatizované srovnávání historických map s vyznačením rozdílů.



Řešení musí umožňovat automatické filtrování a reportování relevantních aktiv dotčených novou zranitelností s vyznačením pravděpodobnosti.



Požadavky na shodu nastavení



Řešení musí umožňovat definice a tvorbu vlastní bezpečnostní kontroly konfigurací operačních systémů Windows, Linux na základě vybraných parametrů uložených v registrech a souborových systémech a možnost kontrolovat integritu vybraných konfiguračních souborů.



Řešení musí umožňovat automatické provádění bezpečnostního auditu konfigurace minimálně následujících operačních systémů: Windows desktop 7+ a Windows Server 2008+, RHEL, GNU/Linux distribuce; databází: Oracle 10+, MS SQL Server, Postgres, MySQL; routerů a switchů s podporou pro IOS, NX-OS, Comware 5 a 7 výrobců HP, Cisco; aplikačních web serverů: Apache, WebSphere, MS IIS; a virtualizační platformy VMware; vůči šablonám technických bezpečnostních opatření.



Požadavky na autentizaci, autorizaci a uživatelskou segregaci



Řešení musí umožňovat seskupování testovaných systémů do skupin s přiřazením vlastníků a hodnoty aktiv.



Řešení musí umožňovat katalogizaci rozsahu testovaných webových aplikací pod účtem uživatele a porovnání přístupových práv uvnitř webové aplikace mezi jednotlivými uživateli.



Řešení musí umožňovat provádět testování zranitelností bez nebo volitelně se vzdálenou autentizací na testovaná zařízení na úroveň operačních systémů a databází.



Řešení musí podporovat autentizaci uživatelů do centrální řídící aplikace a centrální databáze výsledků testování, pomocí externího LDAP, primárně AD s Kerberos.



Řešení musí umožňovat centralizované a vysoce zabezpečené šifrované úložiště všech výsledků mapování sítě a testování zranitelností systémů s řízením přístupových oprávnění na základě definovaných rolí a odpovědností k výsledkům a spouštění testování a auditů, dle principu need-to-know.



Řešení musí podporovat uživatelsky definované zranitelnosti a uživatelskou úpravu stávajících signatur



Požadavky na reporting



Řešení musí umožňovat centralizované, agregované ukládání všech výsledků testování zranitelností a auditů konfigurace všech systémů a webových aplikací do jednotné normalizované databáze s centrálním monitoringem stavu zranitelností (formou Dashboardu) a centralizovaným reportingem nad agregovanými výsledky všech realizovaných testů a auditů ze všech lokalit v rámci dodávky.



Řešení musí umožňovat automatické filtrování a reportování relevantních aktiv dotčených zvolenou „Zero-Day“ zranitelností nebo hrozbou s vyznačením pravděpodobnosti úspěšného útoku.



Řešení musí umožňovat konfigurovatelný reporting a filtrování výsledků testování, zpracování trendů za libovolné časové období nad historií testování, porovnávání stavu zranitelností za zvolené časové období a oblast sítě a srovnávání výsledků vybraných historických testů.



Řešení musí umožňovat reporting výsledků mapování a testování zranitelností přes celou infrastrukturu v rámci dodávky, nezávislý reporting nad konkrétními realizovanými testy, reporting s automatickou korelací poslední známé informace a stavu zranitelností nad zvoleným rozsahem reportu.



Řešení musí umožňovat generování reportu nalezených zranitelností dle optimální logiky instalace patchů od nejnovějších po nejstarší patche a s vyřazením nahrazených patchů novějšími.



Řešení musí umožňovat podrobný technický reporting všech zjištěných zranitelností, informací a detailů o reportovaných systémech s možností filtrování zvolené úrovně a typu detailu.



Řešení musí umožňovat vytvořit sumární přehledový manažerský reporting o celkovém stavu a počtu zranitelností, trendem a vyplývající míře rizika nad zvoleným rozsahem reportu.



Řešení musí umožňovat konfigurovatelný reporting a filtrování výsledků testování webových aplikací s možností třídění a filtrování výsledků testování dle všech kategorií zranitelností aktuální verze OWASP TOP-10 a filtrování výsledků testování dle zvolené topologie (logických větví) webových aplikací.



Řešení musí umožňovat archivaci výsledků testů min. 12 měsíců s možností exportu minimálně ve formátech XML, CSV, HTM, PDF.



Řešení musí umožňovat automatickou centrální archivaci a korelaci všech výsledků historických testů zranitelností ze všech testovaných zařízení a oddělení reportingu od jednotlivých výsledků jednotlivých testů.



Řešení musí konsolidovat zranitelnosti odstranitelné stejným postupem a toto prezentovat formou remediačních plánů v rámci reportů.



Řešení musí identifikovat zranitelnosti pro které existuje exploit, případně asociované s konkrétním malware kitem.





Tento funkční test ověří, že technické řešení na podporu služby VULN poskytuje bezchybně všechny požadované funkcionality uvedené v příloze smlouvy č.5 - Technická specifikace, včetně integrace se systémy Objednatele (SIEM, Zálohování, apod.), přičemž může být doplněn o jakoukoli položku této přílohy, případně i o ověření funkčnosti vyplývající z požadavků uvedených v  příloze č.5 Smlouvy – Popis technického řešení.

Akceptační test je ukončen nahlášením výsledku a předáním seznamu nalezených vad. Po odstranění podstatných vad budou akceptační testy celé opakovány a ověří tak kvalitu předávaného technického řešení pro podporu služby VULN.

V případě neodstranění podstatných vad nebude řešení akceptováno ani s výhradami.

Podstatné vady jsou vady, které způsobují tak závažné problémy, že Objednatel nemůže odebírat službu VULN v požadované kvalitě, například nelze produkt nebo jeho klíčovou část používat či ovládat.

Úspěšný akceptační test je takový, kdy tabulka akceptačního testu obsahuje všechny požadované řádky vyplněné výsledkem testu s hodnotou „ANO“ a je predispozicí k podepsání předávacího protokolu dle smlouvy článku V. 1).

      1. Dokumentace

Dokumentaci v rámci poskytování plnění bude udržovat poskytovatel služby a bude obsahovat jak originální dokumentaci dodávanou výrobcem VULN řešení, tak i dokumenty popisující nasazení podpůrné technologie VULN v prostředí Objednatele.

Oficiální dokumentace výrobce produktu VULN bude vedena v elektronické podobě (formát PDF nebo MS Word) a bude provedena v českém, nebo anglickém jazyce. Dokumentace od výrobce musí pokrývat minimálně následující oblasti:

  • popis architektury;

  • instalace řešení;

  • administrace řešení;

  • uživatelská příručka;

Dokumentace popisující nasazení technologie VULN v prostředí Objednatele musí být předána v elektronické podobě ve formátu MS Word a bude vedena v českém jazyce. Minimální požadavky na rozsah a obsah dodávané dokumentace je následující:

  • Instalační dokumentace

    • Popis architektury;

    • Komunikační matice komponent;

    • Instalované verze;

    • Licence;

    • Instalační postup;

  • Implementační dokumentace

    • Popis nastavení komponent VULN řešení;

    • Popis konfigurace zálohování VULN řešení;

    • Popis nastavení integrace se systémem SIEM

    • Popis nastavení integrace se systémem PIM

    • Popis nastavení konfigurace Provozního monitoringu

  • Uživatelská příručka

    • Popis uživatelského rozhraní VULN řešení z pohledu uživatele;

    • Popis uživatelských postupů při práci s VULN řešením;

  • Zajištění kontinuity provozu

    • Popis postupu obnovy ze zálohy;

    • Doporučení pro archivaci (datové komunikace po překročení onsite limitu);

    • Popis postupu v případě havárie jednotlivých komponent včetně postupu obnovy do provozního stavu;

      1. Školení

Dodavatel zajistí proškolení minimálně 3 osob Objednatele na úrovni uživatele řešení v rozsahu umožňujícím provádět:

  • Provádění analýz zranitelností;

  • Provádění analýz shody konfigurací;

  • Provádění auditu přístupů do systému;

  • Monitoring stavu zařízení;

  • Zálohování a obnovu konfigurace a dat;

  • Tvorbu pohledů a reportů;

Školení musí být poskytnuto v českém nebo slovenském jazyce.

    1. Podpora

Dodavatel ručí za to, že VULN řešení bude funkční a použitelné v prostředí Objednatele a bude odpovídat požadavkům Objednatele, uvedených v Technické specifikaci a vlastnostem deklarovaným v dokumentaci dodané Dodavatelem. Služby poskytované Dodavatelem musí vyhovovat technickým specifikacím a požadavkům výrobce.

Podpora služby zahrnuje činnosti definované ve Specifikaci katalogových listů, viz Příloha č.1 Smlouvy.

Podpora bude poskytována dle  parametrů definovaných ve Specifikaci katalogových listů, viz Příloha č.1 Smlouvy a bude probíhat v českém jazyce, nedohodnou-li se pověřené osoby smluvních stran v konkrétním případě jinak.

Odstraňování vad technických prostředků bude Dodavatelem prováděno výměnným způsobem na místě s tím, že náhradní díl nebo zařízení musí být nové a bezvadné a musí být doručeno do místa provádění opravy.

    1. Platformy

Pokud bude VULN řešením vyžadována instalace komponent do virtuální VMware infrastruktury Objednatele, součástí nabídky musí být:

  • specifikace počtu požadovaných virtuálních serverů a jejich parametrů s ohledem na dostatečnou výkonnost řešení a současnou adekvátnost parametrů;

  • požadavek na geografické umístění virtuálních serverů v rámci infrastruktury Objednatele

  • specifikace požadavků na parametry komunikačních tras a síťových prostupů mezi jednotlivými komponentami řešení VULN;

Veškeré SW licence potřebné k provozu řešení VULN (např. OS, DB) musí být součástí dodávky. Seznam všech dodaných licencí bude součástí nabídky.

Veškeré dodané komponenty (SW, HW) budou instalovány v konfiguraci podporované výrobcem/výrobci a budou udržovány v aktuální verzi, v konfiguraci zaručující vzájemnou kompatibilitu všech komponent a dostatečně výkonnostně nadimenzované s ohledem na parametry požadované pro toto VULN řešení.

Veškerý dodaný hardware a software (včetně operačního systému, databazí, apod.) bude plně ve správě Dodavatele a bude poskytnuta jeho Podpora a Maintenance dle parametrů definovaných ve Specifikaci katalogových listů, viz Příloha č.1 Smlouvy

Řešení VULN musí být v souladu s interní směrnici Objednatele „Definice závazné architektury a požadavků pro vývoj a zabezpečení provozu registrů a klíčových aplikací MZe“ (interní směrnice není přílohou zadání, bude Dodavateli k dispozici v rámci projektu - výňatek s přehledem technologií je uveden níže).

Důvodem tohoto požadavku je zajištění kompatibility se stávající infrastrukturou Zadavatele a zároveň možnost využití stávajících mechanizmů (HW/SW nástroje, personál, servisní smlouvy) pro správu a monitoring dodaných komponent řešení a jednotného přístupu, bez potřeby dalších investic na straně Zadavatele.

Výjimku tvoří řešení, které budou dodány ve formě tzv. „appliance“, tedy řešení, kdy již samotný výrobce nabízí a dodává VULN řešení či některou z jeho komponent jako společný celek softwarových a hardwarových prostředků.

Níže je vykopírován přehled platforem ze zmíněné směrnice:

  • Síťové technologie

    • WAN, LAN, HW balancery – technologie Cisco, HP, F5;

    • Firewally, SSL akcelerátory – technologie Cisco, Citrix, HP, F5;

    • SAN prvky – technologie Cisco, HP, Brocade;

  • Databázové systémy

    • RedHat Linux Enterprise rel. 6 a vyšší + Oracle 11g rel. 2 a vyšší;

    • Microsoft SQL server verze 2008 a vyšší (pouze pro technologické platformy neumožňující využití Oracle DB);

  • Serverové operační systémy

    • Windows server 2012 R2 a vyšší;

    • Red Hat Enterprise Linux AS release 6 a vyšší (64 bit);

  • Technologie pro poštovní služby a autentizaci

    • Aplikační autentizace – LDAP Oracle Internet Directory 10g rel. 2 a vyšší;

    • Poštovní služby – MS Exchange 2013 nebo vyšší;

    • Doménová autentizace a autentizace desktopových aplikací Microsoft v prostředí MZe – MS Active Directory;

  • Virtualizační technologie

    • VMware ESX 5.0 a vyšší;

  • Aplikační servery

    • Oracle WebLogic Server 11g rel. 1 a vyšší (64 bit) – má vlastní webserver;

    • Microsoft .NET (dot NET) – produkty v rámci MS Internet Information Server 7.0;

    • JBoss – IIS 7.0 a vyšší (win) nebo Apache (linux);

  • Prezentační vrstva

    • Microsoft Internet Explorer verze 11.0 a vyšší.

V případě, že zadávací podmínky této Veřejné zakázky obsahují požadavky nebo odkazy na obchodní firmy, názvy nebo jména a příjmení, specifická označení zboží a služeb, které platí pro určitou osobu, popřípadě její organizační složku za příznačné, nebo patenty, ochranné známky nebo označení původu, umožňuje Zadavatel výslovně pro plnění Veřejné zakázky použití i jiných, kvalitativně a technicky obdobných řešení, která naplní Zadavatelem požadovanou funkcionalitu (byť jiným způsobem).


Příloha č. 5

Technická specifikace

DOPLNÍ Poskytovatel v souladu s nabídkou viz samostatný dokument





















Document Metadata

Filed: July 22nd, 2022