číslo jednací: 46448/2022/510
spisová značka: S0682/2021/VZ

 

 

Úřad pro ochranu hospodářské soutěže příslušný podle § 248 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, ve správním řízení zahájeném dne 27. 12. 2021 na návrh z téhož dne, jehož účastníky jsou

• zadavatel – Česká pošta, s.p., IČO 47114983, se sídlem Politických vězňů 909/4, 225 99 Praha 1,  
• navrhovatel – ATS-TELCOM PRAHA a.s., IČO 61860409, se sídlem Nad elektrárnou 1526/45, 106 00 Praha 10,
• vybraný dodavatel – AXENTA a.s., IČO 28349822, se sídlem Mlýnská 326/13, 602 00 Brno, ve správním řízení zastoupena na základě plné moci ze dne 7. 11. 2022 JUDr. Jindřichem Jaškem, advokátem, ev. č. ČAK 18759, se sídlem Koliště 259/55, 602 00 Brno,

ve věci veřejné zakázky „Centrální Log Management“ zadávané v otevřeném řízení, jehož oznámení bylo odesláno k uveřejnění dne 30. 3. 2021 a uveřejněno ve Věstníku veřejných zakázek dne 6. 4. 2021 pod ev. č. zakázky Z2021-010892, ve znění pozdějších oprav, a v Úředním věstníku Evropské unie dne 2. 4. 2021 pod ev. č. 2021/S 065-168959, ve znění pozdějších oprav, 

rozhodl takto:                          

 

 

I.

Správní řízení vedené ve věci návrhu navrhovatele – ATS-TELCOM PRAHA a.s., IČO 61860409, se sídlem Nad elektrárnou 1526/45, 106 00 Praha 10 – ze dne 27. 12. 2021 se ve vztahu k částem návrhu jmenovaného navrhovatele týkajícím se nesplnění požadavků

• č. 147, č. 148, č. 149, č. 150, č. 159 a
• č. 401 v kontextu tvrzení navrhovatele, že „Použití kryptografických funkcí tak zajišťuje toliko kontrolu integrity (tedy zjištění, zda byl zápis změněn), přičemž zápis před samotnou změnou či smazáním nechrání. To je přitom v přímém rozporu s bodem 401 a 506 Přílohy č. 1 smlouvy“ 

uvedených v příloze č. 1 návrhu smlouvy vybraným dodavatelem – AXENTA a.s., IČO 28349822, se sídlem Mlýnská 326/13, 602 00 Brno – podle § 257 písm. h) zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, zastavuje, neboť předmětným částem návrhu nepředcházely řádně a včas podané námitky.

II.

Návrh navrhovatele – ATS-TELCOM PRAHA a.s., IČO 61860409, se sídlem Nad elektrárnou 1526/45, 106 00 Praha 10 – ze dne 27. 12. 2021 se, kromě částí týkajících se nesplnění požadavků:

• č. 147, č. 148, č. 149, č. 150, č. 159 a
• č. 401 v kontextu tvrzení navrhovatele, že „Použití kryptografických funkcí tak zajišťuje toliko kontrolu integrity (tedy zjištění, zda byl zápis změněn), přičemž zápis před samotnou změnou či smazáním nechrání. To je přitom v přímém rozporu s bodem 401 a 506 Přílohy č. 1 smlouvy“ 

uvedených v příloze č. 1 návrhu smlouvy vybraným dodavatelem – AXENTA a.s., IČO 28349822, se sídlem Mlýnská 326/13, 602 00 Brno – podle ustanovení § 265 písm. a) zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, zamítá, neboť nebyly zjištěny důvody pro uložení nápravného opatření.

 

Odůvodnění

I.               ZADÁVACÍ ŘÍZENÍ

1.             Zadavatel – Česká pošta, s.p., IČO 47114983, se sídlem Politických vězňů 909/4, 225 99
Praha 1 (dále jen „zadavatel“) – jakožto veřejný zadavatel ve smyslu § 4 odst. 1 písm. e) 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 „zákon“) – zahájil dne 30. 3. 2021 odesláním oznámení o zahájení zadávacího řízení k uveřejnění otevřené řízení za účelem zadání veřejné zakázky „Centrální Log Management“ (dále jen „veřejná zakázka“ nebo „zadávací řízení“). Oznámení bylo uveřejněno ve Věstníku veřejných zakázek dne 6. 4. 2021 pod ev. č. zakázky Z2021-010892, ve znění pozdějších oprav, a v Úředním věstníku Evropské unie dne 2. 4. 2021 pod ev. č. 2021/S 065-168959, ve znění pozdějších oprav.   

2.             Podle bodu 2.1 zadávací dokumentace je předmětem veřejné zakázky „dodávka software pro centrální sběr a management logů pro Českou poštu, s. p. včetně hardware, software a potřebných licencí k jeho provozování, jeho implementace a poskytování podpory a údržby (support & maintenance) po dobu 48 měsíců od akceptace dodaného řešení.“

3.             Dne 22. 7. 2021 rozhodl zadavatel o výběru dodavatele – AXENTA a.s., IČO 28349822, se sídlem Mlýnská 326/13, 602 00 Brno, ve správním řízení zastoupena na základě plné moci ze dne 7. 11. 2022 JUDr. Jindřichem Jaškem, advokátem, ev. č. ČAK 18759, se sídlem Koliště 259/55, 602 00 Brno (dále jen „vybraný dodavatel“), přičemž oznámení o výběru ze dne 29. 7. 2021 (dále jen „oznámení o výběru“) bylo účastníkům zadávacího řízení doručeno téhož dne.

4.             Proti rozhodnutí o výběru navrhovatel podal dne 10. 8. 2021 námitky z téhož dne (dále jen „námitky“). Rozhodnutím o námitkách ze dne 23. 8. 2021 (dále jen „rozhodnutí o námitkách č. 1“), které bylo navrhovateli doručeno téhož dne, zadavatel citované námitky navrhovatele odmítl. Vzhledem k tomu, že navrhovatel nepovažoval rozhodnutí o námitkách za učiněné v souladu se zákonem, podal dne 2. 9. 2021 návrh na zahájení řízení o přezkoumání úkonů zadavatele Úřadu (dále jen „návrh ze dne 2. 9. 2021“), které Úřad vedl pod sp. zn. ÚOHS-S0379/2021/VZ.

5.             Ve správním řízení sp. zn. S0379/2021/VZ Úřad rozhodnutím č. j. ÚOHS-39240/2021/500/AIv ze dne 19. 11. 2021 zrušil rozhodnutí o námitkách č. 1. Zadavatel s ohledem na citované rozhodnutí Úřadu rozhodl znovu o námitkách navrhovatele rozhodnutím o námitkách ze dne 16. 12. 2021, které bylo navrhovateli doručeno téhož dne.

6.             Vzhledem k tomu, že navrhovatel s rozhodnutím o námitkách nesouhlasil, podal dne 27. 12. 2021 návrh na zahájení řízení o přezkoumání úkonů zadavatele Úřadu (dále jen „návrh“).

II.             OBSAH NÁVRHU

7.             Navrhovatel úvodem v čl. I návrhu rekapituluje dosavadní průběh zadávacího řízení. Následně navrhovatel objasňuje důvody, jež ho vedly k podání návrhu.

8.             V čl. II návrhu navrhovatel shrnuje důvody nezákonnosti postupu zadavatele, přičemž má za to, že

a.             řešení nabízené vybraným dodavatelem nesplňuje všechny požadavky zadavatele na nástroj pro Log Management stanovené v příloze č. 1 s názvem „Technická specifikace Nástroje/Řešení a Podpory (funkční a technické požadavky)“ přílohy č. 6 zadávací dokumentace – Vzor smlouvy (dále jen „příloha č. 1 smlouvy“), přičemž zadavatel měl dle navrhovatele přistoupit k vyloučení vybraného dodavatele ze zadávacího řízení, a tím, že tak neučinil, porušil ustanovení § 48 odst. 2 spím. a) zákona ve spojení s § 48 odst. 9 zákona.

b.             zadavatel nesprávně posoudil mimořádně nízkou nabídkovou cenu (dále jen „MNNC“) obsaženou v nabídce vybraného dodavatele, neboť za jím nabízenou cenu není a ani nemůže být zajištěno plnění veřejné zakázky.

8.             V čl. III návrhu se navrhovatel vyjadřuje k nesplnění technických požadavků zadavatele stanovených v příloze č. 1 smlouvy.

9.             Konkrétně navrhovatel uvádí, že nástroj vybraného dodavatele dle uživatelského manuálu v rozporu s bodem 304 přílohy č. 1 smlouvy neumožňuje aktualizaci systému v jednom kroku a v jednotném balíku prostřednictvím centrální konzole a neumožňuje ani rolling upgrade. Zároveň v rozporu s bodem 305 přílohy č. 1 smlouvy neumožňuje ani downgrade a veškerá konfigurace není verzována ve version control systemu (Git) tak, aby byla zajištěná vysoká úroveň kontroly nad provozním nastavením systému včetně možnosti návratu k předchozí verzi konfigurace. Dle navrhovatele zadavatel tuto námitku v rozhodnutí o námitkách nevyvrátil. Dle navrhovatele skutečnost, že LogMan.io (základ, ze kterého vychází nástroj vybraného dodavatele) používá architekturu microservices, nemusí nutně znamenat, že tento nástroj také podporuje všechny funkcionality, jejichž absenci u tohoto nástroje navrhovatel namítal. Současně navrhovatel uvádí, že zadavatel v rozhodnutí o námitkách či předchozím správním řízení sp. zn. ÚOHS-S0379/2021/VZ neuvedl nic relevantního k požadavku na „rolling upgrade“. Navrhovatel pak dále uvádí, že v dokumentaci k LogMan.io nikde není zmíněná kapitola o upgrade nebo downgrade systému ani o centrální konzoli.

10.         Navrhovatel dále uvádí, že v době podání tohoto návrhu nedisponuje přístupem k nabídce vybraného dodavatele ani k neveřejné části dokumentace nástroje LogMan.io. V tomto kontextu navrhovatel žádá Úřad, aby si podklady k nástroji Logman.io od společnosti TeskaLabs vyžádal a následně je v kontextu podaného návrhu posoudil. Stejně tak navrhovatel Úřad žádá, aby si od výrobce nástroje Logman.io tj. společnosti Teskalabs vyžádal kompletní českou verzi dokumentace k nástroji LogMan.io a jeho jednotlivým komponentám a tuto taktéž v kontextu podaného návrhu posoudil. Současně navrhovatel uvádí, že není možné po něm požadovat zcela podrobné a detailní odůvodnění, proč plnění nabízené vybraným dodavatelem nesplňuje technické požadavky zadavatele, když navrhovatel nemůže objektivně disponovat všemi nezbytnými podklady.

11.         K námitce, že „nabízený nástroj navíc v rozporu s bodem 506 Přílohy č. 1 negarantuje integritu uložených dat a umožňuje mazání a modifikaci uložených logů, přičemž tato skutečnost je také v rozporu s legislativními a normativními požadavky kladenými na tento nástroj prostřednictvím vyhlášky č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti), přičemž nesplnění těchto požadavků je v přímém rozporu s bodem 901 Přílohy č. 1 smlouvy“, pak navrhovatel dodává, že argumentace zadavatele týkající se režimu write-once, která má být dle zadavatele zajištěna pomocí kryptografických funkcí, je absurdní. Dle navrhovatele kryptografické funkce mohou napomoci předejít pozměnění logů, v žádném případě však nemohou napomoci zabránit jejich smazání. Použití kryptografických funkcí tak dle názoru navrhovatele zajišťuje toliko kontrolu integrity (tedy zjištění, zda byl zápis změněn), přičemž zápis před samotnou změnou či smazáním nechrání.

12.         Navrhovatel je dle svých slov nadále přesvědčen, že v rozporu s požadavkem dle bodu č. 201 přílohy č. 1 smlouvy nástroj vybraného dodavatele neumožňuje hardwarovou appliance, ale toliko appliance virtuální. Navrhovatel je přitom přesvědčen, že by vybraný dodavatel nemohl hardware dle požadavků zadavatele dodat s ohledem na jeho velmi nízkou nabídkovou cenu.

13.         Navrhovatel má dále za to, že nástroj vybraného dodavatele v rozporu s body 101 až 144 přílohy č. 1 smlouvy nepodporuje sběr, parsování a normalizaci logů požadovaných platforem a technologií. K tomu navrhovatel uvádí, že v námitkách zcela jednoznačně označil, že nástroj LogMan.io nepodporuje tuto funkcionalitu v rozporu s body 101 až 144 Přílohy č. 1 smlouvy jako celek, a tudíž zpochybňoval možnost podpory všech platforem. Skutečnost, že tato funkcionalita není podporována, pak dle navrhovatele vyplývá i z dokumentace nástroje LogMan.io, a to minimálně v rozsahu bodů 102, 103, 121, 122, 127, 134 a 135 přílohy č. 1 smlouvy. Z dokumentace nástroje žádným způsobem nevyplývá, že by nástroj LogMan.io v souladu s požadavky zadavatele podporoval také parsování a normalizaci logů platforem a technologií Apache httpd, Apache Tomcat, Kernun Clear Web, Kernun web filter, Microsoft Exchange log, MS Azure Cloud (který zahrnuje mj. funkce MS office 365) a MS Azure Sentinel. Obecně se dle navrhovatele (minimálně ve vztahu k MS Azure Cloud) nejedná o funkcionality, které by bylo možné do systému jednoduše doprogramovat. Je přitom zřejmé, že pokud výrobce neuvádí podporu těchto zásadních platforem a technologií (např. MS Azure Cloud patří z pohledu uživatele systému ke zcela zásadním), jeho řešení tyto platformy a technologie nepodporuje.

14.         Mnoho z údajně produktem LogMan.io podporovaných technologií potřebuje dle navrhovatele složitou konfiguraci nejen v rámci LogMan.io, ale i jeho komponent. V dokumentaci k produktu se přitom nenachází žádný popis nastavení zdrojových systémů, jejich podpora, ani nastavení na straně produktu LogMan.io. Minimálně zajištění podpory MS Azure Cloud (bod 134 přílohy č. 1 smlouvy) je dle navrhovatele značně složitou problematikou, když vyžaduje vývoj API, které propojení této technologie zajistí, což je značně časově, finančně, technologicky a odborně náročný proces, který není možné provést v krátkém časovém horizontu.

15.         K tabulce a dokumentaci LogMan.io, na kterou odkazoval vybraný dodavatel ve svých vyjádřeních v rámci správního řízení sp. zn. ÚOHS-S0379/2021/VZ, navrhovatel uvádí, že uvedené specifikuje parsování pouze zlomku zadavatelem požadovaných zdrojů. Z této části dokumentace pak zároveň vyplývá, že u zdrojů, které jsou podporovány, dochází k parsování pouze hlaviček logů daných zdrojů, nikoliv jejich vlastního obsahu. Výjimku tvoří pouze logy, které jsou předávané ve strukturovaném formátu (zde formáty CEF a JSON), kde je parsování algoritmizované již samotným formátem předávaných dat. Dle navrhovatele je zřejmé, že ačkoliv celá tabulka na první pohled působí dojmem, že nástroj LogMan.io podporuje parsování všech logů a technologií požadovaných zadavatelem, a to v zadavatelem požadovaném rozsahu, po jejím důkladném prostudování nezbývá než dojít k závěru, že tomu tak není. Z tabulky je přitom dále dle navrhovatele evidentní neznalost dotčené problematiky vybraným dodavatelem a také to, že nástroj LogMan.io parsování a normalizaci některých zdrojů podporovat nemůže.

16.         Navrhovatel poukazuje na to, že např. ve vztahu k podpoře MS Azure Cloud vybraný dodavatel uvádí, že logy z této platformy budou získávány prostřednictvím transportního protokolu. Získat tímto způsobem logy z MS Azure Cloud ovšem dle navrhovatele není možné. Obdobné uvádí navrhovatel i k platformě VMware, přičemž dle navrhovatele nástroji LogMan.io chybí jak potřebné API rozhraní VMware, tak dokumentace, jak daný zdroj nastavit. Nástroj LogMan.io tak parsování a normalizaci logů z této platformy nepodporuje, když uvedené logy nemůže ani získat. Skutečnost, že nástroj neumožňuje data ani sbírat, je pak navíc v přímém rozporu s body 401 až 421 přílohy č. 1 smlouvy.

17.         Ve vztahu k požadavku na podporu platformy Microsoft SQL pak vybraný dodavatel odkazuje na Microsoft SQL Server 2008, přičemž se dle navrhovatele jedná o již dlouhou dobu nepodporovaný systém, což mimo jiné znamená, že již nemůže obdržet bezpečnostní aktualizace. Z uvedeného přitom dle navrhovatele vyplývá, že jestliže vybraný dodavatel tento systém v rámci procesu parsování a normalizace logů používá, nemůže nástroj LogMan.io splňovat požadavky stanovené v bodu 901 a 902 přílohy č. 1 smlouvy. Nástroj LogMan.io v takovém případě dle navrhovatele nesplňuje požadavky na jeho bezpečnost ve vztahu k zachování a neměnnosti logů, potažmo ve vztahu k systému jako celku.

18.         Ve vztahu k požadavku na normalizaci a parsování logů ze zdroje Microsoft – any logs from Event Viewer pak dle navrhovatele vybraný dodavatel odkazuje na přítomnost parseru pro dávno nepodporovaný systém Microsoft Sharepoint 2012, nikoliv na logy Microsoft Event View.

19.         Navrhovatel je zároveň nadále přesvědčen, že nástroj nabízený vybraným dodavatelem nemá v rozporu s bodem 153, 154 a 159 přílohy č. 1 smlouvy nijak řešenu zálohu a obnovu konfigurací celého nástroje z centrální konzole a rovněž neumožňuje nastavení nezávislé zálohovací politiky, což dle navrhovatele vyplývá zejména z uživatelského manuálu tohoto nástroje. Dokumentace nástroje LogMan.io dle navrhovatele nepopisuje a ani nezmiňuje v žádném bodě zálohování nebo obnovování konfigurace systému jako celku prostřednictvím centrální konzole a způsob zpracování zálohy konfigurace.

20.         K tomu v reakci na rozhodnutí o námitkách dále navrhovatel uvádí, že požadavek na možnost nastavení nezávislé zálohovací politiky rozhodně nezahrnuje pouze možnost určit, kde se data nachází. Pokud má nástroj umožňovat nastavení nezávislé zálohovací politiky, nestačí pouze pokud je schopen identifikovat, kde se data v systému nachází, ale musí také z logiky věci umožňovat nastavení, kdy a v jakém rozsahu mají být zálohy prováděny a takto nastavené zálohování také provést, a to sám o sobě. Současně navrhovatel poukazuje na to, že dle jeho názoru sám zadavatel v rozhodnutí o námitkách potvrzuje, že nástroj LogMan.io (ani žádná
z jeho komponent či jiných částí plnění poskytovaných vybraným dodavatel) neumožňuje tvorbu záloh, přičemž logicky nemůže umožňovat ani tvorbu zálohovací politiky. Dále navrhovatel k argumentu zadavatele, že zálohovací politika je implementována pomocí „Index Lifecycle Management“ (dále jen „ILM“) uvádí, že ILM se k zálohování logů ani k tvorbě samotné zálohovací politiky nijak nevztahuje, neboť ILM se vztahuje toliko k životnímu cyklu jednotlivých logů nebo jejich skupin. ILM totiž dle navrhovatele umožňuje pouze definici a „druhů“ uložení dat (logů a jejich skupin) v nástroji. Dle navrhovatele žádná z fází ILM a ani ILM samotné nemá nic společného se samotným zálohováním roztříděných logů či jejich souborů. V žádné z těchto fází ani ve spojení s nimi totiž nedochází k tvorbě záloh žádných dat, které by bylo následně možné v případě poškození/zničení originálu dat obnovit a ztracená data tak „získat zpět“.

21.         Daný nástroj pak také dle názoru navrhovatele v rozporu s bodem 145 přílohy č. 1 smlouvy neumožňuje přístup více uživatelů současně. Ani tato funkcionalita totiž dle navrhovatele
z veřejně dostupných dokumentů nevyplývá a zadavatel v rozhodnutí o námitkách pouze konstatoval, že nástroj tuto funkcionalitu podporuje a ničím relevantním tuto skutečnost nepodložil.

22.         Navrhovatel také dále trvá na námitce, že daný nástroj v rozporu s body 146 a 166 přílohy č. 1 smlouvy neumožňuje snadné vytváření a definování uživatelských rolí s možností definice přístupových práv a granulárního přidělování práv v rámci rolí, podle zdrojů logů, skupin zařízení, jednotlivých serverů, typu logu, když jejich definice je řešena tenanty, nikoliv pomocí pokročilých funkcí jako jsou RBAC, což podle něj plyne z veřejně dostupné dokumentace. Navrhovatel dále k tomu uvádí, že pokud tato základní funkcionalita jako RBAC není v dokumentaci ani slovem zmíněna, je zřejmé, že ve smyslu požadavku zadavatele v nástroji LogMan.io (a to ani prostřednictvím komponenty SeaCat) není k dispozici. V tomto kontextu navrhovatel Úřad upozorňuje také na skutečnost, že z dokumentace nástroje LogMan.io ani ze zadavatelem poskytnutých odkazů do dokumentace nevyplývá, že by tento nástroj splňoval také požadavky dle bodu 147, 148, 149 a 150 přílohy č. 1 smlouvy, přičemž se jedná o požadavky spojené s požadavkem dle bodu 146 přílohy č. 1 smlouvy.

23.         Ani ve vztahu k námitce, že nástroj dle uživatelského manuálu zároveň v rozporu s bodem 304 přílohy č. 1 smlouvy neumožňuje aktualizaci systému v jednom kroku a v jednotném balíku prostřednictvím centrální konzole a neumožňuje ani rolling upgrade, a v rozporu s bodem 305 přílohy č. 1 smlouvy neumožňuje ani downgrade, přičemž veškerá konfigurace není verzována ve version control systému (Git) tak, aby byla zajištěná vysoká úroveň kontroly nad provozním nastavením systému včetně možnosti návratu k předchozí verzi konfigurace, zadavatel dle navrhovatele neuvedl v rozhodnutí o námitkách žádnou relevantní argumentaci, která by tento závěr navrhovatele vyvracela.

24.         K uvedenému navrhovatel dále doplňuje, že zadavatelem odkazované části dokumentace nástroje Logman.io neprokazují jím tvrzené skutečnosti, ale pravý opak. Navrhovatel mj. uvádí, že část dokumentace nástroje LogMan.io[1] obsahuje informace prokazující, Logman.io používá pro správu verzí nástroj GIT, že jsou jednotlivé komponenty Logman.io zabaleny a provozovány v dockeru a že pro správu docker kontejneru používá docker-compose. Proces aktualizace je dle navrhovatele následující: 1. git pull; 2. docker-compose pull; 3. docker-compose up -d. Dle navrhovatel se tedy proces aktualizace se v případě nástroje LogMan.io skládá ze tří kroků a nikoliv jednoho, jak se snaží tvrdit zadavatel. Tato skutečnost je přitom v přímém rozporu s požadavkem zadavatele dle bodu 304 přílohy č. 1 smlouvy na umožnění aktualizace v jednom kroku. Další skutečností je dle navrhovatele to, že z žádné části veřejné dokumentace není zřejmé, že by se aktualizace systému prováděla jinak, než pomocí nástrojů pro příkazovou řádku git, docker, docker-compose. Vzhledem k tomu, že SSH shell, prostřednictvím které jsou výše uvedené příkazy používány, nelze považovat za „centrální konzoli“ ve smyslu požadavku dle bodu 304 přílohy č. 1 smlouvy, je dle navrhovatele zřejmé, že nástroj LogMan.io nesplňuje ani požadavek na aktualizaci prostřednictvím centrální konzole. K tomu navrhovatel dále ve svém návrhu odkazuje na strukturu nástroje Logman.io.

25.         Skutečnost, že SSH shell příkaz docker-compose nelze považovat za provedení aktualizace prostřednictvím centrální správcovské konzole, jelikož spravuje pouze microservice spuštěné na tom konkrétním node, kde příslušný uživatel daný příkaz spustí, pak dle navrhovatele prokazuje tvrzení samotného vybraného dodavatele uvedeného v rámci vyjádření ve správním řízení sp. zn. ÚOHS-S0379/2021/VZ. Sám zadavatel navíc dle navrhovatele odkazuje na centrální konzoli (která dle navrhovatele není v dokumentaci nástroje vůbec zmíněna, natož snad popsána) jako na SSH konzoli k systému. Lze přitom s jistotou tvrdit, že se nejedná o centrální konzoli, nýbrž o konzoli k jednomu systému v rámci clusteru. Dle navrhovatele je tedy zřejmé, že požadavek na aktualizaci systému prostřednictvím centrální konzole není splněn, když dle dokumentace jsou k aktualizaci užívány příkazy vztahující se vždy toliko k jednomu členovi clusteru, tj. ke každé dílčí komponentě zvlášť, a nikoliv k celému clusteru.

26.         Ani využití architektury microservices dle navrhovatele nezaručuje splnění zadavatelova požadavku na průběh aktualizace (Rolling upgrade atd.), když i při jejím využití se může výrobce systému rozhodnout takovou funkcionalitu neimplementovat a tím při vývoji nástroje ušetřit čas a náklady. Nástroj nabízený vybraným dodavatelem tak požadavek zadavatele dle bodu 304 přílohy č. 1 smlouvy nesplňuje, když neumožňuje aktualizaci celého nástroje prostřednictvím centrální konzole.

27.         Navrhovatel je i nadále přesvědčen, že nástroj nabízený vybraným dodavatelem v rozporu s bodem 401 a 506 přílohy č. 1 smlouvy nezabezpečuje data proti jejich modifikaci nebo smazání a zároveň umožňuje mazání nebo modifikování již uložených logů. Zadavatelem odkazované kryptografické funkce nemohou splnění těchto zadávacích podmínek nástrojem zajistit. Použití kryptografických funkcí zajišťuje toliko kontrolu integrity (tedy zjištění, zda byl zápis změněn), přičemž zápis před samotnou změnou či smazáním nechrání. To je dle navrhovatele přitom v přímém rozporu s bodem 401 a 506 přílohy č. 1 smlouvy a je tak dle jeho názoru zřejmé, že se zadavatel s námitkou toho, že nástroj umožňuje v rozporu s požadavky zadavatele mazání a modifikaci logů, řádně nevypořádal.

28.         Z veřejně dostupné dokumentace a rozhodnutí o námitkách č. 2 nástroje dle navrhovatele vyplývá, že jeho instalaci provádí sám uživatel (zde zadavatel), přičemž v takovém případě musí mít přístup k root oprávněním celého systému. V takovém případě však zadavatel, respektive jím pověřená osoba, může využít těchto root oprávnění a smazat jak samotný systém, tak všechna data, která jeho prostřednictvím byla uložena. Současně navrhovatel uvádí, že s ohledem na to, co uvádí zadavatel v rozhodnutí o námitkách, tak navrhovatel má za to, že vybraný dodavatel svým nástrojem porušuje pravidla poskytnutí licence komponenty Elasticsearch (a tedy je v rozporu s požadavky zadavatele uvedenými v čl. 8 návrhu smlouvy) či nedodržuje integritu systému.

29.         Navíc i v případě, že by instalaci neprováděl samotný uživatel, je navrhovatel přesvědčen, že z veřejné části dokumentace nástroje LogMan.io vyplývá, že root přístup bude zachován minimálně zástupci vybraného dodavatele/výrobci nástroje LogMan.io, případně jiné osobě provádějící instalaci nástroje. V takovém případě bude mít vždy daná osoba možnost smazat celý systém včetně všech jeho uložených logů, což je v rozporu s požadavkem zadavatele v bodu 506 přílohy č. 1 smlouvy, přičemž tato skutečnost je také v rozporu s legislativními a normativními požadavky kladenými na tento nástroj prostřednictvím vyhlášky, přičemž nesplnění těchto požadavků je v přímém rozporu rovněž s bodem 901 přílohy č. 1 smlouvy. Dále navrhovatel poukazuje na to, že funkcionality, které jsou nutné k běžnému provozu a užívání nástroje LogMan.io, vyžadují oprávnění role root, není možné, aby byl zachován požadavek na nezměnitelnost a nesmazatelnost jednotlivých zápisů.

30.         Co se týče dříve předloženého znaleckého posudku, navrhovatel konstatuje, že z něj žádným způsobem nevyplývá, jak znalec došel k závěru, že nástroj LogMan.io splňuje všechny legislativní požadavky dle vyhlášky. Z obrázků ani skutečností uvedených ve znaleckém posudku totiž nevyplývá nic, na čem by bylo uvedený závěr možné postavit. V tomto kontextu se tedy jeví jako vhodné, aby Úřad v souladu se zásadou materiální pravdy nechal zpracovat revizní znalecký posudek, který by funkcionalitu daných požadavků zadavatele v nástroji LogMan.io ověřil, a to na základě provedení praktické zkoušky.

31.         Co se týče námitky, že nástroj v rozporu s body 510 a 511 přílohy č. 1 smlouvy neumožňuje definici a zasílání alertů (upozornění) pomocí SMTP, přičemž v rozporu s bodem 810 a 813 přílohy č. 1 smlouvy ani nedisponuje předpřipravenými alerty (upozorněními) a pohledy na uložená data dle kategorií a logického členění a nepodporuje jejich zasílání v různých formátech PDF, HTML a CSV příp. dalších, a námitky, že v nástroji rovněž chybí předdefinované pohledy na uložená data, tzv. dashboardy dle bodů 705 a 706 přílohy č. 1 smlouvy, podle navrhovatele zadavatel nijak nepotvrdil, že by stejné formáty byly podporovány také v rámci odesílání alertů pomocí SMTP, přičemž navrhovatel má dále za to, že použitá komponenta KIBANA vytváření reportů ve formátu HTML nepodporuje.

32.         Ve vztahu k námitce, že v rozporu s bodem 512 přílohy č. 1 neumožňuje nástroj konfiguraci notifikací pomocí grafického vizuálního programovacího jazyka formou obrázků obsahujících aplikační logiku, neboť celá konfigurace probíhá prostřednictvím příkazových řádek zadáváním písemných příkazů, navrhovatel konstatuje, že argumentace zadavatele k této námitce uvedená v rozhodnutí o námitkách není pravdivá, nebo přinejmenším není ze strany zadavatele podložená relevantními podklady. Sám zadavatel dle navrhovatele v poznámce pod čarou č. 6 uvádí odkaz na LogMan.io, avšak z tohoto odkazu je dle navrhovatele zřejmé, že LogMan.io žádným grafickým vizuálním prostředím pro tvorbu aplikační logiky nedisponuje, když veškeré programování probíhá pomocí příkazového řádku, tedy ve formě textu.

33.         Navrhovatel k tomu dále uvádí, že dokumentace k produktu LogMan.io neobsahuje žádnou zmínku o podpoře vizuálního programování. Poznámka pod čarou číslo 9 rozhodnutí o námitkách č. 2 totiž dle navrhovatele obsahuje odkaz na deklarativní jazyk používaný pro psaní parserů v rámci produktu LogMan.io, nikoliv na zadávací dokumentací požadované použití vizuálního programovacího jazyka. Dle veřejně dostupné dokumentace, na kterou zadavatel odkazuje, je dle navrhovatele zřejmé, že produkt LogMan.io nemá integrovanou grafickou nadstavbu používající aplikační logiku pro vizuální programování. „SP-Lang“ je navíc termín, jehož obsah není zadavateli, ale ani obecně v dotčeném odvětví známý (což dle navrhovatele vyplývá i z toho, že tento pojem nelze vyhledat prostřednictvím internetového vyhledávače a není ani popsán na wikipedii). Navrhovateli tedy není zřejmé, co se snaží zadavatel poukazem na tento „jazyk“ prokázat. Navrhovateli ani není zřejmé, jak zadavatel k tomuto „pojmu“ přišel, přičemž zde je důvodné se domnívat, že zadavatel cituje „nějaký“ podklad od vybraného dodavatele, aniž by bylo zřejmé, zda předmětný podklady byl součástí nabídky, nebo byl opatřen od vybraného dodavatele v souvislosti s přípravou vyjádření k návrhu. Druhá z obou možnosti by pak zjevně indikovala rozpor se zásadou transparentnosti a rovného přístupu.

34.         Dále navrhovatel uvádí, že ze zadavatelem tvrzené kombinace prostředí YAML a deklarativního jazyka SP-Lang splnění požadavku na programování prostřednictvím obrázků nevyplývá. YAML je dle navrhovatele textový formát, který specifikuje strukturu dokumentu (textu), přičemž česká ani anglická wikipedie k prostředí YAML, ani hlavní web tohoto formátu, a dokonce ani manuál LogMan.io nezmiňují žádnou možnost práce s tímto formátem prostřednictvím obrázků (vizuálně).

35.         Ani ve vztahu k absenci překladu dokumentace nástroje a veškerého jeho konfiguračního a nástrojového rozhraní do českého jazyka zadavatel dle navrhovatele neuvedl žádné konkrétní skutečnosti, o které by opřel svá tvrzení, že nástroj nabízený vybraným dodavatelem tyto požadavky zadavatele splňuje.

36.         Ze všeho výše uvedeného tak dle navrhovatele vyplývá, že nabídka vybraného dodavatele byla zpracována v rozporu se zadávacími podmínkami a vybraný dodavatel měl být tedy v souladu s ustanovením § 48 odst. 2 písm. a) nebo c) zákona, ve spojení s ustanovením § 48 odst. 8 zákona ze zadávacího řízení vyloučen. To se ovšem nestalo a zadavatel místo toho přistoupil
k odeslání oznámení o výběru, čímž se dle navrhovatele dopustil porušení ustanovení § 48 odst. 8 zákona.

37.         Nadto navrhovatel upozorňuje, že není přípustné, aby vybraný dodavatel po uplynutí lhůty pro podání nabídek daný software nějak dále upravoval a tím fakticky měnil podstatu své nabídky, resp. dodávané plnění, přičemž k okamžiku uplynutí lhůty pro podání nabídek nástroj LogMan.io požadavky zadavatele dle navrhovatele nesplňoval a ani splňovat nemohl. Navrhovatel je tak přesvědčen, že dochází ze strany vybraného dodavatele k neustálým a kontinuálním změnám nabídky, které jsou ze své podstaty v rozporu s ustanovením § 46 odst. 2 zákona.

