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.
39
Č.j.: ÚOHS-46448/2022/510
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
40
Č.j.: ÚOHS-46448/2022/510
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 (emailem) 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)
41
Č.j.: ÚOHS-46448/2022/510
•
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 Syslog4, Parsování Apache HTTP Server build-in preprocessor5, 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-Lang6 deklarativního enricheru
s využitím ECS schématu7 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 Highperformance parser (SP-Lang) spolu s některým univerzálním kolektorem (file, TCP, UDP),
pokud výrobce neurčí jinak.
4
viz https://docs.teskalabs.com/logman.io/collector/inputs
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
6
viz https://docs.teskalabs.com/logman.io/reference/declarative
7
viz https://www.elastic.co/guide/en/ecs/current/index.html
5
42
Č.j.: ÚOHS-46448/2022/510
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-file8, Parsování - Apache HTTP Server build-in
preprocessor9, 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 logu10.
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-Lang11 deklarativního enricheru
s využitím ECS schématu12 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 Highperformance 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 Syslog13, Parsování - CEF built-in
preprocessor14, Normalizace – ECS Schema.
8
viz https://docs.teskalabs.com/logman.io/collector/inputs
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
10
viz https://tomcat.apache.org/tomcat-8.5-doc/logging.html
11
viz https://docs.teskalabs.com/logman.io/reference/declarative
12
viz https://www.elastic.co/guide/en/ecs/current/index.html
13
viz https://docs.teskalabs.com/logman.io/collector/inputs
14
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
9
43
Č.j.: ÚOHS-46448/2022/510
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-Lang15 deklarativního enricheru
s využitím ECS schématu16 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 Highperformance 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/arcsightcef-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 ingestor17, Parsování - Apache HTTP Server build-in
preprocessor18, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu19.
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-Lang20 deklarativního enricheru
s využitím ECS schématu21 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 Highperformance 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.“
15
viz https://docs.teskalabs.com/logman.io/reference/declarative
viz https://www.elastic.co/guide/en/ecs/current/index.html
17
viz https://docs.teskalabs.com/logman.io/architecture
18
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
19
viz https://docs.broadcom.com/doc/FOS-90x-Admin-AG
20
viz https://docs.teskalabs.com/logman.io/reference/declarative
21
viz https://www.elastic.co/guide/en/ecs/current/index.html
16
44
Č.j.: ÚOHS-46448/2022/510
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-fabricappliances«
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 ingestor22, Parsování - Apache HTTP Server build-in
preprocessor23, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu24.
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-Lang25 deklarativního enricheru
s využitím ECS schématu26 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 Highperformance 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-securitvappliances/63884-config-asa-OO.html«
22
viz https://docs.teskalabs.com/logman.io/architecture
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
24
viz https://www.cisco.com/c/en/us/support/docs/security/pix-500-series-security-appliances/63884-config-asa00.html#anc6
25
viz https://docs.teskalabs.com/logman.io/reference/declarative
26
viz https://www.elastic.co/guide/en/ecs/current/index.html
23
45
Č.j.: ÚOHS-46448/2022/510
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 ingestor27, Parsování - Apache HTTP Server build-in
preprocessor28, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu29.
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-Lang30 deklarativního enricheru
s využitím ECS schématu31 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 Highperformance 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-firepowerfirewalls.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 ingestor32, Parsování - Apache HTTP Server build-in
preprocessor33, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu34.
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-Lang35 deklarativního enricheru
27
viz https://docs.teskalabs.com/logman.io/architecture
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
29
Viz https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/200479-Configure-Logging-on-FTD-viaFMC.html#anc6
30
viz https://docs.teskalabs.com/logman.io/reference/declarative
31
viz https://www.elastic.co/guide/en/ecs/current/index.html
32
viz https://docs.teskalabs.com/logman.io/architecture
33
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
34
viz https://community.cisco.com/t5/networking-documents/how-to-configure-logging-in-cisco-ios/ta-p/3132434
35
viz https://docs.teskalabs.com/logman.io/reference/declarative
28
46
Č.j.: ÚOHS-46448/2022/510
s využitím ECS schématu36 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 Highperformance 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 ingestor37, Parsování - Apache HTTP Server build-in
preprocessor38, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu39.
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-Lang40 deklarativního enricheru
s využitím ECS schématu41 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.“
znalec ve 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ů
36
viz https://www.elastic.co/guide/en/ecs/current/index.html
viz https://docs.teskalabs.com/logman.io/architecture
38
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
39
viz
https://www.cisco.com/c/en/us/support/docs/smb/switches/cisco-small-business-200-series-managedswitches/smb104-manage-system-logs-on-the-200-300-series-managed-switches.html
40
viz https://docs.teskalabs.com/logman.io/reference/declarative
41
viz https://www.elastic.co/guide/en/ecs/current/index.html
37
47
Č.j.: ÚOHS-46448/2022/510
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 ingestor42, Parsování - Apache HTTP Server build-in
preprocessor43, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu44.
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-Lang45 deklarativního enricheru s využitím ECS
schématu46 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-lancontrollers/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 ingestor47, Parsování - Apache HTTP Server build-in
preprocessor48, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu49.
42
viz https://docs.teskalabs.com/logman.io/architecture
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
44
viz
https://www.cisco.com/c/en/us/support/docs/wireless/4100-series-wireless-lan-controllers/107252-WLCSyslog-Server.html
45
viz https://docs.teskalabs.com/logman.io/reference/declarative
46
viz https://www.elastic.co/guide/en/ecs/current/index.html
47
viz https://docs.teskalabs.com/logman.io/architecture
48
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
49
viz https://www.manualslib.com/manual/546491/Dell-Force10-S2410-01-10ge-24p.html?page=107
43
48
Č.j.: ÚOHS-46448/2022/510
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-Lang50 deklarativního enricheru s využitím ECS
schématu51 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-os9nastaven%C3%AD-aspr%C3%Alva-p%C5%99ihla%C5%Alov%C3%Aln%C3%AD-vp%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 ingestor52, Parsování - Apache HTTP Server build-in
preprocessor53, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu54.
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-Lang55 deklarativního enricheru s využitím ECS
schématu56 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.“
50
viz https://docs.teskalabs.com/logman.io/reference/declarative
viz https://www.elastic.co/guide/en/ecs/current/index.html
52
viz https://docs.teskalabs.com/logman.io/architecture
53
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
54
viz https://support.f5.com/csp/article/K13080
55
viz https://docs.teskalabs.com/logman.io/reference/declarative
56
viz https://www.elastic.co/guide/en/ecs/current/index.html
51
49
Č.j.: ÚOHS-46448/2022/510
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 ingestor57, Parsování - Apache HTTP Server build-in
preprocessor58, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu59.
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-Lang60 deklarativního enricheru s využitím ECS
schématu61 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
57
viz https://docs.teskalabs.com/logman.io/architecture
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
59
viz https://www.flowmon.com/en/blog/creating-custom-logs-from-netflow
60
viz https://docs.teskalabs.com/logman.io/reference/declarative
61
viz https://www.elastic.co/guide/en/ecs/current/index.html
58
50
Č.j.: ÚOHS-46448/2022/510
Způsob řešení: Sběr - Syslog ingestor62, Parsování - Apache HTTP Server build-in
preprocessor63, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu64.
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-Lang65 deklarativního enricheru s využitím ECS
schématu66 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/appendixb-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 ingestor67, Parsování - Apache HTTP Server build-in
preprocessor68, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu69.
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-Lang70 deklarativního enricheru s využitím ECS
schématu71 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
62
viz https://docs.teskalabs.com/logman.io/architecture
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
64
viz https://help.fortinet.com/fddos/4-7-0/fortiddos/Appendix_B-Remote-Syslog-Reference.htm
65
viz https://docs.teskalabs.com/logman.io/reference/declarative
66
viz https://www.elastic.co/guide/en/ecs/current/index.html
67
viz https://docs.teskalabs.com/logman.io/architecture
68
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
69
viz https://kb.fortinet.com/kb/documentLink.do?externalID=FD44614
70
viz https://docs.teskalabs.com/logman.io/reference/declarative
71
viz https://www.elastic.co/guide/en/ecs/current/index.html
63
51
Č.j.: ÚOHS-46448/2022/510
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/administrationguide/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 ingestor72, Parsování - Apache HTTP Server build-in
preprocessor73, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu74.
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-Lang75 deklarativního enricheru s využitím ECS
schématu76 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.),
72
viz https://docs.teskalabs.com/logman.io/architecture
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
74
viz https://wiki.freeradius.org/guide/Syslog-HOWTO
75
viz https://docs.teskalabs.com/logman.io/reference/declarative
76
viz https://www.elastic.co/guide/en/ecs/current/index.html
73
52
Č.j.: ÚOHS-46448/2022/510
•
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/administrationguide/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 ingestor77, Parsování - Apache HTTP Server build-in
preprocessor78, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu79.
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-Lang80 deklarativního enricheru s využitím ECS
schématu81 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 ingestor82, Parsování - Apache HTTP Server build-in
preprocessor83, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu84.
77
viz https://docs.teskalabs.com/logman.io/architecture
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
79
viz https://www.greycortex.com/blog/review-greycortex-mendel
80
viz https://docs.teskalabs.com/logman.io/reference/declarative
81
viz https://www.elastic.co/guide/en/ecs/current/index.html
82
viz https://docs.teskalabs.com/logman.io/architecture
83
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
84
viz https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00045612en_us
78
53
Č.j.: ÚOHS-46448/2022/510
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-Lang85 deklarativního enricheru s využitím ECS
schématu86 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 ingestor87, Parsování - Apache HTTP Server build-in
preprocessor88, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu89.
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-Lang90 deklarativního enricheru s využitím ECS
schématu91 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.“,
k otázce č. 19 ve znění:
85
viz https://docs.teskalabs.com/logman.io/reference/declarative
viz https://www.elastic.co/guide/en/ecs/current/index.html
87
viz https://docs.teskalabs.com/logman.io/architecture
88
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
86
89
viz
https://sc1.checkpoint.com/documents/R80.40/WebAdminGuides/EN/CP_R80.40_LoggingAndMonitoring_AdminGui
de/Topics-LMG/Working-with-Syslog-Servers.htm
90
viz https://docs.teskalabs.com/logman.io/reference/declarative
91
viz https://www.elastic.co/guide/en/ecs/current/index.html
54
Č.j.: ÚOHS-46448/2022/510
„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z JSON (format)
Způsob řešení: Sběr - Collector, smart-file92, Parsování - JSON built-in preprocessor93,
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-Lang94 deklarativního enricheru s využitím ECS
schématu95 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.“,
k otá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 ingestor96, Parsování - Apache HTTP Server build-in
preprocessor97, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu98.
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-Lang99 deklarativního enricheru s využitím ECS
schématu100 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.“,
k otázce č. 21 ve znění:
„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z Kernun web
filter
92
viz https://docs.teskalabs.com/logman.io/collector/inputs
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
94
viz https://docs.teskalabs.com/logman.io/reference/declarative
95
viz https://www.elastic.co/guide/en/ecs/current/index.html
96
viz https://docs.teskalabs.com/logman.io/architecture
97
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
98
viz https://download.kernun.com/doc/handbook/index.html
99
viz https://docs.teskalabs.com/logman.io/reference/declarative
100
viz https://www.elastic.co/guide/en/ecs/current/index.html
93
55
Č.j.: ÚOHS-46448/2022/510
Způsob řešení: Sběr - Syslog ingestor101, Parsování - Apache HTTP Server build-in
preprocessor102, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu103.
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-Lang104 deklarativního enricheru s využitím ECS
schématu105 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.“,
k otá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 ingestor106, Parsování - Apache HTTP Server build-in
preprocessor107, 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-Lang108 deklarativního enricheru s využitím ECS
schématu109 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.“,
k otá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 ingestor110, Parsování - Apache HTTP Server build-in
preprocessor111, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu112.
101
viz https://docs.teskalabs.com/logman.io/architecture
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
103
viz https://download.kernun.com/doc/handbook/index.html
104
viz https://docs.teskalabs.com/logman.io/reference/declarative
105
viz https://www.elastic.co/guide/en/ecs/current/index.html
106
viz https://docs.teskalabs.com/logman.io/architecture
107
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
108
viz https://docs.teskalabs.com/logman.io/reference/declarative
109
viz https://www.elastic.co/guide/en/ecs/current/index.html
110
viz https://docs.teskalabs.com/logman.io/architecture
111
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
112
viz https://wiki.freeradius.org/guide/Syslog-HOWTO
102
56
Č.j.: ÚOHS-46448/2022/510
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-Lang113 deklarativního enricheru s využitím ECS
schématu114 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.“,
k otá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 ingestor115, Parsování - Apache HTTP Server build-in
preprocessor116, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu117.
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-Lang118 deklarativního enricheru s využitím ECS
schématu119 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.“,
k otá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 ingestor120, Parsování - Apache HTTP Server build-in
preprocessor121, Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na
dokumentaci výrobce zdroje logu122.
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-Lang123 deklarativního enricheru s využitím ECS
schématu124 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
113
viz https://docs.teskalabs.com/logman.io/reference/declarative
viz https://www.elastic.co/guide/en/ecs/current/index.html
115
viz https://docs.teskalabs.com/logman.io/architecture
116
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
117
viz https://access.redhat.com/solutions/400733
118
viz https://docs.teskalabs.com/logman.io/reference/declarative
119
viz https://www.elastic.co/guide/en/ecs/current/index.html
120
viz https://docs.teskalabs.com/logman.io/architecture
121
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
122
viz https://logtail.com/tutorials/how-to-start-logging-with-postfix/
123
viz https://docs.teskalabs.com/logman.io/reference/declarative
124
viz https://www.elastic.co/guide/en/ecs/current/index.html
114
57
Č.j.: ÚOHS-46448/2022/510
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-file125, Parsování - High-performance parser (SPLang)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-Lang127 deklarativního enricheru s využitím ECS
schématu128 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-file129, Parsování - Microsoft ULS built-in preprocessor130,
Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce
zdroje logu131.
125
viz https://docs.teskalabs.com/logman.io/collector/inputs
viz https://docs.teskalabs.com/logman.io/parser/high-performance-parsing
127
viz https://docs.teskalabs.com/logman.io/reference/declarative
128
viz https://www.elastic.co/guide/en/ecs/current/index.html
129
viz https://docs.teskalabs.com/logman.io/collector/inputs
130
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
131
viz https://blog.machsol.com/microsoft-sharepoint/sharepoint-unified-logging-system-uls
126
58
Č.j.: ÚOHS-46448/2022/510
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-Lang132 deklarativního enricheru s využitím ECS
schématu133 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 collector134, Parsování - Microsoft ULS built-in preprocessor135,
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-Lang136 deklarativního enricheru s využitím ECS
schématu137 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 collector138, Parsování - Microsoft ULS built-in preprocessor139,
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-Lang140 deklarativního enricheru s využitím ECS
schématu141 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
132
viz https://docs.teskalabs.com/logman.io/reference/declarative
viz https://www.elastic.co/guide/en/ecs/current/index.html
134
viz https://docs.teskalabs.com/logman.io/collector/wec
135
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
136
viz https://docs.teskalabs.com/logman.io/reference/declarative
137
viz https://www.elastic.co/guide/en/ecs/current/index.html
138
viz https://docs.teskalabs.com/logman.io/collector/wec
139
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
140
viz https://docs.teskalabs.com/logman.io/reference/declarative
141
viz https://www.elastic.co/guide/en/ecs/current/index.html
133
59
Č.j.: ÚOHS-46448/2022/510
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 collector142, Parsování - W3C build-in preprocessor143, 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-Lang144 deklarativního enricheru s využitím ECS
schématu145 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-file146, Parsování - W3C build-in preprocessor147,
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-Lang148 deklarativního enricheru s využitím ECS
schématu149 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í:
142
viz https://docs.teskalabs.com/logman.io/collector/wec
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
144
viz https://docs.teskalabs.com/logman.io/reference/declarative
145
viz https://www.elastic.co/guide/en/ecs/current/index.html
146
viz https://docs.teskalabs.com/logman.io/collector/inputs
147
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
148
viz https://docs.teskalabs.com/logman.io/reference/declarative
149
viz https://www.elastic.co/guide/en/ecs/current/index.html
143
60
Č.j.: ÚOHS-46448/2022/510
„Požadavek zadavatele: Nástroj podporuje sběr, parsování a normalizaci logů z MS Active
Directory
Způsob řešení: Sběr - WEC collector150, 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-Lang152 deklarativního enricheru s využitím ECS
schématu153 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 (SPLang) 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-Lang155 deklarativního enricheru s využitím ECS
schématu156 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.
150
viz https://docs.teskalabs.com/logman.io/collector/wec
viz https://docs.teskalabs.com/logman.io/parser/high-performance-parsing
152
viz https://docs.teskalabs.com/logman.io/reference/declarative
153
viz https://www.elastic.co/guide/en/ecs/current/index.html
154
viz https://docs.teskalabs.com/logman.io/parser/high-performance-parsing
155
viz https://docs.teskalabs.com/logman.io/reference/declarative
156
viz https://www.elastic.co/guide/en/ecs/current/index.html
157
viz https://docs.teskalabs.com/logman.io/parser/high-performance-parsing
151
61
Č.j.: ÚOHS-46448/2022/510
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-Lang158 deklarativního enricheru s využitím ECS
schématu159 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 ingestor160, Parsování - Syslog built-in preprocessor161,
Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce
zdroje logu162.
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-Lang163 deklarativního enricheru s využitím ECS
schématu164 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.“
158
viz https://docs.teskalabs.com/logman.io/reference/declarative
viz https://www.elastic.co/guide/en/ecs/current/index.html
160
viz https://docs.teskalabs.com/logman.io/architecture
161
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
162
viz https://dev.mysql.com/doc/refman/5.7/en/error-log-syslog.html
163
viz https://docs.teskalabs.com/logman.io/reference/declarative
164
viz https://www.elastic.co/guide/en/ecs/current/index.html
159
62
Č.j.: ÚOHS-46448/2022/510
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 ingestor165, Parsování - Syslog built-in preprocessor166,
Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce
zdroje logu167.
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-Lang168 deklarativního enricheru s využitím ECS
schématu169 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 ingestor170, Parsování - Syslog built-in preprocessor171,
Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce
zdroje logu172.
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-Lang173 deklarativního enricheru s využitím ECS
schématu174 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
165
viz https://docs.teskalabs.com/logman.io/architecture
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
167
viz https://en.wikibooks.org/wiki/OpenSSH/Logging_and_Troubleshooting
168
viz https://docs.teskalabs.com/logman.io/reference/declarative
169
viz https://www.elastic.co/guide/en/ecs/current/index.html
170
viz https://docs.teskalabs.com/logman.io/architecture
171
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
172
viz https://community.oracle.com/tech/developers/discussion/2579616/how-to-send-autdit-log-to-syslog
173
viz https://docs.teskalabs.com/logman.io/reference/declarative
174
viz https://www.elastic.co/guide/en/ecs/current/index.html
166
63
Č.j.: ÚOHS-46448/2022/510
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 ingestor175, Parsování - Syslog built-in preprocessor176,
Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce
zdroje logu177.
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-Lang178 deklarativního enricheru s využitím ECS
schématu179 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.),
175
viz https://docs.teskalabs.com/logman.io/architecture
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
177
viz https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-admin/monitoring/use-syslog-for-monitoring/configuresyslog-monitoring
178
viz https://docs.teskalabs.com/logman.io/reference/declarative
179
viz https://www.elastic.co/guide/en/ecs/current/index.html
176
64
Č.j.: ÚOHS-46448/2022/510
•
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-svslogfor-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 ingestor180, Parsování - Syslog built-in preprocessor181,
Normalizace – ECS Schema. Dále k tomu vybraný dodavatel odkázal na dokumentaci výrobce
zdroje logu182.
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-Lang183 deklarativního enricheru s využitím ECS
schématu184 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-svslogfor-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-file185, Parsování - High-performance parser (SPLang)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.
180
viz https://docs.teskalabs.com/logman.io/architecture
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
182
viz https://www.postgresql.org/docs/9.5/runtime-config-logging.html
183
viz https://docs.teskalabs.com/logman.io/reference/declarative
184
viz https://www.elastic.co/guide/en/ecs/current/index.html
185
viz https://docs.teskalabs.com/logman.io/collector/inputs
186
viz https://docs.teskalabs.com/logman.io/parser/high-performance-parsing
181
65
Č.j.: ÚOHS-46448/2022/510
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-Lang187 deklarativního enricheru s využitím ECS
schématu188 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, RestAPI189, 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-Lang191 deklarativního enricheru s využitím ECS
schématu192 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 collector193, Parsování - Microsoft ULS built-in preprocessor194,
Normalizace – ECS Schema. Dále k tomu vybraný dodavatel uvedl, že zde lze předpokládat, že
187
viz https://docs.teskalabs.com/logman.io/reference/declarative
viz https://www.elastic.co/guide/en/ecs/current/index.html
189
viz https://docs.teskalabs.com/logman.io/collector/inputs
190
viz https://docs.teskalabs.com/logman.io/parser/high-performance-parsing
191
viz https://docs.teskalabs.com/logman.io/reference/declarative
192
viz https://www.elastic.co/guide/en/ecs/current/index.html
193
viz https://docs.teskalabs.com/logman.io/collector/wec
194
viz https://docs.teskalabs.com/logman.io/parser/preprocessor
188
66
Č.j.: ÚOHS-46448/2022/510
WEF/WEC bude posílat i jiné, než ULS logy. Pro ně se použije high-performance parser (SPLang).
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-Lang195 deklarativního enricheru s využitím ECS
schématu196 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, file197, Parsování - High-performance parser (SPLang)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-Lang199 deklarativního enricheru s využitím ECS
schématu200 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)«.
195
viz https://docs.teskalabs.com/logman.io/reference/declarative
viz https://www.elastic.co/guide/en/ecs/current/index.html
197
viz https://docs.teskalabs.com/logman.io/collector/inputs
198
viz https://docs.teskalabs.com/logman.io/parser/high-performance-parsing
199
viz https://docs.teskalabs.com/logman.io/reference/declarative
200
viz https://www.elastic.co/guide/en/ecs/current/index.html
196
67
Č.j.: ÚOHS-46448/2022/510
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ů:
68
Č.j.: ÚOHS-46448/2022/510
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ástroje201.
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.
201
viz https://docs.teskalabs.com/logman.io/webui/how-to-use-the-logman-interface
69
Č.j.: ÚOHS-46448/2022/510
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é.
70
Č.j.: ÚOHS-46448/2022/510
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.
71
Č.j.: ÚOHS-46448/2022/510
•
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).
72
Č.j.: ÚOHS-46448/2022/510
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 zde202.
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ů,
202
viz https://www.elastic.co/guide/en/elasticsearch/reference/current/index-lifecycle-management.html
73
Č.j.: ÚOHS-46448/2022/510
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í
74
Č.j.: ÚOHS-46448/2022/510
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ů
203
204
viz https://docs.teskalabs.com/logman.io/reference/commander
viz. architektura produktu https://docs.teskalabs.com/logman.io/architecture
75
Č.j.: ÚOHS-46448/2022/510
přijímaných logů. Příklad jednoho z opatření v LogMan.io pro integritu uložených dat je např.
zde205.
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.
205
viz https://github.com/LibertyAces/BitSwanPump/blob/master/bspump/integrity/integrityenricher.py
76
Č.j.: ÚOHS-46448/2022/510
[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-Lang206.
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ž
206
viz https://docs.teskala bs.com/logman.io/reference/declarative
77
Č.j.: ÚOHS-46448/2022/510
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 zde207.
207
viz. https://www.elastic.co/guide/en/kibana/current/lens.html
78
Č.j.: ÚOHS-46448/2022/510
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]
79
Č.j.: ÚOHS-46448/2022/510
•
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
80
Č.j.: ÚOHS-46448/2022/510
•
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 zde208.
Příklad exportu do CSV v Kibaně:
208
viz. https://www.elastic.co/guide/en/kibana/7.x/reporting-getting-started.html
81
Č.j.: ÚOHS-46448/2022/510
[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
82
Č.j.: ÚOHS-46448/2022/510
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“.
83
Č.j.: ÚOHS-46448/2022/510
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ě X209 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
209
Pozn. Úřadu: U každého jednotlivého požadavku bylo odkazováno právě na tento požadavek.
84
Č.j.: ÚOHS-46448/2022/510
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
85
Č.j.: ÚOHS-46448/2022/510
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í).
86
Č.j.: ÚOHS-46448/2022/510
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í