Upozornění: Text přílohy byl získán strojově a nemusí přesně odpovídat originálu. Zejména u strojově nečitelných smluv, kde jsme použili OCR. originál smlouvy stáhnete odsud
w ¡ ¢ £¤¥¦§ ¨©
20.08.2021 10:22:55
2021/0896/ICT
KUPNÍ SMLOUVA
(dále jen „smlouva“)
Dodávka systému pro záznam událostí
Kladno
se sídlem: nám Starosty Pavla 44, 272 52 Kladno
Ing. , primátora
00234516
CZ00234516
(dále jen jako „kupující“)
CompuNet s.r.o. a
zapsaný:
se sídlem: v OR u MS v Praze, oddíl C, vložka 118594
Zubatého 295/5, 150 00 Praha 5
bankovní spojení:
jednatelem
276 08 514
CZ 276 08 514
Komerční banka a.s.
Kontaktní osoba: Martin Pokorný
Email:
Telefon:
(dále jen „prodávající“)
Preambule
Tuto smlouv s prodávajícím
s názvem „Dodávka systému pro záznam událostí“ Zadávací dokumentace k výše
jako vybraným
prodávajícím
jednotlivých ustanovení smlouvy. Prodávající
zadávací podmínky kupujícího stanovené v zadávací dokumentaci nim
žádné výhrady.
I. P smlouvy
1. Prodávající se touto smlouvou zavazuje, a umožní nabýt kupujícímu k P
v P
smlouvy.
42231135543221........NKMpkszjbFSBZnSspM6PTeouuramua0ráecmraoííopdoplszhscrldvltutdtvthPuiáeuián-vánjnvreívpcvniceinaaíaýsjkojsmsjJo–cktcrkríoír(mí„afrsdzdzgds2pnáaulkpoz,ed6ot.ueýylv3Meá0žjcvnoíáa8ivceBajbfant0aá-deuvhAkdmýIk6jsaiVreo„ž7o:j,.bfduíz5ihelsapoh:joíkepm-nPpootdhuaallljnykrenbt3ab,yvdi“u0bž)nv.ížvzdoIríympkus.asdyretkCoetaváIšp,dpyv.kopáheanMjeváonjrkaíéíctýsunímpé(cndejrleuváárljolszíeeuk.mavžujibplctouondasýají„víšcknpcyieaoPh.1mpvldok.vé9.mdd6pvl7íeánuy5csaz0ye-ítáken,oa-ocb“nh).vanliahsketévznpaílDotssPttávmyHrk,šzllo,denae4ucádn1vhvyýay3nom,ú.vydpksy7sluttne5.ktjáer,2u-áldežKnižojínčávihdíášo.aníeastmkt,íi
4.
V. Záruka za jakost je nové, nepoužívané a
1. Prodávající prohlašuje, že dodané zboží ží není
kupujícího proti písemnému potvrzení. záruku za jakost v délce
2. Prodávající poskytuje na zboží .
prodávající zavazuje, že zboží bu
3. a pro
ávazku bude
považováno za podstatné porušení smluvní povinnosti s právem kupujícího odstoupit od
smlouvy.
VI. Práva a povinnosti smluvních stran
1. K
kupující .
2. K souladu s touto
smlouvou.
3. P souladu
s souladu s touto smlouvou. Dále je povinen nejednat
v rozporu s
kupující
4. Prodávající je povinen zajistit, ab prodávajícímu nebo jsou k prodávajícímu
jsou v -li taková osoba jakékoliv
.
ustanovení této smlouvy,
5.
zejm.:
a)
bylo kupujícímu odevzdáno nahrazované zboží, a
b) -li mezi prodávajícím
kupujícímu odevzdáno, a po provedení opravy opraven
a kupujícím dohodnuto jinak.
6. Prodávající je
provozních možností kupujícího.
7. Reklamované vady se prodávající zavazuje odstranit v soulad
8. ostí
VII. za každý
1. Bude - li prodávající v prodlení s odevzdáním zboží nebo s
prodávající povinen zaplatit kupujícímu smluvní pokutu ve výši 1.000,-
(i
2. Bude-li kupující v prodlení s
na kupujícím úhradu smluvní pokuty ve výši 0,1 % z
3.
1. Prodávajíc VIII. Prohlášení smluvních stran
2. okamžiku dodání váznout žádné
práva kupujícího.
3.
4. touto smlouvou smluvní strany uzavírají tzv. Non Disclosure Agreement (NDA),
které se strany v
IX.
1. Smlouva nabývá platnosti dnem jejího podpisu
registru smluv.
2. Tato s
-
IPP4783659ZVIjnen....aaiPdgkgvpwpSkzPvSPT.rh.aáuaeoPammrresozaáoktdtlbdellovdrovuálnntájsuvevívcnniýajaecj.lz1íjok)h.:íicbPD2D…,zkcsu,a13iyaitskphShgt:rth0hItiaenra–opmt4aya:agárj:rož24lnTt.tlleny0y0Puoesv2vaks+vt1prvcivég0nz.ei0h2nluí8oo'hez0.js1d0ui2si'cwrtl,jaíužásdšvreváiaesoýnn.pplbmm,eonsmižcsítcpikúifíoy.d(k4tpdsaaneojulesetléypejnndrozoons.dpícáázizbsmvenacíiljscyíhúehdk)h.acopo.Zjieb…OpaastunkIuvnuhzrgpeaedmííkcjoíncr…étjiéhegvon…:pásrluismmm,dzáao…yttokvliyuc…ahž n3eísrmotujnh zpaispvyíorodbljédhnažt
….
- Příloha č.1 - Technická specifikace Předmětu koupě
Předmět zakázky:
Navrhnout, dodat a implementovat centrální úložiště pro sběr a analýzu logů (SEM/SIEM řešení)
s možností následné analýzy a řešení bezpečnostních událostí/incidentů z kritických systémů a
aplikací. Navržený systém musí zachovávat originál logů za účelem bezpečnostního auditu a
umožňovat splnění legislativních norem a požadavků, zejména pak doložením souladu
nabízeného systému s požadavky ISO/ČSN 27001:2013 pro pořizování auditních záznamů.
Systém musí být schopen shromáždit provozní data ze všech důležitých systémů na jednom
místě a dlouhodobě je uchovávat. Tímto operátor IT/Bezpečnosti dostane možnost zjistit
informace o bezpečnostních incidentech, provozních stavech a případných závadách v IT
v reálném čase ii v pohledu do minulosti nejméně jeden rok zpět. Toto úložiště musí být schopné
generovat reporty o aktivitách systémů ii uživatelů, včetně auditních reportů na vyžádání, nebo se
stanovenou periodicitou s definovatelným obsahem, a to bez nutnosti používat SQL syntaxi.
Nutností je možnost procházení těchto logů integrovaným grafickým rozhraním s
předdefinovanými pravidly pro rychlé vyhledávání (např. jako jsou změny v systémech provedené
administrátory; seznam nově vytvořených účtů v MS AD a Office365 za zvolenou periodu; změny
v přístupových právech pro zadaného uživatele nebo k zadané složce; monitoring privilegovaných
účtů, sdílených účtů a změn konfigurací; sledování souborových systémů apod.) Dále musí
systém umožňovat sledovat chování uživatelů a systémů s možností upozorňování na překročení
pravidel, a to na základě limitů nebo korelací událostí stanovených administrátorem systému.
Cílem je mít jednotné úložiště logů s pokročilými nástroji analýzy a upozorňování, ke kterému
budou mít přístup pouze autorizovaní pracovníci zadavatele. Nezbytnou nutností je vyloučit
možnost modifikace logů ze strany administrátorů nebo uživatelů. Systém musí dále umožňovat
snadnou klasifikaci dat, tvorbu uživatelsky definovaných parserů, filtrů, upozornění a korelací bez
účasti výrobce nebo dodavatele ve snadno pochopitelném grafickém rozhraní bez nutnosti
používat znalostí programátora. Dokumentace musí poskytnout jednoznačný návod, jak takovéto
činnosti provádět, a to včetně široké škály vzorových příkladů.
Zálohování konfigurace ii dat a jejich obnova je nezbytnou nutností, kterou musí dodaný systém
podporovat. Protože není předem známo přesné množství logů vznikajících v naší organizaci,
požadujeme, aby dodaný systém podporoval plánované ii ad-hoc zálohování vzniklých dat na
externí zálohovací systém, optimálně za využití SMB protokolu. Zálohováním dat na externí
- systém musí umožnit dosáhnout požadavku na délku uložení logovaných událostí po dobu
minimálně 18 měsíců - dle "Bezpečnostního doporučení NCKB pro Administrátory 4.0". Platí
však, že požadujeme, aby systém umožňoval on-line zobrazit hodnoty nad všemi interně
uloženými daty za libovolné časové období bez nutnosti nejprve modifikovat konfiguraci systému
nebo parametrů uložených dat.
Součástí dodávky musí být úplná a podrobná dokumentace systému v češtině. Ne všichni naši
administrátoři a budoucí operátoři systému dokonale ovládají angličtinu, proto požadujeme, aby
součástí dodávky byla ii dokumentace v českém jazyce, obsahem ii kvalitou srovnatelná ss aktuální
dokumentací v angličtině. Proto v rámci odpovědi na výběrové řízení požadujeme předložit
kompletní dokumentaci k celému systému a poznámky kk vydání (release notes) kk systému ii všem
návazným komponentům. Není přípustné předložit českou dokumentaci, která bude odkazovat do
dokumentace, která bude v jiném jazyce, než je čeština. Dodaný systém plánujeme provozovat
vlastními lidskými zdroji, proto by nabízený systém měl umožňovat našim pracovníkům IT
provádět základní ii středně pokročilé konfigurace bez nutnosti konzultovat dodavatele nebo
výrobce. Nabízený systém proto musí splňovat očekávané parametry uživatelské přívětivosti a
integrity uživatelského rozhraní a vyhnout se nutnosti používaní skriptů, maker, konfiguraci v
příkazové řádce nebo terminálu. Dále by dokumentace měla poskytnout jednoznačné návody, jak
konfigurovat nejčastější zdrojová zařízení pro spolupráci s nabízeným systémem.
V případě pochybností o vlastnostech nabízeného systému si vyhrazujeme právo vyžádat funkční
vzorek nabízeného řešení pro ověření funkčních vlastností a provést ověřovací testy ještě před
ukončením výběrového řízení. V tomto případě je dodavatel povinen dodat funkční vzorek do 11
týdne od výzvy zadavatele a poskytnout součinnost s testováním. Dále si vyhrazujeme právo
vyžádat kontakty alespoň na 3 referenční zákazníky z našeho sektoru pro účely zjištění
zkušeností s nabízeným systémem.
Systém musí dále umožňovat bezeztrátový sběr a příjem událostí ze zdrojů na pobočkách, a to
vlastním řešením. Toto řešení zamezí ztrátě událostí během přenosu po mnohdy saturovaných a
ne zcela spolehlivých linkách. Realizace sběru a přenosu událostí z poboček do centrálního
úložiště může být realizována jak fyzickým, tak virtuálním řešením. V případě nabídnutí
virtuálního řešení požadujeme systém pro platformu VMware ESXi.
Technická specifikace
Zadavatel vyžaduje, aby nabízené řešení mělo níže požadované funkce již v době podání
nabídky, nikoliv aby se jednalo o budoucí funkce plánovaných verzí software pro nabízené řešení
Nabídnutá
specifikace
(účastník
Číslo Řešení SEM/SIEM do 10000 událostí/s ss minimálně 160TB velikostí databáze přesně popíše,
jak nabízení
zařázení plní
požadovaná
parametry]
Obecné požadavky na systém pro centralizovanou správu logů, událostí a
AM&L&fe strojových dat
Systém pracuje jako hardwarová appliance ss jedním uceleným webovým
&fe
11 rozhraním pro všechny administrátorské ii operátorské činnosti. Nevyžaduje ll/li gri-JLl
instalaci dalších systémů a aplikací, vyjma podpory sběru na pobočkách aa
agenta pro sběr Windows logů. Doložte katalogový list produktu (datasheet) aa,, 34
podrobně popisující hardwarové 11 softwarové parametry nabízeného
systému.
Systém provádí zpracování událostí zz předdefinovaných zdrojů logů napříč AANNOOii
VVTTiiÁÁrrffee 22 výrobci aplikací, operačních systémů a síťového hardware (viz tabulka seznam
podporovaných zařízení).
m Veškerá konfigurace systému se musí provádět v grafickém rozhraní jednotné m
uživatelské webové konzole. Systém poskytuje podporu pro vizuální
33 programování pro všechny kroky zpracování strojových dat. Ve webové §§??LLffll//UUiiffÉÉ
konzoli se nepřipouští konfigurace za využití skriptů, maker nebo textových
konfiguračních polí, do kterých se složité textové skripty/makra vkládají.
Systém umožňuje dopsání parserů pro výše neuvedená zařízení uživatelem AANNOOtt ŠŠPPiiJJuuHHtt
bez nutnosti spolupráce ss výrobcem nebo dodavatelem (vč. subdodavatelů)
nabízeného systému - Uživatelsky definované parsery. Dokumentace musí vvííkk ssrrnn.. </99
obsahovat přehledný návod na vytváření zákaznických parserů aa systém musí
obsahovat možnost testování aa ladění zákaznických parserů v jednotném
4 ovládacím grafickém webovém rozhraní viz bod čč.. 1. Vytváření aa testování
parserů nesmí mít vliv na provoz systému. Pro psaní parserů nesmí být
použito textové psaní programového kódu ale tzv, vizuální programování,
které automaticky opravuje uživatele aa upozorňuje ho na chyby. Požadujeme
předložit příslušnou dokumentaci k vytváření parserů a testování jejich
funkčnosti.
Systém umožňuje v grafickém rozhraní vizuálního programovacího jazyka kkW Wf ffffllwwuuttee
snadno provádět třídění aa značkování vstupních dat pro jejich další
55 zpracování. Neeppřřipouští se nastavování třídění vstupních dat ve formě VV\\hh CCTTLL 0?9
skriptuu/makra zobrazeného v textovém okně. Předložte příslušný odkaz na
dokumentaci popisující funkčnost třídění vstupních dat.
Systém přijímá aa zpracovává logy, události aa další strojově generovaná data
prostřednictvím minimálně následujících protokolů: SYSLOG (dle RFC3164, kkNNQQffttkkMMffcc
RFC5424, RFC5425) aa RREELLPP.. Systém musí umožňovat příjem logů ii na rozsahu
mm.Jbí alespoň 50 UDP aa TCP portů pro zjednodušené třídění vstupních zpráv. Dále mm.Jbí
požadujeme podporu sběru strojových dat zz databází ss nastavením vv
6 grafickém menu systému minimálně pro databáze MSSQL, MySQL, Oracle aa
PostgreSQL aa to bez nutnosti instalovat na databázzoový server doplňkový
software nebo agenta. Předložte detailní komunikační maattrici nabízeného
systému aa dokumentaci kk nastavení sběru zz databází v grafickém rozhraní
systému.
Přijaté logy systém standardizuje do jednotného formátu aa logy jsou
normalizovány (rozdělovány) do příslušných polí dle jejich typu. Zároveň
systém uchovává ii originální verzi zpráv. Integrované parsery systému
77 automaatticky přidávají ke zprávám, kterých ssee to týká, meta informace o jaký
druh zprávy se jedná, minimálně požadujeme rozlišení těchto druhů zpráv:
úspěšné přihlášení, neúspěšné přihlláášení, odhlášení, konfigurační změna,
značka/tag. Tyto meta informace musí být možné přidávat ii v uživatelsky
definovaných parserech.
Hodnoty jednotlivých parsovaných polí je možné v definici parseru přetypovat
aa standardizovat alespoň na tyto základní druhy: číslo, IIPP adresa, MAC adresa,
8 URL Nad uloženými čísly je pak možné při prohledávání dat provádět ŘŘNNOO//ffPPuuvvbbllfftt..
matemaattické operace (součty všech hodnot, průměry, nej menší/neejjvěěttší
hodnota apod.).
Systém zachovává původní informaci ze zdroje logu oo časové značce události,
ale nedůvěřuje jí aa vytváří vlastní důvěryhodné časové razítko ke každému
9 logu, které vzniká v okamžiku přijetí logu systémem a kterým se systém
defaultně řídí.
Všechna pole aa položky přijaté systémem jsou automaatticky indexovány. Nad
10 všemi položkami je možné ihned provádět vyhledávání bez nutnosti
dodatečného ručního indexování administrátorem.
11 Možnost sběru událostí minimálně ve formátech RAW, Syslog RFC5424, CCEEFF,, hhHHQQffttllMMVVtt..
LLEEEEFF,, JSON RFC8259.
Systém nesmí v žádném případě umožnit mazání nebo modifikování již
MMfifuíu B uložených logů v rámci požadované retence. A to ani libovolnou konfiguračníMf V
12 změnou - admmiinistrátorovi ss nejvyššími oprávněními kk navrhovanému
systému. Každý zpracovaný log musí mít dohledatellný unikátní identifikátor,
který umožní jeho jednoznačnou identifikaci.
Systém musí umožňovat konfiguraci filttrraace nerelevaannttních událostí v
grafickém rozhraní vizuálního programovacího jazyka. Pro psaní filttrraace nesmí CCííll..JJjj
13 být použito textová psaní programového kódu ale tzv. vizuální programování,
pp..
které automaatticky opravuje uživatele aa upozorňuje ho na chyby. Předložte
odkaz na dokumentaci popisující způsob filttrroování nerelevaannttních událostí.
14 Systém provádí konsolidacii logů na interním storage logovacího systému.
Systém umožňuje snadné vyhledávání událostí aa okamžité vytváření
grafických reportů (ad hoc) bez nutnosti dodatečného programování nebo
15 aplikování dotazů v SQL jazyce. Reportovací nástroj musí být integrální VVIIll 5TTl.lf.yfsyoučástí
součástí navrhovaného systému aa musí se obsluhovat v jednotném rozhraní
nabízeného produktu. Předložte link nebo pdf popisující způsob vytváření
reportů.
Systém provádí ucelenou vizualizaci logů, událostí aa strojových dat (grafy
ňflOfWmfc 16 událostí). Vizualizace musí být dynamická, tj. volbou v jednom grafu se ostatní ňflOfWmfc
příslušné grafy v pohledu na data upraví dle požadované volby automaatticky.
Systém umožňuje snadno vytvářet grafické znázornění událostí vv
dashboardech nad všemi uloženými daty za libovolné časové období bez
nutnosti nejprve modifikovat konfiguraci systému nebo parameettrů uložených
tolOjSttÁfe 17 dat. Historická data v požadované délce retence uložená v systému je možné tolOjSttÁfe
prohledávat okamžitě bez časových prodlev opětovného importu nebo
dekomprimace starších dat, prohledávání dat nesmí vyžadovat manuální
konfiguraci aa zásahy uživatele.
Systém provádí automatické doplňování reverzních DNS záznamů, čísel aa
18 jmen ASN systému aa geolokace ke všem přijatým událostem aa všem polím,
obsahujícím IIPP adresy.
Systém podporuje nativní získávání logů zz Officcee365 prostředí ss licencí EE33 bez
$no,šf>mfe nutnosti instalovat dodatečné externí komponenty. Požadujeme předložit link
i/tí J° na dokumentaci popisující nastavení systému v jednotném grafickém rozhraní
19 $no,šf>mfe
zztthhJ°i i
tak, aby získával logy zz Officcee365.
V případě krátkodobého (do 10 minut) až dvounásobného přetížení systému
20 proti jeho tabulkovým hodnotám nesmí dojít ke ztrátě logů nebo
nesprávnému stanovení časového razítka. Všechny přijaté nezpracované
logy/udáálloosstti musí být ukládány do vyrovnávací paměti*
21 Systém musí umožňovat unifikkované vyhledávání napříč všemi typy dat aa kkNNddjjSSppuuiijjWWiiii
zařízeními dle normalizovaných polí (uživatelské jméno, zdrojová IIPP,,
značka/tag apod.).
Dodavatel musí předložit potvrzení vystavené autorizovanou osobou o shodě, //{{NNOOffWWllííÚÚ//tt
že nabízený systém splňuje požadavky normy ČSN/ISO 27001:2013 na
SllJ*) 22 pořizování auditních záznamů. Toto potvrzení není možné nahradit Sil SllJ*)
certifikátem na společnost dodavatele (subdodavatele) nebo výrobce
nabízeného systému. Nelze nahradit čestným prohlášením
Systém musí mít možnost uložení uživatelem vytvořených pohledů na data
23 (dashboardů) pro budoucí zpracování. Továrně dodané pohledy na data
nesmí jít administrátorem ani uživatelem systému nevratně modifikovat nebo
smazat.
HHvvoo//ffmmyyzz Systém obsahuje reportovací nástroj ss přednastaveennýmmii nejběžněějjšími
24 reporty aa možností vlastních úprav aa vytvoření nových pohledů. Pro vytváření
nových pohledů na data není přípustné používat povinně SQL jazyk.
Systém obsahuje předpřiprraavené pohledy na uložená data dle jednotlivých
25 kategorií zdrojových zařízení ii dle logického členění.
Na základě pohledu na uložená data lze provést export dat ve strukturovaném
26 formátu tak, jak jsou v továrně nastaveném nebo uživatelsky nastaveném
pohledu data skutečně zobrazena.
hh^^iiMMuuHHÍÍ Konfigurační aa Systémové rozhraní aa dokumentace kk těmto rozhraním musí
být identické v anglickém ii v českém jazyce. Neeppřřiipouští se omezená
& dokumentace v českém jazyce nebo zjednodušená dokumentace odkazující
27 SH &
na další dokumentaci v anglickém jazyce, případně na dokumentaci třetích
stran. Požadujeme předložit link na online dokumentaci nebo připojit pdf
aktuální kompletní dokumentace kk ověření jednotlivých vlastností
navrhovaného systému. u
28 Systém nabízí kapaaccitní ii výkonovou škálovatelnost.
wwvvppKKmmzz Čistá kapacita úložného prostoru (kapacita diskového pole) dostupná pro
29 uložená data nabízeného systému musí být minimálně 160TB dat.
Požadujeme, aby ze systému bylo možné za běhu vytáhnout libovolné dva
30 disky, bez ztráty dat aa vlivu na funkčnost řešení. Redundance disků nesmí
ovlivňovat požadovanou kapacitu úložiště.
$puvu&£ 31
Monniitoring stavu systému - alertování při překročení prahových hodnot nebo AArrvvOO// $puvu&?
chybě systému, přeposlání upozornění pomocí SMTP nebo Syslog.
32 Qt- Požadujeme, aby systém obsahoval REST-API pro integraci ss externím ffííDDIIOO dto
IInní í
monitorovacím systémem (Zabbix, Nagios, MRTG aa další) aa umožňoval
autorizovaný přístup ke strukturované databázi logů. Požadujeme předložit
vzorový návod na integraci ss externím monitorovacím systémem.
/ Dodavatel doloží prohlášení výrobce o shodě ss požadavky Vyhlášky 82 / 2018
Sb. „o bezpečnostních opatřeních, kybernetických bezpečnostních
m wM 33
incidentech, reaktivních opatřeních aa o stanovení náležitostí podání v oblasti m wM
kybernetické bezpečnosti aa likvidaci dat (vyhláška o kybernetické
/ bezpečnosti)" k Zákonu 181 / 2014 Sb. „o kybernetické bezpečnosti aa o změně
souvisejících zákonů (zákon o kybernetické bezpečnosti)".
Jednotná centrální webová konzole ss jednotným grafickým rozhraním pro
přístup k logům, alertům, reportům aa pro správu systému. ZZ této konzole se
34 itl provádí veškerá konfigurace, správa ii analýza logů. Není přípustné, aby
navrhovaný systém měl více rozdílných konzolí od různých výrobců ss lil 11lil itl
rozdílným ovládáním nebo aby se konfigurace musela provádět mimo
jednotné webové rozhraní. Požadujeme předložit dokumentaci, ze které je
zřejmé, jakým způsobem je realizována konfigurace v rámci jednotné konzole.
Požadujeme, aby systém umožňoval jednotné vytváření uživatelských rolí
definujících přístupová práva kk uloženým událostem a jednotlivým ovládacím ii//ttjjcc sí y
komponentům systému. Připojte odkaz na dokumentaci popisující vytváření
sítoty 35
uživatelských rolí.
Dodaný systém musí obsahovat ucelené all-in-one řešení pro parsování aa
36 normalizaci přijatých událostí bez nutnosti dodatečné instalace externích
aplikací nebo systémů. Jedinou přípustnou výjimkou je monitorování systémů
Windows pomoci agentů.
Systém musí podporovat ověřování uživatele systému na externím LDAP
íwymtL 37
serveru. V případě výpadku externího LDAP systému musí podporovat ověření íwymtL
lokálního účtu. Systém automaticky zaznamenává uživatelská jména u akcí
provedených konkrétním uživatelem.
Minimální HW parametry požadovaného systému
Jedna hardwarová appliance o velikosti max. 2U, včetně ramena pro kabelový
38 management umožňujícího vysunutí zapnutého systému zz racku pro servisní
účely.
HW appliance obsahuje veškeré potřebné komponenty (CPU, RAM, diskový
39 prostor) pro svoji činnost a je nezávislá na dalších systémech.
woicitúMz
40 2 procesory, min. 16 jader každý, ss podporou HyperThreadingu.
41 Min. 128GB DDR-4 aa NVMe paměťové pole pro zpracování dat v čase blízkém
reálnému (Near Real-Time).
Minimálně 160TB pro integrovanou databázi podporovanou HW AANNQQ,, CCttwwWW,,zz
akcelerovaným SSAASS RAID řadičem ss read-write cache min. 8GB. Řadič
42 diskového pole musí obsahovat zálohovací baterii nebo být vybaven flash
frNO“-p--Ml pamětí.
Minimálně
4x 1Gbit LAN porty + llxx dedikovaný 1Gbit port pro management --f--r----N------O-“--p- -M --------l-
HW. Konfigurace všech parametrů síťového rozhraní včetně link agregace dle
LACP (802.3ad)),, VLÁN aa IP adresace v jednotném webovém rozhraní systému
i/ll 43 i/ll
aa doložte příslušný odkaz na dokumentaci. ffllDDllOOMMttiijjIItt
44 Větráky v systému musí být vyměnitelné za provozu aa redundantní.
45 2x napájecí zdroje ss redundancí napájení 1+1. žžtt
Virtuální KVM (tj. převzetí textové ii grafické konzole serveru aa zajištění řtt£?
46 přenosu povelů zz klávesnice aa myši vzdáleného počítače.
ř
Systém pro vzdálenou správu serveru včetně potřebné licence, pokud je třeba
47 (obdoba HP iLO, Dell iDRAC apod)
Výkonnostní aa SW parametry systému
Systém funguje formou HW appliance (všechny části systémů je možné
48 nastavit v centrální webové konzoli aa není nutné editovat žádné konfigurační
soubory, scriply nebo makra v příkazové řádce).
Aktualiizzace systému jsou distribuovány v jednotném balíku aa jejich instalace
jíl v^ j k je prováděna uživatelsky přes centrální webovou správcovskou konzoli.
l/il ctt Všechny aktualizace musí být prováděny zz webového prostředí bez potřeby
/ / rnu /
l/il MMLL.. ctt
49 asistence dodavatele//vvýýrobce dodávaného systému. Požadujeme předložení
tr posledních 4 poznámek kk novému vydání (release notes) pro kontrolu aa tr
parameettrů navrhovaného systému.
/f/W/AaW- Systém musí podporovat downgrade v jednom kroku, pro případ problémů ss /f/W/AaW-
I//2 ŠŠiill.. JO 50 novou verzí systému po upgrade. Není přípustný downgrade pouze za I//2 JO
součinnosti výrobce. Popište podrobně způsob realizace downgrade.
Průměrný trvalý příjem min. 10000 událostí/s. Výkon musí být dosažen na
požadované množství událostí ss průměrnou délkou zpráv minimálně 700Byte
trvale. Systém musí prokazatelně kompletně zpracovat přijaté události včetně
51 vytváření očekávaných metadat (DNS-PTR, čísla a jména ASN, geolokace),
zajišťovat normalizaci, zamezovat ztrátě přijatých událostí nebo posunutí
důvěryhodného časového razítka oproti času skutečného příjmu každé
události.
Špičkový příjem minimálně 20000 událostí/s po dobu nejméně 10 minut aa
průměrnou délkou minimálně 700byte. Systém musí prokazatelně kompletně
zpracovat přijaté události, zamezovat ztrátě ukládaných dat nebo posunutí
důvěryhodného časového razítka oproti času skutečného příjmu zpráv. PPřřii
52 zpracování dat během špičkového příjmu akceptujeme zpoždění zobrazeni
zpracovávaných dat. Systém ani ve špičkovém výkonu nesmí dovolit ztrátu
dat, skluz důvěryhodného časového razítka nebo jiné prokazatelné vady na
zpracovávaných datech oproti zpracování při průměrném trvalému příjmu
událostí.
Licenčně neomezený počet zařízení pro příjem zasílaných událostí. Licenčně
m.iPUJKuložených 53
neomezený počet událostí v 6B za den nebo licence na minimálně 500GB m.iPUJK
uložených událostí za den. Integrovaná databáze musí mít čistou velikost
nejméně 120 TB aa nad to musí podporovat kompresi ukládaných dat.
Uživatelská konfigurace klasifikace dat, parserů, filtrů a alertů se provádí
ffltOjMidu pomocí vizuálního programovacího jazyka v centrální správcovské webové JE
konzoli. Vizuální programovací jazyk musí uživateli umožnit psát konfigurace
54 bez nutnosti znaallosti programování (např. Node-RED, Microsoft VPL, Blockly
apod). Vizuální programovací jazyk není prezentován textově, ale graficky
formou schémat--ssymmbbollů, které reprezeennttují aplikační logiku a kontrolují
syntaxí.
Konfigurace uživatellských parserů musí umožňovat automatické doplňování
55 DNS reverzních záznamů, čísel a jmen autonomních sítí, geolokační Informace
aa identifikace výrobce zařízení podle MAC admsy,
Systém musí podporovat doplňování zpráv o informace zz textových ňNOfitldwfc
prohledávacích tabulek. (Naappřříklad kk uživatelskému jménu doplnit zz textové
prohledávací tabulky informaci oo jeho emailu, členství v AD skupinách aa ttllii SIL h h
56 podobně). Pro automaattickou aktualizaci takto uložených doplňujících
informací musejí být tyto textové prohledávací tabulky naplnitelné pomocí
RREESSTT API nabízeného systému aa modifikovatelné přes jednotné webové
rozhraní. Doložte odkazem na dokumentaci, jakým způsobem lze plnit textové
tabulky prostřednictvím REST-API nabízeného systému.
firJO/SM/ujfe Možnost on-line ladění uživatelsky definovaných parserů -- při jejich vytváření
je možné vložit skupinu testovacích zpráv, při změně je okamžitě zobrazena
firJO/SM/ujfe
V\l S7S. Jo V\l výsledná podoba rozparsovaných dat aa případná chybová hlášení ss
57 upozorněním na chybná místa vytvářeného parserů. Pro snadnějjší vytváření
S7S. Jo
parserů požadujeme mít možnost vložení minimálně 20 testovacích zpráv
současně. Doložte odkazem na dokumentaci, ze které je zřejmé, jakým
způsobem se vkládají testovací zprávy během psaní nového uživatelského
parseru aa jakým způsobem je prezentován výstup testu.
V centrální správcovské konzoli je možné přidávat kk jednotlivým zdrojům dat,
aplikacím, zařízením nebo IIPP subnetům tzv. značky, označující například
umístění zařízení, typ zařízení, kritičnost zařízení apod. Systém obsahuje
58 předdefinované značky, které automatticky přidává kk přijímaným zprávám.
Příklady značek: konfigurační změna, úspěšné ověření uživatele, neúspěšné
ověření uživatele, zpráva přišla zz Windows, zpráva byla vygenerována
firewallem atd...
Všechny přidávané značky jsou ukládány ss každou přijatou událostí, na
59 základě značky je možné filtrovat data nebo omezovat oprávnění uživatelů
systému kk jednotlivým událostem,
Pro budoucí nasazení ve vysoké dostupnostti je vyžadována podpora sestavení
- v clusteru - požadujeme podporu minimálně 2 nodů. Nastavení clusteru se
musí kompletně realizovat v grafickém rozhraní správcovské konzole v
ÍTt.Jo jednom kroku, není přípustné konfigurovat sestavení scripty, makry nebo
úpravou textové konfigurace systému aa pomocí ručních restartů služeb.
((////£?
60 Systém ve vysoké dostupnosti musí přehledně informovat o stavu clusteru aa
procesu synchroniizzace databází. Dokumentace k realizaci vysoké dostupnosstti
musí být kompletní aa popisovat všechny kroky sestavování aa obnovení v
případě výpadku komponenty clusteru. Doložte odkazem na dokumentaci,
jakým způsobem se cluster vytváří aa jakým způsobem se provádí obnovení po
možném výpadku jednotlivých zúčastněných komponent.
61 V případě využití více nodů v clusteru se automaatticky zrychluje zpracování
vstupních dat aa vyhledávání v již uložených datech.
62 V případě rozšíření systému na cluster musí navrhovaný systém zaajjistit
bezvýpaaddkkoovvoosst sběru logů.
km, cc//uuii//uutt km, Řešení musí umožňovat rozšíření mezipamětti diskového subsystému o SSSSDD
63 nebo NVRAM typu o kapacitě minimálně 3TB.
Systém musí umožňovat export dat ve formátu vhodném pro další strojové
64 zpracování bez dodatečných omezení na časové období, množství nebo
obsah exportovaných dat. Během exportu je možné označit pouze vybraná
pole, která mají být do exportu zahrnuta.
Podpora zálohování nebo obnovení konfigurace v jednom kroku aa jednom
souboru pro celý systém. Doložte odkazem na dokumentaci, jakým způsobem o
se provádí zálohování aa obnova konfigurace systému.
íTil.Jo í 65
]]//}}%%
Podpora důvěryhodného zálohování dat na externí systém. Požadováno
66 plánované ii ad-hoc zálohování. Zálohy dat musejí být vhodně kompresovány.
IIřřiill šfl.Jo Doložte odkazem na dokumentaci, jakým způsobem se realizuje zálohování aa
obnova záloh.
Alerty
Systém je schopen na základě uživatelsky zadaanných podmínek splněných
67 v přijatých datech vygenerovat alert.
Text emaiilu vygenerovaného alertem musí být uživatelsky definovatelný
68 ss proměnnými, které jsou vyplněny zz přijaté rozparsované události.
Systém musí obsahovat výrobcem předpřipravené sety/vzory alertů aa
korelací.
ftrtO, ((PPttááťťtt 69
ftrtO,
Systém musí provádět konfigurace alertů aa korelací pomocí vizuálního
programovacího jazyka. Vizuální programovací jazyk není prezentován čistě
textově, ale textově-grafickou formou, která vizualizuje aplikační logiku ffttNNOOjj JJffttMMuubbaa
vytvářeného alertu. Konfigurace alertů musí umožňovat okamžitou kontrolu
funkčnosti výstupu alertu nebo korelace vložením příslušné testovací zprávy,
\\!!llll $ 70
včetně zobrazení upozornění na případné uživatelské chyby. Doložte odkazem ggTTííii.. $oo
na dokumentaci, jakým způsobem realizujete konfiguraci aa testovaní alertů aa
korelací.
Jako výstupní pravidlo Alertu musí systém umět odeslat událost, která alert
71 VVllkkssii^^iiOO vyvolala, na externí systém minimálně prostřednictvím SMTP nebo Syslogu
pres TCP protokol. UU Syslog protokolu požadujeme možnost definice formátu
odesílaných dat pro snazší integraci se systémy třetích stran. Doložte
odkazem na dokumentaci, jakým způsobem se zpráva, která vyvolala spuštění
alertu, odesílá na externí systém aa jak se definuje formát odesílání dat.
V alertech je možné nejen využívat, ale ii přiřazovat značky (příklad: pošli alert
vaa jen v případě, že se událost stala na kritickém serveru aa je označen názvem sttuu .jo
72 lokality, nebo pokud událost obsahuje podmínku, přiřaď novou značku). v
Doložte odkazem na dokumentaci, jakým způsobem lze v jednotném
grafickém rozhraní systému definovat a přiřazovat značky.
Systém podporuje základní funkce SIEM funkce pro korelace událostí aa
73 upozornění ss hraničními limity, Definice korelačních pravidel je prováděna
pomocí vizuálního programovacího jazyka aa musí obsahovat možnost vložení
testovací zprávy aa výsledku testu o provedené akci.
Sběr událostí zz Microsoft prostředí
Události zz Microsoft prostředí jsou vyčítány pomocí agenta instalovaného
přímo v koncových systémech. Windows agent musí současně podporovat jak
monitoring interních Windows logů, tak monitoring textových souborových
74 logů. .. Agent se nesmí instalovat individuálně, ale prostřednictvím MS AD
Group Policy a nesmí vyžadovat žádnou konfiguraci na cílovém systému,
Předložte kompletní dokumentaci kk instalalaci aa konfiguraci agenta pro sběr
logů zz prostředí Windows.
WWddffiittmmttee 75
Agent zajišťuje sběr nemodifikovaných událostí a detailní zpracování
auditních informací.
76 Agent podporuje nastavení filtrace odesílaných událostí pomocí centrální
správcovské konzole.
Filtrace odesílaných událostí agentem se konfiguruje pomocí vizuálního
WOfSfíůufe programovacího jazyka zz centrální správcovské konzole systému. Logy
nastavené kk filtraci jsou filtrovány na straně Windows agenta aa nejsou nijak WOfSfíůufe
77 l/ii eenn--iioo odesílány po sfti. Vizuální programovací jazyk není prezentován textově, ale
textově-graflckou formou, která vizualizuje aplikační logiku vytvářeného l/ii
alertu, Filtry musejí umožňovat okamžitě testovat jejich účinnost a zobrazit
kolik zz uložených dat zvolený filtr zasáhne aa kolik logů by případně filtroval
minimálně 2a posledních 24 hodin. Doložte odkazem na dokumentaci, jakým
způsobem se vytváří aa přiřazují filtry pro Windows agenty pro sběr logů aa
jakým způsobem se testuje účinnost filtru.
- Windows agent nevyžaduje administrátorské zásahy na koncovém systému -
je centrálně spravovaný aa jeho konfigurace musí být kompletně realizována v WWOO^^CCJJUUVVIIttiičč..
lil ssmm..hh grafickém rozhraní systému bez využití skriptů nebo maker. Konfigurace musí
78 být automaticky distribuována přímo zz centrální konzole systému. Správa aa iilil
aktualizace Windows agenta se neprovádí zz Group Policy. Doložte odkazem
na dokumentaci, jakým způsobem se centrálně zz grafického rozhraní spravují
Windows agenti včetně všech možností nastavení. íícciioollttííuuhhee..
79 Komunikace Windows agenta aa centrálního systému musí být šifrovaná.
Windows agent podporuje sběr nejen ze základních systémových logů
(Aplikace, Zabezpečení, Instalace, Systém), ale je možné zz centrální konzole v
grafickém rozhraní nastavit ii sběr všech ostatních logů ve složce Protokoly
aplikací aa služeb. Dále musí Windows agent podporovat centralizované
nastavení zz administrátorské konzole systému pro sběr textových logů včetně
kh 80 kh
možnosti výběru jejich formátu. Doložte odkazem na dokumentaci, jakým
způsobem se nastavují parametry sběru logů globálně aa jakým způsobem uu
konkrétního agenta.
Windows agent automaticky doplňuje ke všem odesílaným událostem jejich
81 textový popis tak, jak je zobrazen v Prohlížeči událostí (Event Viewer) na /{(VOiJMfe
koncovém systému.
Počet instalací Windows agenta by neměl být licenčně aa časově omezen,
pokud je licenčně nebo časově omezen, tak požadujeme dodání licencí na
Windows agenty v množství 1000 na dobu předpokládané morální životnosti
produktu - 7 let. Pokud je dodávaný Windows Agent výrobkem třetí strany,
mu sn.S sn.Soo 82
mu
doložte digitálně podepsaný souhlas výrobce software třetí strany ss použitím
1000 licencí na dodávaného Windows agenta v naší organizaci po dobu 7 let.
Podpora pro sběr událostí zz poboček
Systém musí obsahovat centrálně spravované řešení, které sbírá události na
pobočkách aa umožní jejich odeslání po saturované lince bez ztráty dat.
Doložte odkazem na dokumentaci, jakým způsobem realizujete sběr událostí zz
i/ii 83
poboček.
Systém musí podporovat centralizovanou správu pro sběr událostí přímo zz
84 centrálního úložiště dat včetně dokumentace požadavků na virtualizaci aa
komunikační matici pro šifrovaný přenos dat.
Řešení musí být schopno automaticky navázat spojení ss centrálním úložištěm
85 dat aa přenášená data šifrovat. V případě výpadku spojení mezi pobočkou aa
centrálou musí spojení automaticky obnovit.
86 Řešení musí komunikovat po definovaném IIPP protokolu, aby mohla být
centrálně nastavena kvalita služby (QoS) pro přenos událostí.
Řešení musí poskytovat kapacitu vyrovnávací paměti pro minimálně 100GB
A/v o> 87 událostí, které na pobočce mohou vzniknout během výpadku spojení mezi A/v o>
pobočkou aa datovým centrem.
88 Řešení pro sběr dat zz poboček musí mít výkon minimálně 5 tisíc událostí/s, aa
to ii v trvalé zátěži.
Řešení musí poskytnout podporu pro sběr událostí na identických UDP ii TCP
89 portech jako hlavní dodaný systém.
Řešení musí být k dispozici jako fyzický systém nebo jako virtuální systém pro
VMware EESSXXii aa Hyper-V.
W0f 90
W0f {{PPLLAA//UUffee ::
Řešení musí být schopno komunikovat zz pobočky na centrálu ii přes
vícenásobný překlad adres (NAT).
WWDDttPPmmffcc 91
Vysoká dostupnost, SW Podpora a záruka na hardware
92 Požadujeme volitelnou podporu pro nasazení ve vysoké dostupnosti.
HW - Požadovaná min. Slétá servisní podpora na hardware appliance ss
93 opravou v místě instalace serveru aa ss garantovanou odezvou následující
pracovní den od nahlášení případné závady.
AíVvftmfe 94
Systém musí podporovat vygenerování TSR (technického support reportu) pro AíVvftmfe
možnost diagnostiky bez vzdáleného přístupu.
SW - Podpora výrobce na aktualizaci systému aa parserů na 2 roky. Podpora
/IMBÚÚhV Vé 95 musí obsahovat aktualizaci SW minimálně 4x ročně, opravy chyb aa
telefonickou aa emailovou podporu ss diagnostikou vzdáleným přístupem. hé
96 Školení administrátoru pro 5 osob v rozsahu min. 8h //ff//YYffffiiWWmmjjťť
Tabulka č.ll seznam zdrojů logů Qradar LLEEEEFF (generický/standardizovaný
formát) _________
Minimální seznam podporovaných zdrojů logů
AIP Safe (https://aipsafe.cz/)) HAProxy (structuurreedd rfc5425 logformat|__
Apache httpd
ApacheTomcat Hillstone NGF FW__W ________________
Amavis
Antivir AVG HPE Aruba Instant APP(WLAN)________________________
Antivir Avast
Antivir Eset Remote administrátor HPPEEAruba Mobility Controller (WLAN)___
Brocade FFCC switches
ArcSight CCEEFF (geneerrický/standarrdizovaannýý HPE iLo 4 (Server OoB management)
formát)
Barracuda Email Security Gateway HPE IMC
Cisco ASA
Cisco ASA-Lite (optimalizované pro výkon) HPE routers __________________
Cisco Firepower
Cisco IISSEE HPE switchess Procurve OOSS____________ ______
Cisco IIOOSS
Cisco IronPort HPE switches Comware OOSS
Cisco Nexus
Cisco SMB HPE Comwaree WLAN
Cisco UUCCSS
Cisco WLC Huawei USG __ __________________________
CompuNet GAMA (na vyžádání) CheckPoint LOG Exportér Lite (optimalizován na
Dell ForcelO výkon)________________________ __________________
Dell iDrac (Server OoB management)
Dell Isilon CheckPoinntt LOG Exportér ___________
Dell PowerConnect
Dell SonicWALL CheckPoint via OPSEC protocol
Dell W-series WiFi
Discard (speciální pravidlo na fitrování událostí) ISCBIND
Dropbear SSSSHH ("součást Embedded Linux
distribucí) ISCDHCP
Epacs (htttpp::////wwwwww.e.eppaacsc.sc.zc/z) /)
Extreme NAC JSON (genericky/standardizovaný ffoorrmmáát)t)
Extreme Networks XOS
FlowMon Juniper SRX________________________________________________________
FortiAuthenticator
FortiDDoS Juniper SRX-Lite (optimmaallizizoovvaanénépro výkonn))______
Fortigate
FortiGate-Lite (optimalizované pro výkon) Kašpersky Endpoint Security
FortiMail
FortiManager Kašpersky Security Center____________________________
FF55 BiglP ASM
FreeRADIUS Kerio Connect______ _______ ___
Greycortex NTA
Keerriioo Control_______ _____________ _______
Kernun Clear Web ____ ______
Kernun Webfilter _________ __
Lenovo XCIarity (Serrvveerr OoB management)
Linux Bashh commands log ________________ __
Linux Cron___________________________________________
Linuuxx Freeradiuss ______________ _________________
]Jnux Iptables____ ________________ ____________
Linux Postfix
LOGmanager
Mikrotik ________________ ________________ _______
Microsoft Exchange________ ________________
Microsoft EExxcchhanagnege trackkiinngglog (2010-2019)
Microsoftt ShhaarreePPoionitnt _________________ ______
Microsoofftt__SSQQL_L___________________ __________________
Microsoft Windows DHCCPP logg ______________
Microsoft Windows DN5 debug log_________________
Microsoft Windows Firewalll________________ _________
Microsoft Windowss HS/wweebbsseervrevre__r_______
Microsoft Windows HS/ftpserver
a a
adresář) Microsoft Windows logy zz Event View (libovolný SpamAssasinn__________ ________________________________________
adresář) Stapro FONS Enterprise, Akord, Qpenllmss_______
Microsoft Windows logy z libovolného
textového souboru Squid (Web Proxy)
Microsoft Windows-lite (optimalizované pro
výkon) Squid for Windows
MySQL
Radware Defense Pro
Nginx
Novell eDDiireeccttory RFC5425 (geneerrlcký/standarrdizovaanný formát)
Officce365
OpenSSH server SSyymmaanntetcec Endpoint Prootteeccttioionn Manager___________
Oracle DB
Palo Alto Neettworks NGFW Symantec Messagging Gateway (Bríghtmail)
PostgreSQL
Pulse Secure Synoíogy NAS DSM ______________
Ruckuss wireless
Safettica DLP Trape? ee______________________ ______ ______ ____ ____
SAP (5M19 a SM20 logy)
Shorewalll Trend Micro Apex OOnnee__________________________ ____
SonicWall
Sophos TrendMMiicro DeeeppDDiissccoveerry ___________________ __
TreennddMMiiccrroo DeeppSSeeccuurritiyty______________
SMS TrendMMiicro TippingPooiint SMS
UBNT Rocket
UBNTUniFI ____________________________
VEEAM Backup and Restoorree_____________________________
WhaleboneJo (PNS serrvveerr))_________________________
mmVmware (včetně květnové aktualizace VMWARE