38.         V čl. IV návrhu se navrhovatel vyjadřuje k nesprávnému posouzení MNNC, přičemž uvádí, že zadavatel nepostupoval způsobem, který vyžaduje zákon a rozhodovací praxe, když si zřejmě zdůvodnění MNNC od vybraného dodavatele vůbec nevyžádal, nebo pokud si jej vyžádal, toto vyjádření dostatečně kriticky nepřezkoumal. Pokud by tak totiž učinil, musel by dle navrhovatele dojít k jednoznačnému závěru, že předmět veřejné zakázky nelze vůbec za nabídkovou cenu vybraného dodavatele realizovat, pokud by vybraný dodavatel měl dodržet všechny zákonem a zadavatelem stanovené povinnosti ve smyslu § 113 odst. 4 písm. a) zákona nebo pokud by vybraný dodavatel neobdržel neoprávněnou veřejnou podporu dle § 113 odst. 4 písm. b) zákona. Zadavatel tak i tímto svým postupem zatížil dle navrhovatele zadávací řízení vadou, když v rozporu s § 6 odst. 1 zákona, a tedy v rozporu se zásadou přiměřenosti a transparentnosti, a rovněž v rozporu s ustanovením § 113 odst. 1 zákona neprovedl řádné posouzení zákona obsažené v nabídce vybraného dodavatele, a když v rozporu s § 113 odst. 6 vybraného dodavatele ze zadávacího řízení nevyloučil. Současně navrhovatel odkazuje na svou argumentaci uvedenou v námitkách, kde nad výše uvedené uvádí, že nabídka vybraného dodavatele byla nízká ve srovnání s nabídkami ostatních dodavatelů a taktéž ve srovnání s předpokládanou hodnotou veřejné zakázky.

39.         Závěrem návrhu navrhovatel shrnuje, že nabídka vybraného dodavatele nesplňuje požadavky zadavatele, zákona a vyhlášky, přičemž vybraný dodavatel měl být z tohoto důvodu v souladu s § 48 odst. 2 písm. a) nebo c) zákona vyloučen a zadavatel měl dle § 48 odst. 8 zákona povinnost takto učinit, což se ovšem nestalo. Navrhovatel je také přesvědčen, že nabídka vybraného dodavatele obsahuje MNNC, kterou vybraný dodavatel nemůže řádně zdůvodnil, a charakter MNNC vybraného dodavatele, v kombinaci s nedostatky jím nabízeného řešení, jednoznačně znemožňuje řádné plnění předmětu veřejné zakázky. S ohledem na uvedené navrhovatel navrhuje, aby Úřad rozhodl o návrhu tak, že zadavatel nedodržel postup stanovený zákonem, a aby uložil zadavateli opatření k nápravě spočívající ve zrušení rozhodnutí o výběru i všech navazujících úkonů, a aby zavázal zadavatele, aby následně provedl nové posouzení nabídek, vyloučil vybraného dodavatele z další účasti v zadávacím řízení a rozhodl o výběru nabídky navrhovatele.

III.           PRŮBĚH SPRÁVNÍHO ŘÍZENÍ

40.         Podle § 249 zákona ve spojení s § 44 odst. 1 zákona č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů (dále jen „správní řád“) bylo zahájeno správní řízení o přezkoumání úkonů zadavatele dne 27. 12. 2021, kdy Úřad obdržel návrh navrhovatele. Předmět správního řízení je vymezen obsahem uvedeného návrhu.

41.         Účastníky správního řízení podle § 256 zákona jsou:

• zadavatel,
• navrhovatel,
• vybraný dodavatel.

42.         Zahájení správního řízení oznámil Úřad jeho účastníkům oznámením č. j. ÚOHS-44335/2021/511/KZa ze dne 28. 12. 2021.

43.         Dne 6. 1. 2022 Úřad od zadavatele obdržel dokumentaci o zadávacím řízení. Tentýž den Úřad rovněž obdržel vyjádření zadavatele k návrhu z téhož dne (dále jen „vyjádření k návrhu“).

Vyjádření zadavatele ze dne 6. 1. 2022

44.         Zadavatel v prvé řadě uvádí, že navrhovatelův návrh se obsahově shoduje s návrhem ze dne 2. 9. 2021, přičemž nově přidal pouze svou argumentaci ze své repliky k vyjádření zadavatele ze dne 2. 9. 2021, která byla již posuzována v rámci správního řízení sp. zn. S0379/2021/VZ. Z tohoto důvodu zadavatel odkazuje na svá vyjádření učiněná v citovaném správním řízení, a to na vyjádření k návrhu ze dne 13. 9. 2021 a vyjádření k podkladům rozhodnutí ze dne 12. 11. 2021. S ohledem na výše uvedené Úřad poté, co níže shrne obsah vyjádření zadavatele ze dne 6. 1. 2022, shrne i obsah vyjádření k návrhu ze dne 13. 9. 2021 a vyjádření k podkladům rozhodnutí ze dne 12. 11. 2021 (tj. vyjádření podaných ve správním řízení sp. zn. S0379/2021/VZ).

45.         Zadavatel zdůrazňuje zejména to, že navrhovatel neustále setrvává v té argumentační rovině, kdy by za jediné řádné vypořádání jeho námitek považoval předložení, resp. praktickou demonstraci funkčnosti řešení vybraného dodavatele. To však zadavatel považuje za nemožné, přičemž analogicky řečeno jde dle jeho názoru v daném případě o totéž, jako by v zakázce na zhotovení stavby navrhovatel žádal po zadavateli za účelem ověření např. správnosti statických výpočtů či tepelně izolačních vlastností stavby zhotovení samotné stavby.

46.         Dále zadavatel upozorňuje na to, že navrhovatel ve svém návrhu odkazuje na přílohu návrhu, která mu nebyla však zaslána. Zadavatel v tomto ohledu má za to, že navrhovatel nesplnil svou povinnost uloženou mu v § 251 odst. 1 a 2 zákona, neboť návrh neobsahuje všechny písemné důkazní prostředky, na které se navrhovatel odvolává (resp. takto byl alespoň zadavateli zaslán), což mj. dle zadavatele znamená, že přinejmenším zadavateli nebyl v zákonné lhůtě dle § 251 odst. 2 zákona návrh doručen v kompletní podobě.

47.         Zadavatel uvádí, že z důvodu nezaslání příloh návrhu se není objektivně schopen vyjádřit k argumentaci obsažené v odst. 35 až 43, 63 a 64 návrhu č. 2, neboť pro takové vyjádření nedisponuje potřebnými podklady. I přes uvedené zadavatel uvádí, že údajné tvrzení vybraného dodavatele obsažené v první větě odst. 41 návrhu č. 2 zadavatel v dokumentaci předložené vybraným dodavatelem v rámci zadávacího řízení nikde nenalezl. Navíc zadavatel požaduje podporu platformy MS SQL bez uvedení verze obecně a vybraný dodavatel potvrzuje, že předmětný systém toto splňuje.

48.         K tvrzením navrhovatele obsaženým v odst. 33 návrhu č. 2 zadavatel uvádí, že zde navrhovatel toliko spekuluje o tom, že podpora zpracování logů získaných z platformy AZURE je složitá a není časově možné ji zvládnout. To je ovšem velmi zavádějící tvrzení, které je postaveno čistě na subjektivním pocitu či dojmu. Z hlediska zadavatele je podstatné to, že vybraný dodavatel uvedl, že je schopen plnění poskytnout, přičemž zadavatel nemá rozumné důvody zpochybňovat to, že vybraný dodavatel disponuje zkušeností s implementací, a jeho deklaraci, že jím nabízený produkt uvedené podporuje a on má znalosti potřebné k implementaci navrhovaného řešení.

49.         Tvrzení navrhovatele obsažená v odst. 34 návrhu č. 2 pak zadavatel považuje předně za zmatečná, neboť čistě z textace jmenovaného odstavce zadavateli není jasné, co přesně chce navrhovatel říci, resp. uvedené chápe nejvýše jako nepodloženou spekulaci, že bude nutno v rámci řešení vybraného dodavatele implementovat další API.

50.         Ke skutečnostem uváděným v odst. 47 až 50 návrhu č. 2 zadavatel nejprve uvádí, že citace uvedená v odst. 48 návrhu č. 2 je vytržena z kontextu, resp. následné závěry navrhovatele zcela zjevně ignorují zbytek textu odst. 16 rozhodnutí o námitkách č. 2, kde je tvorba záloh a zálohovací politiky v řešení vybraného dodavatele popsána. Argumentace navrhovatele se pro zadavatele nepochopitelně omezuje na tvrzení, že nástroj nabízený vybraným dodavatelem sám o sobě nevytváří kopie určené k zálohování (byť i toto v něm provést lze), přičemž ignoruje úvod odpovědi zadavatele, v níž je popsáno, že předmětný nástroj poskytuje připravená data k zálohování a umožňuje potom obecnými nástroji zálohu vytvořit.

51.         V případě odst. 79 návrhu č. 2 pak zadavatel poukazuje na to, že se navrhovatel snaží překrucovat argumentaci, kterou zadavatel uvedl ve svých dřívějších vyjádřeních.

52.         K podmínce grafického vizuálního prostředí pro tvorbu aplikační logiky zadavatel opětovně uvádí, že produkt TeskaLabs LogMan.io nabízený vybraným dodavatelem v jeho nabídce obsahuje výkonný deklarativní jazyk SP-Lang, přičemž tento jazyk je používán pro tvorbu vlastních parserů, normalizaci, logů, vytváření korelací a konfiguraci notifikací. SP-Lang poskytuje dle navrhovatele i grafické vizuální prostředí pro tvorbu aplikační logiky. Svým uživatelům pak umožnuje vytvářet jednoduchou formou vysoce výkonné konfigurace respektive deklarace. LogMan.io nabízí i možnost práce přes příkazový řádek (CLI), což je varianta preferovaná pokročilými uživateli, kteří chtějí mít absolutní kontrolu nad provozem nástroje nebo požadují hlubokou integraci např. v rámci SOCu (Security Operation Centre). Příkazový řádek ale představuje jen jednu z variant (tj. nikoliv jedinou variantu), jak LogMan.io konfigurovat pro konkrétní úlohy. Současně zadavatel přiložil jako přílohu tohoto vyjádření zevrubný popis jazyka SP-Lang.

53.         Ke skutečnostem uvedeným v odst. 86 návrhu č. 2 zadavatel uvádí, že především vůbec nereflektují realitu kontraktačního procesu v rámci zadávání veřejných zakázek. Zadavatel dle svých slov pochopitelně prověřil nabídku vybraného dodavatele dle jejího obsahu a následně seznal, že vyhovuje zadání tak, jak byla podána. Proto také to, zda nástroj nabízený vybraným dodavatelem pro plnění veřejné zakázky i po podání nabídky dál procházel vývojem, není dle zadavatele podstatné. Obecně přitom platí, že zadavatelé de facto posuzují nabídku vždy „pouze“ jako určitý předem definovaný závazek dodavatele - např. ani u dodávky kancelářského papíru není potřebné a často ani možné, aby dodavatel disponoval ve chvíli podání nabídky celým objemem zboží, které má na základě smlouvy dodat, u stavební zakázky zase není třeba, aby dodavatel disponoval v momentě podání nabídky veškerým stavebním materiálem, atp.

54.         V návaznosti na uvedené a dále k tvrzením a závěrům navrhovatele obsaženým v odst. 87 návrhu č. 2 zadavatel uvádí, že nástroj LogMan.io není dle vědomostí zadavatele nabízen výlučně jako plnění této veřejné zakázky, ale výrobce jej distribuuje i jiným svým klientům. Je přitom dle zadavatele logické, že jeho výrobce nemůže zastavit jeho vývoj jen proto, že figuruje jako poddodavatel určité veřejné zakázky. Taková představa je obzvláště v tak dynamickém sektoru, jako je vývoj IT, dle zadavatele naprosto absurdní.

55.         Co se týká odkazu na metadata příloh č. 1 až 4 rozhodnutí o námitkách č. 2 v odst. 87 návrhu 2, pak zadavateli není jasné, jaká metadata má navrhovatel na mysli, neboť přílohy rozhodnutí o námitkách č. 2 obsahovaly pouze ilustrativní screenshoty (tj. obrázky), a proto není schopen na tuto výtku reagovat, neboť obsah závěrů navrhovatele není objektivně zřejmý. Ohledně tvrzení navrhovatele o údajné úzké spolupráci vybraného dodavatele na vypořádání námitek navrhovatele pak zadavatel v tomto ohledu odkazuje již na své rozhodnutí o námitkách č. 1 a vyjádření ze dne 13. 9. 2021.

56.         Zadavatel dále doplňuje, že v obecné rovině nabídka sama o sobě nemůže obsahovat bez dalšího úplně vše, na co se může navrhovatel teoreticky zeptat, neboť to by součástí nabídky de facto muselo být její vlastní a kompletní plnění, což jednoduše není reálné (v tomto konkrétním případě by opět musel zadavatel požadovat předložení funkčního řešení již v nabídkách, k čemuž se zadavatel již vyjadřoval výše).

57.         Co se týká posouzení MNNC v nabídce vybraného dodavatele, zadavatel uvádí, že problematiku technické relevance nabídky a mimořádně nízké nabídkové ceny samozřejmě posuzoval ve vzájemných souvislostech, neboť jinak dle názoru zadavatele ani postupovat nelze, jelikož (ne)relevanci ceny ve smyslu případné existence MNNC je třeba vždy porovnávat s konkrétně nabídnutým plněním. Uvedené ostatně vyplývá dle názoru zadavatele přímo z obsahu jeho žádosti o vysvětlení nabídky a zdůvodnění mimořádně nízké nabídkové ceny zaslané vybranému dodavateli dne 16. 6. 2021. Jelikož pak k otázce MNNC navrhovatel v příslušné části návrhu č. 2 neuvedl nic, co by již nebylo obsaženo v návrhu č. 1, zadavatel opětovně odkazuje na své vyjádření ze dne 13. 9. 2021 a rovněž na závěry Úřadu obsažené v odst. 106 rozhodnutí č. 1.

Vyjádření zadavatele k návrhu ve správním řízení sp. zn. S0379/2021/VZ

58.         Ve svém vyjádření ze dne 13. 9. 2021 zadavatel k námitce navrhovatele týkající se hardwarové appliance zadavatel uvádí, že byť nástroj LogMan.io lze dodávat i provozovat jako virtuální appliance, tato varianta nebyla pro plnění veřejné zakázky vybraným dodavatelem zvolena. Nadto zadavatel uvádí, že navrhovatel již ve svých námitkách naznačil, že je seznámen s veřejně dostupnými dokumenty ohledně řešení LogMan.io. Pro zadavatele je tedy těžko pochopitelný argumentační postoj navrhovatele, který zjevně ví, že existují dokumenty, které jeho námitky vyvracejí (a nejspíše je i seznámen s jejich obsahem), ale namítá vůči zadavateli, že jej s nimi detailně neseznámil.

59.         K tvrzením navrhovatele týkajícím se režimu write-once zadavatel uvádí, že režim write-once, jak napovídá již prostý překlad, znamená „zápis jednou“. V praxi to znamená, že nástroj umožňuje pouze jeden zápis, který je originální a neměnný, a jelikož produkt LogMan.io
v tomto režimu pracuje, tak tímto deklaruje, že jakýkoli uložený údaj nelze nijak modifikovat. Jestliže pak zadavatel dále v rozhodnutí o námitkách uvedl, že „Tato vlastnost je zajištěna pomocí kryptografických funkcí, konkrétně digitálních podpisů a kryptografických hashů přijímaných logů,“ pak uvedené dle zadavatele neznamená, že je toto zajištěno prostým kryptováním (neboli šifrováním), nýbrž využitím konkrétních funkcí, které zajistí, že jakákoli modifikace (což je i smazání) není možná.

60.         Tvrzení navrhovatele o možném zneužití root oprávnění je dle zadavatele zavádějící, neboť popisovaná možnost kompromitace produktu (SW nástroje) naprosto nesouvisí s jeho vlastnostmi. Každá aplikace musí pro svůj provoz mít roli root (superadmin) pro zajištění privilegovaných operací. Pravidla pro provádění privilegovaných oprávnění má ovšem zadavatel zakotvena a velmi detailně popsána v rámci systému pro řízení uživatelů (Identity management) a systému pro řízení privilegovaných účtů (Privileged identity management), což je součástí komplexního systému pro řízení kybernetické bezpečnosti zadavatele. Ochrana privilegovaných oprávnění či účtů však není předmětem veřejné zakázky, jak navozuje navrhovatel, pročež uvedená námitka je dle zadavatele neopodstatněná.

61.         Zadavatel dále dodává, že vybraný dodavatel podáním nabídky, resp. souhlasem s obchodními podmínkami (tj. návrhem smlouvy), potvrzuje, že jím nabízené řešení je v souladu s požadovanými licenčními podmínkami zadavatele, což v praxi znamená, že pokud dojde k jejich porušení, pak vybraný dodavatel odpovídá za z toho vzešlé následky (škody), což je v závazném návrhu smlouvy jednoznačně deklarováno. Jelikož zadavatel po prozkoumání informací jemu dostupných jak z veřejně dostupných zdrojů, tak těch uvedených v nabídce vybraného dodavatele a ve vysvětlení nabídky, neshledal žádný relevantní důvod pro pochybnosti v tomto směru, pak má za to, že převzetí zmíněného smluvního závazku vybraným dodavatelem mu v tomto ohledu poskytuje dostatečnou záruku.

62.         Dále se zadavatel postupně vyjadřuje k jednotlivým požadavkům, které dle navrhovatele nástroj vybraného dodavatele nesplňuje, a vysvětluje, proč je podle něj tento názor navrhovatele nesprávný.    

63.         K otázkám zasílání alertů (upozornění) pomocí SMTP a údajně chybějících předdefinovaných pohledů na uložená data (dashboardy) zadavatel poukazuje na logickou nekonzistenci argumentace navrhovatele, který dle zadavatele jak návrhu, tak v námitkách obě otázky spojil dohromady a současně se v návrhu nad tímto spojením pozastavuje (zadavatel ovšem dle svých slov v daném ohledu reagoval na námitku tak, jak byla vznesena). K tomu dále zadavatel dodává, že v rozhodnutí o námitkách netvrdil nic o spojitosti zasílání alertů s komponentou pro export, nýbrž pouze uvedl výčet, kde všude je mimo jiné podporováno více formátů.

64.         Zadavatel dále reaguje na námitky týkající se MNNC. K tomu zadavatel zejména uvádí, že posouzení MNNC v nabídce vybraného dodavatele provedl, když vybraného dodavatele ke zdůvodnění MNNC vyzval, následně se zadavatel zabývá splnitelností veřejné zakázky za cenu nabídnutou vybraným dodavatelem.

Vyjádření k podkladům rozhodnutí ve rámci správního řízení sp. zn.  S0379/2021/VZ

65.         Ve vyjádření k podkladům rozhodnutí ze dne 12. 11. 2021 se zadavatel vyjádřil mj. k argumentaci navrhovatele, že „není možné, aby zpřístupněním nabídky jednoho dodavatele druhému došlo k porušení obchodního tajemství“; zadavatel k tomu uvedl, že tento závěr je nesprávný, neboť nejde jen o ty parametry nabízeného plnění, které jsou v zadávacím řízení „testovány“ a z povahy věci tak nemohou být utajovány, ale např. o způsob, jakým jich dodavatel dosáhl. Tj. v obecné rovině např. výrobní postup, v IT oblasti např. konkrétní architektura dodávaného řešení, zdrojové kódy, ale např. též způsob cenotvorby, způsob vytěžování personálních kapacit, atp., které samozřejmě mohou být pro každého dodavatele konkurenčně významné.

Další průběh správního řízení

66.         Usnesením č. j. ÚOHS-00966/2022/511 ze dne 10. 1. 2022 určil Úřad zadavateli lhůtu k provedení úkonu – podání informace Úřadu o dalších úkonech, které zadavatel v šetřeném zadávacím řízení v průběhu správního řízení provede, a zaslání příslušné dokumentace o zadávacím řízení pořízené v souvislosti s provedenými úkony.

67.         Rozhodnutím č. j. ÚOHS-01487/2022/500 ze dne 13. 1. 2022 Úřad uložil zadavateli zákaz uzavřít smlouvu na veřejnou zakázku, a to až do pravomocného skončení správního řízení vedeného pod sp. zn. ÚOHS-S0682/2021/VZ.

68.         Usnesením č. j. ÚOHS-01495/2022/511 ze dne 13. 1. 2022 Úřad správní řízení podle § 64 odst. 1 písm. e) správního řádu ve spojení s § 261 odst. 2 zákona přerušil s cílem získat s cílem získat znalecký posudek z oboru Kybernetická bezpečnost a/nebo Informační a komunikační technologie, a to do doby doručení výše uvedeného znaleckého posudku.

69.         Dne 2. 6. 2022 byl usnesením č. j. ÚOHS-18650/2022/500 z téhož dne (dále jen „usnesení ze dne 2. 6. 2022“) ustanoven v projednávané věci znalec. Tento byl vyzván, aby zodpověděl otázky, které jsou blíže popsány v bodech 165 až 200 odůvodnění tohoto rozhodnutí. Znalci bylo v rámci daného usnesení rovněž uloženo, aby znalecký posudek ve 2 vyhotoveních podal Úřadu do 2 měsíců ode dne doručení Úřadu.

70.         Dne 2. 6. 2022 Úřad účastníkům řízení prostřednictvím přípisu „Sdělení o ustanovení znalce“ č. j. ÚOHS-18722/2022/511 z téhož dne oznámil, že v daném zadávacím řízení na veřejnou zakázku byl ustanoven znalec k vypracování znaleckého posudku.

71.         Usnesením č. j. ÚOHS-18722/2022/511 ze dne 9. 8. 2022 Úřad prodloužil znalci lhůtu pro provedení znaleckého posudku na základě žádosti znalce ze dne 8. 8. 2022, a to do 19. 8. 2022.

72.         Usnesením č. j. ÚOHS-28419/2022/500 ze dne 19. 8. 2022 Úřad prodloužil znalci lhůtu pro provedení znaleckého posudku na základě žádosti znalce ze dne 17. 8. 2022, a to do 31. 8. 2022.

73.         Dne 31. 8. 2022 byl Úřadu doručen ve 3 vyhotoveních „Znalecký posudek č. 73/7/2022“ ze dne 31. 8. 2022.

74.         Žádostí o doplnění znaleckého posudku ze dne 9. 9. 2022 Úřad požádal o doplnění znaleckého posudku č. 73/7/2022 ze dne 31. 8. 2022 o odpovědi na dotazy č. 1 až 56 tak, aby byly skutečně zodpovězeny Úřadem položené otázky. Současně Úřad požádal o řádné zdůvodnění odpovědí.

75.         Dne 16. 9. 2022 byl Úřadu doručen ve 3 vyhotoveních „Znalecký posudek č. 73/7/2022“ ze dne 16. 9. 2022 (dále jen „znalecký posudek“).

76.         Žádostí o vysvětlení znaleckého posudku ze dne 20. 9. 2022 Úřad požádal znalce o bližší vysvětlení jeho odpovědi k dotazu č. 51 znaleckého posudku tak, aby nevznikaly pochybnosti mezi zdůvodněním a samotnou odpovědí na položený dotaz.

77.         Dne 21. 9. 2022 Úřad obdržel vysvětlení znalce z téhož dne (dále jen „vysvětlení znaleckého posudku“) k odpovědi na dotaz č. 51 znaleckého posudku.

78.         Přípisem č. j. ÚOHS-33339/2022/511 ze dne 23. 9. 2022 Úřad oznámil pokračování správního řízení vedeného pod sp. zn. ÚOHS-S0682/2021/VZ účastníkům řízení.

79.         Žádostí o vysvětlení znaleckého posudku ze dne 30. 9. 2022 Úřad požádal znalce o bližší vysvětlení jeho odpovědi k dotazu č. 53 znaleckého posudku tak, aby byly Úřadu známy bližší důvody, proč nemůžete jednoznačně vyloučit, že požadavek uvedený v bodě č. 53 lze splnit způsobem uvedeným v tomto bodě a bližší vysvětlení role „nezávislého auditora“.

80.         Dne 7. 10. 2022 Úřad obdržel vysvětlení znalce (dále jen „vysvětlení znaleckého posudku č. 2“) k odpovědi na dotaz č. 53 znaleckého posudku a k otázce „nezávislého auditora“.

81.         Usnesením č. j. ÚOHS-35119/2022/511 ze dne 7. 10. 2022 Úřad stanovil účastníkům lhůtu 10 dnů k vyjádření se ke znaleckému posudku. Uvedenou lhůtu Úřad následně prodloužil usnesením č. j. ÚOHS-35811/2022/511 ze dne 13. 10. 2022 a usnesením č. j. ÚOHS-37738/2022/511 ze dne 26. 10. 2022.

82.         Dne 20. 10. 2022 zadavatel doručil vyjádření z téhož dne, ve kterém uvádí, že nemá ke znaleckému posudku připomínky, a současně opakuje, že nabídka vybraného dodavatele splňuje podmínky předmětného zadávacího řízení a zadavatel v jeho rámci postupoval v souladu se zákonem.

83.         Usnesením č. j. ÚOHS-39512/2022/511 ze dne 8. 11. 2022 Úřad stanovil účastníkům lhůtu 7 dnů k vyjádření se k podkladům rozhodnutí.

84.         Dne 8. 11. 2022 zadavatel doručil vyjádření z téhož dne, ve kterém uvádí, že odkazuje na své předchozí vyjádření k návrhu. Zadavatel je též toho názoru, že i ostatní důkazy obsažené ve správním spisu jeho názor podporují.

Vyjádření navrhovatele ze dne 15. 11. 2022

85.         Dne 15. 11. 2022 doručil navrhovatel vyjádření k podkladům rozhodnutí z téhož dne (dále jen „vyjádření navrhovatele k podkladům“).

86.         Navrhovatel nejprve namítá nepřezkoumatelnost znaleckého posudku, přičemž uvádí, že znalecký posudek ve znění vysvětlení znaleckého posudku nedisponuje všemi náležitostmi ve smyslu § 28 odst. 1 a 2 zákona o znalcích. Konkrétně navrhovatel uvádí, že většina odpovědí znalce neobsahuje odůvodnění v rozsahu umožňujícím přezkoumatelnost znaleckého posudku, jakož i povinnou náležitost ve smyslu § 28 odst. 2 písm. h) zákona o znalcích.

87.         Tyto nedostatky navrhovatel demonstruje mj. na tom, že u odpovědí na otázku č. 8 a č. 18–25 znalec odpovídá pouze v tom smyslu, že nástroj logman.io má cca 80 % předdefinovaných výrobců a ostatní je nutné doprogramovat na místě zákazníka z důvodu rozdílných požadavků, přičemž dále znalec dodává, že se jedná o běžnou praxi. Navrhovatel má tedy za to, že se jedná o nedostatečné zdůvodnění, resp. znalec nekriticky převzal tvrzení vybraného dodavatele či spol. TeskaLabs. Současně navrhovatel uvádí, že dle bodu č. 1.1.2 písm. b) znaleckého posudku znalec vychází z toho, že informace z jiných zdrojů, které sloužily jako další podklad pro zpracování znaleckého posudku, jsou věrohodné a nebyly ve všech případech z hlediska jejich přesnosti a úplnosti ověřovány.

88.         Dále navrhovatel uvádí, že z bodu č. 1.9.3 znaleckého posudku vyplývá, že znalec provedl dne 4. 8. 2022 místní šetření v prostorách dodavatele a dále prostřednictvím videohovoru i se zástupci společnosti TeskaLabs a zástupci spol. O2 Czech Republic a.s. Navrhovatel má za to, že na otázky položené Úřadem de facto odpovídaly výše zmíněné subjekty a znalec jejich odpovědi pouze převzal. Navrhovatel má za to, že znalec neměl místní šetření vůbec provádět a měl vycházet pouze z materiálů, které poskytl znalci Úřad. Současně znalec ve znaleckém posudku dle navrhovatele neuvádí, jaké skutečnosti při místním šetření zjistil. Navrhovatel má tedy za to, že i z tohoto důvodu je znalecký posudek nepřezkoumatelný a není ho možné použít jako důkaz.

89.         Navrhovatel taktéž uvádí, že znalecký posudek je vnitřně rozporný. Dle navrhovatele znalec na jednu stranu v bodě 1.9.3 nálezu znaleckého posudku uvádí, že mu byla při místním šetření „vysvětlena, umožněna a předvedena funkcionalita související s dotazy 1 – 56“, čímž dle navrhovatele znalecký posudek evokuje, že znalec prověřil funkčnost všech rozporovaných aspektů nástroje LogMan.io a že mu bylo předvedeno splnění veškerých požadavků zadavatele, na které se Úřad dotazoval. Na druhou stranu znalec dle navrhovatele v řadě případů uvádí, že splnění dílčích požadavků vůbec neověřil. Toto měl znalec udělat např. u otázky č. 48, kde uvedl, že „nebylo znalcem ověřeno“, přičemž dále vychází pouze z webu společnosti TeskaLabs. Navrhovatel má však za to, že znalec pouze přebírá závěry společnosti TeskaLabs, které nijak kriticky nehodnotí.  Převzetí tvrzení a závěrů vybraného dodavatele či společnosti TeskaLabs dle navrhovatele vyplývá také z odst. 1.8 znaleckého posudku, kterou znalec de facto slovo od slova přebírá z webových stránek nástroje Logman.io.

90.         Vnitřní rozpornost znaleckého posudku navrhovatel dovozuje i z odpovědi na otázku č. 51, přičemž navrhovatel uvádí, že z odpovědi znalce vyplývá, že mu splnění předmětného požadavku zadavatele nebylo v rámci místního šetření předvedeno. Navrhovatel má za to, že odpověď znalce na tuto otázku je ve vzájemném rozporu s jejím odůvodněním, když znalec na jednu stranu tvrdí, že nemůže vyloučit, že splnění takového požadavku zajistit lze, a na druhou stranu tvrdí, že takový požadavek objektivně splnit nelze, resp. že takovou možnost v některých aspektech vůbec neověřoval. Současně navrhovatel uvádí, že požadavek zadavatele na integritu a nesmazatelnost dat neurčuje konkrétní míru nesmazatelnosti či nemodifikovatelnosti pořízených dat, ale vyplývá z něj, že nástroj nesmí umožnit modifikaci či smazání dat žádným způsobem, a to ani prostřednictvím příkazu administrátora, ani prostřednictvím „hackerských technik“. Dále navrhovatel uvádí, že ani závěr znalce, že nástroj LogMan.io je na „velmi vysoké kybernetické úrovni“ není ničím doložen. Současně ani tvrzení znalce, že u společnosti TeskaLabs probíhá certifikace na ISO 27001, nic nedokazuje.

91.         Obdobné závěry navrhovatel tvrdí i k odpovědi znalce na otázku č. 53, kde znalec taktéž uvádí, že „nebylo znalcem jednoznačně ověřeno nebo vyloučeno“. Navrhovatel má za to, že pokud však nebylo splnění tohoto požadavku jednoznačně ověřeno ani vyloučeno, nemůže znalec poskytnout jednoznačnou odpověď na položenou otázku a uvést, že možnost splnění tohoto požadavku nemůže jednoznačně vyloučit. Navrhovatel tak má za to, že závěr znalce a jeho zdůvodnění jsou ve vzájemném rozporu. K dopovězení na otázku Úřadu by dle navrhovatele stačilo, aby znalci bylo předvedeno, že nástroj LogMan.io vizuálním programovacím jazykem disponuje a že je tento funkční.

92.         S ohledem na výše uvedené má navrhovatel za to, že znalecký posudek je vnitřně rozporný a nepřezkoumatelný, přičemž pokud jde o účast znalce na místním šetření, nezachytil znalec dle navrhovatele žádným způsobem obsah tohoto místního šetření a neučinil jej přílohou znaleckého posudku tak, aby ve smyslu § 28 odst. 1 a § 28 odst. 2 písm. f) a h) zákona o znalcích zajistil přezkoumatelnost znaleckého posudku. Znalecký posudek tak vykazuje dle navrhovatele formální vady, pro které mu není možné přiznat důkazní váhu. Dále v tomto ohledu navrhovatel odkazuje na judikaturu soudů týkající se problematiky dokazování znaleckým posudkem. Dle navrhovatele má Úřad povinnost zadat zpracování revizního znaleckého posudku znaleckému ústavu, přičemž zadání by Úřad měl formulovat takovým způsobem, aby nebylo ověřováno, zda je možné jednoznačně vyloučit, že určitým způsobem není možné určitý požadavek zadavatele splnit, ale aby znalec jednoznačně potvrdil, že nástroj nabízený vybraným dodavatelem tyto požadavky jednoznačně splňuje či nesplňuje, a to k okamžiku podání finální nabídky.

93.         Dále navrhovatel namítá, že jím dosud popsaná pochybení týkající se zpracování znaleckého posudku ve spojení se skutečností, že znalec přebírá pouze závěry zadavatele, které mu sdělil vybraný dodavatel a společnost TeskaLabs, ukazují na potenciální podjatost znalce. Navrhovatel upozorňuje na to, že znalec se bez vědomí Úřadu a navrhovatele zúčastnil místního šetření a testování demoverze nástroje Logman.io za přítomnosti zástupců vybraného dodavatele, společnosti TeskaLabs a společnosti O2 Czech Republic a.s., přičemž uvedené znalec nijak nezdokumentoval. Současně navrhovatel uvádí, že ve vztahu k testování demoverze znalec ve znaleckém posudku neuvedl identitu „nezávislého auditora“, který měl testování provádět. Navrhovatel tedy má za to, že znalec nezajistil transparentnost zpracování znaleckého posudku, čímž zavdal příčinu pochybovat o jeho nepodjatosti. Dle navrhovatele již nikdy nebude možné ověřit, zda znalec nebyl vybraným dodavatelem a společností TeskaLabs jakkoli ovlivněn tak, aby závěry znaleckého posudku vyzněly v jejich prospěch. Navrhovatel opakuje, že pro vypracování znaleckého posudku znalec vůbec nepotřeboval kontaktovat vybraného dodavatele či společnost TeskaLabs. Navrhovateli není zřejmé, proč se jednání účastnila i společnost O2 Czech Republic a.s., neboť z webu vybraného dodavatele dle navrhovatele vyplývá, že u této společnosti je implementováno jiné řešení než produkt Logman.io. Navrhovatel tedy má pochybnost, zda znalci byla prezentována skutečně funkcionalita nástroje Logman.io.

94.         Navrhovatel má za to, že s ohledem na doktrinální výklad a rozhodovací praxi je přitom nutné připomenout, že pro vyloučení znalce z důvodu jeho podjatosti není nezbytně nutné, aby bylo prokázáno, že znalec skutečně podjatý je, postačí, že o jeho nepodjatosti lze pochybovat. Právě takovou pochybnost o nepodjatosti znalce přitom dle navrhovatele zakládá skutečnost, že se znalec osobně sešel s osobami, které mají přímý zájem na výsledku řízení, přičemž průběh těchto schůzek žádným způsobem nezdokumentoval (navrhovatel uvádí např. pořízení audiovizuálního záznamu), aby mohlo být vyloučeno, že znalec nebyl těmito osobami nezákonným způsobem ovlivněn a že sám nezískal zájem na výsledku šetření. Z výše uvedeného navrhovatel dovozuje, že by měl být zpracován revizní posudek. 

95.         V další části svého vyjádření navrhovatel napadá dle jeho názoru nevhodně položené otázky na znalce. S ohledem na položené otázky jsou dle stěžovatele odpovědi znalce vzhledem k předmětu správního řízení a ke konkrétně rozporovaným skutečnostem naprosto irelevantní.  Dle navrhovatele předmětem správního řízení je otázka, zda nabídka vybraného dodavatele splnila zadávací podmínky. Otázky na znalce tak dle navrhovatele měly být položeny takovým způsobem, aby se znalec jednoznačně vyjádřil, zda nástroj LogMan.io zadávací podmínky splňuje, či nikoliv. Dle navrhovatele Úřadem položené otázky žádným způsobem nepřispívají k objasnění skutkového stavu.

96.         Navrhovatel dále upozorňuje na to, že veřejná zakázka je koncipována jako veřejná zakázka na dodávky ve smyslu § 14 odst. 1 zákona, nikoliv jako veřejná zakázka na služby ve smyslu § 14 odst. 2 zákona. Současně navrhovatel uvádí, že technické podmínky vymezující předmět veřejné zakázky jsou dle § 37 odst. 1 zákona součástí podmínek účasti v zadávacím řízení. Podmínky účasti přitom musí být z povahy věci splněny již k okamžiku uplynutí lhůty pro podání nabídek. Z uvedeného navrhovatel dovozuje, že pokud má být předmětem veřejné zakázky dodávka software, musí vybraný dodavatel splňovat všechny podmínky účasti v zadávacím řízení včetně technických podmínek ke dni podání nabídky. Součástí předmětu plnění není dle navrhovatele úprava programového vybavení, ale jeho prostá dodávka bez podstatných úprav. V případě, kdy by měly být součástí předmětu veřejné zakázky také případné úpravy již existujícího software či vytvoření „bespoke software“, by se dle navrhovatele muselo jednat o veřejnou zakázku na služby. Podle navrhovatele nabídka, která by nerespektovala koncept veřejné zakázky (tedy místo dodávky by nabízela poskytnutí služeb), by byla sama o sobě v rozporu se zadávacími podmínkami. Dodavatele, který by takovou nabídku podal, by tedy byl zadavatel povinen vyloučit již v okamžiku, kdy by skutečnost, že nabídka nerespektuje koncepci předmětu veřejné zakázky, vyšla najevo. Případná následná změna konceptu smlouvy na veřejnou zakázku ve smyslu výše uvedeného, kterou by zadavatel zrealizoval až po uzavření smlouvy dle původních zadávacích podmínek, by přitom představovala podstatnou, a tedy zakázanou změnu závazku ze smlouvy na veřejnou zakázku ve smyslu § 222 odst. 1 a 3 zákona. Navrhovatel tak má za to, že pro rozhodnutí ve věci není rozhodné, zda by případně bylo možné požadavky zadavatele způsobem, který uvedl v průběhu řízení vybraný dodavatel, splnit, ale zda je nástroj LogMan.io skutečně ke dni podání nabídek splňoval. Z uvedeného důvodu tak znalecký posudek není dle navrhovatele způsobilým podkladem pro rozhodnutí, přičemž Úřad má zadat revizní znalecký posudek, který jednoznačně odpoví na otázku, zda nabídka vybraného dodavatele ke dni uplynutí lhůty pro podání nabídek splňovala technické podmínky vymezující předmět veřejné zakázky.

97.         Navrhovatel dále uvádí, že zadavatel stále nemá a nemůže mít postaveno najisto, zda vybraný dodavatel splnil podmínky účasti v zadávacím řízení, pročež jej nemohl k uzavření smlouvy vybrat a ani s ním nemůže následně smlouvu uzavřít. Jedinou možností je dle navrhovatele v případě, kdy Úřad nepřistoupí k doplnění dokazování, zrušení rozhodnutí o výběru.

98.         V další části vyjádření k podkladům se navrhovatel vyjadřuje k jednotlivým částem znaleckého posudku a navrhuje dílčí části zadání revizního znaleckého posudku. K odpovědi na otázky č. 1 až 43 navrhovatel uvádí, že není jednoznačně průkazná a spoléhá se výhradně na tvrzení dodavatele. Znalec dle navrhovatele neprovedl ani základní šetření, kterým by ověřil, zda je tvrzení vybraného dodavatele nebo výrobce LogMan.io o minimálně 80 % podporovaných zdrojů skutečně pravdivé, a neuvedl relevantní skutečnosti odůvodňující závěr, že absentující funkcionality lze skutečně doprogramovat. S ohledem na tuto skutečnost navrhovatel navrhuje provést důkladné šetření směřující k objasnění těchto skutečností. K tomu uvádí, že pro každý požadovaný či podporovaný zdroj logů by měla být k dispozici dokumentace nastavení daného zdroje pro sběr logů či událostí do nástroje LogMan.io. V tomto nástroji se přitom musí nacházet pro každý podporovaný zdroj unikátní parser či normalizátor logů. Ten lze i rychlým náhledem identifikovat a posoudit, zda danou operaci normalizace je opravdu schopen realizovat. Strojová data jednotlivých požadovaných či podporovaných výrobců se natolik liší, že tyto unikátní parsery či normalizátory logů lze snadno prozkoumat a potvrdit, zda jsou v řešení LogMan.io přítomny a zda daný zdroj dle otázek č. 1 až 43 je opravdu podporován a nejedná se tak pouze o přejmenovanou kopii jiného parseru či normalizátoru.

99.         K odpovědi na otázky č. 44, 45A a 45B navrhovatel uvádí, že není jednoznačně průkazná. Z požadavků zadavatele, resp. z přílohy č. 1 smlouvy dle navrhovatele vyplývá, že řešení musí umožnit přístup více uživatelů současně, a to jak k datům systému, tak i k incidentům. Řešení taktéž musí umět separovat role a definovat pro konkrétní skupiny či uživatele dané oprávnění, přičemž toto vytváření rolí má být dle požadavků zadavatele snadné. S ohledem na tuto skutečnost navrhovatel navrhuje na testovaném řešení skutečně ověřit, zda je požadovaná funkcionalita skutečně k dispozici a zda je proces vytváření rolí snadný. Dále navrhuje, aby znalec ověřil nad danou skupinou pořízených dat (výběr z bodů 1 až 43), zda lze vytvořit nejméně tři rozdílné role s oprávněním k pouze určité části pořízených dat. Způsob průběhu ověření požaduje navrhovatel zadokumentovat a potvrdit, zda nad jednou skupinou dat lze snadno vytvářet a uživatelům (a jejich skupinám) přiřazovat role vymezující přístup
k pouze vybraným datům, incidentům a zároveň i ke konfiguračním komponentám řešení LogMan.io.

100.     K odpovědi na otázku č. 46 navrhovatel uvádí, že není jednoznačně průkazná. Z požadavků zadavatele, resp. z přílohy č. 1 smlouvy, dle jeho názoru vyplývá, že řešení musí umožňovat zálohování a obnovení konfigurace z centrální konzole. Znalcem přiložený odkaz na dokumentaci dle navrhovatele popisuje pouze způsob organizace diskového úložiště řešení LogMan.io a není v něm ani zmínky o zálohování a obnovování konfigurace. Závěr znalce je tak dle jeho názoru zcela nepodložený, a tudíž nepřezkoumatelný. Navrhovatel tedy navrhuje provést otestování, že nástroj umožnuje běžně realizované kroky zálohování a obnovení konfigurace z centrální konzole, a to nejlépe vytvořením zálohy konfigurace, nastavením nástroje do továrního nastavení a obnovením konfigurace z vytvořené zálohy. Postup a výsledek testu je nutné zadokumentovat a vyvodit jednoznačný závěr o splnění požadavku zadavatele.

101.     K odpovědi na otázku č. 47 navrhovatel uvádí, že není jednoznačně průkazná. Z požadavků zadavatele, resp. z přílohy č. 1 smlouvy, dle jeho názoru vyplývá, že řešení musí umožňovat nastavení nezávislé zálohovací politiky jak pro konfiguraci, tak pro jednotlivá úložiště. Zdůvodnění znalce je přitom založené na konstatování, že systém založený na ELK s různými nadstavbami jako logtrash apod. umožňuje zálohování i nezávislé zálohování. Tato argumentace však neumožňuje potvrdit naplnění tohoto požadavku zadavatele, protože se očekává, že dodané řešení bude provádět nezávislé zálohovací politiky pro konfiguraci i pro jednotlivá úložiště. Tato problematika má být zároveň popsaná v dokumentaci výrobce řešení a řešení ji má nativně umožňovat bez nutnosti používat různé nespecifikované nadstavby. Závěr znalce je tak zcela nepodložený, a tudíž nepřezkoumatelný. Navrhovatel navrhuje otestování tohoto požadavku vytvořením nezávislých politik zálohování pro konfiguraci a pro pořízená data a provedení otestování obnovení dat z jednotlivých záloh. Kroky potřebné k vytvoření nezávislých politik zálohování, k provedení zálohy a k následnému obnovení dat ze zálohy je přitom nutné přezkoumatelně zdokumentovat. Na základě provedeného testu je nutné učinit jednoznačný závěr, zda navržené řešení danou funkcionalitu podporuje.

102.     K odpovědi na otázky č. 49 a 50 navrhovatel uvádí, že není jednoznačně průkazná. Zadavatel prostřednictvím těchto logicky spojených bodů požaduje možnost aktualizace nástroje v jednotném balíku a dále i downgrade (ponížení software verze řešení) přes centrální konzoli. Navrhovatel navrhuje provést upgrade řešení na poslední dostupnou verzi software v jednotném balíku dle doporučení výrobce (protože žádná část dokumentace LogMan.io neobsahuje ani k dnešnímu datu popis postupu upgrade a downgrade software), otestování funkčnosti řešení a změny v řešení dle „release notes“ k dané poslední verzi software. Následně navrhuje provést downgrade a znovu otestovat funkčnost řešení. Postup a výsledek testu je přitom nutné přezkoumatelně zdokumentovat a vyvodit z něj jednoznačný závěr, zda nabízené řešení požadavek zadavatele v úplném rozsahu splňuje.

103.     K odpovědi na otázku č. 51 navrhovatel uvádí, že není jednoznačně průkazná. Požadavek zadavatele, resp. přílohy č. 1 smlouvy, na nástroj je, aby nástroj garantoval integritu pořízených dat a systém neumožňoval mazání nebo modifikaci již pořízených dat. Požadavek zadavatele přitom neurčuje konkrétní míru nesmazatelnosti či nemodifikovatelnosti pořízených dat. Požadavek je tedy nutné vykládat tak, že nástroj nesmí umožnit modifikaci či smazání dat žádným způsobem, a to ani prostřednictvím příkazu administrátora, ani prostřednictvím „hackerských“ technik. Pro tyto a ani pro jiné případy totiž požadavek zadavatele žádnou výjimku neobsahuje. Závěr znalce je tak v kontextu jeho konstatování, že vždy lze určitým způsobem dosáhnout smazání dat, zcela nepodložený, a tudíž nepřezkoumatelný. Navrhovatel dále uvádí, že dle veřejně dostupné dokumentace k nástroji LogMan.io je k množství správcovských úkonů nad navrženým systémem LogMan.io nutný plný administrátorský přístup ke konzoli systému. Navrhovatel navrhuje nástroj otestovat tak, že se použije například administrátorský přístup umožňující upgrade či downgrade systému a vytváření nezávislých zálohovacích politik, tento účet bude připojen k centrálním konzolím (dle bodů 46 a 47 znaleckého posudku) a ověří se, že dané přístupové oprávnění neumožňuje prostřednictvím ani jedné z konzolí (webové a ssh) manipulaci s tou částí souborového systému řešení, která obsahuje pořízená strojová data jednotlivých zdrojů. Postup a výsledek testu je přitom nutné přezkoumatelně zdokumentovat a vyvodit z něj jednoznačný závěr, zda nabízené řešení požadavek zadavatele v úplném rozsahu splňuje.

104.     K odpovědi na otázku č. 53 navrhovatel uvádí, že není jednoznačně průkazná. Požadavek zadavatele na nástroj je, aby byla umožněna konfigurace notifikací prostřednictvím vizuálního programovacího jazyka. Znalec však tuto funkcionalitu dle navrhovatele žádným způsobem neověřil. Z dalších podkladů rozhodnutí, které obsahují obchodní tajemství vybraného dodavatele, přitom dle navrhovatele vyplývá, že jeho odůvodnění implementace tohoto požadavku nijak neprezentuje funkčnost vizuálního programovacího jazyka ve smyslu dotčeného požadavku zadavatele. Dokumentace výrobce LogMan.io neobsahuje dle navrhovatele jediný vzorový příklad (také odpověď či její část skrytá pod obchodním tajemstvím ukazuje pouze obrázek možné konfigurace), který je snadné složit a následně provést záznam obrazovky mimo vlastní navržené řešení. Dále navrhovatel uvádí, že dokumentace neobsahuje popis, jakým způsobem notifikaci uložit a správně aplikovat. To dle něj vede k pochybám, zda má navržený systém Logman.io funkci konfigurace notifikací prostřednictvím vizuálního programovacího jazyka integrovanou a pokud ano, tak zda je takto vytvořená notifikace opravdu funkční. Závěr znalce je tak dle navrhovatele nepodložený, a tudíž nepřezkoumatelný. Navrhovatel dále navrhuje provést ověření funkčnosti vytváření notifikací prostřednictvím vizuálního programovacího jazyka vytvořením notifikace na libovolnou událost na základě několika jednoduchých podmínek v prostředí vizuálního programovacího jazyka, tuto notifikaci v daném řešení aktivovat a otestovat, zda je daná notifikace funkční. Dále navrhuje otestovat, zda při vzniku události naplňující podmínky požadované v nově vytvořené notifikaci je tato notifikace skutečně provedena. Postup a výsledek testu je přitom nutné přezkoumatelně zdokumentovat a vyvodit z něj jednoznačný závěr, zda nabízené řešení požadavek zadavatele v úplném rozsahu splňuje.

105.     K odpovědi na otázku č. 55 navrhovatel uvádí, že není jednoznačně průkazná. Požadavek zadavatele na nástroj je, aby obsahoval předpřipravené pohledy na data dle seznamu technologií dle bodů č. 1 až 44 znaleckého posudku. Ve způsobu řešení se pouze konstatuje, že dané pohledy jsou již předpřipravené, ale není představen ani seznam těchto pohledů a nebyla provedena kontrola, zda se o tyto pohledy dle jednotlivých technologií opravdu jedná. Dále je přiložen seznam generických pohledů na data, který ve většině uvedených případů neřeší pohled na pořízená data z hlediska log managementu, ale z hlediska metriky, tj. dohledu nad vytížením zdrojů. Závěr znalce je tak dle navrhovatele zcela nepodložený, a tudíž nepřezkoumatelný. Navrhovatel dále navrhuje provést kontrolu přítomnosti předpřipravených pohledů na data bodů č. 1 až 44 znaleckého posudku a namátkové otestování, zda jsou tyto pohledy funkční pro všechny požadované technologie. Postup a výsledek testu je přitom nutné přezkoumatelně zdokumentovat a vyvodit z něj jednoznačný závěr, zda nabízené řešení požadavek zadavatele v úplném rozsahu splňuje.

106.     V návaznosti na vše výše uvedené tak navrhovatel navrhuje, aby Úřad přistoupil k zadání revizního znaleckého posudku, který bude zpracován transparentním způsobem, který bude zpětně přezkoumatelný a který jednoznačně zodpoví otázku, zda nabídka vybraného dodavatele ke dni podání nabídek splňovala technické podmínky vymezující předmět veřejné zakázky. Při zpracování tohoto revizního posudku je dle navrhovatele nutné provést testování verze nástroje LogMan.io, která byla aktuální k okamžiku uplynutí lhůty pro podání nabídek, a ověření všech navrhovatelem rozporovaných požadavků zadavatele a zejména výše uvedených skutečností. V zájmu zajištění transparentnosti a přezkoumatelnosti revizního znaleckého posudku navrhovatel žádá, aby testování nástroje proběhlo v rámci ústního jednání před Úřadem, které Úřad za tímto účelem nařídí, a to za účasti zástupců vybraného dodavatele, spol. TeskaLabs, navrhovatele a za účasti samotného znalce. Navrhovatel dále žádá, aby byl průběh testování zdokumentován prostřednictvím audiovizuálního záznamu, aby se předešlo případným pochybnostem o průběhu testování a aby bylo zajištěno, že revizní posudek bude plně přezkoumatelný.

107.     Závěrem navrhovatel uvádí, že trvá na svém návrhu, a navrhuje, aby Úřad rozhodl o návrhu tak, že zadavatel nedodržel postup stanovený zákonem, a aby uložil zadavateli opatření
k nápravě spočívající ve zrušení rozhodnutí o výběru i všech navazujících úkonů, a aby zavázal zadavatele k provedení nového posouzení nabídek, k vyloučení vybraného dodavatele z další účasti v zadávacím řízení a k rozhodnutí o výběru nabídky navrhovatele.

IV.          ZÁVĚR

108.     Úřad přezkoumal na základě § 248 a následujících ustanovení zákona případ ve všech vzájemných souvislostech a po zhodnocení všech podkladů, zejména relevantních částí obdržené dokumentace o zadávacím řízení, vyjádření účastníků řízení, znaleckého posudku a na základě vlastních zjištění rozhodl:

• o zastavení správního řízení podle § 257 písm. h) zákona ve vztahu k částem návrhu týkajícím se nesplnění požadavků č. 147, 148, 149, 150, 159, 401 uvedených v příloze č. 1 návrhu smlouvy vybraným dodavatelem, neboť předmětným částem návrhu nepředcházely řádně a včas podané námitky.
• ve vztahu ke zbývajícím částem návrhu o zamítnutí návrhu dle § 265 písm. a) zákona, neboť nebyly zjištěny důvody pro uložení nápravného opatření.

109.     Ke svému rozhodnutí Úřad uvádí následující rozhodné skutečnosti.

Relevantní ustanovení zákona a dalších právních předpisů

110.     Podle § 6 odst. 1 zákona musí zadavatel při postupu podle tohoto zákona dodržovat zásady transparentnosti a přiměřenosti.

111.     Podle § 28 odst. 1 písm. o) zákona se pro účely tohoto zákona mimořádně nízkou nabídkovou cenou rozumí nabídková cena nebo náklady uvedené účastníkem zadávacího řízení, které se jeví jako mimořádně nízké ve vztahu k předmětu veřejné zakázky.

112.     Podle § 48 odst. 4 zákona zadavatel může vyloučit účastníka zadávacího řízení, pokud nabídka účastníka zadávacího řízení obsahuje mimořádně nízkou nabídkovou cenu, která nebyla účastníkem zadávacího řízení zdůvodněna.

113.     Podle § 113 odst. 4 zákona zadavatel požádá účastníka zadávacího řízení o písemné zdůvodnění způsobu stanovení mimořádně nízké nabídkové ceny. Žádost o zdůvodnění mimořádně nízké nabídkové ceny se považuje za žádost podle § 46 zákona, lze ji doplňovat a vznést opakovaně. V žádosti o zdůvodnění mimořádně nízké nabídkové ceny musí zadavatel požadovat, aby účastník zadávacího řízení potvrdil, že

a)    při plnění veřejné zakázky zajistí dodržování povinností vyplývajících z právních předpisů vztahujících se k předmětu veřejné zakázky, jakož i pracovněprávních předpisů a kolektivních smluv vztahujících se na zaměstnance, kteří se budou podílet na plnění veřejné zakázky, a

b)    neobdržel neoprávněnou veřejnou podporu.

114.     Podle § 113 odst. 5 zákona účastník zadávacího řízení musí v objasnění mimořádně nízké nabídkové ceny potvrdit skutečnosti podle § 113 odst. 4 zákona. Mimořádně nízkou nabídkovou cenu může účastník zadávacího řízení dále odůvodnit zejména prostřednictvím

a)    ekonomických aspektů výrobního procesu, poskytovaných služeb nebo konstrukčních metod,

b)    použitých technických řešení nebo výjimečně příznivých podmínek, které má účastník zadávacího řízení k dispozici pro plnění veřejné zakázky, nebo

c)     originality stavebních prací, dodávek nebo služeb.

115.     Podle § 113 odst. 6 zákona zadavatel posoudí objasnění mimořádně nízké nabídkové ceny. Zadavatel účastníka zadávacího řízení vyloučí, pokud z objasnění mimořádně nízké nabídkové ceny vyplývá, že

a)    nabídková cena je mimořádně nízká nabídková cena z důvodu porušování povinností uvedených v § 113 odst. 4 písm. a) zákona,

b)    nabídková cena je mimořádně nízká z důvodu veřejné podpory a účastník zadávacího řízení není schopen na výzvu zadavatele prokázat, že veřejná podpora byla poskytnuta v souladu s předpisy Evropské unie; jestliže je účastník zadávacího řízení vyloučen z tohoto důvodu, informuje zadavatel o této skutečnosti Evropskou komisi, nebo

c)     neobsahuje potvrzení skutečností podle § 113 odst. 4 zákona.

116.     Podle § 242 odst. 2 zákona námitky proti úkonům oznamovaným v dokumentech, které je zadavatel povinen podle tohoto zákona uveřejnit či odeslat stěžovateli, musí být doručeny zadavateli do 15 dnů od jejich uveřejnění či doručení stěžovateli.

117.     Podle § 251 odst. 4 zákona náležitosti návrhu podle odstavce 1 věty první a druhé nemohou být dodatečně měněny ani doplňovány s výjimkou odstranění nedostatků návrhu ve lhůtě stanovené Úřadem; Úřad k takovým změnám a doplněním nepřihlíží. K novým skutečnostem uvedeným v návrhu oproti skutečnostem obsaženým v námitkách podaných zadavateli přihlédne Úřad jen tehdy, jde-li o takové skutečnosti, které navrhovatel nemohl tvrdit již vůči zadavateli; navrhovatel je povinen prokázat, že jde o takové nové skutečnosti, které nemohl tvrdit již vůči zadavateli.

118.     Podle § 251 odst. 2 zákona návrh musí být, není-li stanoveno jinak, doručen Úřadu a ve stejnopisu zadavateli do 10 dnů ode dne, v němž stěžovatel obdržel rozhodnutí, kterým zadavatel námitky odmítnul.

119.     Podle § 257 písm. h) zákona Úřad zahájené řízení usnesením zastaví, jestliže návrhu nepředcházely řádně a včas podané námitky, to neplatí pro návrhy podle § 254 zákona.

120.     Podle § 265 písm. a) zákona platí, že Úřad návrh zamítne, pokud nebyly zjištěny důvody pro uložení nápravného opatření.

K nedoručení příloh návrhu zadavateli

121.     K námitce zadavatele, že mu navrhovatel ve lhůtě dle § 251 odst. 2 zákona nedoručil kompletní stejnopis návrhu, když zadavateli nebyly doručeny přílohy návrhu, na které navrhovatel v textu návrhu odkazuje, Úřad uvádí následující.  V § 250 odst. 1 větě druhé a třetí zákona je uvedeno, že navrhovatel je povinen k návrhu připojit v elektronické podobě písemné důkazní prostředky, jejichž provedení navrhl, nejsou-li součástí dokumentace o zadávacím řízení. Součástí návrhu je doklad o složení kauce podle § 255 odst. 1 nebo 2 a v případě návrhu zasílaného Úřadu před uzavřením smlouvy na veřejnou zakázku rovněž doklad o doručení námitek zadavateli. Z citovaného ustanovení § 250 odst. 1 zákona tak dle jazykového výkladu vyplývá, že zákon rozlišuje „návrh“ a „písemné důkazní prostředky“, které se k návrhu připojují. Úřad tedy má za to, že „návrh“ je samostatnou listinou. Pakliže § 251 odst. 2 zákona uvádí, že návrh musí být doručen ve stejnopisu zadavateli, jedná se s ohledem na výše uvedené právě o tuto samostatnou listinu. Současně Úřad konstatuje, že účelem doručení stejnopisu zadavateli je především seznámit zadavatele s argumentací navrhovatele. Pakliže by se zadavatel chtěl seznámit i s tím, co vše bylo Úřadu doručeno v rámci příloh návrhu, resp. seznámit se s přiloženými důkazními prostředky, může využít svého práva nahlížet do správního spisu a s těmito dokumenty se kdykoliv seznámit. V této souvislosti Úřad připomíná, že kromě povinnosti vyjádřit se k návrhu do 10 dnů ode dne obdržení jeho stejnopisu (viz § 252 odst. 1 zákona) je zadavatel oprávněn ve lhůtě 15 dnů ode dne doručení oznámení o zahájení řízení navrhovat důkazy, uvádět skutečnosti a činit jiné návrhy. Pokud by se tedy s některými skutečnostmi seznámil až prostřednictvím nahlédnutí do správního spisu, může na ně v této lhůtě reagovat. Z uvedeného tedy vyplývá, že zadavatel nebyl nijak krácen na svých právech vyjádřit se k obsahu návrhu.

122.     Úřad tak k uvedené argumentaci zadavatele uzavírá, že nedoručení příloh stejnopisu návrhu není vadou, která by byla důvodem pro zastavení správního řízení dle § 257 písm. e) zákona.

K výroku I. tohoto rozhodnutí

Zjištěné skutečnosti

123.     V námitkách je v čl. II. s názvem „K nesplnění zadávacích podmínek“ odstavci 8. uveden seznam požadavků, které zadavatel stanovil v příloze č. 1 smlouvy. V uvedeném seznamu požadavků jsou pod jednotlivými písmeny uvedeny body 101 a 144, 145, 146 a 166, 153, 154, 167, 201, 304, 305, 506, 510 a 511, 512, 705, 706, 810, 813, 901, 1001. Dále pak v odstavci 9. navrhovatel k uvedenému uvedl, že „nástroj nabízený Vybraným dodavatelem pro účely realizace předmětu Veřejné zakázky nesplňuje výše uvedené závazné požadavky Zadavatele (…) K jednotlivým bodům, které nástroj vybraného dodavatel nesplňuje, Stěžovatel podrobněji vyjadřuje dále“.

124.     V odstavci 11. námitek je uvedeno: „Z dostupných informací a z uživatelského manuálu nástroje pak vyplývá, že tento nemá v rozporu s bodem 153 a 154 Přílohy č. 1 smlouvy nijak řešenu zálohu a obnovu konfigurací celého nástroje z centrální konzole a rovněž neumožňuje nastavení nezávislé zálohovací politiky. V rozporu s bodem 145 Přílohy č. 1 pak nástroj také neumožňuje přístup více uživatelů současně.“.

125.     V odstavci 12. námitek je uvedeno: „Nabízený nástroj pak také v rozporu s body 146 a 166 neumožňuje snadné vytváření a definování uživatelských rolí s možností definice přístupových práv a granulárního přidělování práv v rámci rolí, podle zdrojů logů, skupin zařízení, jednotlivých serverů, typu logu, když jejich definice je řešena tenanty, nikoliv pomocí pokročilých funkcí jako jsou RBAC apod.“.

126.     V odstavci 14. námitek je uvedeno: „Dle dostupných informací nabízený nástroj navíc v rozporu s bodem 506 Přílohy č. 1 negarantuje integritu uložených dat a umožňuje mazání a modifikaci uložených logů, přičemž tato skutečnost je také v rozporu s legislativními a normativními požadavky kladenými na tento nástroj prostřednictvím vyhlášky č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti), přičemž nesplnění těchto požadavků je v přímém rozporu s bodem 901 Přílohy č. 1 smlouvy.“.

Právní posouzení

127.     Úřad předně v obecné rovině uvádí, že jednou z podmínek pro řádné projednání návrhu na přezkoumání úkonů zadavatele Úřadem je předchozí podání námitek zadavateli. Platí, že návrh je až druhotným nástrojem procesní obrany dodavatele, neboť prvotním nástrojem jsou námitky, jež jsou podávány přímo zadavateli, který tím dostává možnost na námitky dodavatele reagovat. Zákon tak vyžaduje, aby byly veškeré námitky nejprve uplatněny u zadavatele, a to řádně a včas. V situaci, kdy navrhovatel nevyužije možnosti podání námitek, resp. takto neučiní včas a řádně, tedy s veškerými zákonnými náležitostmi, pak není oprávněn domáhat se ochrany svých práv před Úřadem.

128.     Úřad v posuzované věci předně uvádí, že zadavatel doručil navrhovateli oznámení o výběru dne 29. 7. 2021. Proti rozhodnutí o výběru navrhovatel podal dne 10. 8. 2021 námitky. Rozhodnutím o námitkách, které bylo navrhovateli doručeno dne 23. 8. 2021, zadavatel citované námitky navrhovatele odmítl. Vzhledem k tomu, že navrhovatel nepovažoval rozhodnutí o námitkách za učiněné v souladu se zákonem, podal dne 2. 9. 2021 návrh na zahájení řízení o přezkoumání úkonů zadavatele Úřadu, kterým bylo zahájeno správní řízení sp. zn. ÚOHS-S0379/2021/VZ; v rámci tohoto řízení Úřad rozhodnutí o námitkách č. 1 zrušil. Zadavatel následně vydal rozhodnutí o námitkách č. 2, kterým opětovně námitky navrhovatele odmítl.

129.     Úřad uvádí, že navrhovatel v námitkách mj. namítá, že nástroj nabídnutý vybraným dodavatelem nesplňuje zadávací podmínky. Konkrétně navrhovatel namítá nesplnění některých technických požadavků na poptávaný nástroj uvedených zadavatelem v příloze č. 1 smlouvy. Navrhovatel v námitkách nejprve uvedl výčet napadených požadavků, konkrétně požadavky uvedené v příloze č. 1 smlouvy pod body 101 a 144, 145, 146 a 166, 153, 154, 167, 201, 304, 305, 506, 510 a 511, 512, 705, 706, 810, 813, 901, 1001. Dále navrhovatel v námitkách rozvedl argumentaci k jednotlivým napadeným bodům (viz body 123. až 126. odůvodnění tohoto rozhodnutí).

130.     V návrhu navrhovatel taktéž namítá, že nástroj nabídnutý vybraným dodavatelem nesplňuje zadávací podmínky, nicméně po porovnání námitek s obsahem návrhu Úřad zjistil, že v návrhu navrhovatel nově napadá nesplnění dalších požadavků dle přílohy č. 1 smlouvy.

131.     Konkrétně navrhovatel nově napadá nesplnění požadavku č. 159 (týkajícího se nastavení nezávislé archivační politiky viz bod 141. odůvodnění tohoto rozhodnutí); tvrzení o nesplnění tohoto požadavku přitom navrhovatel včleňuje ke své argumentaci, v níž napadá nesplnění požadavku č. 153 a č. 154 (viz bod 19. odůvodnění tohoto rozhodnutí). V námitkách jsou naopak napadány pouze požadavky 153 a 154, resp. požadavek na zálohu a obnovu konfigurací celého nástroje z centrální konzole a nastavení nezávislé zálohovací politiky (viz bod 124. odůvodnění tohoto rozhodnutí), avšak požadavek č. 159, resp. nastavení archivační politiky nikoliv.

132.     Dále navrhovatel v návrhu nově napadá nesplnění požadavků č. 147 až 150, přičemž tyto námitky navrhovatel včleňuje do argumentace týkající se nesplnění požadavků č. 146 a 166 (neumožnění snadného vytváření a definování uživatelských rolí), přičemž navrhovatel uvádí, že body č. 147 až 150 souvisejí s požadavkem dle bodu 146 přílohy č. 1 smlouvy (viz bod 22. odůvodnění rozhodnutí). K tomu Úřad uvádí, že byť zadavatel rozdělil požadavky v příloze č. 1 smlouvy do určitých dílčích tematických celků, přičemž požadavek č. 146 a požadavky č. 147 – 150 spadají do jednoho takového celku, stále platí, že v námitkách navrhovatel nesplnění požadavků č. 147 až 150 nenamítal. To, že tyto požadavky souvisí s požadavkem č. 146, přitom navrhovatel bezpochyby musel vědět již v době podání námitek, nicméně jejich nesplnění v námitkách nenamítal (ani je nijak nenaznačil), a proto je ani nemůže nyní nově napadat
v návrhu.

133.     Navrhovatel v návrhu nově uvádí též nesplnění požadavku č. 401, přičemž tuto námitku včleňuje do argumentace k nesplnění bodu č. 506 přílohy č. 1 smlouvy, když mj. uvádí, že „Použití kryptografických funkcí tak zajišťuje toliko kontrolu integrity (tedy zjištění, zda byl zápis změněn), přičemž zápis před samotnou změnou či smazáním nechrání. To je přitom
v přímém rozporu s bodem 401 a 506 Přílohy č. 1 smlouvy“ (viz bod 27. odůvodnění tohoto rozhodnutí). Navrhovatel tedy v námitkách namítal nesplnění požadavku č. 506, podle něhož má nástroj garantovat integritu uložených dat, přičemž nesmí umožnit mazání nebo modifikování již uložených logů. Každý log pak dle tohoto požadavku musí mít unikátní identifikátor, který umožní jeho jednoznačnou identifikaci. Tento požadavek č. 506 byl v příloze č. 1 smlouvy uveden v sekci „Zpracování událostí“. Nově napadený požadavek č. 401 byl naopak zařazen do sekce „Sběr a distribuce dat“, přičemž dle tohoto požadavku zadavatel požaduje řešení, které zahrnuje také kolektor, který sbírá události ve vzdálených lokalitách a umožní jejich odeslání po saturované lince bez ztráty dat. Zároveň šifruje a komprimuje posílaná data a zabezpečuje je proti jejich modifikaci nebo smazání, přičemž je garantováno doručení do centrálního prvku (viz bod 141. odůvodnění tohoto rozhodnutí). Byť se tedy oba požadavky částečně týkají modifikace a mazání, každý z těchto požadavků je samostatný a každý v sobě zahrnuje širší problematiku. Současně Úřad podotýká, že z přílohy č. 1 smlouvy vyplývá, že požadavek č. 506, který byl napadnutý v námitkách, se týká konkrétně mazání a modifikace logů, ale nově napadnutý požadavek č. 401 je obecnějšího charakteru a týká mj. obecně mazání a modifikace dat. 

134.     Úřad tedy konstatuje, že v případě shora tvrzení se jedná o uvedení nových skutečností
v návrhu oproti skutečnostem obsaženým v námitkách; k takovým skutečnostem má Úřad
v souladu s § 251 odst. 4 zákona přihlédnout pouze tehdy, jde-li o takové skutečnosti, které navrhovatel nemohl tvrdit již vůči zadavateli, přičemž navrhovatel je povinen prokázat, že jde o takové nové skutečnosti, které nemohl tvrdit již vůči zadavateli. Navrhovatel přitom to, že by šlo o takové skutečnosti, neprokázal (a ani netvrdil). Úřad dodává, že dle jeho názoru o takové skutečnosti nešlo, neboť z ničeho neplyne, že by o těchto skutečnostech navrhovatel nemohl vědět již při podání námitek (např. z veřejně dostupné dokumentace nástroje, která byla jeho primárním zdrojem u ostatních námitek). 

135.     Dle § 257 písm. h) zákona je podání včasných a řádných námitek zadavateli podmínkou pro následné podání návrhu na přezkoumání úkonů zadavatele v téže věci. Z výše uvedeného přitom plyne, že navrhovatel ve vztahu k některým částem návrhu námitky zadavateli nepodal; je tedy zřejmé, že není splněna zákonná podmínka pro projednání těchto částí návrhu Úřadem. Z uvedeného důvodu Úřad rozhodl, že správní řízení ve vztahu daným částem návrhu podle § 257 písm. h) zákona zastavuje.

136.     Úřad dodává, že z důvodu procesní ekonomie rozhodl o zastavení řízení o části návrhu (výrok I.) rozhodnutím a nikoli usnesením, jak předpokládá § 257 zákona, a to rovněž s přihlédnutím k závěrům předsedy Úřadu, ke kterým dospěl v rozhodnutí č. j. ÚOHS-R0204/2018/VZ- 04701/2019/321/ZSř ze dne 15. 2. 2019: „Za třetí lze zmínit situaci, kdy navrhovatel uvede v návrhu rozsáhlou argumentaci týkající se výhrad, které v námitkách neuplatnil, pak o této části návrhu Úřad rozhodne podle § 257 písm. h) zákona samostatným výrokem. V této situaci zákon sice předpokládá formu usnesení, ale tato forma není nezbytně nutná, pakliže Úřad o zbytku návrhu rozhoduje rozhodnutím. Tudíž Úřad může podle § 257 písm. h) zákona přímo rozhodnout v samostatném výroku rozhodnutí, v jehož dalších výrocích pojedná zároveň i o dalších částech návrhu. Rozhodnutí je totiž vyšší forma než usnesení, tudíž v rámci něj může Úřad pojednat o všech skutečnostech, i o těch, u kterých, pokud by se rozhodovalo pouze o nich, by postačovala forma usnesení. Takový závěr potvrzuje např. usnesení Nejvyššího soudu sp. zn. 30 Cdo 1662/2004 ze dne 2. 5. 2005, z něhož vyplývá: »O zrušení rozsudku soudu prvního stupně a o vrácení věci k dalšímu řízení odvolací soud rozhoduje – jak vyplývá z ustanovení § 223 o.s.ř. - formou usnesení. Povahu usnesení neztrácí toto rozhodnutí ani v případě, je-li přičleněno k jinému rozhodnutí odvolacího soudu, pro něž je ustanovením § 223 o.s.ř. stanovena forma rozsudku.«“ Z toho důvodu Úřad rozhodoval o zastavení řízení v části návrhu rozhodnutím.

137.     S ohledem na vše výše uvedené Úřad rozhodl tak, jak je uvedeno ve výroku I. tohoto rozhodnutí.

K výroku II. tohoto rozhodnutí

Skutečnosti vyplývající z dokumentace o zadávacím řízení a další zjištěné skutečnosti

138.     V bodě 4.1 vzoru smlouvy je uvedeno následující:

»Dodavatel se zavazuje realizovat Předmět plnění v následujících termínech:

4.1.1 Dodat Řešení dle odst. 2.2.1 až 2.2.3 v souladu s harmonogramem dle Přílohy č. 3 (dále jen „Harmonogram“).

4.1.2    Poskytovat Podporu dle odst. 2.2.4 a 2.2.5 průběžně po dobu 4 let od akceptace Řešení dodaného dle odst. 2.2.1 až 2.2.«

139.     V bodě 5.1.1 vzoru smlouvy je uvedeno následující:

„Spolu s Předmětem plnění bude předána také veškerá dokumentace (např. produktová, uživatelská) vztahující se k Předmětu plnění a k Software, bez níž by nemohlo docházet
k řádnému užívání Software v souladu s poskytnutou Licencí, v českém jazyce, která bude předána spolu s Předmětem plnění v elektronické podobě.“

140.     V příloze č. 1 smlouvy je část označená jako „Popis řešení Nástroje včetně schématického znázornění architektury“, přičemž je zde poznámka „(doplní dodavatel)“.

141.     V příloze č. 1 smlouvy je část označená jako „Požadavky na nástroj pro Log Management“, kde jsou uvedeny mj. následující požadavky:

142.     V příloze č. 3 smlouvy s názvem „Harmonogram“ je uvedena následující tabulka:

Činnost	Výstup / Akceptační kritérium	Počet dní
Vytvoření Cílového konceptu	Cílový koncept nasazení LM bude popisovat minimálně následující oblasti: Finální architektura řešení, včetně síťové komunikační matice (datové toky) Základní návrh implementace do podnikové architektury v souladu s Přílohou č. 7 této Smlouvy, doplněný o požadavky na konfiguraci/nastavení HW/SW (dle potřeby popřípadě o specifické instalační postupy) Síťová komunikační matice popisující dopad veškerou potřebnou datovou komunikaci LM jak mezi sebou navzájem, tak i jinými komponentami. Popis integrační dokumentace popisující dopad integrace na ostatní systémy Specifikace zákaznických modifikací a úprav Detailní popis provedených zákaznických konfigurací pro nasazení a provoz LM v ČP (nad rozsah standardní produktové dokumentace) Popis zajištění důvěrnosti a integrity zpracovávaných informací (logů), včetně bezpečné archivace Návrh úprav a doplnění řídící dokumentace Objednatele Požadavky na součinnost ze strany Dodavatele Případné změnové požadavky v projektu Plán obnovy po výpadcích řešení (DRP), včetně návrhu testování před akceptací Popis možného rozšíření škálováním jak vertikálně, tak i horizontálně, a to až do 50 000 EPS a s tím i odpovídající navýšení objemu dat	D + doplní Dodavatel
Instalace a konfigurace HW a SW komponent	Funkční nástroj v prostředí Objednatele	D + doplní účastník
Integrace s AD/LDAP, prostupy	Nástroj je integrovaný s AD/LDAP a jsou rozděleny přístupy a role	D + doplní účastník
Implementace v rozsahu dle Přílohy 2 této smlouvy	Nástroj zpracovává logy minimálně v rozsahu dle Přílohy 2 této smlouvy	D + doplní účastník
Nastavení reportingu a způsobu hlášení	Jsou funkční reporty a proces zasílání reportů v souladu s technickou specifikací v Příloze 1	D + doplní účastník
Seznámení pracovníků Objednatele s Řešením	Uživatelské seznámení s Řešením, které představí uživatelům celkový funkční stav a naučí uživatele jak základy, tak pokročilé možnosti práce s Řešením, jeho webovým rozhraním i konfigurací (web, CLI, python). Seznámení bude minimálně v rozsahu 2 dnů (2x 6 hodin) pro minimálně 20 účastníků. Seznámení proběhne v prostorách a s technikou Objednatele.	D + doplní účastník
Testování plánů obnovy	V rámci akceptace bude proveden test plánů obnovy. Bude simulován výpadek SW a HW komponent dle postupů definovaných v Cílovém konceptu. Akceptačním kritériem je úspěšná obnova řešení.	D + doplní účastník
Úprava a doplnění řídící dokumentace Objednatele	Aktuální řídící dokumentace v elektronické podobě (DOCx, XLSx…)	D + doplní účastník
Akceptace	Plně funkční řešení v rozsahu Implementace (Příloha 2 této smlouvy)	D + doplní účastník

Následně pod tabulkou je uvedeno, že »Termín „D“ je roven dnu, kdy nabyla tato Smlouva účinnosti.«.

143.     V protokolu o jednání komise ze dne 15. 6. 2021 (dále jen „protokol č. 1) je uvedeno k nabídce vybraného dodavatele, že „Komise shledala celkovou nabídkovou cenu jako mimořádně nízkou“, přičemž dále je zde uvedeno následující:

»Komise proto požádala v souladu s § 113 odst. 4 zákona o písemné zdůvodnění způsobu stanovení mimořádně nízké nabídkové ceny k výše uvedené veřejné zakázce, která se liší od ostatních nabídek téměř řádově (jednotky mio vers. desítka mio.).

Komise považuje za důležité se ujistit, že nabízené řešení v prvé řadě kvalitativně a funkčně odpovídá zadání a je proveditelné v rámci nabídkové ceny. Z toho důvodu žádá, aby se účastník ve vysvětlení zaměřili na detailní osvětlení ekonomické výhodnosti nabízeného řešení, například popisu, zda se jedná o kombinaci open source platforem, jakým způsobem jsou tyto platformy podporovány, jak zajistí udržitelnost řešení po dobu trvání kontraktu a také jak bude implementace a následná podpora ze strany účastníka zajištěna lidskými zdroji (zaměstnanecky, externě, atd.). Dále je pro zadavatele také důležitá informace, zda se jedná o proprietární řešení „vyspecifikované“ pro konkrétní poptávku ze strany zadavatele, nebo jestli se jedná o standardizované řešení, které účastník standardně nabízí a realizuje. Dále komise žádá, aby účastník na základě znalosti problematiky a možností trhu objasnil, kde vidí hlavní důvod mimořádně vysoké úspory oproti ostatním konkurenčním řešením, která jsou účastníkovi známa, a na trhu se s nimi standardně setkává.

Komise dále požaduje detailní rozbor sestavení finanční nabídky v oblasti náročnosti předpokládaných prací, a to ve smyslu poskytnutí nutné součinnosti ze strany zadavatele. Zadavatel ve smyslu návrhu smlouvy předpokládá součinnost formou poskytnutí nezbytně nutných informací a nastavení prostředí ICT přesně dle pokynů účastníka (viz. odst. 5.4. návrhu smlouvy). Zadavatel dle koncepce obchodních podmínek nepředpokládá žádné další odborné práce ze své strany a požaduje dodávku předmětu plnění de facto „na klíč“. Pro uvedení řešení do rutinního provozu (produkce) bude také nezbytně nutné seznámit s provozními činnostmi obsluhu řešení na straně zadavatele dle ustanovení v odst. 2.2.3 návrhu smlouvy a ve spojitosti s formou provozu komise žádá objasnění, do jaké hloubky bude toto seznámení s obsluhou nutné (náročné) a v jakém čase předpokládáte předání řešení do plného/ částečného režimu
v kombinaci s rozsahem nabízené podpory. Zjednodušeně řečeno, komise žádá o informaci
v jakém poměru, resp. vztahu budou provozní činnosti po dobu podpory rozděleny mezi účastníka a zadavatele.

Vysvětlení nabídkové ceny musí jasně prokázat, že se účastník velmi podrobně zabýval sestavením nabídkové ceny, že disponuje zkušeností, která mu umožnila optimalizovat nabídkovou cenu a vychází ze zkušenosti z implementací obdobných řešení a nabízí standardizované řešení, kde neexistuje relevantní riziko vzniku nepředpokládaného technického problému.

Komise dále požaduje, aby účastník zadávacího řízení výslovně potvrdil, že při plnění veřejné zakázky zajistí dodržování povinností vyplývajících z právních předpisů vztahujících se
k předmětu veřejné zakázky, jakož i pracovněprávních předpisů a kolektivních smluv vztahujících se na zaměstnance, kteří se budou podílet na plnění veřejné zakázky, a dále že neobdržel neoprávněnou veřejnou podporu.«

144.     Z žádosti o písemné vysvětlení nabídky a zdůvodnění mimořádně nízké nabídkové ceny ze dne 16. 6. 2021 (dále jen „žádost o objasnění“) vyplývá, že se zadavatel dotazoval vybraného dodavatele na otázky dle protokolu č. 1 (viz předchozí bod odůvodnění tohoto rozhodnutí) týkající se MNNC.

145.     Z dokumentace o zadávacím řízení vyplývá, že dne 22. 6. 2021 vybraný dodavatel doručil zadavateli vysvětlení nabídky a zdůvodnění mimořádně nízké nabídkové ceny z téhož dne (dále jen „objasnění MNNC“), kde vybraný dodavatel na položené dotazy zadavatele týkající se MNNC uvedl mj. následující:

„Společnost AXENTA a.s. především prohlašuje, že nabízené řešení kvalitativně a funkčně odpovídá zadání a je proveditelné v rámci nabídkové ceny.

Pro plnění veřejné zakázky jsme se rozhodli použít technické řešení od výrobce TeskaLabs, který nám poskytl nejvýhodnější cenové podmínky a jeho řešení spolehlivě splní všechny nároky plynoucí ze zadávací dokumentace. Použitá technologie využívá nové trendy v oblasti zpracování logů, je spolehlivější, rychlejší, a navíc finančně méně náročná.

Ze znalosti trhu a nabízených technologií můžeme konstatovat, že se jedná o standardní implementaci nástroje Log Managementu a objem prací nijak nepřevyšuje nároky na srovnatelné implementace.

Co se týká použité technologie (TeskaLabs LogMan.io), tak se jedná o moderní a efektivní způsob zpracování logů, který je navržen jako vysoce škálovatelný systém; to znamená, že ho lze nasazovat od malých instalací po ty největší, a to vždy s důrazem na optimální ekonomiku konkrétní velikosti instalace.

Platforma, která LogMan.io pohání, je složena z renomovaných open-source nástrojů, např. Apache Kafka nebo ElasticSearch, ke kterým není třeba dokupovat licence od třetích stran. Zároveň výrobce TeskaLabs disponuje zkušeným týmem specialistů, kteří umí všechny použité open-source komponenty efektivně provozovat a spravovat. Toto vše umožňuje výrobci stanovovat ceny pro produkt LogMan.io v podstatě lineárním způsobem, v přímé závislosti na počet požadovaných EPS.

Rozbor sestavení finanční nabídky – cena licence nástroje TeskaLabs LogMan.io byla stanovena dle platného ceníku společnosti TeskaLabs. Cena licence se stanovuje dle EPS a dle zadávací dokumentace se jedná o 851 EPS, které společnost AXENTA standardním způsobem nacenila na cenu, která byla vložena do nabídky.

Zde shledáváme nejvýraznější důvod pro mimořádně vysoké úspory oproti ostatním konkurenčním řešením:

• Zadavatel se vydává cestou postupného růstu, kdy nejprve staví základní systém a připojuje první zdroje logů (dle nabídky etapa 1).
• Poté se předpokládá připojování dalších zdrojů a postupný růst velikosti systému a potažmo i jeho ceny (dokupování EPS licence).
• Toto je způsob, který volí i jiní zákazníci a cena těchto dodávek je a byla obdobná.
• Pokud jiný účastník výběrového řízení předložil nabídku přesahující deset milionů, tak (1) se jedná o cenu naprosto nepřiměřenou požadovaným EPS a dalšímu rozsahu; (2) lze dovodit, že z nějakého důvodu naceňuje podstatně vyšší EPS, než bylo zadavatelem v první etapě požadováno.“

Následně vybraný dodavatel uvedl cenový rozbor své nabídky.

Dále vybraný dodavatel uvedl následující:

»Společnost AXENTA prohlašuje, že uvedená cena je srovnatelná s obdobnými nabídkami a dodávkami, při kterých byla použita technologie od výrobce TeskaLabs.

Technické zadání ze zadávací dokumentace veřejné zakázky jsme důkladně prostudovali a proběhla řada interních odborných debat na téma jakým způsobem budeme řešit např. vysokou dostupnost řešení, konkrétní hardwarové prostředky, napojování jednotlivých zdrojů včetně časové náročnosti, bezpečnostní aspekty celé instalace, uživatelskou zkušenost operátorů, předpokládaný růst řešení, diskové úložiště a další.

Je nutno dodat, že se z pohledu společnosti AXENTA jedná o vcelku standardní dodávku, která se velmi podobá předchozím úspěšným dodávkám produktu LogMan.io pro zákazníky podobné velikosti, jako je zadavatel. Během tvorby nabídky byla vyhodnocována jednotlivá rizika tak, jak je známe z obdobných dodávek a žádné významné riziko identifikováno nebylo. Obvyklým rizikem bývá např. zdroj logů, který je "exotický", u něj se může stát např. to, že nebude
k dispozici dokumentace a během dodávky bude implementátor muset vyvinout větší úsilí během napojování. Toto riziko jsme ale v zadávací dokumentaci neidentifikovali. Další riziko bývají integrační práce, např. napojení systému na Active Directory a další systémy. Opět jsme shledali, že zadavatel požaduje poměrně běžnou sadu integraci, kde nevidíme významnější míru rizika. Implementace a následná podpora dodaného řešení bude ze strany AXENTA primárně poskytována vlastními lidskými zdroji (zaměstnanci společnosti AXENTA) s možnou podporou výrobce při řešení událostí, které nyní nelze předvídat.

Při implementaci nepředpokládáme žádné odborné práce ze strany zadavatele a dodávka předmětu plnění bude v podstatě „na klíč“, jak požaduje zadavatel.

Dále na náš dotaz společnost TeskaLabs (výrobce) prohlašuje, že usiluje o dodání svého produktu LogMan.io v jeho nejnovější verzi. Společnost TeskaLabs se systémově nezabývá dodávkou "specifických" zákaznických řešení, jejich misí je vývoj produktů v oblasti kybernetické bezpečnosti. Technologie společnosti TeskaLabs jsou známy širokými možnostmi konfigurace a jejich produkty jsou určeny pro korporátní trhy, kde se vyžaduje vysoká míra přizpůsobitelnosti produktu „na míru“ korporátního zákazníka. Toto přizpůsobení má
v dodávce na zodpovědnost implementační partner a nejedná se o „proprietární řešení vyspecifikované pro konkrétní poptávku“. V nabídce se tedy nejedná o řešení, které bude nasazeno pouze u zadavatele, ale je standardně dodáváno zákazníkům, jako součást řešení kybernetické bezpečnosti.

Dodávky tohoto typu jsou vždy doplněny o proškolení technického personálu na straně zadavatele/provozovatele. V základním rozsahu se jedná o školení v rozsahu dvou dnů. V rámci podpory je potom možné čerpat konzultace na specifická témata, v rozsahu několika hodin měsíčně.

Výrobce TeskaLabs také poskytuje online fórum pro koncové uživatele produktu, kde jsou
k dispozici specialisté společnosti TeskaLabs a kde je možné řešit neobvyklé situace nebo třeba otázky spojené s rozvojem řešení. V plně produkčním provozu se předpokládá, že zadavatel bude provozovat systém TeskaLabs LogMan.io sám, tak jako ostatní uživatelé.«

Závěrem vybraný dodavatel uvedl, že „Společnost AXENTA a.s., jako účastník zadávacího řízení potvrzuje, že při plnění veřejné zakázky zajistí dodržování povinností vyplývajících z právních předpisů vztahujících se k předmětu veřejné zakázky, jakož i pracovněprávních předpisů a kolektivních smluv vztahujících se na zaměstnance, kteří se budou podílet na plnění veřejné zakázky, a dále že neobdržel neoprávněnou veřejnou podporu.“.

146.     V protokolu o jednání komise ze dne 29. 6. 2021 (dále jen „protokol č. 2“) je uvedeno následující:

„Náplní jednání komise bylo dokončení posouzení splnění podmínek účasti v zadávacím řízení a objasnění mimořádně nízké nabídkové ceny u účastníka řízení, jehož nabídka byla vyhodnocena jako ekonomicky nejvýhodnější. Komise zohlednila doručené písemné vysvětlení předložených informací a písemné zdůvodnění způsobu stanovení mimořádně nízké nabídkové ceny, která jsou součástí dokumentace o zadávacím řízení.

Komise došla k závěru, že účastník řízení, jehož nabídka byla vyhodnocena jako ekonomicky nejvýhodnější, je způsobilý k realizaci veřejné zakázky, prokázal splnění kvalifikace a jeho nabídka splňuje zákonné a zadávací podmínky k veřejné zakázce. Komise akceptovala zdůvodnění mimořádně nízké nabídkové ceny předložené účastníkem, jejíž výši účastník odůvodnil zejména použitým technickým řešením. Účastník dále potvrdil, že při plnění veřejné zakázky zajistí dodržování povinností vyplývajících z právních předpisů vztahujících se
k předmětu veřejné zakázky, jakož i pracovněprávních předpisů a kolektivních smluv vztahujících se na zaměstnance, kteří se budou podílet na plnění veřejné zakázky, a dále že neobdržel neoprávněnou veřejnou podporu.“

147.     Ve veřejné dokumentaci nástroje Logman.io[2] na stránce týkající se manuální instalace je popsán postup manuální instalace nástroje, přičemž mj. jsou zde uvedeny interakce s Git viz následující obrázky:

 

 

148.     Zadavatel v rámci správního řízení sp. zn. S0379/2021/VZ doručil Úřadu vyjádření zadavatele ze dne 13. 9. 2021, přičemž k němu jako přílohu přiložil znalecký posudek č. 203-7/2020 (dále jen „znalecký posudek č. 203-7/2020“) vypracovaný znalcem Vítem Lidinským, IČO 71443029, se sídlem Jesenicova 500/8, Praha 3 – Žižkov, zadaný společností TESKALABS LTD, odštěpný závod, IČO 07957157, se sídlem Kodaňská 1441/46, 101 00 Praha 10 (dále jen „Teskalabs“).

149.     Ve znaleckém posudku č. 203-7/2020 je v bodě 1 s názvem „Úvod“ uvedeno, že „Předmětem znaleckého posudku je odpovědět na následující otázky položené Znalci Zadavatelem

1. Posuďte, zda produkt naší společnosti TeskaLabs Logman.io splňuje požadavky ČSN/ISO 27001:2013.

2. Posuďte, zda produkt naší společnosti TeskaLabs LogMan.io splňuje požadavky zákona o kybernetické bezpečnosti v platném znění pro Log Management SW.“

150.     Ve znaleckém posudku č. 203-7/2020 v bodě 1.3 s názvem „Použité podklady a zdroje informací“ jsou uvedeny následující podklady pro tvorbu posudku.

 

151.     Ve znaleckém posudku č. 203-7/2020 v bodě 2.3 s názvem „Požadavek ISO 27001 na Log Management“ je uvedeno následující:

„Konkrétní požadavky na zpracování logů jsou uvedeny v rámci ISO 27001 v příloze A, části 14.2. Celá oblast týkající se oblasti logování a práce s logy je uvedena na následujícím obrázku.

 

Znalec uvádí, že obecné požadavky v příloze A uvedené normy jsou na základě provedené analýzy rizik, případně dalších legislativních požadavků konkretizovány pro každou implementaci ISMS. V obecné rovině je nezbytné, aby Log Management zajišťoval

• Centrální uložení logů
• Možnost přezkumu vedených logů
• Zajištění vedených logů proti zfalšování a neoprávněnému přístupu“

152.     Ve znaleckém posudku č. 203-7/2020 v bodě 2.4 s názvem „Požadavek ZKB a VKB“[3] je uvedeno následující:

»Zákon o kybernetické bezpečnosti v detailu prováděný vyhláškou o kybernetické bezpečnosti vychází z ISO 27001. V některých případech (to je i případ logů) nastavuje některé základní požadavky (požadavky nejsou nastaveny dle analýzy rizik s „nulovou” počáteční hodnotou, ale již s hodnotou přednastavenou na konkrétní hodnotě).

VKB obsahuje tyto požadavky v rámci paragrafu 22 povinnost pro dotčené osoby zajistit logování HW a SW komponent, dále v ustanovení odst. 2, písm. c) ochranu získaných informací před neoprávněným čtením a jakoukoli změnou a následně podle odst. 3 nebo odst. 4 zajištění uchování záznamů po dobu 12 nebo 18 měsíců podle typu dotčené osoby.

V rámci požadavků podle paragrafu 23 a 24 je Log Management nástrojem pro správce a provozovatele Významného informačního systému. V případě jiných povinných osob je Log Management součástí nástroje SIEM, jehož provoz je povinností právě podle paragrafu 23 a 24. V rámci požadavků VKB a ZKB je nezbytné, aby Log Management zajišťoval

• Uložení logů
• Ochranu logů před neoprávněným čtením a jakoukoli změnou 
• Archivaci logů pod dobu 12 měsíců«

153.     Ve znaleckém posudku č. 203-7/2020 v bodě 2.6 s názvem „Závěry“ jsou v tabulce uvedeny závěry k požadavkům na fungování Log Managementu.

 

154.     Ve znaleckém posudku č. 203-7/2020 je v bodě 2.5 s názvem „Funkce TeskaLabs LogMan.io“ je uvedeno mj. následující:

„Log Management TeskaLabs LogMan.io obsahuje funkce pro příjem logů (bez omezení jejich formátu či struktury). Následně dojde v rámci komponenty Ingestor k označení každého logu časovým razítkem. Do JSON struktury, která obsahuje data logu je kromě časového razítka přidán rovněž hash předchozí JSON struktury předchozího logu. Tím je zajištěna řada uložených logů z hlediska jejich časového pořízení/přijetí do Log Managementu a jejich neměnnosti.

Po projití Ingestorem jsou logy rozparsovány a uloženy. Délka uložení není aplikačně omezena a je odvislá od zakoupené licence TeskaLabs LogMan.io.

Pro přístup k logům je využíván nástroj Kibana nebo nativní GUI TeskaLabs LogMan.io. Přístup k logům je chráněn přihlášením pouze pro oprávněné uživatele. Vybrané pohledy na prostředí aplikace jejím vlastním GUI byly pořízeny Znalcem při místním šetření a jsou uvedeny na následujících obrázcích.“

Dále jsou zde uvedeny obrázky s pohledy na aplikaci TeskaLabs LogMan.io.

155.     Ve znaleckém posudku č. 203-7/2020 je v bodě 3 s názvem „Výrok“ je uvedeno k otázkám znaleckého posudku následující:

K otázce č. 1 – „Produkt společnosti TeskaLabs Logman.io splňuje požadavky ČSN/ISO 27001:2014 jako poslední verzi této normy a rovněž ČSN/ISO 27001:2013 jako verze předchozí na produkt typu Log Management.“

K otázce č. 2 – „Produkt společnosti TeskaLabs LogMan.io splňuje požadavky ZKB a VKB na produkt typu Log Management pro správce a provozovatele Významného informačního systému.“  

156.     Usnesením č. j. ÚOHS-33210/2021/511/LHl ze dne 1. 10. 2021 určil Úřad ve správním řízení sp. zn. S0379/2021/VZ vybranému dodavateli lhůtu k vyjádření se k tvrzením navrhovatele uvedeným v čl. IV návrhu, podle nichž systém nabízený vybraným dodavatelem nesplňuje požadavky zadavatele na systém Log Managementu stanovené v bodech 101 až 146, 153, 154, 166, 304, 305, 510, 511 a 512 přílohy č. 1 smlouvy, a k doložení svého vyjádření příslušnými podklady. Dne 11. 10. 2021 vybraný dodavatel doručil reakci na uvedenou výzvu Úřadu (dále jen „vyjádření vybraného dodavatele ze dne 11. 10. 2021“). Obsah vyjádření vybraného dodavatele ze dne 11. 10. 2021 je pak včleněn do textu usnesení ze dne 2. 6. 2022, kterým Úřad ustanovil znalce (viz „Navržený způsob řešení“ u jednotlivých otázek).

157.     Úřad dne 16. 9. 2022 obdržel znalecký posudek, v němž znalec v části 1 bod 1.1.2 mj. uvedl, že „Tento znalecký posudek byl zpracován v souladu s těmito obecnými předpoklady a omezujícími podmínkami:

„a) Bylo provedeno řádné šetření k ověření správnosti a úplnosti předložených souborů jako podklad pro znalecké posouzení. (…)

b) Vychází se z toho, že informace jiných zdrojů, které sloužily, jako další podklad pro zpracování tohoto znaleckého posudku jsou věrohodné a nebyly tudíž ve všech případech z hlediska jejich přesnosti a úplnosti ověřovány. (…)“

158.     V části 1 bod 1.9 s názvem „Použité metody a prostředky“ znaleckého posudku znalec uvedl mezi své metody a prostředky následující:

• Technické vybavení znalce – Hardware (HW)

o   Laboratorní počítač typu PC notebook VisionBook

• Programové vybavení znalce – Software (SW)

o   Operační systém MS Windows 10

o   MS Office 365, 2007

o   Adobe Reader DC

o   Mozilla Firefox EU

• Místní šetření dne 4. 8. 2022
• Testování demoverze logman.io
• Znalcem oslovené společnosti TeskaLabs a vybraný dodavatel

159.     V bodě 1.9.3 znaleckého posudku znalec uvedl, že provedl dne 4. 8. 2022 místní šetření u vybraného dodavatele, přičemž konkrétně je v tomto bodě uvedeno následující:

»Znalci bylo umožněno setkání na půdě společnosti AXENTA v Brně na Jundrovské 31, prostřednictvím video rozhovoru se zástupci společnosti TeskaLabs v následujícím složení:

• Společnost TeskaLabs Ltd., p. Aleš Teska, hlavní produktový architekt, CTO
• Společnost O2, p. Jiří Sedlák, vedoucí Security Expert Centra
• Společnost O2, p. Pavel Venc, hlavní analytik Security Expert Centra
• Společnost AXENTA a.s., p. Lukáš Přibyl, CEO
• Společnost AXENTA a.s., p. Peter Jankovský, hlavní architekt řešení, CTO
• Společnost AXENTA a.s., p. Jan Kozák, pre-sales a projektový manažer

Předmětem této formy místního šetření, bylo vysvětlení a zodpovězení otázek 1-56 a dále i ukázky řešení majitelem a hlavním architektem logma.io p. Alešem Teskou, dále byly přítomni zástupci společnosti O2 u které je podobné řešení nasazeno – implementováno společností Axenta a.s., která implementaci provedla.

Průběh šetření:

Před započetím samotného místního šetření představil „moderátor“ šetření pan Lukáš Přibil, CEO, AXENTA a.s. přítomné a objasnil jim důvody a podstatu místního šetření. Znalci byla vysvětlena, umožněna a předvedena funkcionalita SW logman.io související s dotazy 1-56. Mezi znalcem a přednášejícími nedošlo k žádnému sporu a veškeré dotazy byly řádně odpovězeny. Pro místní šetření byly použity následující pomůcky:

• SW logman.io nasazený ve společnosti O2

Na dotazy reagovali zúčastnění ukázkou, vysvětlením, jak zástupci společnosti, která SW logman.io vyvinula, tak jej potvrdili zástupci společnosti, která SW logman.io provozuje.«

160.     V bodě 1.9.4 znaleckého posudku znalec uvedl jako jednu z metod použitých pro zpracování znaleckého posudku „Testování demoverze logman.io“, přičemž konkrétně k této metodě uvedl následující:

„V období měsíce srpna bylo provedeno testování demoverze logman.io nezávislým auditorem formou MS TEAMS (Microsoft Teams je firemní platforma, která umožňuje textovou komunikaci, video hovory, datové úložiště pro ukládání souborů a integraci dalších aplikací do tohoto prostředí. Platforma také umožňuje integrovat produkty jiných společností).

Interaktivní meeting se uskutečnil 19.8.2022 v ranních hodinách. S předem avizovaným (e-mailem) okruhem otázek:

Ukázka vysvětlení zpracování:

1. Definování a nastavování přístupových rolí

1.      (ověření funkčnosti u dvou různých rolí admin/user)

2. Zpracovávání formátu WIN logů

• (MS, OS, MS SQL,DHCP,AD,firewall)
• Logy z cloud AZURE (sharepoint, 0365)
• Bez agentový systém?

3. Zpracování jiných typů formátů, jako je JSON

1.      formátu CEF logů

2.      Načítání logů z TXT souboru

3.       SAP

4. Možnost záloh, logů a konfigurace, na cizí úložiště (síťový disk)

5. Kontejnerizace:

1.      Downgrade vs. Upgrade

2.      Je možné ukázat praktickou ukázku downgrade?

3.      Jak probíhá nasazování nových verzí?“

161.     V bodě 1.9.5 znaleckého posudku znalec uvedl jako jednu z metod použitých pro zpracování znaleckého posudku oslovení společnosti TeskaLabs a vybraného dodavatele, přičemž konkrétně k této metodě uvedl následující:

„Společnost TeskaLabs i AXENTA obdrželi soubor otázek s možností odpovědět popř. se vyjádřit k dotazům 1-56.“

162.     V části 1 bod 1.10 s názvem „Výsledky a hodnocení“ znalec sděluje, že „Výsledky jednotlivých metod – viz 1.9.3 – 1.9.5 jsou shodné a jejich výsledky jsou uvedeny v odpovědích v kap. 2“.

163.     V části 1 bod 1.11 s názvem „Shrnutí a závěr“ znalec sděluje, že „Z důvodů velkého množství zařízení a jejich modifikací i požadavků zákazníků má logman.io cca 80% předdefinovaných - zbývající doprogramuje u zákazníka dle jeho potřeb, což je běžnou praxí.“.

164.     V části 2 znaleckého posudku znalec odpovídá na jednotlivé otázky Úřadu.

165.     K otázce č. 1 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Apache httpd

Navržený způsob řešení: Sběr - Collector, smart-file, alternativne přes Syslog[4], Parsování - Apache HTTP Server build-in preprocessor[5], Normalizace – ECS Schema

Souhrnně ke způsobu řešení požadavků zadavatele č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[6] deklarativního enricheru
s využitím ECS schématu[7] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek zadavatele uvedený
v bodě 1 lze splnit realizací navrženého způsobu řešení popsaného v tomto bodě. Svou odpověď zdůvodněte.“

a k otázce č. 2 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Apache Tomcat

Způsob řešení: Sběr - Collector, smart-file[8], Parsování - Apache HTTP Server build-in preprocessor[9], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel uvedl, že Apache TomCat produkuje logy ve formátu kompatibilním s Apache HTTP Serverem, přičemž odkázal na dokumentaci výrobce zdroje logu[10].

Souhrnně ke způsobu řešení požadavků zadavatele č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[11] deklarativního enricheru
s využitím ECS schématu[12] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 2 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 1 lze splnit způsobem popsaným v tomto bodě“ (totožnou odpověď znalec uvedl i k otázce č. 2), přičemž ve zdůvodnění je dále k oběma otázkám uvedeno, že

• »všechny systémy, které jsou založené na platformě Linux s možnosti tvorby logů do syslogu, standardizovaný log, umožňují práci s těmito logy,
• standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi«

166.     K otázce č. 3 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z ArcSight CEF format all sources

Způsob řešení: Sběr - Collector, smart-file, alternativne přes Syslog[13], Parsování - CEF built-in preprocessor[14], Normalizace – ECS Schema.

Souhrnně ke způsobu řešení požadavků zadavatele č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[15] deklarativního enricheru
s využitím ECS schématu[16] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 3 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 3 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://docs.teskalabs.com/loeman.io/reference/integ
• https://docs.centrifv.eom/Content/lntegrationContent/SIEM/arcsight-cef/arcsight-cef-format.htm«

167.     K otázce č. 4 ve znění:

„Požadavek zadavatele:Nástroj podporuje sběr, parsování a normalizaci logů z Brocade FC switches

Způsob řešení: Sběr - Syslog ingestor[17], Parsování - Apache HTTP Server build-in preprocessor[18], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[19].

Souhrnně ke způsobu řešení požadavků zadavatele č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[20] deklarativního enricheru
s využitím ECS schématu[21] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 4 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

Znalec se ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 4 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://www.ibm.com/docs/sk/dsm?topic=os-configuring-syslog-brocade-fabric-appliances«

168.     K otázce č. 5 ve znění:

„Požadavek zadavatele:Nástroj podporuje sběr, parsování a normalizaci logů z Cisco ASA

Způsob řešení: Sběr - Syslog ingestor[22], Parsování - Apache HTTP Server build-in preprocessor[23], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[24].

Souhrnně ke způsobu řešení požadavků zadavatele č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[25] deklarativního enricheru s využitím ECS schématu[26] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 5 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 5 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://www.cisco.com/c/en/us/support/docs/securitv/pix-500-series-securitv-appliances/63884-config-asa-OO.html«

169.     K otázce č. 6 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Cisco Firepower

Způsob řešení: Sběr - Syslog ingestor[27], Parsování - Apache HTTP Server build-in preprocessor[28], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[29].

Souhrnně ke způsobu řešení požadavků zadavatele č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[30] deklarativního enricheru
s využitím ECS schématu[31] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 6 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 6 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://www.manageengine.com/products/firewall/help/configure-cisco-firepower-firewalls.html«

170.     K otázce č. 7 ve znění:

„Požadavek zadavatele:Nástroj podporuje sběr, parsování a normalizaci logů z Cisco IOS

Způsob řešení: Sběr - Syslog ingestor[32], Parsování - Apache HTTP Server build-in preprocessor[33], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[34].

Souhrnně ke způsobu řešení požadavků zadavatele č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[35] deklarativního enricheru
s využitím ECS schématu[36] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 7 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 7 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://www.auvik.com/franklvit/blQg/configure-svslog-cisco/«

171.     K otázce č. 8 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Cisco SMB

Způsob řešení: Sběr - Syslog ingestor[37], Parsování - Apache HTTP Server build-in preprocessor[38], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[39].

Souhrnně ke způsobu řešení požadavků zadavatele č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[40] deklarativního enricheru
s využitím ECS schématu[41] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 8 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalecve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 8 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi«

172.     K otázce č. 9 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Cisco WLC

Způsob řešení: Sběr - Syslog ingestor[42], Parsování - Apache HTTP Server build-in preprocessor[43], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[44].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[45] deklarativního enricheru s využitím ECS schématu[46] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 9 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 9 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://www.cisco.eom/c/en/us/support/docs/wireless/4100-series-wireless-lan-controllers/107252-WLC-Svslog-Server.html«

173.     K otázce č. 10 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Dell Force10

Způsob řešení: Sběr - Syslog ingestor[47], Parsování - Apache HTTP Server build-in preprocessor[48], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[49].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[50] deklarativního enricheru s využitím ECS schématu[51] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 10 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 10 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://www.dell.eom/support/kbdoc/cs-cz/000102563/dell-emc-networking-os9-nastaven%C3%AD-aspr%C3%Alva-p%C5%99ihla%C5%Alov%C3%Aln%C3%AD-v-p%C5%99ep%C3%ADna%C4%8Di«

174.     K otázce č. 11 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z F5

Způsob řešení: Sběr - Syslog ingestor[52], Parsování - Apache HTTP Server build-in preprocessor[53], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[54].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[55] deklarativního enricheru s využitím ECS schématu[56] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 11 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 11 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://support.f5.eom/csp/article/K13080«

175.     K otázce č. 12 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z FlowMon

Způsob řešení: Sběr - Syslog ingestor[57], Parsování - Apache HTTP Server build-in preprocessor[58], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[59].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[60] deklarativního enricheru s využitím ECS schématu[61] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 12 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 12 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://www.flowmon.com/en/blog/creating-custom-logs-from-netflow«

176.     K otázce č. 13 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z FortiDDoS

Způsob řešení: Sběr - Syslog ingestor[62], Parsování - Apache HTTP Server build-in preprocessor[63], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[64].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[65] deklarativního enricheru s využitím ECS schématu[66] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 13 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 13 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://docs.fortinet.com/document/fortiddos-f/6.2.0/handbook/797529/appendix-b-remote-syslog- reference.«

177.     K otázce č. 14 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z FortiGate (FOS 5.2)

Způsob řešení: Sběr - Syslog ingestor[67], Parsování - Apache HTTP Server build-in preprocessor[68], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[69].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[70] deklarativního enricheru s využitím ECS schématu[71] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 14 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 14 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://docs2.fortinet.com/document/fortianalyzer/6.0.5/administration-guide/576889/configuring- log-forwarding (umi CEF, syslog)«

178.     K otázce č. 15 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z FreeRADIUS

Způsob řešení: Sběr - Syslog ingestor[72], Parsování - Apache HTTP Server build-in preprocessor[73], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[74].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[75] deklarativního enricheru s využitím ECS schématu[76] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 15 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 15 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://docs2.fortinet.com/document/fortianalyzer/6.0.5/administration-guide/576889/configuring- log-forwarding (umi CEF, syslog)«

179.     K otázce č. 16 ve znění:

„Požadavek zadavatele:Nástroj podporuje sběr, parsování a normalizaci logů z GreyCortex MENDEL

Způsob řešení: Sběr - Syslog ingestor[77], Parsování - Apache HTTP Server build-in preprocessor[78], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[79].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[80] deklarativního enricheru s využitím ECS schématu[81] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 16 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 16 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://www.grevcortex.com/blog/review-grevcortex-mendel«

180.     K otázce č. 17 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z HPE iLo 4 (Server OoB management)

Způsob řešení: Sběr - Syslog ingestor[82], Parsování - Apache HTTP Server build-in preprocessor[83], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[84].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[85] deklarativního enricheru s využitím ECS schématu[86] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 17 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 17 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://support.hpe.com/hpesc/public/docDisplay?docld=emr_na-a00045612en_us«

181.     K otázce č. 18 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z CheckPoint

Způsob řešení: Sběr - Syslog ingestor[87], Parsování - Apache HTTP Server build-in preprocessor[88], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[89].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[90] deklarativního enricheru s využitím ECS schématu[91] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 18 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

kotázce č. 19 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z JSON (format)

Způsob řešení: Sběr - Collector, smart-file[92], Parsování - JSON built-in preprocessor[93], Normalizace – ECS Schema.

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[94] deklarativního enricheru s využitím ECS schématu[95] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 19 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

kotázce č. 20 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Kernun Clear Web

Způsob řešení: Sběr - Syslog ingestor[96], Parsování - Apache HTTP Server build-in preprocessor[97], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[98].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[99] deklarativního enricheru s využitím ECS schématu[100] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 20 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

kotázce č. 21 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Kernun web filter

Způsob řešení: Sběr - Syslog ingestor[101], Parsování - Apache HTTP Server build-in preprocessor[102], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[103].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[104] deklarativního enricheru s využitím ECS schématu[105] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 21 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

kotázce č. 22 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Linux Cron

Způsob řešení: Sběr - Syslog ingestor[106], Parsování - Apache HTTP Server build-in preprocessor[107], Normalizace – ECS Schema.

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[108] deklarativního enricheru s využitím ECS schématu[109] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 22 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

kotázce č. 23 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Linux Freeradius

Způsob řešení: Sběr - Syslog ingestor[110], Parsování - Apache HTTP Server build-in preprocessor[111], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[112].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[113] deklarativního enricheru s využitím ECS schématu[114] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 23 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

kotázce č. 24 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Linux Iptables

Způsob řešení: Sběr - Syslog ingestor[115], Parsování - Apache HTTP Server build-in preprocessor[116], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[117].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[118] deklarativního enricheru s využitím ECS schématu[119] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 24 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

kotázce č. 25 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Linux postfix

Způsob řešení: Sběr - Syslog ingestor[120], Parsování - Apache HTTP Server build-in preprocessor[121], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[122].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[123] deklarativního enricheru s využitím ECS schématu[124] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 25 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 18 lze splnit způsobem popsaným v tomto bodě“, (totožnou odpověď znalec uvedl i k otázkám č. 19 až 25, přičemž ve zdůvodnění je k otázkám č. 18 až 25 dále shodně uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi«.

182.     K otázce č. 26 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Microsoft Exchange log

Způsob řešení: Sběr - Collector, smart-file[125], Parsování - High-performance parser (SP-Lang)[126], Normalizace – ECS Schema.

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[127] deklarativního enricheru s využitím ECS schématu[128] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 26 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

k otázce č. 27 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Microsoft SharePoint

Způsob řešení: Sběr - Collector, smart-file[129], Parsování - Microsoft ULS built-in preprocessor[130], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[131].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[132] deklarativního enricheru s využitím ECS schématu[133] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 27 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

k otázce č. 28 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Microsoft SQL

Způsob řešení: Sběr - WEC collector[134], Parsování - Microsoft ULS built-in preprocessor[135], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel uvedl, že Microsoft SQL Server 2008 poskytuje funkci SQL Server Auditing. Tutu funkci MS SQL server loguje všechny změny v databazí a mnohé další udalosti do Windows Event Logu (WEC).

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[136] deklarativního enricheru s využitím ECS schématu[137] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 28 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

k otázce č. 29 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Microsoft Windows DHCP log

Způsob řešení: Sběr - WEC collector[138], Parsování - Microsoft ULS built-in preprocessor[139], Normalizace – ECS Schema.

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[140] deklarativního enricheru s využitím ECS schématu[141] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 29 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

k otázce č. 30 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Microsoft Windows firewall

Způsob řešení: Sběr - WEC collector[142], Parsování - W3C build-in preprocessor[143], Normalizace – ECS Schema.

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[144] deklarativního enricheru s využitím ECS schématu[145] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 30 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

k otázce č. 31 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Microsoft Windows IIS

Způsob řešení: Sběr - Collector, smart-file[146], Parsování - W3C build-in preprocessor[147], Normalizace – ECS Schema.

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[148] deklarativního enricheru s využitím ECS schématu[149] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 31 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

k otázce č. 32 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z MS Active Directory

Způsob řešení: Sběr - WEC collector[150], Parsování - High-performance parser (SP-Lang) [151], Normalizace – ECS Schema.

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[152] deklarativního enricheru s využitím ECS schématu[153] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 32 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

k otázce č. 33 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z MS Azure Cloud

Způsob řešení: Sběr - MS Azure collector (add-on), Parsování - High-performance parser (SP-Lang) [154], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel uvedl, že MS Azure cloud je velmi široký pojem. Pokud na MS Azure běží jiné aplikace, pak se log collection provádí pomocí technologie, kterou aplikace podporuje (syslog, WEC, atd.).

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[155] deklarativního enricheru s využitím ECS schématu[156] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 33 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

k otázce č. 34 ve znění:

„Požadavek zadavatele:Nástroj podporuje sběr, parsování a normalizaci logů z MS Azure Sentinel

Způsob řešení: Sběr - MS Azure Sentinel collector (add-on), Parsování - High-performance parser (SP-Lang) [157], Normalizace – ECS Schema.

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[158] deklarativního enricheru s využitím ECS schématu[159] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 34 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“,

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 26 lze splnit způsobem popsaným v tomto bodě“, (totožnou odpověď znalec uvedl i k otázkám č. 27 až 34), přičemž ve zdůvodnění je k otázkám č. 26 až 34 dále shodně uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• WEC/WEF/(wincollect), systém umožňuje práci s MS logy,
• U WIN systémů - ano umí, umí případně logování do souboru a jeho následné vyčítání, v některých případech je potřeba nastavit windows port forwarding, lze nastavit za pomocí GPO (group policy)«.

183.     K otázce č. 35 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z MySQL

Způsob řešení: Sběr - Syslog ingestor[160], Parsování - Syslog built-in preprocessor[161], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[162].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[163] deklarativního enricheru s využitím ECS schématu[164] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 35 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

a k otázce č. 36 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z OpenSSH server

Způsob řešení: Sběr - Syslog ingestor[165], Parsování - Syslog built-in preprocessor[166], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[167].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[168] deklarativního enricheru s využitím ECS schématu[169] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 36 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 35 lze splnit způsobem popsaným v tomto bodě“, (totožnou odpověď znalec uvedl i k otázce č. 36), přičemž ve zdůvodnění je dále uvedeno shodně k oběma otázkám, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi«.

184.     K otázce č. 37 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Oracle DB

Způsob řešení: Sběr - Syslog ingestor[170], Parsování - Syslog built-in preprocessor[171], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[172].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[173] deklarativního enricheru s využitím ECS schématu[174] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 37 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 37 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://docs.oracle.com/cd/E36784 01/html/E37127/audittask-ll.html«.

185.     K otázce č. 38 ve znění:

„Požadavek zadavatele:Nástroj podporuje sběr, parsování a normalizaci logů z Palo Alto

Způsob řešení: Sběr - Syslog ingestor[175], Parsování - Syslog built-in preprocessor[176], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[177].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[178] deklarativního enricheru s využitím ECS schématu[179] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 38 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 38 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://docs.paloaltonetworks.com/pan-os/9-l/pan-os-admin/monitoring/use-svslog-for-monitoring/configure-syslog-monitoring«.

186.     K otázce č. 39 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z PostgreSQL

Způsob řešení: Sběr - Syslog ingestor[180], Parsování - Syslog built-in preprocessor[181], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce zdroje logu[182].

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[183] deklarativního enricheru s využitím ECS schématu[184] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 39 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 39 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• https://docs.paloaltonetworks.com/pan-os/9-l/pan-os-admin/monitoring/use-svslog-for-monitoring/configure-syslog-monitoring«.

187.     K otázce č. 40 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z SAP

Způsob řešení: Sběr - Collector, smart-file[185], Parsování - High-performance parser (SP-Lang)[186], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel uvedl, že předpokládá se zpřesnění parsingu a normalizace pomocí High-performance parsingu (SP-Lang) dle specifických nastavení SAPu u České Pošty, toto provádí implementátor.

Souhrnně ke způsobu řešení  požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[187] deklarativního enricheru s využitím ECS schématu[188] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 40 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

a k otázce č. 41 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z VMware

Způsob řešení: Sběr - Collector, RestAPI[189], Parsování - High-performance parser (SP-Lang)[190], Normalizace – ECS Schema.

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[191] deklarativního enricheru s využitím ECS schématu[192] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 41 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 40 lze splnit způsobem popsaným v tomto bodě“, (totožnou odpověď) znalec uvedl i k otázce č. 41, přičemž ve zdůvodnění je dále uvedeno shodně k oběma otázkám, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,«.

188.     K otázce č. 42 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Windows - any logs from Event Viewer.

Způsob řešení: Sběr - WEC collector[193], Parsování - Microsoft ULS built-in preprocessor[194], Normalizace – ECS Schema. Dále k tomu vybraný dodavatel uvedl, že zde lze předpokládat, že WEF/WEC bude posílat i jiné, než ULS logy. Pro ně se použije high-performance parser (SP-Lang).

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[195] deklarativního enricheru s využitím ECS schématu[196] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 42 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

a k otázce č. 43 ve znění:

„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Windows - any text log from file.

Způsob řešení: Sběr - Collector, smart-file, file[197], Parsování - High-performance parser (SP-Lang)[198], Normalizace – ECS Schema.

Souhrnně ke způsobu řešení požadavků č. 1) až 43) vybraný dodavatel uvádí, že obohacování a normalizace je implementována pomocí SP-Lang[199] deklarativního enricheru s využitím ECS schématu[200] a že seznam zdrojů logů neobsahuje konkrétní verze technologií, případně je místy obecný (any logs, any text file). V takovém případě se bude nasazovat High-performance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP), pokud výrobce neurčí jinak.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 43 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 42 lze splnit způsobem popsaným v tomto bodě“, (totožnou odpověď znalec uvedl i k otázce č. 43), přičemž ve zdůvodnění je dále uvedeno shodně k oběma otázkám, že

• »standardně má logman.io cca 80% předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení, (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.),
• jedná se o běžnou praxi, která upravuje logman.io „na míru" zákazníkovi,
• U WIN systémů - ano umí, umí případně logování do souboru a jeho následné vyčítání, v některých případech je potřeba nastavit windows port forwarding, lze nastavit za pomocí GPO (group policy)«.

189.     K otázce č. 44 ve znění:

„Požadavek zadavatele:Řešení musí umožnit přístup více uživatelů současně, a to jak na úrovni přístupu ke vstupním/zdrojovým datům systému, tak i k incidentům.

Způsob řešení: TeskaLabs LogMan.io je z pohledu uživatelů webová aplikace, to znamená, že uživatelé používají svůj internetový prohlížeč k přístupu k centrální konzoli nástroje. Toto je dokladováno v následujících obrázcích, z nichž vyplývá, že řešení umožňuje přistup více uživatelů současně, a tudíž splňuje požadavek.

Uživatelé se přihlašují do TeskaLabs LogMan.io pomocí webového rozhraní:

 

Každý přihlášený uživatel pracuje ve své „relaci“, nástroj obsahuje přehled těchto uživatelských relací, tj. současně pracujících uživatelů:

 

Zde např. vidíme tři přihlášené uživatele, kteří pracují s nástrojem samostatně. Uživatelé jsou zde identifikování pomocí tzv. „credentials“, tj. technické formy tak, aby nedocházelo ke zbytečné kompromitaci citlivých údajů, jako je uživatelské jméno atp.

Řízení přístupu uživatelů (tj. jejich přihlašování a kontrolu oprávnění k přístupu k jednotlivým komponentám a akcím) poskytuje komponenta TeskaLabs SeaCat Auth. To je nástroj pro správu autentikace a autorizace uživatelů, identity management, session management, Single Sing-On, vícefaktorovou autentizaci uživatelů atd. Jedná se o technologii, kterou vyrábí společnost TeskaLabs a je dodávaná jako součást TeskaLabs LogMan.io, ale i jiných produktu společnosti a konečně je nabízena na trhu i jako samostatný produkt. Pověření administrátoři mohou využít i nízkoúrovňový přístup do systémové konzole pomocí standardního nástroje SSH. Tento přístup umožňuje přístup více uživatelů/administrátorů současně.

Vybraný dodavatel taktéž odkazuje na dokumentaci nástroje[201].

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 44 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 44 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že „umí separovat role a definovat pro konkrétní skupiny/uživatele dané oprávnění.“.

190.     K otázkám č. 45.A a č. 45.B ve znění:

„A. Požadavek zadavatele: Nástroj umožňuje snadné vytváření uživatelských rolí definujících přístupová práva k uloženým událostem a jednotlivým konfiguračním komponentám nástroje.

B. Požadavek zadavatele: Nástroj umožňuje definování uživatelských rolí s možností nastavení přístupových práv (možností granulárního přidělování práv v rámci role podle zdrojů logů, skupin zařízení, jednotlivých serverů, typu logu apod.).

Způsob řešení: TeskaLabs LogMan.io pomocí komponenty TeskaLabs SeaCat Auth poskytuje autorizaci včetně RBAC - tj. uživatelům je možné přidělovat role a konkrétní zdroje. Role je možné vytvářet a přiřazovat buď globálně nebo na úrovni jednotlivých tenantů.

Zde je prezentována schopnost TeskaLabs LogMan.io spravovat přístupová práva uživatelů pomocí tzv. RBAC schématu.

Nástroj umožňuje vytvářet a spravovat role.

 

Role muže být buď globální nebo specifická pro konkrétního tenanta.

 

Zdroje jsou tzv. „zabudované“ a také mohou být uživatelsky definované.

 

Zdroj je např. konkrétní akce v nástroji, jako je přístup ke konfiguračním položkám, komponentám nástroje nebo více granulární, např. čtení, vkládání, editace či mazání položek.

Uživatel si také muže určit zdroje podle skupin logů, např. podle zdrojů, skupin, serverů atp.

Uživatele lze přiřazovat do jednotlivých rolí.

 

Každé roli lze přiřadit zdroje, tj. zde se přiděluje roli oprávnění zdroje používat.

TeskaLabs LogMan.io poskytuje několik úrovní, na kterých lze řídit přistup k logů:

• Nejvyšší úroveň představuji tzv. „tenanti“, ty odpovídají např. celým organizacím
• Další úroveň představují skupiny logů, které se zařazují do tzv. „indexu“ (v terminologii zadáni jsou to „logspaces“), ty jsou optimální volbou pro řízení přístupu (a třeba i zálohovací politiky) uživatelů. Při vhodném návrhu je možné tuto úrovně aplikovat i hierarchicky, do hloubky cca 10 stupňů. Jedná se o doporučovaný přístup k izolaci uživatelských přístupu.
• Nejnižší úroveň pak představuje řízení přístupu pro jednotlivé záznamy, a to tím, že záznamy jsou vybaveny konkrétním označením RBAC zdroje, který uživatel musí mít přiřazen tak, aby k logu mohl přistoupit. Tento přistup má dopad na celkovou výkonnost řešení.

Otázky znalci:

Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 45.A. lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.

Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 45.B. lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 45.A. lze splnit způsobem popsaným v tomto bodě“, (totožnou odpověď znalec uvedl i k otázce č. 45.B), přičemž ve zdůvodnění je dále uvedeno shodně k oběma otázkám, že

• „https://docs.teskalabs.com/logman.io/reference/auth/ (nelze dohledat veškeré informace),
• z přiložené dokumentace lze soudit, že lze požadavek splnit,
• umožňují škálovatelnost uživatelských přístupů, umí separovat role a definovat pro konkrétní skupiny/uživatele dané oprávnění.“

191.     K otázce č. 46 ve znění:

„Požadavek zadavatele: Záloha a obnovení konfigurace celého nástroje je umožněna z centrální konzole.

Způsob řešení: Zálohování a obnova je obrazovka centrální konzole, ze které se provádí záloha a obnovení konfigurace. Další možnost, jak řídit konfiguraci, je využití „site repository“ a verzování pomocí nástroje pro správu verzí (např. Git).

 

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 46 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 46 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• https://docs.teskalabs.com/logman.io/maintenance/diskorganisation
• má centrální konzoli tak ano požadavek lze splnit způsobem popsaným v tomto bodě.
• každá verze management konzole, nebo jiné části je verzována a je vytvořena kompatibilní matice, která říká jaké verze jsou spolu možné kombinovat a jsou i zpětně kompatibilní (díky kontejnerizovaní, lze modulárně skládat).

192.     K otázce č. 47 ve znění:

„Požadavek zadavatele: Existuje možnost nastavení nezávislé zálohovací politiky jak pro konfiguraci, tak pro jednotlivá úložiště (logspace).

Způsob řešení: Zálohovací politika pro úložiště logů je implementována pomocí „Index Lifecycle Management“, což je vlastnost technologie ElasticSearch, ve které jsou logy uloženy. Nastavení je popsáno zde[202].

Obrazovka, kde se nastavování provádí:

 

ILM je možné konfigurovat pro jednotlivé skupiny logů (logspace).

Současně vybraný dodavatel dodává, že Elasticsearch je v LogMan.io – volitelně – využit jako persistentní vrstva – v kombinaci s mnohem modernější tzv. stream (proudovou) architekturou, kde se využívá komponenta Apache Kafka – jeden z nejúspěšnějších opensource nástrojů, původem ze společnosti LinkedIn – a pak komponenta Bitswan, což je opensource produkt pro proudovou analytiku, jež je přímo vyvíjena (i) společností TeskaLabs.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 47 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 47 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že „systém, založený na systému ELK (opensource) z různými nástavbami jako logtrash apod. umožňuje zálohování i nezávislé zálohování.“.

193.     K otázce č. 48 ve znění:

„Požadavek zadavatele: Řešení může být provozováno pouze jako samostatná hardwarová appliance a nabídky musí obsahovat náklady včetně HW potřebný k jejímu provozu.

Způsob řešení: Jelikož se LogMan.io dodává hlavně velkým organizacím, jeho typická forma instalace je tzv. dedikovaný cluster, který se sestává z fyzických hardwarových appliances (zjednodušeně serverů), příkladem je např. dodávka pro O2 Czech Republic, realizovaná formou více fyzických hardwarových appliances, O2 Slovakia (6 fyzických appliances), významný telekomunikační operátor aktivní ve střední Evropě (6 fyzických appliances), dodávka pro významnou složku Ministerstva dopravy, realizovaná na 2 fyzických appliances.

Produkt LogMan.io je znám svým vysokým výkonem, který (krom jiných vlastností) dosahuje moderním přístupem ke škálování, tj. každá z jeho komponent podporuje provoz v režimu clusteru. Tato výhoda pak v podstatě předurčuje LogMan.io pro nasazování na více než jednu appliance, a to pak přímo vede k potřebě dodávat produkt na hardwarových appliances. LogMan.io i jiné produkty společnosti TeskaLabs lze dodávat i provozovat jako virtuální appliance, tato varianta ale nebylo pro předmětné výběrové řízení zvolena.

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 48 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 48 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že „nebylo znalcem ověřeno, ale podle stránek výrobce a dodavatele https://teskalabs.com/products/siem/ je možné splnit popsaným způsobem.“.

194.     K otázce č. 49 ve znění:

„Požadavek zadavatele: Aktualizace nástroje jsou distribuovány v jednotném balíku a jejich instalace je prováděna přes centrální konzoli. Řešeni musí podporovat tzv. rolling upgrade, tj. postupný upgrade jednotlivých uzlů clusteru bez celkového downtime systému minimálně
z pohledu přijmu logu.

Způsob řešení:

Vybraný dodavatel způsob řešení popisuje následovně:

Z veřejně dostupné dokumentace je patrné, že nástroj LogMan.io je distribuován formou tzv. kontejnerů. Kontejnery se pak automaticky spouští v rámci příslušné appliance (ať hardwarové nebo softwarové). Aktualizace technicky probíhá stažením příslušné verze kontejnerů. Toto lze provést v jednom kroku a to „vpřed“ (tj. upgrade) nebo „vzad“ (tj. downgrade) z centrální konzole. LogMan.io používá pokročilou architekturu tzv. microservices nikoliv dnes již zastaralou monolitickou architekturu. Toto konkrétně znamená, že aplikace je rozdělena do malých nezávislých částí, které lze samostatně zapínat či vypínat, upgradovat nebo downgradovat a tak dále. Rolling upgrade pak přímo vychází z vlastností microservice architektury a je to výchozí způsob, jak se LogMan.io aktualizuje.

Microservice architektura nástroje LogMan.io také umožnuje definovat veškerou konfiguraci a konkrétní specifika nasazení ve formě popisného konfiguračního bloku (zvaného site config). Ten je pak možné spravovat pomocí nástroje Git (tj. version control system)[203]. Toto verzování umožňuje snadný návrat k libovolné předchozí verzi konfigurace. Jedná se o pokročilou vlastnost, která je důležitá pro organizace, které chtějí nebo musí aplikovat proces zvaný „configuration management“ (např. dle ISO 9001).

V jiném Úřadu předloženém dokumentu vybraný dodavatel popisuje řešení následovně:

[obchodní tajemství: popis způsobu řešení]

Díky architektuře TeskaLabs LogMan.io při upgrade nedochází k nedostupnosti systému, protože jednotlivé komponenty jsou redundantní, a to buď tím, že běží ve více instancích nebo tím, že se logy ukládají v Apache Kafka po tu dobu, upgrade konkrétní komponenty[204].

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 49 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

a k otázce č. 50 ve znění:

„Požadavek zadavatele:Nástroj podporuje downgrade (včetně sběrných kolektorů), pro případ problémů s novou verzí nástroje po upgrade.

Způsob řešení:[obchodní tajemství: popis způsobu řešení]

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 50 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 49 lze splnit způsobem popsaným v tomto bodě“, (totožnou odpověď znalec uvedl i k otázce č. 50), přičemž ve zdůvodnění je dále uvedeno shodně k oběma otázkám, že „každá verze management konzole, nebo jiné části je verzována a je vytvořena kompatibilní matice, která říká jaké verze jsou spolu možné kombinovat a jsou i zpětně kompatibilní (díky kontejnerizovaní, lze modulárně skládat) - lze tedy splnit způsobem popsaným v tomto bodě.“.

195.     K otázce č. 51 ve znění:

„Požadavek zadavatele:Nástroj garantuje integritu uložených dat. Nesmí umožnit mazání nebo modifikování již uložených logů. Každý log musí mít unikátní identifikátor, který umožní jeho jednoznačnou identifikaci.

Způsob řešení: Jednou ze základních vlastností LogMan.io je to, že logy jsou spravovány
v režimu write-once, tj. logy není možné mazat a ani modifikovat. Tato vlastnost je zajištěna pomocí kryptografických funkcí, konkrétně digitálních podpisů a kryptografických hashů přijímaných logů. Příklad jednoho z opatření v LogMan.io pro integritu uložených dat je např. zde[205].

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 51 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 51 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že „nebylo možné ověřit (vždycky lze data vymazat, jen záleží jak moc je to obtížné).“.

196.     K otázkám č. 52.A a č. 52.B ve znění:

„A. Požadavek zadavatele:Nástroj umožňuje monitoring vlastního stavu a notifikace při překročení prahových hodnot (minimální místo na disku, vytížení paměti, CPU) nebo chybě nástroje s přeposláním upozornění pomocí SMTP nebo Syslog.

B. Požadavek zadavatele: Nástroj umí odeslat událost, která notifikaci vyvolala na externí nástroj minimálně prostřednictvím SMTP nebo Syslogu přes TCP protokol.

Způsob řešení: LogMan.io umožňuje zasílání alertů pomocí SMTP (mailem) a dalších protokolů. O tuto část se v architektuře stará tzv. notifikační mikroslužba

Smysl tohoto požadavku je, aby administrátor instalace byl aktivně upozorněn nástrojem na možné provozní problémy, například neobvykle vysoká zátěž, docházející diskové místo atp. TeskaLabs LogMan.io pro monitoring vlastního stavu využívá open-source komponenty Grafana, InfluxDB a Telegraf. Jedná se o široce rozšířené technologie, které technický personál obvykle zná.

Grafana je webové uživatelské rozhraní. Grafana je plně integrována do centrální webové konzole. To znamená, že uživatelé jsou autentizováni i autorizováni jednotným způsobem (Single Sign-On). Do Grafany mohou přistupovat pouze pověření uživatelé (např. s rolí administrátora).

SMTP je upozornění pomocí zaslání emailu, jeho konfigurace se provádí v nastavení nástroje Grafana, konkrétně viz snímek.

 

[obchodní tajemství: popis způsobu řešení]

Otázky znalci:

Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 52.A. lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.

Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 52.B. lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 52.A. lze splnit způsobem popsaným v tomto bodě“, (totožný závěr odpovědi znalec uvedl i k otázce č. 52.B), přičemž ve zdůvodnění je dále uvedeno shodně k oběma otázkám, že „systém, založený na systému ELK (opensource) z různými nástavbami umožňuje nastavení SMTP notifikaci.“.

197.     K otázce č. 53 ve znění:

„Požadavek zadavatele: Konfigurace notifikací je pomocí vizuálního programovacího jazyka. Vizuální programovací jazyk není prezentován textově, ale graficky formou obrázků, které obsahují aplikační logiku.

Způsob řešení: Produkt TeskaLabs LogMan.io obsahuje výkonný deklarativní jazyk SP-Lang[206]. Tento jazyk je používán pro tvorbu vlastních parserů, normalizaci logů, vytváření korelací a konfiguraci notifikací. SP-Lang poskytuje i grafické vizuální prostředí pro tvorbu aplikační logiky. SP-Lang je základním kamenem nástroje TeskaLabs LogMan.io, který celý produkt TeskaLabs LogMan.io posunuje do oblasti profesionálních nástrojů s unikátní přidanou hodnotou. Uživatelům umožnuje vytvářet jednoduchou formou vysoce výkonné konfigurace respektive deklarace. SP-Lang vychází z tzv. Human-Computer-Interaction (HCI), což je obor, který se zabývá interakcí lidí a počítačových systémů. Tj. optimalizovaný ergonomický nástroj, který řeší úlohy spojené se zpracováním a vyhodnocováním logů na optimální úrovní a to jak pro lajky tak IT profesionály. LogMan.io nabízí i možnost práce přes příkazový řádek (CLI), což je varianta preferovaná pokročilými uživateli, kteří chtějí mít absolutní kontrolu nad provozem nástroje nebo požadují hlubokou integraci např.
v rámci SOCu (Security Operation Centre). Příkazový řádek ale představuje jen jednu z variant, jak LogMan.io konfigurovat pro konkrétní úlohy.

[obchodní tajemství: popis způsobu řešení]

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 53 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 53 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že „Nebylo znalcem jednoznačně ověřeno nebo vyloučeno“.

198.     K otázkám č. 54.A a č. 54.B ve znění:

„A. Požadavek zadavatele: Nástroj má možnost uložení uživatelem vytvořených pohledů na data (dashboardů) pro budoucí zpracování.

B. Požadavek zadavatele: Nástroj možnost vlastních úprav a vytvoření nových pohledů na data (dashboardů), přičemž není přípustné používat povinně SQL jazyk.

Způsob řešení: TeskaLabs LogMan.io obsahuje několik komponent, ve kterých je možné zobrazovat data formou pohledu neboli dashboardu. Uživatele si mohou vytvářet vlastní pohledy např. v nástroji Kibana Lens. Tato komponenta nevyžaduje používaní žádného dotazovacího jazyka (např. SQL).

Vytváření vlastních pohledů pomocí Kibana Lens viz. následující snímek:

 

Zde si může uživatel vytvařet své pohledy bez použití dotazovacího jazyka. Pohledy lze ukládat do knihovny tlačítkem „Save“.

Více informací je pak možné najít zde[207].

Otázky znalci:

Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 54.A. lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.

Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 54.B. lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 54.A. lze splnit způsobem popsaným v tomto bodě“, resp. totožný závěr odpovědi znalec uvedl i k otázce č. 54.B, přičemž ve zdůvodnění je dále uvedeno shodně
k oběma otázkám, že „systém, založený na systému ELK (opensource) z různými nástavby jako je Kiabana nebo Grafana umožňuje jednoduchou i složitou tvorbu dashboardů a dalších grafických pohledů.“.

199.     K otázce č. 55 ve znění:

„Požadavek zadavatele:Nástroj obsahuje předpřipravené pohledy na uložená data dle jednotlivých kategorií zdrojových zařízení i dle logického členění.

Způsob řešení: Pro dodávku v rámci tohoto výběrového řízení se předpokládá dodání předpřipravených pohledů podle seznamu technologii dle bodů č. 1) až 43). Tyto pohledy jsou již předpřipravené. Dále pak bude dodána sada standardních pohledů, které zprostředkovávají obvykle vyžadované pohledy na logy, jako je aktuální a historický průtok logů nebo počty logů v jednotlivých úrovních závažnosti.

Předdefinované pohledy:

Seznam předpřipravených pohledů v komponentě Kibana:

• SSH failed login attempts source locations [Logs System] ECS Disk
• Usage [Metrics System] ECS
• New groups over time [Logs System] ECS
• SSH users of failed login attempts [Logs System] ECS
• Dashboards [Logs System] ECS
• Processes By Memory [Metrics System] ECS
• Load Gauge [Metrics System] ECS
• Outbound Traffic [Metrics System] ECS
• Swap usage [Metrics System] ECS
• New groups [Logs System] ECS
• Network Traffic (Bytes) [Metrics System] ECS
• Top Hosts By Memory (Realtime) [Metrics System] ECS
• New users [Logs System] ECS
• Service Sub-State [Metrics System]
• New users by shell [Logs System] ECS
• Top Processes By CPU [Metrics System] ECS
• Top sudo commands [Logs System] ECS
• New users by home directory [Logs System] ECS
• Service Memory Use Over Time [Metrics System]
• Memory Usage Gauge [Metrics System] ECS
• Memory usage vs total [Metrics System] ECS
• Successful SSH logins [Logs System] ECS
• Number of hosts [Metrics System] ECS
• Interfaces by Outgoing traffic [Metrics System] ECS
• Memory Usage [Metrics System] ECS
• Service States [Metrics System]
• CPU Usage [Metrics System] ECS
• Running Services [Metrics System]
• System Navigation [Metrics System] ECS
• Syslog hostnames and processes [Logs System] ECS
• Syslog events by hostname [Logs System] ECS
• Container Memory stats [Metrics System] ECS
• Container CPU usage [Metrics System] ECS
• Container Block IO [Metrics System] ECS
• Return Codes Of Exited Services [Metrics System]
• Interfaces by Incoming traffic [Metrics System] ECS
• Packetloss [Metrics System] ECS
• Top Services By Memory Usage [Metrics System]
• Top Hosts By CPU (Realtime) [Metrics System] ECS
• CPU Usage Gauge [Metrics System] ECS
• Disk used [Metrics System] ECS
• Hosts histogram by CPU usage [Metrics System] ECS
• SSH login attempts [Logs System] ECS
• Network Traffic (Packets) [Metrics System] ECS
• New users over time [Logs System] ECS
• Sudo commands by user [Logs System] ECS
• Number of processes [Metrics System] ECS
• Inbound Traffic [Metrics System] ECS
• Sudo errors [Logs System] ECS
• Disk IO (Bytes) [Metrics System] ECS
• System Load [Metrics System] ECS
• Top Services By Task Count [Metrics System]
• Tip [Metrics System] ECS

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 55 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 55 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• „systém, založený na systému ELK (opensource) z různými nástavby jako je Kiabana nebo Grafana umožňuje jednoduchou i složitou tvorbu dashboardů a dalších grafických pohledů. Tyto nadstavby obsahují i předem definované pohledy a dashboardy,
• nadstavby kibana a grafana umožňují rychlý import/export z a do systému, s tím, že obsahují základní pohledy, všechny pohledy lze modifikovat.“

200.     K otázce č. 56 ve znění:

„Požadavek zadavatele:Nástroj umožňuje vytvářet reporty ve formátech PDF, HTML a CSV, popř. dalších.

Způsob řešení: Nastroj TeskaLabs LogMan.io umožňuje vytvářet reporty ve dvou komponentách:

a) Kibana

Možnosti exportu v Kibaně jsou popsány zde[208].

Příklad exportu do CSV v Kibaně:

 

[obchodní tajemství: popis způsobu řešení]

Otázka znalci: Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě 56 lze splnit způsobem popsaným v tomto bodě. Svou odpověď zdůvodněte.“

znalec ve znaleckém posudku uvádí: „Odpověď: Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 56 lze splnit způsobem popsaným v tomto bodě“, přičemž ve zdůvodnění je dále uvedeno, že

• „Systém založený na systému ELK (opensource) z různými nástavby jako je Kiabana nebo Grafana umožňuje export dat,
• nadstavby kibana a grafana umožňují rychlý import/export z a do systému, s tím, že obsahují základní pohledy, všechny pohledy lze modifikovat.“

201.     Dne 21. 9. 2022 Úřad obdržel vysvětlení znaleckého posudku k odpovědi na dotaz č. 51 znaleckého posudku, přičemž znalec Úřadu sdělil, že

• »nástroj je bezpečně zpracován autorem programu LogMan.io společností TeskaLabs a je na velmi vysoké kyberbezpečnostní úrovni.
• Dokladem je i právě probíhající certifikace společnosti na ISO 27001.
• Větu „nebylo možné ověřit (vždycky lze data vymazat, jen záleží jak moc je to obtížné)“ – vysvětluji - doplňuji: znalec neprověřoval tuto bezpečnost (konkrétně možnost smazání dat) heckerskými technikami ani penetračním testováním.
• Vzhledem k několikafaktorové ochraně, kterou má společnost TeskaLabs vyvinutou i nasazenou, je ovšem i tato možnost pouze v rovině teorie a tedy de facto nepravděpodobná.

Na odpovědi: „Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 51 lze splnit způsobem popsaným v tomto bodě.“ trvám.«

202.     Dne 7. 10. 2022 Úřad obdržel vysvětlení znaleckého posudku č. 2 k odpovědi na dotaz č. 53 znaleckého posudku a k otázce „nezávislého auditora“, přičemž znalec Úřadu sdělil, že

K dotazu č. 53:

»Odpovídám - doplňuji:

Produkt TeskaLabs LogMan.io obsahuje deklarativní jazyk SP-Lang, kterým se konfigurují deklarace ale i parsery, enrichery, korelátory a další komponenty produktu. Tento jazyk má i svou vizuální reprezentaci, která využívá rozšířenou technologii Blockly ( https://en.wikipedia.org/wiki/Blockly ). Toto umožňuje uživatelům vytvářet a modifikovat notifikace v grafickém prostředí, kde jednotlivé výrazy jsou prezentovány formou výrazů.

Ukázka funkčnosti byla provedena. Proto odpovídám: „Nemohu jednoznačně vyloučit, že požadavek uvedený v bodě 53 lze splnit způsobem popsaným v tomto bodě.“

Deklarativní jazyk SP-Lang nebyl znalcem ověřován, jedná se o deklarativní funkcionální jazyk vyvinutý společností TeskaLabs, který je použit v produktu TeskaLabs LogMan.io a jeho analýza by převyšovala mnohonásobně čas i rozpočet. Proto zdůvodnění: „Nebylo znalcem jednoznačně ověřeno nebo vyloučeno“«

K roli „nezávislého auditora“:

„Role „nezávislého auditora“ byla znalcem využita pro potvrzení nebo vyvrácení znalcových zjištění.

Nezávislý auditor NEBYL přibrán jako konzultant ve smyslu níže citovaných ustanovení zákona o znalcích. Nezpracovával samostatně zvláštní dílčí otázky.“

Právní posouzení

203.     Úřad konstatuje, že předmět tohoto správního řízení spočívá mj. v posouzení, zda nástroj nabízený vybraným dodavatelem splňuje technické požadavky zadavatele stanovené v příloze č. 1 smlouvy.

204.     Úřad na tomto místě uvádí, že předmět veřejné zakázky spočívá v dodávce software pro centrální sběr a management logů pro zadavatele včetně hardware, software a potřebných licencí k jeho provozování, jeho implementace a poskytování podpory a údržby (viz bod 2. odůvodnění tohoto rozhodnutí). Současně ze vzoru smlouvy a její přílohy č. 3 vyplývá, že dodání předmětu plnění bude probíhat podle harmonogramu, který stanoví a v nabídce předloží účastník zadávacího řízení (viz body 138. a 142. odůvodnění tohoto rozhodnutí).

205.     Z nabídky vybraného dodavatele vyplývá, že nástroj nabídnutý vybraným dodavatelem pro plnění veřejné zakázky vychází z nástroje Logman.io vyráběného společností TeskaLabs. Současně z nabídky vyplývá, že vybraný dodavatel v nabídce (konkrétně v příloze č. 1 smlouvy sekci „Popis řešení Nástroje včetně schématického znázornění architektury“) zevrubně popsal architekturu svého řešení včetně základních parametrů tohoto řešení.

K znaleckému posudku

206.     Jelikož Úřad seznal, že pro posouzení toho, zda nástroj nabídnutý vybraným dodavatelem navrhovatelem uváděné technické požadavky zadavatele splňuje či nikoli, je zapotřebí odborných znalostí, kterými oprávněné úřední osoby nedisponují, ustanovil Úřad za účelem zodpovězení odborných otázek znalce. Úřad dodává, že i navrhovatel ve svém návrhu žádal o „znalecký posudek, který by funkcionalitu daných požadavků Zadavatele v nástroji LogMan.io ověřil“.

207.     Úřad obecně uvádí, že správní orgán provede důkaz znaleckým posudkem tam, kde je k posouzení skutečností významných pro zjištění skutkového stavu věci zapotřebí odborných znalostí. Správní orgán musí dbát o to, aby znalcem byl ustanoven odborník z toho oboru, popřípadě z jeho odvětví, do něhož spadá odborné posouzení konkrétních skutečností; zadání musí formulovat tak, aby znalci nebylo ukládáno vyjadřovat se k otázkám, u nichž nejde o odborné posouzení skutečností, nýbrž o právní posouzení určitého skutkového stavu nebo o výklad právního předpisu.

208.     V šetřeném případě Úřad dotazy znalci koncipoval tak, že u každé položené otázky nejprve ocitoval požadavek zadavatele na poptávaný nástroj, dále uvedl popis řešení tohoto požadavku prezentovaný vybraným dodavatelem a závěrem Úřad položil otázku znalci ve znění „Sdělte, zda můžete jednoznačně vyloučit, že požadavek uvedený v bodě X[209] lze splnit realizací navrženého způsobu řešení popsaného v tomto bodě. Svou odpověď zdůvodněte.“. Důvodem této formulace dotazu je skutečnost, že ze zadávacích podmínek nijak nelze dovodit, že by ke dni podání nabídek do zadávacího řízení muselo být řešení nabídnuté vybraným dodavatelem (stejně jako řešení ostatních dodavatelů) již plně funkční, resp. že by muselo již v té době disponovat všemi zadavatelem požadovanými vlastnostmi a funkcionalitami, a nebylo tedy ani teoreticky možné zkoumat nějaký reálný finální produkt, který má být zadavateli dodán. Úkolem znalce bylo tedy ve vztahu ke každému definovanému požadavku posoudit způsob řešení uvedený vybraným dodavatelem a sdělit, zda může jednoznačně vyloučit, že tímto způsobem lze daný požadavek splnit. Pokud přitom znalec možnost realizace řešení navrženého vybraným dodavatelem u konkrétního požadavku jednoznačně vyloučit nemůže, je dle Úřadu nutné s ohledem na specifika šetřeného případu tento požadavek zadavatele považovat za splněný.

209.     Úřad tedy zdůrazňuje, že podstatou šetřeného případu, tj. otázkou, kterou je třeba ve správním řízení posoudit, není to, zda nástroj nabídnutý vybraným dodavatelem v době podání jeho nabídky byl plně funkční a splňoval všechny požadavky zadavatele, ale to, zda tento nástroj v době předání zadavateli může odpovídat požadavkům zadavatele. S ohledem na výše uvedené Úřad postupoval i při formulaci dotazů znalci, neboť pokud v době podání nabídek ještě předmětný systém ve své finální podobě neexistoval (a ani existovat nemusel), pak cílem položení otázek nemohlo být zjištění toho, zda v době podání nabídky nástroj nabízený vybraným dodavatelem předmětné požadavky zadavatel splňoval, ale to, zda existuje nějaký důvod, proč by v době dodání zadavateli tyto požadavky splňovat nemohl.

210.     Navrhovatelova argumentace je postavena zejména na tom, že dle jeho názoru k okamžiku uplynutí lhůty pro podání nabídek nástroj LogMan.io technické požadavky zadavatele stanovené v příloze č. 1 smlouvy nesplňoval a ani splňovat nemohl. Navrhovatel je přesvědčen, že následným „dovysvětlováním“ nástroje Logman.io dochází ze strany vybraného dodavatele k neustálým a kontinuálním změnám nabídky, které jsou ze své podstaty v rozporu s ustanovením § 46 odst. 2 zákona.

211.     Současně navrhovatel ve vyjádření k podkladům uvádí, že veřejná zakázka je koncipována jako veřejná zakázka na dodávky ve smyslu § 14 odst. 1 zákona, nikoliv jako veřejná zakázka na služby ve smyslu § 14 odst. 2 zákona. Z uvedeného navrhovatel dovozuje, že pokud má být předmětem veřejné zakázky dodávka software, musí vybraný dodavatel splňovat všechny podmínky účasti v zadávacím řízení včetně technických podmínek vymezujících její předmět již k okamžiku uplynutí lhůty pro podání nabídek. Dodavatel dle navrhovatele nemůže nabídnout zadavateli dodávku něčeho, čím v době uplynutí lhůty pro podání nabídek nedisponuje, resp. něčeho, co ke dni uplynutí lhůty pro podání nabídek nesplňuje požadavky zadavatele na předmět plnění. Součástí předmětu plnění totiž není úprava programového vybavení, ale jeho prostá dodávka bez podstatných úprav. S ohledem na to je navrhovatel toho názoru, že Úřad otázky položené znalci formuloval nevhodně, když dle navrhovatele měly být položeny takovým způsobem, aby znalec jednoznačně zodpověděl, zda nabídka vybraného dodavatele ke dni uplynutí lhůty pro podání nabídek splňovala technické podmínky vymezující předmět veřejné zakázky.

212.     K uvedenému Úřad v prvé řadě uvádí, že ze zadávací dokumentace nevyplývá, že by dodavatelé byli povinni již v době podání nabídky předložit zadavateli nástroj, který by splňoval všechny technické požadavky zadavatele, ani že by takovým funkčním nástrojem museli v době podání nabídky reálně disponovat. Úřad podotýká, že dle zadávací dokumentace se předání jednotlivých částí předmětu plnění odvíjí od harmonogramu, který stanoví sami účastníci zadávacího řízení v rámci svých nabídek (viz body 138. a 142. odůvodnění tohoto rozhodnutí). Z uvedeného tedy vyplývá, že v době podání nabídky nemusí mít dodavatel ve své dispozici samotný dodávaný nástroj, ale pouze musí garantovat, že nástroj, který zadavateli nabízí, bude splňovat technické požadavky zadavatele. Dodavatelé museli v rámci nabídky (v části „Popis řešení Nástroje včetně schématického znázornění architektury“ obsažené v rámci přílohy č. 1 smlouvy) pouze uvést určité informace o dodávaném nástroji, jak již bylo uvedeno výše, což vybraný dodavatel učinil.

213.     Úřad dále uvádí, že u dodávek informačních systémů lze z pohledu dodavatele rozlišit 2 typy systémů. Jednak jde o systémy již existující (kompletně naprogramované), ke kterým dodavatel zadavateli poskytne za úplatu pouze software, resp. zdrojové kódy k těmto systémům, přičemž není zapotřebí do těchto systémů jakkoliv zasahovat. Druhým typem jsou systémy, které jsou vytvářeny dle individuálních potřeb zákazníka, respektive jsou customizovány (upraveny) z již existujících systémů dle individuálních potřeb zákazníka, popř. jsou vytvořeny zcela nově (tzv. „na zelené louce“). Úřad má za to, že mj.  ohledem na množství technických požadavků zadavatele (mj. individualizovaný výběr platforem a technologií, ze kterých má nástroj umět sbírat, parsovat a normalizovat logy stanovený v příloze č. 1 smlouvy) se v šetřeném případě jedná právě o případ, kde nejde o běžný jednoduchý systém, který by byl univerzálně použitelný u více různých zákazníků, ale jedná se o individualizovaný systém. Při přípravě takového systému je přitom dle Úřadu logické, že k jeho vytvoření je použit nějaký dílčí předem vytvořený základ, který je následně upravován dle konkrétních potřeb zadavatele. S ohledem na to je i pochopitelné, že zadávací dokumentace neobsahuje požadavek zadavatele na předložení vzorku nástroje či demonstraci jeho funkčnosti, a zadavatel tudíž musí spoléhat na informace, které dodavatelé uvedou ve svých nabídkách (konkrétně v příloze č. 1 smlouvy sekci „Popis řešení Nástroje včetně schématického znázornění architektury“), resp. na to, že dodavatelé jsou schopni jimi prezentovaný systém reálně dodat. Je pak na zadavateli, aby si adekvátně smluvně ošetřil, že mu vybraný dodavatel skutečně poskytne plnění, ke kterému se ve své nabídce zavázal. Současně je dle Úřadu nutné uvést, že s ohledem na § 7 zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů, je třeba vycházet z předpokladu, že dodavatelé jednají poctivě a v nabídkách předkládají informace o plnění, které mají skutečně v úmyslu dodat (presumpce poctivosti a dobré víry). Úřad dále uvádí, že zmíněné závěry se nevztahují pouze na informační systémy, ale de facto na jakoukoliv dodávku, kterou dodavatel musí upravovat dle individuálních požadavků zadavatele (např. dodání upravených aut pro policejní či vojenské účely nebo dodání nábytku upraveného na míru apod.).

214.     Úřad tedy uzavírá, že se nelze ztotožnit s námitkou navrhovatele, že vybraný dodavatel nemůže nabídnout nástroj, který v době podání nabídky ještě v kompletní podobě (tj. se zahrnutím všech technických požadavků zadavatele) nemá, neboť, jak bylo uvedeno výše, podstatné je, zda daný nástroj dokáže v určeném termínu a v požadovaných parametrech zadavateli dodat. Úřad pro úplnost dodává, že ani v případě jiných typů dodávek nemusí dodavatel disponovat s dodávaným zbožím v době podání nabídky (jinými slovy mít tento produkt na skladě), ale může si je zajistit až k okamžiku termínu předání dodávky zadavateli (a pro případ, že svému závazku dodavatel nedostojí, musí být srozuměn s tím, že může čelit případným smluvním sankcím ze strany zadavatele).

215.     S ohledem na skutečnost, že předmět plnění nemusel být ke dni podání nabídky kompletně hotový a vybavený všemi zadavatelem požadovanými funkcionalitami, Úřad konstatuje, že dotazy znalci formuloval správně, resp. formuloval je jediným možným způsobem, který s ohledem na konkrétní skutkové okolnosti daného případu připadal v úvahu, aby byl zjištěn stav věci, o němž nejsou důvodné pochybnosti ve smyslu § 3 správního řádu.

216.     Navrhovatel dále ve svém vyjádření k podkladům namítá podjatost znalce a z toho důvodu požaduje vypracování revizního posudku.

217.     Úřad k tomu uvádí, že se podjatostí znalce zabýval v usnesení č. j. ÚOHS-44232/2022/500 ze dne 9. 12. 2022, přičemž rozhodl o tom, že znalec není z podání znaleckého posudku vyloučen.

218.     Následně se bude Úřad zabývat konkrétními požadavky zadavatele na poptávaný systém, ve vztahu k nimž navrhovatel namítá, že je nástroj nabídnutý vybraným dodavatelem nesplňuje.

K požadavkům č. 101 až 144

219.     Navrhovatel v prvé řadě napadá to, že nástroj nabízený vybraným dodavatelem v rozporu s body 101 až 144 přílohy č. 1 smlouvy nepodporuje sběr, parsování a normalizaci logů požadovaných platforem a technologií. Navrhovatel zejména poukazuje na to, že z veřejně dostupné dokumentace nástroje Logman.io neplyne, že by tento nástroj tyto funkcionality podporoval, resp. dle navrhovatele některé požadované platformy nejsou na webu či v dokumentaci nástroje vůbec uvedeny. Současně navrhovatel uvádí, že mnoho z údajně produktem LogMan.io podporovaných technologií potřebuje složitou konfiguraci nejen v rámci LogMan.io, ale i jeho komponent. Navrhovatel má za to, že pokud výrobce neuvede dokumentaci, ze které jednoznačně vyplývá, jak jsou dané funkce implementovány, nejedná se o důkaz, ale o pouhé ničím nepodložené tvrzení.

220.     Úřad v prvé řadě uvádí, že zadavatel v bodech 102 až 144 přílohy č. 1 smlouvy vypsal technologie a platformy, u nichž by poptávaný nástroj měl podporovat sběr, parsování a normalizaci logů podle požadavku uvedeného v bodě v příloze č. 1 smlouvy. Každý samostatný bod přílohy č. 1 smlouvy tedy obsahoval název jedné z těchto platforem či technologií (viz bod 141. odůvodnění tohoto rozhodnutí).

221.     K tomu Úřad dále uvádí, že odpovědi na otázky týkající se splnění požadavků č. 101 až 144 přílohy č. 1 smlouvy v nástroji vybraného dodavatele jsou součástí znaleckého posudku, a to v jeho bodech 1. – 43. (viz body  165. až 188. odůvodnění tohoto rozhodnutí).

222.     Ze znaleckého posudku ke všem otázkám týkajícím se požadavků 101 až 144 přílohy č. 1 souhrnně vyplývá, že znalec nemůže jednoznačně vyloučit, že předmětné požadavky uvedené lze splnit způsobem popsaným vybraným dodavatelem. Ve zdůvodnění odpovědí je pak uvedeno, že nástroj Logman.io má cca 80 % předdefinovaných platforem a technologií, přičemž zbývající jsou doprogramovány dle potřeb konkrétního zákazníka. Současně znalec uvádí, že tento postup je běžnou praxí v tomto oboru. Doprogramováni zbylých platforem a technologií přímo u zákazníka se dle znalce provádí z důvodů rozdílných požadavků zákazníků i požadavků výrobců zadavatelem požadovaných zařízení (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.).

223.     K některým z požadavků pak znalec doplňuje konkrétnější zdůvodnění jeho závěru. K požadavkům č. 102 a 103 (viz bod 165. odůvodnění tohoto rozhodnutí) uvádí, že všechny systémy, které jsou založené na platformě Linux s možností tvorby logů do syslogu, umožňují práci s těmito logy. K platformám či technologiím od společnosti Microsoft (tj. požadavky
č. 127 až 135 a 143, 144 – viz body  182. a 188. odůvodnění tohoto rozhodnutí) pak znalec uvedl, že systém umožňuje pracovat s MS logy, přičemž dále dodává, že „U WIN systémů – ano, umí případně logování do souboru a jeho následné vyčítání, v některých případech je potřeba nastavit windows port forwarding, lze nastavit za pomocí GPO (group policy)“. K požadavkům č. 104, 105, 106, 107, 108, 110, 111, 112, 113, 114, 115, 116, 117, 118, 138 a 139 pak znalec uvedl v každé z odpovědí odkaz na část relevantní dokumentace předmětné platformy či technologie, ze které má být umožněn sběr, parsování a normalizace logů.

224.     Úřad tak shrnuje, že ze závěrů znalce nevyplývá, že implementace šetřených požadavků by měla být v případě nástroje vybraného dodavatele složitou procedurou, přičemž drtivá většina (cca. 80 %) platforem a technologií je do nástroje již implementována, a tedy znalec důvod, proč by nástroj neměl být schopen podporovat sběr, parsování a normalizaci logů požadovaných platforem a technologií, neshledal.

225.     Úřad tedy má za to, že skutečnost, že veřejně dostupná dokumentace nástroje Logman.io neobsahuje přesný postup nastavení sběru, parsování a normalizace logů požadovaných platforem a technologií, neznamená, že nástroj nabídnutý v nabídce vybraného dodavatele uvedené neumožňuje, resp. není možné tyto technologie a platformy doimplementovat a splnit tak zadávací podmínky.

226.     K argumentaci navrhovatele, ve které konkrétně namítá, že „Skutečnost, že nástroj neumožňuje data ani sbírat je pak navíc v přímém rozporu s body 401 až 421 Přílohy č. 1 smlouvy“, Úřad uvádí, že navrhovatel tuto námitku umisťuje do části návrhu, ve které je obsažena jeho argumentace týkající se nesplnění požadavků č. 101 až 144 přílohy č. 1 smlouvy, tj. požadavků, kde zadavatel požaduje mj. sběr logů z jím vyjmenovaných platforem a technologií. Podstatou citované navrhovatelovy námitky je tedy to, že dle navrhovatele nástroj vybraného dodavatele nepodporuje část platforem a technologií požadovaných zadavatelem, a proto nemůže ani podporovat sběr dat (resp. logů) z těchto platforem a technologií, což dle navrhovatele je v rozporu i s body č. 401 až 421 přílohy č. 1 smlouvy (tj.
s požadavky v kategorii č. 400 přílohy č. 1 smlouvy, která se týká právě sběru dat). Znalec v rámci odpovědí na položené dotazy č. 1 až 43 Úřadu potvrdil, že u všech zadavatelem požadovaných technologií a platforem není vyloučeno, že řešení vybraného dodavatele, resp. nástroj Logman.io sběr dat dokáže (ať už je implementován či bude implementován s ohledem na výše uvedené). Pokud tedy navrhovatel svůj názor týkající se nesplnění požadavků č. 401 až 421 přílohy č. 1 smlouvy vyvozuje pouze z toho, že nástroj vybraného dodavatele neumožňuje sběr dat, přičemž znaleckým posudkem bylo prokázáno, že nelze vyloučit, že daný nástroj sběr dat umožňuje, je zřejmé, že námitka navrhovatele je lichá.

227.     Navrhovatel též namítá, že ze znaleckého posudku neplyne, že by znalec ověřil, zda je tvrzení vybraného dodavatele nebo výrobce LogMan.io o minimálně 80 % podporovaných zdrojů skutečně pravdivé, ani jak dospěl k závěru, že absentující funkcionality lze skutečně doprogramovat, z čehož navrhovatel dovozuje, že znalec při formulaci odpovědi pouze nekriticky převzal tvrzení vybraného dodavatele, resp. výrobce nástroje LogMan.io. Úřad k tomu uvádí, že z toho, že se zdůvodnění uvedené znalcem shoduje s údaji uvedenými vybraným dodavatelem, nelze bez dalšího dovozovat, že znalec danou otázku reálně nešetřil, a k učinění takového závěru nejsou dle Úřadu ani dány žádné indicie. To, že zdůvodnění znalce se shoduje s vyjádřením vybraného dodavatele, tak dle Úřadu znamená to, že znalec po posouzení věci dospěl ke shodným zjištěním, jaká prezentuje vybraný dodavatel.  Z postupu znalce je nepochybné, že se touto problematikou zabýval a posuzoval ji (např. otázky, které byly probírány v rámci testování demoverze auditorem, se vyloženě týkaly zpracování dílčích formátů logů, viz bod 160. odůvodnění tohoto rozhodnutí). Současně z písm. a) bodu 1.1.2 znaleckého posudku plyne, že znalec provedl šetření k ověření Úřadem předložených podkladů, ve kterých mj. byly zevrubné popisy způsobu řešení vybraným dodavatelem (viz body 165. až 200. odůvodnění tohoto rozhodnutí).

228.     Úřad tak k požadavkům č. 101 až 144 s odkazem na závěry uvedené ve znaleckém posudku konstatuje, že tvrzení navrhovatele o tom, že nástroj nabídnutý vybraným dodavatelem tyto požadavky nesplňuje, se neprokázalo.

K požadavku č. 145

229.     Navrhovatel má taktéž za to, že nástroj vybraného dodavatele neumožňuje přístup více uživatelů současně, a tedy nesplňuje požadavek č. 145 přílohy č. 1 smlouvy. Vybraný dodavatel způsob splnění předmětného požadavku popsal ve svém vyjádření ze dne 11. 10. 2021, přičemž Úřad popsaný způsob jeho splnění vtělil do dotazu č. 44 položeného znalci (viz bod 189. odůvodnění tohoto rozhodnutí). 

230.     Znalec k uvedenému požadavku v bodě č. 44 znaleckého posudku konstatoval, že nemůže jednoznačně vyloučit, že požadavek lze splnit způsobem popsaným vybraným dodavatelem (viz bod 189. odůvodnění tohoto rozhodnutí). Současně znalec v rámci zdůvodnění své odpovědi uvedl, že nástroj umí separovat role a definovat pro konkrétní skupiny/uživatele dané oprávnění.

231.     Úřad tak k požadavku č. 145 s odkazem na závěry uvedené ve znaleckém posudku konstatuje, že tvrzení navrhovatele o tom, že nástroj nabídnutý vybraným dodavatelem tento požadavek nesplňuje, se neprokázalo.

K požadavkům č. 146 a č. 166

232.     Navrhovatel dále napadá to, že nástroj vybraného dodavatele neumožňuje snadné vytváření a definování uživatelských rolí, a tedy je v rozporu s body č. 146 a 166 přílohy č. 1 smlouvy. Vybraný dodavatel způsob splnění předmětných požadavků popsal ve svém vyjádření ze dne 11. 10. 2021, přičemž Úřad popsaný způsob jeho splnění vtělil do dotazů č. 45.A a 45.B položených znalci (viz bod 190. odůvodnění tohoto rozhodnutí). 

233.     Znalec k otázkám vztahujícím se k uvedeným požadavkům v obou případech uvedl, že nemůže jednoznačně vyloučit, že zmíněné požadavky lze splnit způsobem popsaným vybraným dodavatelem. V rámci zdůvodnění pak znalec dále uvedl, že z přiložené dokumentace lze soudit, že lze požadavek splnit, neboť nástroj umožňuje škálovatelnost uživatelských přístupů, umí separovat role a definovat konkrétní skupiny/uživatele daného oprávnění.

234.     Úřad tak k požadavkům č. 146 a 166 s odkazem na závěry uvedené ve znaleckém posudku konstatuje, že tvrzení navrhovatele o tom, že nástroj nabídnutý vybraným dodavatelem tyto požadavky nesplňuje, se neprokázalo.

K požadavkům č. 153, 304, 305 a 306

235.     Navrhovatel má za to, že nástroj Logman.io v rozporu s bodem 153 přílohy č. 1 smlouvy nemá nijak řešenu zálohu a obnovu konfigurací celého nástroje z centrální konzole a „v rozporu s bodem 304 přílohy č. 1 smlouvy neumožňuje aktualizaci systému v jednom kroku a v jednotném balíku prostřednictvím centrální konzole a neumožňuje ani rolling upgrade, a v rozporu s bodem 305 přílohy č. 1 smlouvy neumožňuje ani downgrade, přičemž veškerá konfigurace není verzována ve version control systému (Git) tak, aby byla zajištěná vysoká úroveň kontroly nad provozním nastavením systému včetně možnosti návratu k předchozí verzi konfigurace“. Vybraný dodavatel způsob splnění požadavků č. 153, 304 a 305 popsal ve svém vyjádření ze dne 11. 10. 2021, přičemž Úřad popsaný způsob jeho splnění vtělil do dotazů č. 46, 49 a 50 položených znalci (viz body 191. a 194. odůvodnění tohoto rozhodnutí). 

236.     Znalec k otázkám vztahujícím se k požadavkům č. 153, 304 a 305 uvedl, že nemůže jednoznačně vyloučit, že tyto požadavky lze splnit způsobem popsaným vybraným dodavatelem. V odůvodnění pak znalec uvedl, že požadavky lze splnit, protože nástroj vybraného dodavatele má centrální konzoli a každá verze management konzole nebo jiné části je verzována a je vytvořena kompatibilní matice, která říká, jaké verze je spolu možné kombinovat, přičemž tyto verze jsou i zpětně kompatibilní (díky kontejnerizování, lze modulárně skládat).

237.     Co se týče námitky navrhovatele týkající verzování konfigurace ve version control systému (Git), k tomu Úřad uvádí, že přestože navrhovatel tuto námitku bez bližšího upřesnění uvádí v návrhu spolu s námitkami týkajícími se požadavků č. 304 a 305 přílohy č. 1 smlouvy, tak se dle Úřadu jedná se o samostatný požadavek č. 306 přílohy č. 1 smlouvy.  K tomuto požadavku Úřad v prvé řadě uvádí, že podstatou tohoto požadavku je to, aby systém umožnoval verzování konfigurace ve version control systému (v tzv. GITu), resp. aby bylo možné přecházet mezi jednotlivými verzemi konfigurace nástroje. Dále Úřad konstatuje, že navrhovatel v rámci argumentace k požadavku č. 304 a 305 (při popisu procesu aktualizace nástroje) sám uvádí, že část dokumentace nástroje LogMan.io „obsahuje informace prokazující, že LogMan.io používá pro správu verzí nástroj Git“ (viz bod 24. odůvodnění tohoto rozhodnutí). Současně navrhovatel v této části návrhu odkazuje na konkrétní část dokumentace nástroje, ve které jsou dle Úřadu zjevné odkazy na práci s Git nástrojem (viz bod 147. odůvodnění tohoto rozhodnutí), což, jak bylo uvedeno výše, potvrzuje i sám navrhovatel v rámci jeho popisu procesu aktualizace nástroje. Současně Úřad doplňuje, že dokumentace nástroje popisující práci s verzováním uvádí i konkrétně využitý Git nástroj, a to gitlab.com (viz bod 147. odůvodnění tohoto rozhodnutí).

238.     Jak již Úřad uvedl výše, navrhovatel námitku týkající se požadavku č. 306 včleňuje k námitkám týkajícím se požadavků č. 304 a 305 přílohy č. 1 smlouvy, přičemž tuto námitku nijak blíže nekonkretizuje. Současně navrhovatel v návrhu sám uvádí, že dokumentace nástroje počítá s využitím Git nástroje. Úřad tak s ohledem na tvrzení samotného navrhovatele má za to, že verzování konfigurace ve version control systému (Git) nástroj Logman.io obsahuje (resp. dokumentace k nástroji s napojením na Git pracuje). Úřad k uvedenému uzavírá, že s ohledem na výše uvedená tvrzení navrhovatele ve spojení s dokumentací předmětného nástroje neověřoval zmíněný požadavek č. 306 v rámci znaleckého posudku, neboť bližší zkoumání tohoto požadavku nepovažuje za důvodné, neboť z návrhu plyne, že sám navrhovatel si je vědom toho, nástroj nabídnutý vybraným dodavatelem používá pro správu verzí nástroj Git.

239.     Úřad tak k požadavkům č. 153, 304 a 305s odkazem na závěry uvedené ve znaleckém posudku konstatuje, že tvrzení navrhovatele o tom, že nástroj nabídnutý vybraným dodavatelem tyto požadavky nesplňuje, se neprokázalo. Současně Úřad k požadavku č. 306 uvádí dílčí závěr, že s odkazem na tvrzení navrhovatele, má za to, že nástroj nabídnutý vybraným dodavatelem tento požadavek splňuje.

K požadavku č. 154

240.     Dále navrhovatel namítá, že nástroj vybraného dodavatele rovněž neumožňuje nastavení nezávislé zálohovací politiky, a tedy nesplňuje požadavek č. 154 přílohy č. 1 smlouvy. Vybraný dodavatel způsob splnění požadavku č. 154 popsal ve svém vyjádření ze dne 11. 10. 2021, přičemž Úřad popsaný způsob jeho splnění vtělil do dotazu č. 47 položeného znalci (viz bod 192. odůvodnění tohoto rozhodnutí). 

241.     Znalec v odpovědi na otázku týkající se tohoto požadavku uvedl, že nemůže jednoznačně vyloučit, že tento požadavek lze splnit způsobem popsaným vybraným dodavatelem, přičemž svůj závěr zdůvodnil tím, že systém založený na systému ELK[210] (opensource) s různými nástavbami jako je logtrash apod. umožňuje zálohování i nezávislé politiky (viz bod 192. odůvodnění tohoto rozhodnutí).

242.     K argumentaci navrhovatele, že problematika nezávislé zálohovací politiky má být popsaná v dokumentaci výrobce řešení a řešení ji má nativně umožnovat bez nutnosti používat různé nespecifikované nadstavby, Úřad v prvé řadě uvádí, že je na samotném výrobci (přičemž vybraný dodavatel není výrobce nástroje Logman.io, ale pouze ho používá jako základ pro svoje řešení nástroje pro zadavatele), jaké informace uvede či neuvede do veřejně přístupné dokumentace svého nástroje, a to zvláště s ohledem na důležitost svého „know-how“ ve vysoce konkurenčním prostředí, jakým IT sektor dle Úřadu bezesporu je. K druhé části námitky navrhovatele pak Úřad uvádí, že je na každém dodavateli, jak postaví svůj nabízený nástroj, neboť v tomto ohledu zadavatel v zadávacích podmínkách dodavatele nijak nelimitoval. Současně dle Úřadu je tak námitka navrhovatele, že vše musí být „nativní“, a tedy jinými slovy nesmí být použita nadstavba nějakého použitého systému, resp. nějaká další externí technologie, zcela neopodstatněná, a to i s ohledem na to, že znalec potvrdil, že systém ELK, ze kterého v této části řešení vychází vybraný dodavatel, je tzv. opensource. Úřad k tomu dodává, že kód ELK je veřejně dostupný, a to i s vlastní obsáhlou dokumentací technologie (ostatně na ni v rámci správního řízení odkazují jednotlivý účastníci), a tedy je zjevná použitelnost a provázanost této technologie a případných „nadstaveb“, resp. jinými slovy odborníku v daném oboru musí být zřejmé to, jaká nadstavba je využita a k jakému účelu.

243.     Úřad tak k požadavku č. 154 s odkazem na závěry uvedené ve znaleckém posudku konstatuje, že tvrzení navrhovatele o tom, že nástroj nabídnutý vybraným dodavatelem tento požadavek nesplňuje, se neprokázalo.

K požadavku č. 201

244.     Navrhovatel dále namítá to, že nástroj vybraného dodavatele v rozporu s požadavkem dle bodu č. 201 přílohy č. 1 smlouvy neumožňuje hardwarovou appliance, ale toliko appliance virtuální. Vybraný dodavatel způsob splnění požadavku č. 201 popsal ve svém vyjádření ze dne 19. 8. 2021, přičemž Úřad popsaný způsob jeho splnění vtělil do dotazu č. 48 položeného znalci (viz bod 193. odůvodnění tohoto rozhodnutí).  

245.     Znalec v odpovědi na otázku týkající se této zadávací podmínky uvedl, že nemůže jednoznačně vyloučit, že uvedený požadavek lze splnit způsobem popsaným vybraným dodavatelem, přičemž z odůvodnění plyne, že podkladem pro jeho závěr byly webové stránky výrobce[211] (viz bod 193. odůvodnění tohoto rozhodnutí).  

246.     K námitce navrhovatele, podle níž vybraný dodavatel hardware požadovaný zadavatelem nemůže dodat, neboť tomu neodpovídá jeho nabídková cena, která je dle navrhovatele mimořádně nízká, a nemůže tedy daný hardware zahrnovat, Úřad uvádí, že z toho, že vybraný dodavatel nabídnul nižší cenu (která se navrhovateli jeví jako MNNC), nelze bez dalšího usuzovat, že řešení nástroje vybraného dodavatele požadovaný hardware nezahrnuje. Pakliže navrhovatel de facto jako jediný důvod, z něhož dovozuje nesplnění tohoto požadavku zadavatele, uvádí výši nabídkové ceny nabídky vybraného dodavatele, tak v tomto ohledu Úřad uvádí, že otázka MNNC je řešena dále v odůvodnění tohoto rozhodnutí (viz body 274. a násl. odůvodnění tohoto rozhodnutí).

247.     Úřad tak k požadavku č. 201 s odkazem na závěry uvedené ve znaleckém posudku konstatuje, že tvrzení navrhovatele o tom, že nástroj nabídnutý vybraným dodavatelem tento požadavek nesplňuje, se neprokázalo.

K požadavku č. 506

248.     Navrhovatel taktéž namítá, že nástroj nabízený vybraným dodavatelem v rozporu s bodem 506 přílohy č. 1 smlouvy nezabezpečuje data proti jejich modifikaci nebo smazání a zároveň umožňuje mazání nebo modifikování již uložených logů. Vybraný dodavatel způsob splnění požadavku č. 506 popsal ve svém vyjádření ze dne 11. 10. 2021, přičemž Úřad popsaný způsob jeho splnění vtělil do dotazu č. 51 položeného znalci (viz bod 195. odůvodnění tohoto rozhodnutí). 

249.     Znalec v odpovědi na otázku týkající se této zadávací podmínky uvedl, že nemůže jednoznačně vyloučit, že uvedený požadavek lze splnit způsobem popsaným vybraným dodavatelem, přičemž ve zdůvodnění uvedl: „nebylo možné ověřit (vždycky lze data vymazat, jen záleží, jak moc je to obtížné)“. S ohledem na to, že zdůvodnění se Úřadu jevilo jako rozporné se samotnou odpovědí, požádal Úřad znalce o vysvětlení jeho odpovědi (viz bod 76. odůvodnění tohoto rozhodnutí). Znalec ke své odpovědi doplnil, že nástroj je na velmi vysoké kyberbezpečnostní úrovni, dokladem čehož je dle znalce i právě probíhající certifikace společnosti na ISO 27001.  Své tvrzení „nebylo možné ověřit (vždycky lze data vymazat, jen záleží jak moc je to obtížné)“ znalec vysvětluje tak, že neprověřoval bezpečnost nástroje (možnost mazání dat) hackerskými technikami a ani penetračním testováním. Následně znalec uvedl, že trvá na svém závěru, že nemůže jednoznačně vyloučit, že předmětný požadavek lze splnit způsobem popsaným vybraným dodavatelem (viz bod 201. odůvodnění tohoto rozhodnutí).

250.     Z uvedeného dle Úřadu vyplývá, že znalci nejsou známy důvody, kvůli nimž by řešení vybraného dodavatele nemohlo splňovat požadavky zadavatele, přičemž dle znalce je nástroj Logman.io na velmi vysoké kyberbezpečnostní úrovni. Znalec přitom uvedl, že neprověřoval možnost smazání dat či modifikování uložených logů nezkoumal pomocí hackerských a penetračních technik. Z návrhu však dle Úřadu vyplývá, že navrhovatel nesplnění tohoto požadavku nástrojem vybraného dodavatele nevztahoval k případům, kdy budou použity hackerské či penetrační techniky, ale k běžnému uživatelskému používání. Konkrétně navrhovatel zmiňuje problém přístupu k root oprávnění, které může být dle navrhovatele využito ke smazání všech uložených dat v systému. Ačkoliv dle navrhovatele musí každá aplikace mít roli root, není u každé aplikace obvyklé, aby využití této role vyžadovaly běžné úkony prováděné v této aplikaci. Navrhovatel má za to, že nástroj LogMan.io nutně vyžaduje použití role root pro funkce jako je aktualizace software, aktualizace databází včetně Ipgeolokační databáze, zálohování a obnovy konfigurace, zálohování a obnovy dat a případně další (tj. funkce pro běžnou správu nástroje). Pakliže navrhovatel ve vyjádření k podkladům uvádí, že nástroje nesmí umožnit modifikaci či smazání dat žádný způsobem, a to ani prostřednictvím „hackerských“ technik, tak Úřad má za to, že tento názor navrhovatele nelze přijmout, resp. tímto způsobem nelze požadavek zadavatele vykládat. Hackerské techniky představují zcela nestandardní zásah do systému ze strany cizího subjektu, dle Úřadu je však nutno požadavky zadavatele vztahovat k běžnému, standardnímu provozu a užívání nástroje. Úřad je toho názoru, že s ohledem na podstatu hackerských technik (kdy ty nemusí být obecně známy a podléhají neustálému vývoji) nikdy nemůže být nalezena stoprocentní jistota nenapadnutelnosti daného systému tímto způsobem (a to ani po provedení jakéhokoliv znaleckého posudku), přičemž v tomto ohledu je nutné vykládat i předmětný požadavek zadavatele. Úřad tak má za to, že závěry znalce jsou dostačující k prokázání toho, že nástroj vybraného dodavatele splňuje požadavek č. 506 přílohy č. 1 smlouvy.

251.     K argumentu navrhovatele, že nástroj Logman.io negarantuje integritu uložených dat a umožňuje mazání a modifikaci uložených logů, přičemž tato skutečnost je také v rozporu s legislativními a normativními požadavky kladenými na tento nástroj prostřednictvím vyhlášky, resp. v rozporu s bodem č. 901 přílohy č. 1 smlouvy, Úřad uvádí, že splnění legislativních požadavků vyhlášky je prokázáno znaleckým posudkem č. 203-7/2020. Uvedený závěr Úřad blíže rozvádí níže v odůvodnění tohoto rozhodnutí (viz body 269. a dále odůvodnění tohoto rozhodnutí).

252.     Úřad tak k požadavku č. 506 s odkazem na závěry uvedené ve znaleckém posudku konstatuje, že tvrzení navrhovatele o tom, že nástroj nabídnutý vybraným dodavatelem tento požadavek nesplňuje, se neprokázalo.

K požadavkům č. 510 a č. 511

253.     Navrhovatel dále napadá to, že nástroj v rozporu s body č. 510 a 511 přílohy č. 1 smlouvy neumožňuje definici a zasílání alertů (upozornění) pomocí SMTP. Vybraný dodavatel způsob splnění požadavků č. 510 a 511 popsal ve svém vyjádření ze dne 11. 10. 2021, přičemž Úřad popsaný způsob jejich splnění vtělil do dotazů č. 52.A a 52.B položených znalci (viz bod 196. odůvodnění tohoto rozhodnutí). 

254.     Znalec k otázkám vztahujícím se k požadavkům č. 510 a 511 přílohy č. 1 smlouvy uvedl, že nemůže jednoznačně vyloučit, že tyto požadavky lze splnit způsobem popsaným vybraným dodavatelem. V rámci zdůvodnění pak uvedl, že systém založený na systému ELK (opensource) s různými nadstavbami umožňuje nastavení SMTP notifikací (viz bod 196. odůvodnění tohoto rozhodnutí). 

255.     Úřad tak k požadavkům č. 510 a 511 s odkazem na závěry uvedené ve znaleckém posudku konstatuje, že tvrzení navrhovatele o tom, že nástroj nabídnutý vybraným dodavatelem tyto požadavky nesplňuje, se neprokázalo.

K požadavku č. 512

256.     Navrhovatel má taktéž za to, že nástroj vybraného dodavatele v rozporu s bodem č. 512 přílohy č. 1 smlouvy neumožňuje konfiguraci notifikací pomocí grafického vizuálního programovacího jazyka formou obrázků obsahujících aplikační logiku. Vybraný dodavatel způsob splnění požadavku č. 512 popsal ve svém vyjádření ze dne 11. 10. 2021, přičemž Úřad popsaný způsob jejich splnění vtělil do dotazu č. 53 položeného znalci (viz bod 197. odůvodnění tohoto rozhodnutí). 

257.     Znalec v odpovědi na otázku vztahující se k požadavku č. 512 přílohy č. 1 smlouvy uvedl, že nemůže jednoznačně vyloučit, že tento požadavek lze splnit způsobem popsaným vybraným dodavatelem. S ohledem na to, že znalec ve svém zdůvodnění pouze uvedl, že „Nebylo znalcem jednoznačně ověřeno nebo vyloučeno“, požádal jej Úřad o bližší zdůvodnění jeho závěru (viz bod 79. odůvodnění tohoto rozhodnutí). Znalec ve vysvětlení znaleckého posudku č. 2 pak uvedl, že nástroj Logman.io obsahuje deklarativní jazyk SP-Lang, který má i svou vizuální reprezentaci, která využívá rozšířenou technologii Blockly[212], přičemž toto umožňuje uživatelům vytvářet a modifikovat notifikace v grafickém prostředí, kde jednotlivé výrazy jsou prezentovány formou výrazů. Současně znalec uvedl, že ukázka funkčnosti byla provedena, a proto došel k závěru, že nemůže jednoznačně vyloučit, že předmětný požadavek lze splnit způsobem popsaným vybraným dodavatelem. Nadto znalec dále uvedl, že samotný deklarativní jazyk SP-Lang nebyl ověřován, neboť jeho analýza by převyšovala mnohonásobně čas i rozpočet znalce (viz bod 202. odůvodnění tohoto rozhodnutí). 

258.     K argumentaci navrhovatele uvedené ve vyjádření k podkladům, podle níž bez reálného testu funkčnosti závěr znalce nic nedokazuje, přičemž ani popis řešení se screeny vizuálního prostředí doručené Úřadu vybraným dodavatelem nic nedokazují, neboť si vybraný dodavatel mohl předmětné screeny vytvořit mimo šetřený nástroj, Úřad opětovně uvádí, že znalec neměl primárně dle zadání znaleckého posudku zkoumat funkčnost reálného nástroje (resp. jeho prototypu či demoverze). Podstatou znaleckého posudku bylo pouze ověření reálnosti návrhu řešení, které vybraný dodavatel nabídnul zadavateli v rámci své nabídky odbornou osobou. Uvedené znalec dle Úřadu splnil a v rámci znaleckého posudku (ve znění dalších vysvětlení) uvedl jasné stanovisko, a to, že nemůže jednoznačně vyloučit, že tento požadavek lze splnit způsobem popsaným vybraným dodavatelem.

259.     Co se týče argumentace navrhovatele, že dokumentace nástroje Logman.io neobsahuje jediný vzorový příklad, k tomu Úřad uvádí, že vybraný dodavatel ve svém vyjádření ze dne 11. 10. 2021 odkazuje na dokumentaci nástroje týkající se právě deklarativního jazyka[213]. Na předmětném odkazu dokumentace nástroje je pak další odkaz odkazující konkrétně na popis použitého deklaratorního jazyka SP-Lang[214], kde jsou zachyceny i vzorové příklady použití (viz bod 197. odůvodnění tohoto rozhodnutí).

260.     Úřad tak k požadavku č. 512 s odkazem na závěry uvedené ve znaleckém posudku konstatuje, že tvrzení navrhovatele o tom, že nástroj nabídnutý vybraným dodavatelem tento požadavek nesplňuje, se neprokázalo.

K požadavkům č. 705 a č. 706 

261.     Navrhovatel má dále za to, že v nástroji vybraného dodavatele rovněž chybí předdefinované pohledy na uložená data, tzv. dashboardy dle bodů č. 705 a 706 přílohy č. 1 smlouvy. Vybraný dodavatel způsob splnění požadavky č. 705 a 706 popsal ve svém vyjádření ze dne 11. 10. 2021, přičemž Úřad popsaný způsob jejich splnění vtělil do dotazů č. 54.A a č. 54.B položeného znalci (viz bod 198. odůvodnění tohoto rozhodnutí).   

262.     Znalec v odpovědi na otázky vztahující se k požadavkům č. 705 a 706 přílohy č. 1 smlouvy uvedl, že nemůže jednoznačně vyloučit, že tyto požadavky lze splnit způsobem popsaným vybraným dodavatelem. V rámci zdůvodnění pak uvedl, že systém založený na systému ELK (opensource) s různými nástavbami jako je Kibana nebo Grafana umožňuje jednoduchou i složitou tvorbu dashboardů a dalších grafických pohledů. Současně znalec uvedl, že nadstavba Kibana a Grafana umožňují rychlý import/export z a do systému, s tím, obsahují základní pohledy a všechny pohledy lze modifikovat.

263.     Úřad tak k požadavkům č. 705 a 706 s odkazem na závěry uvedené ve znaleckém posudku konstatuje, že tvrzení navrhovatele o tom, že nástroj nabídnutý vybraným dodavatelem tyto požadavky nesplňuje, se neprokázalo.

K požadavku č. 810 a č. 813

264.     Navrhovatel má taktéž za to, že v rozporu s bodem č. 810 a 813 přílohy č. 1 smlouvy nástroj nedisponuje předpřipravenými alerty (upozorněními) a pohledy na uložená data dle kategorií a logického členění a nepodporuje jejich zasílání v různých formátech PDF, HTML a CSV příp. dalších. Vybraný dodavatel způsob splnění požadavků č. 810 a 813 popsal ve svém vyjádření ze dne 11. 10. 2021, přičemž Úřad popsaný způsob jejich splnění vtělil do dotazů č. 55 a 56 položených znalci (viz body 199. a 200. odůvodnění tohoto rozhodnutí).  

265.     K uvedenému Úřad v prvé řadě uvádí, že požadavky uvedené v bodech č. 810 a 813 přílohy č. 1 smlouvy neřeší problematiku předpřipravených alertů a odesílání pohledů, jak uvádí navrhovatel, neboť požadavky jsou ve znění: „Nástroj obsahuje předpřipravené pohledy na uložená data dle jednotlivých kategorií zdrojových zařízení i dle logického členění.“ a „Nástroj umožňuje vytvářet reporty ve formátech PDF, HTML a CSV, popř. dalších.“. Bod č. 810 tedy dle Úřadu řeší pouze problematiku předpřipravených pohledů (nikoliv alertů) a bod č. 813 vytváření reportů v požadovaných formátech (nikoliv jejich odesílání). S ohledem na uvedené byly dotazy znalci k požadavkům uvedeným v bodech č. 810 a 813 přílohy č. 1 smlouvy formulovány podle skutečného znění těchto požadavků.

266.     Znalec v odpovědi na otázky vztahující se k uvedeným požadavkům uvedl, že nemůže jednoznačně vyloučit, že tyto požadavky lze splnit způsobem popsaným vybraným dodavatelem. Ke zdůvodnění svého závěru k požadavku č. 810 uvedl, že systém založený na systému ELK (opensource) s různými nástavbami jako je Kibana a Grafana umožňuje jednoduchou i složitou tvorbu dashboardů a dalších grafických pohledů. Tyto nadstavby obsahují i předem definované pohledy a dashboardy.  Ke zdůvodnění svého závěru k požadavku č. 813 uvedl, že systém založený na systému ELK (opensource) s různými nástavbami jako je Kibana a Grafana umožňuje export dat. Souhrnně k oběma požadavkům pak znalec uvedl, že nadstavby Kibana a Grafana umožňují rychlý import/export z a do systému, s tím, že obsahují základní pohledy, přičemž všechny pohledy lze modifikovat (viz body 199. a 200. odůvodnění tohoto rozhodnutí). 

267.     Co se týče námitky navrhovatele uvedené ve vyjádření k podkladům rozhodnutí, ve které navrhovatel tvrdí, že odpověď znalce na otázku č. 55 není jednoznačně průkazná, neboť ve způsobu řešení se pouze konstatuje, že dané pohledy jsou již předpřipravené, ale není představen ani seznam těchto pohledů a nebyla provedena kontrola, zda se o tyto pohledy dle jednotlivých technologií opravdu jedná, přičemž vybraným dodavatelem přiložený seznam generických pohledů na data ve většině uvedených případů neřeší pohled na pořízená data z hlediska log managementu, ale z hlediska metriky, tj. dohledu nad vytížením zdrojů, Úřad konstatuje, že z odpovědi znalce jasně vyplývá, že výše popsané technologie umožňují tvorbu dashboardů a grafických pohledů. To, že tyto technologie obsahují i nějaké předpřipravené pohledy, které dle navrhovatele nejsou relevantní k danému požadavku, je dle Úřadu sice pravda, ale vybraný dodavatel i znalec toto uvádějí pouze jako doplnění svých odpovědí. Dle Úřadu je však podstatné to, že obecně dashboardy a grafické pohledy lze dle znalce jednoduše tvořit v nabízeném řešení vybraného dodavatele a data lze současně jednoduše importovat/exportovat do tohoto systému. V tomto ohledu tedy není relevantní nějaký seznam předpřipravených pohledů. I kdyby vybraný dodavatel neměl předpřipravené pohledy na uložená data, tak s ohledem na závěry znalce řešení vybraného dodavatele umožňuje tyto pohledy dotvořit před předáním předmětu plnění zadavateli. Úřad současně uvádí, že ze závěrů znalce nevyplývá, že by existoval důvod, proč by nešlo předpřipravit pohledy dle požadavku č. 810 přílohy č. 1 smlouvy.

268.     Úřad tak k požadavkům č. 810 a 813 s odkazem na závěry uvedené ve znaleckém posudku konstatuje, že tvrzení navrhovatele o tom, že nástroj nabídnutý vybraným dodavatelem tyto požadavky nesplňuje, se neprokázalo.

K požadavkům č. 901 a č. 902

269.     Navrhovatel dále namítá, že nástroj vybraného dodavatele nesplňuje požadavek zadavatele č. 901, tj. nesplňuje legislativní a normativní požadavky vyhlášky, a požadavek č. 902, tj. nesplňuje požadavky normy ISO 27001/2014 – Informační technologie – systémy řízení bezpečnostní informací – bezpečnostní techniky (dále jen „norma ISO 27001/2014“), přičemž nesplnění uvedených požadavků vztahuje ke dvěma konkrétním důvodům.  Prvně navrhovatel uvádí, že vybraný dodavatel v rámci ve svého vyjádření ze dne 11. 10. 2021 u vysvětlení řešení požadavku č. 129, tj. podpora sběru, parsování a normalizace logů platformy Microsoft SQL, odkazuje na Microsoft SQL Server 2008, což je dle navrhovatele již dlouhou dobu nepodporovaný systém, který již nemůže obdržet bezpečnostní aktualizace (a tedy splnit požadavky vyhlášky a normy ISO 27001/2014). Jako druhý důvod, v jehož kontextu navrhovatel namítá nesplnění požadavku č. 901 (zde již není napadáno nesplnění požadavku č. 902), je dle navrhovatele to, že nástroj Logman.io dle požadavku č. 506 negarantuje integritu uložených dat a umožňuje mazání a modifikaci uložených logů, neboť dle navrhovatele bude vždy existovat osoba s možností smazat celý systém včetně všech jeho uložených logů. Z uvedeného tedy vyplývá, že navrhovatel nenapadá nesplnění požadavků č. 901 a č. 902 nástrojem vybraného dodavatele jako celku, ale vznáší námitky pouze ve vztahu ke konkrétním výše uvedeným částem nástroje.

270.     K tomu Úřad v prvé řadě uvádí, že zadavatel ke svému vyjádření ze dne 13. 9. 2021 přiložil Úřadu znalecký posudek č. 203-7/2020, který si nechal vypracovat vybraný dodavatel za účelem zjištění, zda nástroj Logman.io splňuje požadavky normy ČSN/ISO 27001:2013 a požadavky zákona č. 181/2014 Sb. o kybernetické bezpečnosti, ve znění pozdějších předpisů (dále jen „zákon o kybernetické bezpečnosti“) (viz bod 148. odůvodnění tohoto rozhodnutí).

271.     S ohledem na skutečnost, že i k posouzení této části návrhu je zapotřebí odborných znalostí, které úřední osoby nemají, Úřad přistoupil k použití znaleckého posudku č. 203-7/2020 jako důkazu.

272.     Navrhovatel v návrhu ke znaleckému posudku č. 203-7/2020 uvádí, že z něj žádným způsobem nevyplývá, jak znalec došel k závěru, že nástroj LogMan.io splňuje všechny legislativní požadavky dle vyhlášky, přičemž se navrhovateli jeví jako vhodné, aby Úřad v souladu se zásadou materiální pravdy nechal zpracovat revizní znalecký posudek, který by funkcionalitu daných požadavků zadavatele v nástroji LogMan.io ověřil, a to na základě provedení praktické zkoušky. Úřad k argumentaci navrhovatele konstatuje, že ze znaleckého posudku č. 203-7/2020 vyplývá, že závěry znalce jsou založeny zejména na testování nástroje LogMan.io (viz bod 150. odůvodnění tohoto rozhodnutí) . Úřad má taktéž za to, že znalec své závěry náležitě odůvodnil zejména v rámci bodů 2.3 až 2.6 znaleckého posudku č. 203-7/2020 (viz body 151. a 153. odůvodnění tohoto rozhodnutí); bližší komentář k závěrům znalce Úřad činí v následujícím odstavci. Úřad shledal závěry znalce uvedené ve znaleckém posudku za způsobilé být podkladem pro právní posouzení projednávané věci, a proto dospěl k závěru, že není důvod pro zadání revizního posudku.

273.     K samotnému obsahu znaleckého posudku č. 203-7/2020 Úřad nejprve opětovně uvádí, že znalec jako podklad pro vypracování znaleckého posudku krom využití technické dokumentace nástroje LogMan.io taktéž sám tento nástroj testoval (tj. mohl se detailně seznámit s fungováním nástroje). Ze znaleckého posudku č. 203-7/2020 dále vyplývá, že znalec detailně identifikoval a popsal požadavky na nástroj log managementu vyplývající z normy ČSN/ISO 27001, zákona o kyberbezpečnosti a vyhlášky (viz body 151. a 152. odůvodnění tohoto rozhodnutí). Následně v popisu funkcí nástroje Logman.io znalec v kontextu identifikovaných požadavků šetřených předpisů uvedl, že LogMan.io obsahuje funkce pro příjem logů (bez omezení jejich formátu či struktury), přičemžv rámci komponenty Ingestor dojde k označení každého logu časovým razítkem. Do JSON struktury, která obsahuje data logu je kromě časového razítka přidán rovněž hash předchozí JSON struktury předchozího logu. K tomu pak znalec dodává, že je tímto „zajištěna řada uložených logů z hlediska jejich časového pořízení/přijetí do Log Managementu a jejich neměnnosti.“. Dále znalec uvádí informace i ke způsobu archivace (uložení) logů, když uvádí, že „Po projití Ingestorem jsou logy rozparsovány a uloženy. Délka uložení není aplikačně omezena a je odvislá od zakoupené licence TeskaLabs LogMan.io.“. Co se týče zajištění logů proti zfalšování, resp. ochrany logů proti změnám a neoprávněným čtením pak znalec uvádí, že „Pro přístup k logům je využíván nástroj Kibana nebo nativní GUI TeskaLabs LogMan.io. Přístup k logům je chráněn přihlášením pouze pro oprávněné uživatele.“. Současně znalec dokládá ve znaleckém posudku vybrané pohledy na prostředí aplikace jejím vlastním GUI (viz bod 154. odůvodnění tohoto rozhodnutí). Z tabulky uvedené v závěrech znaleckého posudku č. 203-7/2020 pak vyplývá, že všechny identifikované požadavky šetřených předpisů a normy ČSN/ISO 27001 nástroj Logman.io splňuje (viz bod 153. odůvodnění tohoto rozhodnutí).     

274.     Všechny popsané závěry pak znalec uzavírá v rámci výroku znaleckého posudku, kde je uvedeno, že nástroj Logman.io splňuje požadavky normy ČSN/ISO 27001:2014 (jako poslední verze této normy) a rovněž normy ČSN/ISO 27001:2013 (jako verze předchozí) a současně tento nástroj splňuje i požadavky zákona o kybernetické bezpečnosti a vyhlášky (tj. splnění požadavků normy ISO 27001/2014).

275.     K námitce navrhovatele týkající se nesplnění požadavku č. 901, podle níž nástroj Logman.io negarantuje integritu uložených dat a umožňuje mazání a modifikaci uložených logů, Úřad uvádí, že otázka požadavku na garanci integrity dat byla řešena i v rámci znaleckého posudku, který si nechal vyhotovit Úřad (konkrétně dotaz č. 51 viz bod 195. odůvodnění tohoto rozhodnutí). Ze znaleckého posudku v kontextu vysvětlení znaleckého posudku ze dne 21. 9. 2022 pak vyplývá, že znalec nemůže jednoznačně vyloučit, že řešení vybraného dodavatele může splnit předmětný požadavek zadavatele (blíže viz body 248. až 252.  odůvodnění tohoto rozhodnutí). 

276.     Úřad tak k požadavkům č. 901 a 902 s odkazem na závěry uvedené ve znaleckém posudku a ve znaleckém posudku č. 203-7/2020 konstatuje, že tvrzení navrhovatele o tom, že nástroj nabídnutý vybraným dodavatelem tyto požadavky nesplňuje, se neprokázalo.

K překladu dokumentace nástroje do českého jazyka

277.     Navrhovatel ve svém návrhu taktéž brojí proti tomu, že nástroj vybraného dodavatele má svou dokumentaci pouze v anglickém jazyce, a nikoliv v českém jazyce, což je v rozporu s bodem  5.1.1 návrhu smlouvy.

278.     K tomu Úřad nejprve uvádí, že zadavatel v bodě 5.1.1 návrhu smlouvy stanovil, že veškerá dokumentace vztahující se k předmětu plnění a k software, bez níž by nemohlo docházet k řádnému užívání software v souladu s poskytnutou licencí, bude v českém jazyce, přičemž tato dokumentace musí být předána spolu s předmětem plnění v elektronické podobě (viz bod 139. odůvodnění tohoto rozhodnutí). Z uvedeného tak dle Úřadu vyplývá, že dokumentace bude předána až spolu s předáním samotného předmětu plnění zadavateli. V tomto ohledu je tedy irelevantní, zda vybraný dodavatel překlad v českém jazyce v době podání nabídky již vlastnil, nebo ne. S ohledem na skutečnost, že vybraný dodavatel (a taktéž i výrobce produktu Logman.io společnost TescaLabs) jsou české společnosti působící na českém trhu, Úřad má za to, že i v případě, že by vybraný dodavatel zmíněným předkladem v době podání nabídky nedisponoval, není důvod se domnívat, že by jej nedokázal vytvořit do termínu předání předmětu plnění zadavateli.

279.     S ohledem na uvedené Úřad má za to, že neexistuje důvod se domnívat, že vybraný dodavatel nedokáže dostát požadavku uvedenému v bodě 5.1.1 návrhu smlouvy, tj. předložit zadavateli spolu s předáním předmětu plnění veřejné zakázky dokumentaci k předmětu veřejné zakázky v českém jazyce.

K argumentaci navrhovatele uvedené ve vyjádření k podkladům

280.     Navrhovatel ve svém vyjádření k podkladům v prvé řadě tvrdí, že znalecký posudek ve znění vysvětlení znaleckého posudku nedisponuje všemi náležitostmi ve smyslu § 28 odst. 1 a 2 zákona o znalcích. Dle navrhovatele je znalecký posudek nepřezkoumatelný, když dle jeho názoru ve vztahu k většině odpovědí na položené otázky neobsahuje odůvodnění v rozsahu umožňujícím přezkoumatelnost znaleckého posudku jakožto povinnou náležitost ve smyslu
§ 28 odst. 2 písm. f) zákona o znalcích, a neobsahuje ani přílohy potřebné k zajištění přezkoumatelnosti znaleckého posudku jakožto povinnou náležitost ve smyslu § 28 odst. 2 písm. h) zákona o znalcích. Uvedené nedostatky znaleckého posudku pak navrhovatel prezentuje na následujících příkladech.

281.     Navrhovatel nejprve konkrétně uvádí, že u některých otázek znalec v rámci zdůvodnění odpovědi uvádí pouze, že „standardně má logman.io cca 80 % předdefinovaných výrobců, ostatní je nutné tzv. doprogramovat na místě u zákazníka z důvodů rozdílných požadavků i požadavků výrobců těchto zařízení (na základě definovaného portu definují zařízení, který je pak potřeba do konfigurovat/nastavit, zda je to syslog, win log, apod.“, přičemž navrhovatel má za to, že z žádné části znaleckého posudku zároveň nijak nevyplývá, že by znalec citovanou možnost doprogramování jakýmkoliv způsobem prověřoval. Je tak vysoce pravděpodobné, že znalec ve vztahu k odpovědím na tyto otázky pouze nekriticky převzal tvrzení dodavatele, resp. spol. TeskaLabs. K tomu Úřad uvádí, že z odpovědi znalce nijak nevyplývá, že by znalec nekriticky přistupoval ke svému šetření, resp. k vyhodnocení   informací a dat, ze kterých vycházel. Ze znaleckého posudku plyne, že znalci byly primárně předloženy popisy řešení daných požadavků od zadavatele a vybraného dodavatele, přičemž znalec v bodě 1.9 znaleckého posudku uvádí celou řadu dalších metod a prostředků, ze kterých vycházel (místní šetření s předvedením již nasazeného nástroje, testování demoverze a dotazování vybraného dodavatele a výrobce nástroje), přičemž Úřad doplňuje, že znalci byly předány i materiály k jednotlivým otázkám v rámci usnesení, kterým znalec byl ustanoven. Je tedy nepochybné, že znalec využil více metod a udělal si souhrnný závěr o tom, kolik částí je již předdefinovaných a kolik ne. Současně znalec jako odborník v daném oboru zachytil ve svém zdůvodnění to, že dle jeho odborného názoru je doimplementování zbylých částí systému na místě u zákazníka běžnou praxí v tomto oboru.

282.     Navrhovatel dále uvádí, že znalec v bodě 1.1.2 znaleckého posudku (viz bod 157. odůvodnění tohoto rozhodnutí) stanovuje mezi obecnými předpoklady a omezujícími podmínkami znaleckého posudku, že „Vychází se z toho, že informace z jiných zdrojů, které sloužily, jako další podklad pro zpracování tohoto znaleckého posudku jsou věrohodné a nebyly tudíž ve všech případech z hlediska přesnosti a úplnosti ověřovány“, z čehož navrhovatel vyvozuje, že znalecký posudek v dotčených částech vůbec nedisponuje jakoukoliv vypovídací hodnotou pro skutková zjištění, když fakticky pouze přejímá údaje a skutečnosti, které mu sdělil dodavatel či spol. TeskaLabs, aniž by je znalec jakkoliv nezávisle ověřil, což bylo primárně jeho úkolem. K uvedenému Úřad konstatuje, že ze znaleckého posudku plyne, že znalec v bodě 1.1.2 stanovil „Obecné předpoklady a omezující podmínky“, ze kterých následně vycházel při tvorbě znaleckého posudku (viz bod 157. odůvodnění tohoto rozhodnutí). Následně v bodě 1.9 s názvem „Použité metody a prostředky“ blíže rozvedl, jaké prostředky pro svůj výzkum použil a jaké metody pro sběr dat zvolil (viz bod 158. odůvodnění tohoto rozhodnutí). Úřad má za to, že výše uvedené předpoklady znalce nijak neomezily v tom, aby mohl dojít k relevantním odpovědím na dané otázky, neboť znalec zvolil pro vypracování znaleckého posudku několik rozdílných metod, které mu pomohly sesbírat potřebné informace a data a následně na jejich základě dojít k závěrům uvedeným ve znaleckém posudku. Současně Úřad podotýká, že uvedený předpoklad o věrohodnosti informací čerpaných z jiných zdrojů lze chápat s ohledem na to, že znalec ve svém znaleckém posudku (ale i vybraný dodavatel ve svých vyjádřeních, které byly podkladem pro formulování otázek znalci) používá spousty odkazů na technické specifikace nástrojů třetích stran či na jiné údaje, jež získal z veřejně dostupných zdrojů (např. odkazy na web elastic.co, kde je popsán nástroj Elasticsearch), přičemž dle Úřadu je jak z časového, tak i ekonomického hlediska nemyslitelné uvažovat nad tím, že by znalec musel ověřovat tento typ údajů z hlediska jejich pravdivosti.

283.     K tomu, že navrhovatel tento předpoklad vztahuje i k dokumentaci nástroje Logman.io, resp. k informacím o nástroji od výrobce tohoto nástroje – společnosti TeskaLabs, Úřad konstatuje, že dokumentace nástroje Logman.io není určena pouze pro tuto konkrétní veřejnou zakázku (resp. pro vybraného dodavatele), ale pro všechny potenciální zákazníky společnosti TeskaLabs. Úřad tak má za to, že je pouze spekulací navrhovatele, že údaje uvedené v této dokumentaci by měly být nepravdivé či dokonce úmyslně falšovány, aby společnost TeskaLabs napomohla vybranému dodavateli k získání veřejné zakázky. Úřad však má za to, že ze znaleckého posudku nevyplývá, že by znalec přistupoval nekriticky i k údajům uvedeným v dokumentaci nástroje Logman.io. Současně Úřad podotýká, že bod 1.1.2 znaleckého posudku obsahuje krom pasáže citované navrhovatelem taktéž text, v němž znalec uvádí, že provedl řádné šetření k ověření správnosti a úplnosti předložených souborů jako podkladu pro znalecké posouzení (viz bod 157. odůvodnění tohoto rozhodnutí), tj. těch podkladů o řešení vybraného dodavatele, které Úřad předložil k ověření v rámci jednotlivých otázek položených znalci. Z uvedeného tedy dle Úřadu vyplývá, že otázky obsahující konkrétní údaje o řešení nástroje vybraného dodavatele předložené Úřadem znalec ověřoval.

284.     Navrhovatel dále spatřuje nepřezkoumatelnost znaleckého posudku v tom, že dle jeho názoru je znalecký posudek vnitřně rozporný. Dle navrhovatele znalec na jednu stranu v bodě 1.9.3 nálezu znaleckého posudku uvádí, že mu byla při místním šetření „vysvětlena, umožněna a předvedena funkcionalita SW logman.io související s dotazy 1 – 56“, čímž dle navrhovatele evokuje, že mu bylo předvedeno faktické splnění veškerých požadavků zadavatele, na které se Úřad dotazoval, přičemž však u některých odpovědí (na otázky č. 48, 51 a 53) znalec prostě uvádí, že „nebylo ověřeno“. Úřad k tomu v prvé řadě konstatuje, že z navrhovatelem citované věty nijak nevyplývá, že znalci byla předvedena každá funkcionalita nástroje Logman.io, resp. že bylo ověřeno splnění každého ze zadavatelem stanovených požadavků. Úřad současně podotýká, že skutečnost, že předvedení funkcionalit nijak nesouvisí s tím, resp. nemá vliv na to, k jakým závěrům znalec došel u odpovědí na otázky č. 48, 51 a 53. Úřad dále uvádí, že jednotlivými závěry k předmětným otázkám se zabýval již výše v odůvodnění tohoto rozhodnutí (viz body 244. až 247. k otázce č. 48, body 248. až 252. k otázce č. 51 a body 256. až 260. k otázce č. 53), nicméně na tomto místě je nutné opětovně zdůraznit, že Úřad položil znalci otázky tak, že znalec neměl mít ambici ověřovat to, zda nástroj Logman.io splňuje či nesplňuje požadavky zadavatele, ale pouze zjistit, zda řešení vybraného dodavatele tyto požadavky potenciálně splnit může, resp. zda existuje nějaký zásadní problém či překážka, proč by tento nástroj požadavky zadavatele způsobem navrženým v nabídce vybraného dodavatele splnit nemohl. Pokud tedy znalec k předmětným dotazům ve svém zdůvodnění uvádí odpovědi v tom duchu, že „nebylo jednoznačně ověřeno nebo vyloučeno“ (Úřad poznamenává, že znalec ke každé navrhovatelem namítané odpovědi na otázky č. 48, 51 a 53 uvedl i další zdůvodnění, k čemuž Úřad opětovně odkazuje na výše uvedené pasáže tohoto rozhodnutí), lze z takovéto odpovědi dovodit prostý závěr, že znalec nenašel důvody, na jejichž základě by mohl jednoznačně vyloučit, že předmětný požadavek popsaným způsobem splnit lze. 

285.     K argumentaci navrhovatele, že znalec neměl provádět místní šetření, na jehož základě mu byl předveden nástroj Logman.io implementovaný u společnosti O2 Czech Republic a.s., a měl vycházet pouze z podkladů předaných Úřadem, Úřad uvádí následující. Ze znaleckého posudku plyne, že znalec provedl místní šetření, jehož předmětem bylo vysvětlení a zodpovězení Úřadem položených otázek a dále i ukázky řešení nástroje Logman.io nasazeného u společnosti O2, přičemž mezi zúčastněnými byli zástupci vybraného dodavatele, společnost TeskaLabs a společnosti O2 (viz bod 159. odůvodnění tohoto rozhodnutí). Úřad k tomu dále uvádí, že dle § 53 odst. 1 vyhlášky č. 503/2020 Sb., vyhláška o výkonu znalecké činnosti, ve znění pozdějších předpisů, zdrojem dat pro zpracování znaleckého posudku je informační databáze, předmět ohledání, fyzická osoba, písemnost obsažená ve spisu, který vede orgán veřejné moci, nebo kterou předložila fyzická nebo právnická osoba, nebo jiný zdroj informací, které jsou potřebné k odpovědi na zadanou odbornou otázku, přičemž dle odst. 2 citovaného paragrafu si znalec zdroj dat opatří sám nebo prostřednictvím jiné osoby nebo orgánu veřejné moci. Z uvedeného tedy vyplývá, že znalec je při sběru vstupních dat pro vypracování znaleckého posudku de facto nezávislý a v šetřeném případě proto nemusel vycházet pouze z podkladů předaných Úřadem. K tomu Úřad doplňuje, že Úřad vykonání místního šetření po znalci nepožadoval. Úřad taktéž konstatuje, že postup znalce, který mezi své metody zařadil i předvedení fungujícího obdobného nástroje implementovaného u společnosti O2 a testování demoverze nástroje, naopak přidal na kvalitě a objektivitě závěrů znalce. K tvrzení navrhovatele, že znalec v žádné části posudku neuvádí, jaké konkrétní skutečnosti při místním šetření zjistil a jak konkrétně se tyto měly do jeho závěrů promítnout, z čehož navrhovatel dovozuje nepřezkoumatelnost znaleckého posudku, Úřad uvádí, že znalec v bodě 1.10 s názvem „Výsledky a hodnocení“ znaleckého posudku uvedl, že výsledky jednotlivých metod jsou shodné a jejich výsledky jsou uvedeny v odpovědích v kap. 2 (viz bod 161. odůvodnění tohoto rozhodnutí), a tedy tyto závěry lze nalézt v samotném posudku, kde znalec odpovídá na Úřadem položené dotazy.    

286.     K námitce navrhovatele, že znalec ve znaleckém posudku neidentifikoval osobu „nezávislého znalce“, Úřad konstatuje, že usnesením č. j. ÚOHS-34110/2022/511 ze dne 30. 9. 2022 požádal znalce o vysvětlení role „nezávislého auditora“, přičemž vycházel z toho, že podle § 44 odst. 2 a 46 odst. 2 písm. a) vyhlášky platí, že pokud se na zpracování znaleckého posudku podílel konzultant ve smyslu § 23 zákona o znalcích, musí být ve znaleckém posudku označena zvláštní dílčí otázka posuzovaná konzultantem a též musí být označen konzultant, který ji posuzoval, spolu s uvedením důvodu, pro který jej znalec přibral. Znalec k citovanému usnesení uvedl, že nezávislý auditor nebyl přibrán jako konzultant ve smyslu výše zákona o znalcích, neboť nezpracovával samostatně zvláštní dílčí otázku (viz bod 230. odůvodnění tohoto rozhodnutí). S ohledem na uvedené má Úřad za to, že pakliže se nejednalo o konzultanta ve smyslu § 23 zákona o znalcích, neměl znalec povinnost tuto osobu uvádět ve svém znaleckém posudku. Současně z bodu 1. 10 s názvem „Výsledky a hodnocení“ znaleckého posudku (viz bod 162. odůvodnění tohoto rozhodnutí) je zřejmé, že výsledky všech použitých metod znalce došly ke stejnému závěru, přičemž metoda auditu, provedená předmětným auditorem byla pouze jednou z použitých metod.

287.     Navrhovatel ve vyjádření k pokladům dále navrhuje, aby Úřad přistoupil k zadání revizního znaleckého posudku, který bude zpracován transparentním způsobem, který bude zpětně přezkoumatelný a který jednoznačně zodpoví otázku, zda nabídka vybraného dodavatele ke dni podání nabídek splňovala technické podmínky vymezující předmět veřejné zakázky. Současně navrhovatel požaduje, aby při zpracování tohoto revizního posudku bylo provedeno testování verze nástroje LogMan.io, která byla aktuální k okamžiku uplynutí lhůty pro podání nabídek, a ověření všech navrhovatelem rozporovaných požadavků zadavatele. V zájmu zajištění transparentnosti a přezkoumatelnosti revizního znaleckého posudku navrhovatel žádá, aby testování nástroje proběhlo v rámci ústního jednání před Úřadem, a to za účasti zástupců vybraného dodavatele, spol. TeskaLabs, navrhovatele a za účasti samotného znalce. Navrhovatel dále žádá, aby byl průběh testování zdokumentován prostřednictvím audiovizuálního záznamu, aby se předešlo případným pochybnostem o průběhu testování a aby bylo zajištěno, že revizní posudek bude plně přezkoumatelný. Navrhovatel taktéž připojuje návrh na doplnění dokazování spojený s otázkami, které by měl revizní znalecký posudek zodpovědět, a s návrhem způsobu ověření splnění dílčích požadavků zadavatele. 

288.     Úřad k uvedenému předně uvádí, že znalec v bodech 1.9.3 a 1.9.4 znaleckého posudku zachytil průběh místního šetření (viz bod 159. odůvodnění tohoto rozhodnutí) a dále popsal průběh testování demoverze nástroje Logman.io vč. okruhu otázek, které se při testování řešily (viz bod 160. odůvodnění tohoto rozhodnutí). Úřad k této námitce navrhovatele taktéž opětovně zdůrazňuje, že nelze testovat něco, co ještě reálně neexistuje. Dodavatelé nebyli povinni mít v době podání nabídek kompletně funkční nástroj. Současně Úřad má za to, že správní řízení před Úřadem nemá pro dodavatele sloužit jako forma zjišťování „know how“ jejich konkurentů, resp. jako forma nějakého konkurenčního boje mezi dodavateli. Nařízení ústního jednání, ve kterém by byl komplexně předveden nástroj vybraného dodavatele navrhovateli, by pak mohlo sloužit právě k tomuto účelu, tedy ke zjištění „know how“ konkurence. Uvedené lze vztáhnout i na pořizování případného pořizování audiovizuálního záznamu.

289.     Dále Úřad uvádí, že s ohledem na své závěry k formě položených dotazů (viz body 213. a 209. odůvodnění tohoto rozhodnuté) má za to, že položil otázky znalci správně, přičemž znalec na tyto otázky odpověděl přezkoumatelně. V šetřeném případě tedy není nutno pokládat otázky tak, aby bylo nutno přezkoumávat nějaký prototyp nástroje (který zadavatel v zadávacích podmínkách ani nepožadoval) a už vůbec ne kompletní nástroj, který dle navrhovatele měl být hotov již ke dni podání nabídky.

290.     Úřad tak k této námitce navrhovatele uzavírá, že znalecký posudek je zpracován transparentním a přezkoumatelným způsobem, a tedy není nutné zadat zpracování dalšího revizního posudku k tomu, aby byl zjištěn stav věci tak, aby o něm nebyly důvodné pochybnosti, neboť Úřad považuje skutkový stav za dostatečně zjištěný a umožňující právní posouzení věci. Úřad má za to, že takový postup by naopak byl v příkrém rozporu se zásadou hospodárnosti a procesní ekonomie.

K namítané mimořádně nízké nabídkové ceně

291.     V další části návrhu (resp. v námitkách, na něž v souvislosti s touto částí návrhu odkazuje) navrhovatel napadá MMNC v nabídce vybraného dodavatele. Navrhovatel poukazuje na výrazný rozdíl mezi nabídkovou cenou vybraného dodavatele a nabídkovými cenami ostatních účastníků zadávacího řízení a tvrdí, že předmět veřejné zakázky nelze vůbec za nabídkovou cenu vybraného dodavatele realizovat, pakliže by vybraný dodavatel měl dodržet všechny zákonem a zadavatelem stanovené povinnosti ve smyslu § 113 odst. 4 písm. a) a b) zákona. Současně navrhovatel tvrdí, že zadavatel v rozporu se zásadami přiměřenosti a transparentnosti uvedenými v § 6 odst. 1 zákona a rovněž v rozporu s ustanovením § 113 odst. 1 zákona neprovedl řádné posouzení MNNC obsažené v nabídce vybraného dodavatele a v rozporu s § 113 odst. 6 zákona vybraného dodavatele ze zadávacího řízení nevyloučil.

292.     Úřad k problematice MNNC předně uvádí následující. Zákon v ustanovení § 28 odst. 1 písm. o) definuje mimořádně nízkou nabídkovou cenu jako nabídkovou cenu nebo náklady uvedené účastníkem zadávacího řízení, které se jeví jako mimořádně nízké ve vztahu k předmětu veřejné zakázky. Úřad v obecné rovině k posouzení mimořádně nízké nabídkové ceny uvádí, že jeho smyslem je rozpoznat nabídky, které evokují na straně zadavatele oprávněné pochybnosti o tom, zda daný účastník zadávacího řízení bude schopen za takovou nabídkovou cenu předmět veřejné zakázky řádně plnit. Otázkou účelu institutu mimořádné nízké nabídkové ceny se zabýval Nejvyšší správní soud např. ve svém rozsudku sp. zn. 5 As 180/2016 ze dne 14. 9. 2017 v němž konstatoval, že »[s]myslem institutu mimořádně nízké nabídkové ceny je chránit zadavatele před situací, kdy uchazeč ve své nabídce uvede nereálnou cenu, za níž není možné z objektivních důvodů realizovat plnění veřejné zakázky, která by vedla například k nedokončení, nekvalitnímu splnění, případně nekontrolovatelnému navyšování původní nabídkové ceny. Citované ustanovení má také bránit uchazečům v nabízení objektivně nereálné nabídkové ceny s cílem získat „konkurenční výhodu“ oproti ostatním uchazečům a zvítězit tak v zadávacím řízení.«. Úřad dodává, že přestože se uvedený rozsudek Nejvyššího správního soudu vztahuje k předchozí právní úpravě, tj. k zákonu č. 137/2006 Sb., o veřejných zakázkách, lze závěry v něm uvedené aplikovat rovněž ve vztahu k nyní účinnému zákonu.

293.     Zákon ukládá povinnost zadavateli vyžádat si objasnění MNNC od dodavatelů v okamžiku, kdy přítomnost MNNC v nabídce konkrétního dodavatele zjistí. Tento institut má chránit především samotné zadavatele před tím, aby nebyli nuceni uzavřít smlouvu na předmět plnění veřejné zakázky s dodavatelem, u něhož má zadavatel důvodné pochybnosti o tom, zda bude schopen danou veřejnou zakázku v plném rozsahu řádně realizovat podle požadavků uvedených v zadávací dokumentaci. V tomto případě je kladen důraz na dodržení zásady transparentnosti, a to zejména při formulaci a následném postupu v souvislosti s žádostí zadavatele o objasnění MNNC ze strany dodavatele, neboť ten může ve svém důsledku vést až k vyloučení dodavatele ze zadávacího řízení. Jak plyne z § 113 odst. 6 zákona, zadavatel má povinnost účastníka zadávacího řízení vyloučit v případě, kdy z objasnění MNNC vyplývá, že nabídková cena je mimořádně nízká z důvodu porušování povinností uvedených v § 113 odst. 4 písm. a) zákona (tj. povinnosti dodržovat při plnění veřejné zakázky povinnosti vyplývající
z právních předpisů vztahujících se k předmětu veřejné zakázky, jakož i pracovněprávních předpisů a kolektivních smluv vztahujících se na zaměstnance, kteří se budou podílet na plnění veřejné zakázky), dále v případě, kdy je nabídková cena mimořádně nízká z důvodu veřejné podpory a účastník není schopen na výzvu zadavatele prokázat, že veřejná podpora byla poskytnuta v souladu s předpisy Evropské unie; a rovněž, pokud účastník v objasnění MNNC nepotvrdí skutečnosti podle § 113 odst. 4 zákona. V ostatních případech (tj. vyjma § 113 odst. 6 zákona) je zcela na uvážení zadavatele, zda účastníka zadávacího řízení, jehož nabídkovou cenu ve vztahu k předmětu veřejné zakázky posoudil jako MNNC, v zadávacím řízení ponechá, či nikoliv (viz § 48 odst. 4 zákona). Zadavatel však v takovýchto případech vždy musí mít potvrzeny skutečnosti vyžadované ustanovením § 113 odst. 4 zákona. V této souvislosti je však třeba zmínit, že s oprávněním zadavatele ponechat v zadávacím řízení účastníka, u něhož identifikoval MNNC, je bezprostředně spjato riziko, že za určitých okolností může být ohroženo řádné plnění veřejné zakázky; vyhodnocení míry tohoto rizika nicméně náleží jen a pouze zadavateli. Jak tedy dovodila i judikatura správních soudů (k tomu srov. např. rozsudek Krajského soudu v Brně č. j. 62 Af 78/2016-383 ze dne 4. 11. 2016) »zákon č. 134/2016 Sb., o zadávání veřejných zakázek, obsahuje v § 48 odst. 4 konstrukci, podle níž v případě nezdůvodnění mimořádně nízké nabídkové ceny zadavatel účastníka zadávacího řízení může vyloučit (tedy nemusí) – tuto povinnost má pouze ve výjimečných případech, jak na ně pamatuje § 113 odst. 6 tohoto zákona. I z toho zdejší soud nutně dovozuje posun ve vnímání institutu mimořádně nízké nabídkové ceny v tom směru, že nově je upřednostňována odpovědnost samotného zadavatele za uzavření smlouvy za podmínek pro něj „podezřele výhodných“ před nezměnitelným následkem spočívajícím v nemožnosti takovou smlouvu uzavřít; to ve výsledku také může směřovat k výkladu, podle něhož institut mimořádně nízké nabídkové ceny tu přestává být institutem chránícím rovným dílem zadavatele i ostatní dodavatele (resp. zajištění korektní soutěže mezi dodavateli), nýbrž spíše zadavatele, na něhož se pak zároveň klade vyšší odpovědnost při rozhodování o tom, zda se o mimořádně nízkou nabídkovou cenu jedná a jak při zjištění (nezdůvodněné) mimořádně nízké ceny postupovat.«.

294.     Zadavatel, resp. hodnoticí komise, má ve vztahu k MNNC dvě povinnosti: povinnost posoudit, zda konkrétní nabídka neobsahuje MNNC, a v případě kladného zjištění povinnost vyžádat si od účastníka písemné zdůvodnění způsobu stanovení ceny včetně potvrzení, že účastník bude dodržovat právní povinnosti a že neobdržel neoprávněnou veřejnou podporu (blíže viz § 113 odst. 4 zákona).

295.     V šetřeném případě z protokolu č. 1 vyplývá, že hodnoticí komise v nabídce vybraného dodavatele identifikovala přítomnost MNNC, neboť nabídková cena vybraného dodavatele je výrazně nižší než nabídková cena ostatních účastníků zadávacího řízení. S ohledem na uvedené zadavatel dne 16. 6. 2021 vybraného dodavatele vyzval k objasnění MNNC (viz body 143. a 144. odůvodnění tohoto rozhodnutí). Zadavatel vedle žádosti o výslovné potvrzení skutečností dle § 113 odst. 4 zákona, tj. že vybraný dodavatel při plnění veřejné zakázky zajistí dodržování povinností vyplývajících z právních předpisů vztahujících se k předmětu veřejné zakázky, jakož i pracovněprávních předpisů a kolektivních smluv vztahujících se na zaměstnance, kteří se budou podílet na plnění veřejné zakázky, a že neobdržel neoprávněnou veřejnou podporu, vybraného dodavatele s odkazem na ustanovení § 113 odst. 5 zákona vyzval k objasnění MNNC. V žádosti o objasnění zadavatel uvedl, že „Komise považuje za důležité se ujistit, že Vámi nabízené řešení v prvé řadě kvalitativně a funkčně odpovídá zadání a je proveditelné v rámci nabídkové ceny“, přičemž dále zadavatel požadoval osvětlení ekonomické výhodnosti nabízeného řešení, informaci, zda se jedná o proprietární řešení „vyspecifikované“ pro konkrétní poptávku ze strany zadavatele, nebo jestli se jedná o standardizované řešení, které účastník standardně nabízí a realizuje, kromě toho žádal též o objasnění, kde vybraný dodavatel vidí hlavní důvod mimořádně vysoké úspory oproti ostatním konkurenčním řešením; následně zadavatel požadoval detailní rozbor sestavení finanční nabídky v oblasti náročnosti předpokládaných prací (viz bod 142. odůvodnění tohoto rozhodnutí).

296.     Vybraný dodavatel na základě žádosti o objasnění MNNC poskytl zadavateli písemné objasnění MNNC (viz bod 145. odůvodnění tohoto rozhodnutí). V  objasnění MNNC vybraný dodavatel vysvětlil, že pro plnění veřejné zakázky bude použito technické řešení od výrobce TeskaLabs a popsal jeho charakteristiky; dále uvedl, že platforma, která tuto technologii (LogMan.io) pohání, je složena z renomovaných open-source nástrojů, ke kterým není třeba dokupovat licence od třetích stran a že výrobce, spol. TeskaLabs, disponuje zkušeným týmem specialistů, kteří umí všechny použité open-source komponenty efektivně provozovat a spravovat, což umožňuje výrobci stanovovat ceny pro produkt LogMan.io v podstatě lineárním způsobem, v přímé závislosti na počtu požadovaných „EPS“. Dále vybraný dodavatel uvedl, že cena licence nástroje TeskaLabs LogMan.io byla stanovena dle platného ceníku společnosti TeskaLabs. Následně vybraný dodavatel popsal skutečnosti, v nichž shledává nejvýraznější důvod pro mimořádně vysoké úspory oproti konkurenčním řešením. Vybraný dodavatel taktéž uvedl cenový rozbor ceny licence a ceny realizace. Z objasnění MNNC dále plyne, že vybraný dodavatel považuje předmět veřejné zakázky za standardní dodávku, velmi podobnou předchozím úspěšným dodávkám produktu LogMan.io pro zákazníky podobné velikosti, jako je zadavatel. Vybraný dodavatel též popsal, jaká rizika při tvorbě nabídky vyhodnocoval. K otázce „rozložení prací“ mezi vybraným dodavatelem a zadavatelem pak vybraný dodavatel uvedl, že při implementaci nepředpokládá žádné odborné práce ze strany zadavatele a dodávka předmětu plnění bude v podstatě „na klíč“, jak požaduje zadavatel. Vybraný dodavatel zmínil též široké možnosti konfigurace technického řešení spol. TeskaLabs a jejich zacílení pro korporátní trhy vyžadující vysokou míru přizpůsobitelnosti produktu „na míru“ zákazníka. Závěrem vybraný dodavatel potvrdil, že při plnění veřejné zakázky zajistí dodržování povinností vyplývajících z právních předpisů vztahujících se k předmětu veřejné zakázky, jakož i pracovněprávních předpisů a kolektivních smluv vztahujících se na zaměstnance, kteří se budou podílet na plnění veřejné zakázky, a dále, že neobdržel neoprávněnou veřejnou podporu (viz bod 145. odůvodnění tohoto rozhodnutí). Z odpovědi vybraného dodavatele tedy vyplývá, že zadavateli poskytl odpovědi na jeho otázky (viz bod 295. odůvodnění tohoto rozhodnutí), a to včetně potvrzení skutečností dle § 113 odst. 4 zákona (viz bod 145. odůvodnění tohoto rozhodnutí). 

297.     Úřad tedy rekapituluje, že zadavatel MNNC v nabídce vybraného dodavatele identifikoval (o tomto svém kroku pak učinil záznam v protokolu č. 1 a č. 2, viz body 142. a 146. odůvodnění tohoto rozhodnutí), a vznikla mu tedy povinnost vyzvat vybraného dodavatele k písemnému zdůvodnění MNNC a k potvrzení skutečností dle § 113 odst. 4 písm. a) a b) zákona. Z dokumentace o zadávacím řízení vyplývá, že zadavatel tuto svou povinnost splnil. Z dokumentace o zadávacím řízení dále vyplývá, že zadavatel doručené objasnění nabídky vybraného dodavatele posoudil a došel k závěru, že vybraný dodavatel MNNC ve své nabídce dostatečně objasnil, přičemž i potvrdil skutečnosti dle § 113 odst. 4 písm. a) a b) zákona. Úřad uvádí, že z objasnění nabídky opravdu vyplývá, že vybraný dodavatel potvrdil skutečnosti dle § 113 odst. 4 písm. a) a b) zákona, přičemž současně z dokumentace o zadávacím řízení neplyne, že by byl dán některý z dalších obligatorních důvodů vyloučení dle § 113 odst. 6 zákona.  

298.     S ohledem na výše uvedené Úřad uzavírá, že zadavatel při posouzení MNNC vybraného dodavatele z hlediska MNNC postupoval v souladu se zákonem, když si po jejím zjištění vyžádal od vybraného dodavatele její objasnění. I následný postup zadavatele, kdy vybraného dodavatele nevyloučil, je souladný se zákonem, neboť nebyl dán žádný z obligatorních důvodů vyloučení dle § 113 odst. 6 zákona.

Závěr

299.     Na základě shora popsaných skutečností Úřad dospěl k závěru, že nabídka vybraného dodavatele, resp. jím nabídnutý nástroj splňuje technické požadavky zadavatele uvedené
v části označené jako „Požadavky na nástroj pro Log Management“ přílohy č. 1 smlouvy. Úřad současně dospěl k závěru, že zadavatel při posouzení MNNC v nabídce vybraného dodavatele postupoval v souladu se zákonem. Úřad tedy v šetřeném případě neshledal důvody pro uložení nápravného opatření, a proto podle § 265 písm. a) zákona rozhodl o zamítnutí návrhu navrhovatele tak, jak je uvedeno ve výroku II. tohoto rozhodnutí.

Poučení

Proti tomuto rozhodnutí lze do 15 dnů ode dne jeho doručení podat rozklad k předsedovi Úřadu pro ochranu hospodářské soutěže, a to prostřednictvím Úřadu pro ochranu hospodářské soutěže - Sekce veřejných zakázek, třída Kpt. Jaroše 1926/7, Černá Pole, 604 55 Brno. Rozklad proti výroku I. tohoto rozhodnutí nemá podle § 76 odst. 5 zákona č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů, odkladný účinek. Včas podaný rozklad proti výroku II. tohoto rozhodnutí má odkladný účinek. Rozklad a další podání účastníků učiněná v řízení o rozkladu se podle § 261 odst. 1 písm. b) zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, zasílají Úřadu výhradně prostřednictvím datové schránky nebo jako datová zpráva podepsaná uznávaným elektronickým podpisem.

 

otisk úředního razítka

 

v z. Mgr. Michal Kobza

 

Mgr. Markéta Dlouhá

místopředsedkyně

 

 

 

Obdrží

1.      Česká pošta, s.p., Politických vězňů 909/4, 225 99 Praha 1

2.      ATS-TELCOM PRAHA a.s., Nad elektrárnou 1526/45, 106 00 Praha 10

3.      JUDr. Jindřich Jašek, Koliště 259/55, 602 00 Brno

 

Vypraveno dne

viz otisk razítka na poštovní obálce nebo časový údaj na obálce datové zprávy