PRÍSTUP K PROJEKTU

manažérsky výstup I-03

podľa vyhlášky MIRRI č. 401/2023 Z. z.

Schvaľovanie dokumentu

1.     História dokumentu

2.     Popis navrhovaného riešenia

Projekt Podpora v oblasti kybernetickej a informačnej bezpečnosti na regionálnej úrovni –  Mesto Stará Ľubovňa  má za cieľ zvýšiť úroveň informačnej a kybernetickej  bezpečnosti v sektore verejnej správy.

Projekt v rámci výzvy poskytuje prostriedky na realizáciu základných stavebných blokov bezpečnostnej architektúry v súlade s NKIVS a strategickou prioritou informačnej a kybernetickej bezpečnosti. Oblasti bezpečnosti, na ktoré organizácia žiada podporu v rámci tohto projektu (výzvy) predstavujú základný rámec („baseline"), ktorý by mal byť implementovaný. Aktuálny stav implementácie týchto bezpečnostných služieb a funkcií je nízky, preto žiadame o podporu v rámci tohto definovaného rámca. Budúce riešenie základného rámca zabezpečenia informačnej a kybernetickej bezpečnosti na úrovni biznis architektúry by malo pozostávať najmä z nasledovných bezpečnostných riešení:

• Aktivity ohľadom vypracovania dokumentácie a nastavenia procesov riadenia informačnej a kybernetickej bezpečnosti (ďalej len „KIB“) a aktivity ohľadom vypracovania kontinuity činností v zmysle zákona o KB.
• Analytické aktivity zavedenia bezpečnostných opatrení a riešení.
• Implementačné aktivity bezpečnostných riešení.
• Pre-financovanie aktivít riadenia súladu, najmä ohľadom auditu kybernetickej bezpečnosti a aktualizácie analýzy rizík a analýzy dopadov po implementácii bezpečnostných opatrení a riešení, tesne pred ukončením projektu.

Jednotlivé biznis funkcie a bezpečnostné procesy ako aj popis ďalších úrovni architektúry riešenia sú uvedené v nasledujúcich kapitolách.

3.     Architektúra riešenia projektu

Tento projekt predstavuje riešenie základných stavebných blokov bezpečnostnej architektúry a zároveň aj ďalšie bezpečnostné funkcie realizované v organizácii. Organizácia nemá zavedený governance KIB na dostatočnej úrovni a nemá vypracovanú detailnú analýzu rizík a analýzu dopadov, taktiež sú nedostatočne riešené aj ďalšie oblasti riadenia KIB definované zákonom o KB.

Z uvedeného dôvodu bude projekt primárne zameraný na implementáciu governance procesov v oblasti riadenia KIB, kde je cieľom vypracovať dokumentáciu a zaviesť príslušné procesy. Zároveň bude Mesto Stará Ľubovňa žiadať aj o ďalšie oblasti podpory.

Keďže nejde o implementáciu agendového alebo iného obdobného informačného systému verejnej správy, tak v tomto duchu je upravený aj popis jednotlivých úrovni architektúry. Najmä v prípade poskytnutia podpory pre iné ako governance aktivity, kde sa predpokladá aj implementácia bezpečnostných systémov, zariadení alebo technických riešení, sú rovnako jednotlivé bloky architektúry rozpísané spôsobom zohľadňujúcim uvedené skutočnosti.

Pri biznis architektúre je potrebné si uvedomiť, že projekt, resp. jeho aktivity nerealizujú typické služby eGovernment-u a VS, ale ide o služby na úrovni bezpečnostnej architektúry VS, a ako také a z tohto dôvodu, nie sú vedené ako aplikačné služby v MetaIS.

Zároveň je potrebné uviesť, že architektúra pre as-is stav nie je uvedená z dôvodu, že aktuálne tieto služby bezpečnostnej architektúry nie sú implementované, prípadne sú implementované len čiastočne na nepostačujúcej úrovni.

Úrovne architektúry sú ďalej rozpísané podľa jednotlivých aktivít projektu a biznis bezpečnostných funkcií.

Špecifikácia výstupov jednotlivých aktivít je uvedená v kapitole Požadované výstupy (produkt projektu) v dokumente Projektový zámer.

3.1        Biznis vrstva

Biznis architektúra bude pozostávať z nasledovných biznis funkcií, ktoré budú realizovať nižšie uvedené biznis procesy:

• Riadenie aktív a riadenie rizík.
  • Proces evidencie a správy aktív.
  • Proces klasifikácie informácií a kategorizácie IS a sietí.
  • Proces realizácie AR/BIA.
  • Proces rozhodovania ohľadom riadenia identifikovaných rizík.
• Riadenie prístupov.
  • Proces vzdialeného bezpečného prístupu a viac-faktorovej autentifikácie pri vzdialenom prístupe.
  • Proces viac-faktorovej autentifikácie pri prístupe administrátorov k IS a zariadeniam.
• Riadenie kontinuity činností.
  • Proces zálohovania.
  • Proces ochrany a redundancie záloh.
  • Proces riadenia kontinuity procesov, systémov a služieb.
• Bezpečnostný monitoring.
  • Proces zberu a správy logov.
  • Proces identifikácie bezpečnostných incidentov.
  • Proces riešenia bezpečnostných incidentov.
• Riadenie kapacít.
  • Proces monitoringu a vyhodnocovania dostatočnosti prevádzkových kapacít najmä z pohľadu dostupnosti.
• Hodnotenie zraniteľností.
  • Proces realizácie skenovania a identifikovania nových zraniteľností existujúcich systémov a zariadení.

Okrem uvedených biznis funkcií je projekt zameraný aj na podporu pre oblasti:

• governance KIB a bezpečnostná dokumentácia,
• zavedenie procesov riadenia KIB pre všetky relevantné oblasti riadenia,
• audit, riadenie súladu a kontrolných činností - proces posudzovania súladu formou realizácie auditu KIB.

Požiadavky na AR/BIA sú nasledovné:

Zrealizovanie aktualizácie analýzy rizík a vykonanie analýzy dopadov nad identifikovanými informačnými aktívami v súlade s metodikou AR/BIA vytvorenou v rámci projektu a zaevidovanie výsledkov do nástroja na evidenciu aktív a aktualizáciu AR/BIA. Predmetom dodávky bude aj vytvorenie katalógu rizík a podpora pri procese jeho formálneho schvaľovania vedením Mesta Stará Ľubovňa.

Analýza dopadov musí:

• identifikovať rôzne kategórie procesov na základe ich kritickosti a posúdiť ich vzájomné závislosti,
• určiť potenciálne dôsledky (škody/straty) pri rôznych dobách trvania kritických situácií,
• stanoviť maximálne akceptovateľné doby prerušenia (MTO),
• stanoviť minimálne ciele kontinuity podnikania (MBCO),
• určiť cieľové časy obnovy (RTO) a cieľové body obnovy (RPO),
• identifikovať potenciálne dopady vyplývajúce z možného prerušenia činností a stanoviť výšku:
  • funkčných dopadov,
  • finančných dopadov,
  • dopadov spôsobených stratou údajov a dokumentov.
• identifikovať zdroje a prostriedky na obnovu procesov so zásadným vplyvom na kontinuitu činností organizácie na základe hodnoty RTO procesu v min. tomto typovom rozsahu zdrojov:
  • ľudia,
  • aplikácie / databázy,
  • údaje uložené v elektronickej podobe (nezahrnuté v aplikáciách a databázach),
  • údaje uložené na papierovom médiu,
  • IT a komunikačné zariadenia,
  • komunikačné kanály,
  • ostatné vybavenie,
  • vybavenie a infraštruktúra,
  • pracovný kapitál.

Záverečná správa, ako výstup z analýzy dopadov musí obsahovať:

• prehľad vykonávaných činností, ktorý bude obsahovať názov činnosti, jej vymedzenie, vlastníka, MTO a MBCO,
• zoznam procesov, ktorý bude (ak to je možné) obsahovať názov procesu, druh procesu, vlastníka procesu, RTO a RPO procesu (údaje, na základe ktorých bolo stanovené príslušné RTO a RPO budú taktiež súčasťou správy),
• špecifikácie nevyhnutných zdrojov a prostriedkov pre zabezpečenie kontinuity činností.

Pri analýze dopadov je potrebné identifikovať:

• kritické obdobie,
• množstvo práce vykonanej v kritickom období,
• minimálne prijateľné množstvo práce vykonávanej bezprostredne po krízovej situácii,
• či môže definovaný typ krízovej situácie spôsobiť prerušenie procesu.

Pričom kritickým obdobím až krízovou situáciou môže byť:

• nedostupnosť informačných technológií a/alebo dát,
• nedostupnosť prevádzkových priestorov,
• nedostupnosť kritickej časti ľudských zdrojov – zamestnancov,

zlyhanie kľúčového externého dodávateľa služieb.

Požiadavky na kontinuitu činností:

Súčasťou kontinuity činností bude aj zadefinovanie scenárov rôznych udalostí, ktoré potencionálne môžu mať negatívny vplyv na bežné činnosti organizácie ako sú napríklad:

• náhla nedostupnosť personálu či nepoužiteľnosť pracoviska/budovy,
• nedostupnosť technologickej infraštruktúry či potrebných médií,
• incident či živelná katastrofa.

V rámci kontinuity činností musia byť stanovené požiadavky na zdroje (adekvátne finančné, materiálno-technické a personálne zdroje), ktoré budú potrebné na implementáciu vybraných stratégií kontinuity činností. V zmysle požiadaviek zákona o kybernetickej bezpečnosti sa musí určiť čo má byť:

• hlavným cieľom plánu kontinuity s ohľadom na riadenie incidentov v prípade katastrofy alebo iného rušivého incidentu a ako sa obnovia činnosti v stanovených termínoch,
• strategickým imperatívom procesu riadenia kontinuitu s ohľadom na predchádzanie ďalším stratám.

Súčasťou kontinuity činností musí byť vypracovanie analýzy funkčných dopadov a kvalifikácia potencionálnych dopadov a straty v prípade prerušenia alebo narušenia prevádzky u všetkých procesov organizácie. Požiadavkou analýzy funkčného dopadu musí byť určenie:

• cieľovej doby obnovy jednotlivých procesov, siete a informačných systémov a aplikácií, a to najmä určením doby obnovy prevádzky, po uplynutí ktorej je po kybernetickom bezpečnostnom incidente obnovená najnižšia úroveň poskytovania základných služieb,
• cieľového bodu obnovy jednotlivých procesov, siete a informačných systémov základnej služby, a to najmä určením najnižšej úrovne poskytovania služieb, ktorá je dostatočná na používanie, prevádzku a správu siete a informačného systému a zachovanie kontinuity základnej služby.

Kontinuitou musia byť zavedené postupy zálohovania na obnovy siete a informačného systému po jeho narušení alebo zlyhaní v dôsledku kybernetického bezpečnostného incidentu obsahujúce najmenej: 

• frekvenciu a rozsah zdokumentovania a schvaľovania obnovy záloh,
• určenie osoby zodpovednej za zálohovanie,
• časový interval, identifikáciu rozsahu údajov, zadefinovanie dátového média zálohovania a zabezpečenie vedenia dokumentácie o zálohovaní,
• umiestnenie záloh v zabezpečenom prostredí s riadeným prístupom,
• zabezpečenie šifrovania záloh obsahujúcich aktíva klasifikačného stupňa chránené a prísne chránené,
• vykonávanie pravidelného preverenia záloh na základe vypracovaného plánu, testovanie obnovy záloh a precvičovanie zavedených krízových plánov najmenej raz ročne.

Kontinuita činností musí obsahovať minimálne:

• plán kontinuity na stanovenie požiadaviek a zdrojov,
• plán reakcie na incidenty a plány havarijnej obnovy prevádzky,
• politiku a ciele kontinuity,
• analýzu funkčných dopadov,
• stratégiu riadenia kontinuity vrátane evakuačných postupov,

plán údržby a kontroly BCMS.

Jednotlivé biznis funkcie bezpečnostnej architektúry sú znázornené na nasledovnom obrázku:

3.1.1        Prehľad koncových služieb – budúci stav:

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.1.2        Jazyková podpora a lokalizácia

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.2        Aplikačná vrstva

Aplikačná architektúra bude pre jednotlivé relevantné biznis funkcie, uvedené v časti biznis architektúry, tvorená nasledovnými aplikačnými modulmi:

3.2.1        Požiadavky na jednotlivé komponenty

Požiadavky na jednotlivé aplikačné komponenty pre vyššie uvedené aplikačné služby sú nasledovné:

Správa dokumentov

V rámci tejto aplikačnej služby bude na správu bezpečnostnej dokumentácie vytvorenej počas projektu využitý existujúci Dokument manažment systém Mesto Stará Ľubovňa.

Riadenie aktív a rizík

Za účelom identifikácie aktív a ich ďalšej správy, realizáciu klasifikácie a kategorizácie a realizáciu a následne udržiavanie (aktualizácia) analýzy rizík a analýzy dopadov bude nasadená samostatná aplikácia.

Informačný systém pre identifikáciu a riadenie rizík musí spĺňať tieto funkčných vlastnosti:

• správa aktív – vedenie zoznamu aktív subjektu, vrátane ich vlastníkov,
• správa zraniteľností – vedenie zoznamu rozpoznaných zraniteľností, vrátane ich vlastníkov,
• správa hrozieb – vedenie zoznamu rozpoznaných hrozieb,
• správa opatrení – vedenie zoznamu opatrení potrebných na potlačenie zraniteľností,
• správa vzťahov – evidencia rozpoznaných vzťahov medzi aktívami a zraniteľnosťami,
• správa rizík – identifikácia a ohodnotenie rizík na základe pravdepodobností hrozieb, uplatňovaných opatrení a dopadov na subjekt,
• semikvantitatívna prípadne kvantitatívna metóda hodnotenia významnosti rizík,
• číselné ohodnotenie pravdepodobnosti hrozieb a účinnosti opatrení,
• významnosť rizík vyjadrená číselne a následne kategorizovaná.

Užívateľské rozhranie a výstupy musia spĺňať tieto požiadavky:

• pre interakciu s používateľom musí byť k dispozícií webové rozhranie bez špeciálnych nárokov na webový prehliadač v plnej podpore slovenského jazyka,
• výstupy musia byť realizované vo forme prehľadov a zostáv vo formáte PDF vyhotovené v slovenskom jazyku vrátane šablón a komentárov,
• softvér musí umožňovať riadiť prístup užívateľov k obsahu rizikovej analýzy.

Správa používateľov musí umožňovať:

• evidenciu používateľov, oprávnených pristupovať k subjektom a identifikovať resp. manažovať ich riziká,
• širokú integráciu na existujúce systémy správy používateľov,
• prideľovanie rolí oprávneným používateľom s rôznym stupňom oprávnení.

IS pre identifikáciu a riadenie rizík musí byť umožňovať vykonávať revízie a aktualizáciu rizikovej analýzy, riadiť riziká, aktíva, zraniteľnosti a hrozby systémom, ktorý dokumentuje históriu a je auditovateľný. Verejný objednávateľ požaduje informačný systém typu klient – server nasadený u verejného obstarávateľa na jeho servery bez závislosti na cloudových službách, aktualizáciách cez internet a inom komerčnom programovom vybavení okrem operačného systému.

Požiadavky na výkon činností manažéra pre riadenie rizík prostredníctvom IS pre identifikáciu a riadenie rizík:

• tvorba analýz rizík podľa potreby a požiadaviek verejného obstarávateľa,
• pravidelné hodnotenie a ošetrovanie rizík,
• tvorba plánu eliminácie rizík,
• správa aktív a ich vlastníkov,
• dohľad nad riadením rizík.

Súčasťou aktivity je samozrejme aj prvotná identifikácia a evidencia všetkých informačných aktív Mesta Stará Ľubovňa, vykonanie klasifikácie informácií a následne kategorizácie IS a sietí podľa požiadaviek aktuálnej legislatívy a zrealizovanie analýzy rizík a analýzy dopadov nad identifikovanými informačnými aktívami v súlade s metodikou AR/BIA. Predmetom dodávky bude aj vytvorenie katalógu rizík a podpora pri procese jeho formálneho schvaľovania vedením Mesta Stará Ľubovňa.

Riadenie kontinuity činností

Nasadenie cloudového nástroja pre manažovanie a automatické spúšťanie záloh systémov a dát a rovnako aj technologické vybavenie (NAS úložisko) pre bezpečné uloženie záloh v inej serverovni mimo primárnych systémov formou automatickej replikácie záloh do tejto vzdialenej serverovne.

Požiadavky na cloudovú službu pre zálohovanie:

• Vytvorenie a správa backup konta a úložiska v cene predplateného balíka údajov.
• Nastavenie a zálohovania na úložisko.
• Bezplatný prenos údajov do úložiska, platí sa iba za uložený objem, nie za prenos údajov do úložiska.
• Kontrola a správa zálohovania do úložiska, riešenie problémov s prenosom údajov do úložiska v cene predplateného balíka údajov.
• požadovaná kapacita 25 TB.
• Údaje uložené v rámci EÚ.
• Údaje sú kryptované a v prípade úniku teda nečitateľné pre útočníka.
• Nastavenia nemennosti záloh (immutability) – ochrana pred prepísaním/vymazaním, ako ochrana záloh proti ransomware - min. retenčná doba 30 dní.

Cieľom je zároveň vytvorenie aj jednej lokálnej repliky záloh s nasledovnou špecifikáciou:

• Server DELL PE R750xs alebo ekvivalent s rovnakými alebo lepšími parametrami:
• 1 PowerEdge R750xs Motherboard with Broadcom 5720 Dual Port 1Gb On-Board LOM, Ti
• 1x Intel® Xeon® Silver 4314 2.4G, 16C/32T, 10.4GT/s, 24M Cache, Turbo, HT (135W) DDR4-2666 (možnosť doplniť druhý CPU)
• (výkon 1 CPU podľa PassMark Software CPU Benchmark minimálne na úrovni 29 340 bodov k 5.4.2024)
• 1 Chassis with up to 16x2.5“ Drives
• 1 Riser config 4, Half Length, Low Profile, 1x16 + 1x4 slots, 1 CPU
• 1 PowerEdge 2U Standard Bezel
• 6x 32GB RDIMM, 3200MT/s, Dual Rank, 16Gb BASE x8 (minimálne 2 DIMM sloty voľné na doplnenie RAM, pri osadení 1CPU; minimálne 10 voľných DIMM slotov pri osadení 2CPU)
• 1 iDRAC9, Enterprise 15G (možnosť úplného manažmentu servera, vr. BIOS/UEFI; možnosť úplnej konfigurácia RAID controllera z prostredia manažment konzoly a i.)
• 1 Server Secured Component Verification
• 1x BOSS-S2 controller card + with min. 2x M.2 240GB, Hot-Plug (RAID 1)
• 16x 2,4TB HDD SAS 12Gbps 10K 2.5in Hot-Plug (RAID6)
• 1 PERC H755 Adapter LP
• 1 Dual, Fully Redundant(1+1), Hot-Plug Power Supply,1100W MM(100-240Vac) Titanium
• 2x Rack Power Cord 2M (C13/C14 10A)
• 1 Trusted Platform Module 2.0 V3
• 1 Intel E810-XXVDA4 Quad Port 10/25GbE SFP28 Adapter, OCP NIC 3.0
• 1 High Performance Fan x5
• 1 ReadyRails Sliding Rails with Cable Management Arm
• 1 ProSupport and Next Business Day Onsite Service, 60 Month(s)
• // Servis v trvaní 60 mesiacov, nástup na opravu v nasledujúci pracovný deň v rámci podmienok služby, nahlasovanie porúch 24/7 //
• Server a všetky jeho relevantné komponenty (napr. CPU, NIC, RAID Controller, ai.) musia byť certifikované pre VMware vSphere ESXi 7.0 U3, 8.0, 8.0 U1, 8.0 U2, 8.0 U3, prípadne novšie verzie v čase predkladania ponuky – (preukázateľne na https://www.vmware.com/resources/
• compatibility/search.php), keďže verejný obstarávateľ vlastní a mieni využiť existujúce softvérové vybavenie VMware a taktiež z dôvodu kompatibility a interoperability s existujúcou infraštruktúrou.

Požiadavky na UPS:

• UPS Eaton 5PX 3000i RT2U G2 (5PX3000IRT2UG2) + 1ks sieťová manažment karta (NMC) alebo ekvivalent rovnakými alebo lepšími parametrami, s priamou podporou IPM (alebo PCNS) pre riadenie autoshutdown cez vCenter Server
• Technológia: Line-interactive
• Konfigurácia: Rack – možnosť osadiť do racku ako 2U zariadenie – vrátane dodania koľajníc
• Výkon (VA/W): 3000 VA / 3000 W
• Doba zálohovania:
• Pre samotné UPS:
  • Pri 50 % vyťažení: 14 min.
  • Pri 70 % vyťažení: 9 min.
• + 1 EBM:
  • Pri 50 % vyťažení: 66 min.
  • Pri 70 % vyťažení: 38 min.
• + 4 EBM:
  • Pri 50 % vyťažení: 213 min.
  • Pri 70 % vyťažení: 121 min.
• Užívateľské rozhranie:
  • Komunikačné porty: USB, RS232, 1 mini svorkovnica pre diaľkové zapnutie, vypnutie a pre diaľkove odstavenie (RPO)
  • Slot pre komunikačné adaptéry: 1 miesto pre NMC Minislot kartu (NMC karta je súčasťou balenia), NMC ModBus/Jbus alebo MC Contacts/Serial
  • Displej: Graficky LCD displej
• Vstup: C20
• Výstupy: 8 x C13, 2 x C19 (10 zásuviek so zálohováním a prepäťovou ochranou)
• Diaľkovo ovládané výstupy: 2 skupiny po 2 x C13
• Vstupné napätie: rozsah 160-294 V ( nastaviteľné 150-294 V)
• Výstupné napätie: 230 V
• Kmitočet: 50-60 Hz ( rozsah pre 50 Hz 47-70 Hz, pre 60 Hz 56.5-70 Hz), 40 Hz v režime s nízkou citlivosťou
• Záťažové segmenty: 2 skupiny po dvoch individuálne ovládaných zásuvkách
• Záruka výrobcu na elektroniku 3 roky a batérie 2 roky.
• COMPLIANCE:
  • IEC/EN 62040-1, IEC/EN 62040-2, IEC/EN 62040-3, RoHS Compliant, REACH, UL 1778, CSA 22.2
• CERTIFICATIONS:
  • CE, cTUVus, EAC, Cm, UKCA, Ukr, KCC, ENERGY STAR certified

Požiadavky na rack:

• Serverový rack 42U
• Rozmer ŠxHxV (600mm x 1000mm x 42U)
• Perforované predné a zadné dvere
• Polica 19“
• PDU C14/8x C13 19“ a C14/6-8x eurozásuvka 19“

Požiadavky na NAS:

• RackStation 2,2GHz, 4GBRAM, 8xSATA, 2xUSB3.0
• záruka 5 rokov
• kapacita 22 TB SATA, 6Gb/s, 256MB cache, 7200 ot. – 6ks
• čítanie / zápis dát min.: 2300 / 1100 MB/s
• podpora sieťových kariet 10GbE SFP+/RJ-45 a 25GbE SFP28
• redundantný zdroj napájania
• technická a systémová podpora 8/5.

Riešenie musí obsahovať:

• pokročilú technológiu vytvárania snímkou zaisťujúcu plánovateľnú a temer okamžitú ochranu dát zdieľaných zložiek a jednotiek LUN,
• obnovu dát na úrovni súborov a zložiek s obnovením konkrétnych súborov alebo zložiek,
• flexibilný systém kvóty pre zálohy,
• automatické opravy súborov napr. pomocou zrkadlených metadát a konfiguráciou RAID,
• vloženú komprimáciu dát pred zápisom na disk,
• možnosť integrácie s ľubovoľnou virtualizačnou platformou,
• zálohovanie bez licencií určených k ochrane počítačov a serverov so systémom Windows,
• virtuálnych počítačov, ďalších súborových serverov a cloudových aplikácií,
• konsolidáciu úloh zálohovania pre fyzické i virtuálne prostredie s možnosťou rýchleho obnovenia súborov, celých fyzických počítačov a virtuálnych počítačov,
• zálohovanie v prostredí Google Workspace, Gmail, kontaktov, kalendárov a služby Drive zálohovanie dát sady Microsoft 365, OneDrive for Business, SharePoint Online, e-mailov, kontaktov a kalendárov.

Súčasťou riešenia budú aj inštalačné, konfiguračné a migračné práce:

• Analýza a zber údajov
  • 1 Analýza prostredia, plán implementácie, projektové riadenie.
• Inštalácia a konfigurácia HW/SW
  • 1 Inštalácia a konfigurácia Server (Upgr. Firmware, konfigurácia RAID, nastavenie BIOS, Management)
  • 2 Upgrade Firmware UPS MNC
  • 2 Upgrade Firmware UPS
  • 1 Inštalácia a konfigurácia vSphere ESXi (existujúca licencia)
  • 1 Inštalácia a Konfigurácia IPM (alebo obdobného softvéru k UPS podľa bodu 2, vrátane licencie pre min. 3 power nodes
• Inštalácia a konfigurácia Backup/Replica SW
  • 1 VEEAM BACKUP Infraštruktúry (mng, proxy, repository, ...)
  • 1 Nastavenie replikačných jobov vo Veeam B&R
  • 1 Opatrenia na zabezpečenie zálohovacej infraštruktúry Veeam, minimalizácia „viditeľnosti“ zálohovacej infraštruktúry v LAN
• Fyzické zapojenie HW
  • 1 Montáž rack, polica, PDU
  • 1 SERVER - montáž do racku, zapojenie - napájanie, networking, manažment
  • 2 UPS – montáž do racku, zapojenie - napájanie, manažment
• Odovzdanie projektu
  • 1 Základné zaškolenie
  • 1 Základná dokumentácia

Bezpečnostný monitoring ako služba

Súčasťou tejto aplikačnej služby je implementácia centrálneho Log Manažment Systému (LMS) pre účely zberu logov z jednotlivých agendových, podporných a infraštruktúrnych systémov a koncových zariadení. Zariadenia pre LMS sa nakúpia do majetku mesta, ale ďalšia správa LMS bude následne zabezpečená formou služby (LMS as a service) externým dodávateľom spolu so službou bezpečnostného monitoringu (SIEM/SOC as a service).

LMS bude poskytovať dostatočnú kapacitu pre uloženie všetkých logov min. po dobu 6 mesiacov. Implementácia zahŕňa zmapovania súčasných logov, nastavenie logovania zo všetkých relevantných systémov, aplikácii a sieťových zariadení a ich konsolidácia. Predpokladaná kapacita pre uloženie logov je 10 TB. Predpokladaný počet EPS je 500. Počet účtov v AD cca 90.

Súčasťou aktivity bude aj zladenie interných procesov riešenia bezpečnostných incidentov (smernica o monitorovaní a riešení bezpečnostných incidentov uvedená v bode 1.1) s procesmi SOC externého dodávateľa a zabezpečenie a sprevádzkovanie sieťovej konektivity.

Služba SIEM/SOC musí zahŕňať:

• zber a monitorovanie udalostí v sieťach a kritických prvkoch informačných systémov v režime 24 x 7,
• sondu pre zber údajov – virtuálne zariadenie,
• nepretržitá detekcia kyberneticko-bezpečnostných incidentov,
• zber relevantných informácií pri zistených kybernetických incidentoch,
• návrh riešenia kybernetických bezpečnostných incidentov a zníženia následkov zistených kybernetických bezpečnostných incidentov,
• vyhodnocovanie riešenia kybernetických bezpečnostných incidentov a návrh systémových opatrení s cieľom minimalizovať výskyt obdobných kybernetických bezpečnostných incidentov,
• podrobná evidencia bezpečnostných incidentov, ich riešení a príslušnej komunikácie prostredníctvom na to určeného nástroja (ticketing/service desk),
• pravidelný reporting (1 x mesačne).

Predmetom monitoringu budú nasledovné zariadenia:

• Firewall
• virtuálny server pre informačný systém samosprávy (MS Windows 2012 R2)
• virtuálny server       pre zálohovanie (MS Windows 2012 R2)
• Domain Controler (Active Directory s počtom účtov cca 90) (MS Windows 2012 R2)
• virtuálny server pre zverejňovanie na (MS Windows 2012 R2)
• pracovné stanice a noteboky W7 (cca 30), W8 (cca 10), W10 (cca 40) , W11 (cca 20) v počte spolu cca 100 ks.

Súčasťou služby a jej ceny musia byť všetky implementačné, softvérové, hardvérové a licenčné prostriedky potrebné pre jej chod.

Fungovanie SOC bude riešené formou „as a service“ a teda externý dodávateľ poskytne skúsený tím odborníkov, SOC procesov, CSIRT procesov a pod. Takýto spôsob realizácie umožní jednak eliminovať mesačné náklady na prevádzku SOC-u a zároveň umožní zabezpečiť efektívny spôsob ochrany kybernetického priestoru. SOC ako služba poskytne najmä efektívny bezpečnostný monitoring výskytu mimoriadnych udalostí a bezpečnostných incidentov a zabezpečenie adekvátnej reakcie na bezpečnostné incidenty. Okrem toho poskytne pokročilé analýzy bezpečnostných incidentov a ich vyšetrovanie, podporu riešenia bezpečnostných incidentov a uvedenia systémov späť do bežnej prevádzky, knowledge base ohľadom jednotlivých incidentov a spôsobov ich riešenia a reporting a štatistiky ohľadom jednotlivých a sumárnych bezpečnostných incidentoch, ich závažnosti a dopadoch.

Zavedenie SOC as a service – Security Operation Centre ako služby prinesie najmä:

• nastavenie procesného fungovania SOC a previazanie interných a externých procesov a roly: definícia roly, procesný model, zavedenie do praxe, prispôsobenie interných nástrojov (napr. service desk) a LMS systému, právna podpora, úprava interných smerníc a pod.,
• vytvorenie interných KB databáz vrátane iniciálneho naplnenia a školení pre riešenie bezpečnostných incidentov.

Pre službu SOC požadujeme nasledovné SLA parametre:

• Incident kategórie HIGH - vysoko nebezpečné incidenty, ktoré môžu spôsobiť vážne škody resp. môžu mať negatívny dopad na kritické aktíva.
  • maximálne 2 hodiny.
• Incident kategórie MEDIUM - incidenty strednej závažnosti, t.j. ktoré akútne neohrozujú kritické časti prostredia.
  • maximálne 4 hodiny.
• Incident kategórie LOW - incidenty nízkej závažnosti bez priameho negatívneho vplyvu na kontinuitu služby.
  • maximálne 8 hodín.

Riadenie kapacít

Požadujeme nasadenie nástroja na riadenie kapacít v súlade s §10 písm. b) vyhlášky NBÚ č. 362/2018 Z. z., ktorou sa ustanovuje obsah bezpečnostných opatrení, obsah a štruktúra bezpečnostnej dokumentácie a rozsah všeobecných bezpečnostných opatrení.

Musí byť pokryté monitorovanie dostupných technologických kapacít dôležitých sieťových zariadení a služieb podľa nakonfigurovaných pravidiel. Monitorovací nástroj musí informovať o vzniknutých technických problémoch a nedostatku kapacít správcu príslušnej služby alebo servera. Musí byť schopný monitorovať rôzne druhy zariadení ako sú fyzické a virtuálne servery, sieťové prvky, dátové úložiská a iné zariadenia, ktoré dokážu poskytnúť údaje o svojej prevádzke. Monitoring musí byť v reálnom čase s možnosťou údaje okamžite vizualizovať prostredníctvom grafov, máp a rôznych náhľadov. Musí byť schopný porovnávať dáta v rôznych časových obdobiach, analyzovať históriu.

Funkčné požiadavky:                 

• Monitorovanie kľúčových informačných systémov a ich jednotlivých komponentov.
• Nastavenie prahových hodnôt alertov a notifikácií.
• Eskalácia notifikácií.
• Tvorba reportov.
• Tvorba vlastných sledovacích schém.

Do monitoringu bude zahrnutých 10 zariadení a služieb, komponentov infraštruktúry z množiny:

• Sieťových a výkonových zariadení.
• VMware služieb.
• Databázových a zálohovacích zariadení.
• Webových služieb.
• Kritického hardvéru.                    

Zber údajov musí podporovať: 

• Agentov SNMP a IPM.
• Bezagentový a špeciálny monitoring.
• Monitoring virtuálnych zariadení.
• Webové aplikácie a Java scenáre.
• Monitoring databáz.
• Kalkulované a agregované položky.
• Interné sledovanie výkonu.

Musí byť podporovaná vizualizácia vo webovom rozhraní a informovanosť v rozsahu:             

• Grafov a máp so zloženými pohľadmi.
• Globálnych Dashboardov.
• Prístupu k získaným hodnotám a zoznamu udalostí.
• Zasielania oznámení.
• Potvrdenia a eskalácie prijatých informácií.
• Schopnosti prijať opatrenia.

Systém musí byť schopný automatizácie, napr. cez Network alebo Low-level discovery. Musí byť schopný správy aj cez smartfón, schopný nasadenia vlastných skriptov s prístupom k funkciám cez API. Musia sa dať definovať pravidlá hodnotenia údajov poskytujúce logické definície stavu zariadení.

Súčasťou implementácie nástroja bude aj zabezpečenie skenovania zraniteľností interných systémov mesta formou služby min. 1x ročne. Súčasťou projektu bude pilotné otestovanie zraniteľností a preukázanie funkčnosti dodávanej služby počas nasledujúceho obdobia. Výsledkom pilotného testovania bude report obsahujúci zoznam identifikovaných zraniteľností, úroveň ich závažnosti a návrh na ich odstránenie.

Okrem toho bude súčasťou riešenia aj dokončenie návrhu segmentácie sietí, za účelom odčlenenia pracovných staníc do samostatného segmentu a nastavenie prestupových FW pravidiel.

Riadenie prístupov – Identifikácia a autentifikácia - Zavedenie 2FA (dvoj-faktorová autentifikácia)

Návrh a zabezpečenie SW/HW riešenia 2FA  (formou mobilnej autentifikácie) na strane používateľov pri vzdialenom prístupe (VPN) a na strane administrátorov, resp. tzv. „power users“ pri prístupe k správe systémov Mesta Stará Ľubovňa. Požadujeme:

• rozšírenie licencií existujúceho NGFW Fortigate pre VPN vzdialený prístup s využitím 2FA pre cca 50 používateľov (Forti Token Mobile licencie),
• zabezpečenie licencií a SW riešenia pre 2FA na prístup tzv. “privilegovaných používateľov” k jednotlivým IS Mesta Stará Ľubovňa – cca do 10 administrátorov, dvojfaktorová autentifikácia bude riešená mobilnou aplikáciou, ktorá zabezpečí druhý autentifikačný faktor.

Zavedenie 2FA umožní zvýšenie úrovne identifikácie a najmä autentifikácie pracovníkov, ale aj zvýšenie úrovne bezpečnosti pri správe IKT  z pozície tzv. „power users" a administrátorov systémov. Dvojfaktorová autentifikáciu je v súčasnosti takmer nevyhnutnou formou zabezpečenia takmer všetkých účtov a služieb, ktoré sú dôležité. Dvojfaktorová autentifikácia umožní ochrániť od neautorizovaného prístupu útočníkov aj v prípade ak získajú prihlasovacie údaje, nakoľko sa nedostanú cez overenie v druhom kroku. S ohľadom na uvedené bude v rámci realizácie projektu riešený práve tento systém ochrany pre potreby zabezpečenia VPN pripojenia do LAN siete Mesta Stará Ľubovňa.

Dvojfaktorová autentifikácia bude riešená Tokenmi generovanými mobilnou aplikáciou.

2FA je v projekte nastavená pre viacero typov používateľov:

• Obyčajný používateľ pri prístupe cez VPN, pre ktorého bude zavedenie komponentu predstavovať použitie ďalšieho prostriedku autentifikácie (2FA), ktorý bude predstavovať aplikácia v mobilnom telefóne.
• Administrátor, alebo „power user“ pri prístupe k správe prideleného IS bude mať k dispozícii rovnako aplikáciu v mobilnom telefóne, ktorá zabezpečí druhý autentifikačný faktor.

Funkčné a výkonové požiadavky:

• riešenie využívajúce softvérový autentifikátor dostupný pre platformy mobilných telefónov iOS a Android.
• auto-aktivácia používateľa bez potreby prítomnosti správcu systému,
• možnosť distribúcie autorizačného kódu autentifikácie druhého faktoru:
  • formou výzvy (push notifikácia),
  • formou SMS,
• pre všetkých zamestnancov pristupujúcich cez VPN (cca 50 zamestnancov),
• pre všetkých „power users“ (do 10 administrátorov),
• integrácia s vybranými existujúcimi systémami:
  • minimálne s AD,
  • s FW na perimetri siete pre vzdialený VPN prístup používateľov do internej LAN a k sieťovým službám,
• prideľovanie oprávnení správcom na základe rolí (vlastník systému, IT správca systému, Správca integrácií, Správca používateľov, Podpora používateľov/Helpdesk),
• možnosť vytvárania skupín používateľov a zaraďovanie používateľov do skupín,
• možnosť vytvárania politík a ich aplikovanie:
  • na skupiny používateľov,
  • na používateľa podľa jeho geo-lokácie,
  • na používateľa na základe stavu bezpečnosti jeho terminálu, ktorým sa pripája,
  • na používateľa na základe stavu bezpečnosti mobilného zariadenia používateľa používaného na distribúciu autorizačného kódu,
  • na základe jednotlivých integrácií,
• logovanie:
  • histórie prístupov používateľov (meno, dátum, čas, terminál používateľa, sprístupnený systém, geo-lokácia IP adresy, atď.),
  • informácií o mobilných zariadeniach používateľov použitých na distribúciu autorizačného kódu,
  • úspešných aj neúspešných prihlásení,
• automatická detekcia anomálií a rizika pri prihlasovaní.

3.2.2        Rozsah informačných systémov – AS IS

Implementované bezpečnostné riešenia sa budú dotýkať najmä zvýšenia ochrany a bezpečnosti nasledovných IS:

Čiastočne a okrajovo sa implementované bezpečnostné opatrenia a riešenia budú dotýkať aj nasledovných infraštruktúrnych a podporných IS, ktoré ale nie sú ISVS:

3.2.3        Rozsah informačných systémov – TO BE

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.2.4        Využívanie nadrezortných a spoločných ISVS – AS IS

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.2.5        Prehľad plánovaných integrácií ISVS na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013  e-Governmente – TO BE

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.2.6        Prehľad plánovaného využívania iných ISVS (integrácie) – TO BE

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.2.7        Aplikačné služby pre realizáciu koncových služieb – TO BE

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.2.8        Aplikačné služby na integráciu – TO BE

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.2.9        Poskytovanie údajov z ISVS do IS CSRÚ – TO BE

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.2.10      Konzumovanie údajov z IS CSRU – TO BE

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.3        Dátová vrstva

Z pohľadu dátového modelu nejde o typické biznis (agendové) dáta ale o dáta typu:

• Bezpečnostná dokumentácia a politiky, postupy, analýzy, reporty a pod. – ako výstupy aktivity projektu určené pre ďalšie riadenie rozvoja KIB,
• bezpečnostné konfigurácie a bezpečnostné dáta (napr. logy) – pre fungovanie jednotlivých bezpečnostných komponentov.

Bezpečnostná dokumentácia a politiky, postupy, analýzy, reporty a pod. sú určené pre proces riadenia KIB.

Bezpečnostné konfigurácie a bezpečnostné dáta slúžia pre správne fungovanie bezpečnostných modulov, t.j. jednotlivé komponenty tohto navrhovaného riešenia a zároveň reprezentujú vyhodnocovanie bezpečnostných udalostí a potenciálnych bezpečnostných incidentov.

3.3.1        Údaje v správe organizácie

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.3.2        Dátový rozsah projektu - Prehľad objektov evidencie - TO BE

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.3.3        Referenčné údaje

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.3.4        Kvalita a čistenie údajov

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.3.5        Otvorené údaje

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.3.6        Analytické údaje

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.3.7        Moje údaje

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.3.8        Prehľad jednotlivých kategórií údajov

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.4        Technologická vrstva

3.4.1        Prehľad technologického stavu - AS IS a TO BE

V rámci as-is stavu dnes v rámci Mesta Stará Ľubovňa neexistuje bezpečnostná technológia, ktorá je predmetom tohto projektu.

Z pohľadu to-be bude finálna technologická vrstva závislá od výsledkov verejného obstarávania a technológie, ktorú ponúkne víťazný uchádzač.

Niektoré bezpečnostné riešenia totižto poskytujú viacero alternatív a dajú sa implementovať napr. ako virtuálny appliance, ale prípadne aj ako HW appliance. Predpokladom však je, že väčšina bezpečnostných riešení bude nasadená do virtuálneho prostredia Mesta Stará Ľubovňa, a niektoré riešenia budú nasadené ako cloudová služba, a niektoré ako samostatný HW appliance, prípadne budú nasadení rôzni agenti do infraštruktúry Mesta Stará Ľubovňa.

Vzhľadom na uvedené skutočnosti predpokladáme „high level“ technologickú architektúru tak, ako je uvedené na nasledujúcom obrázku:

3.4.2        Požiadavky na výkonnostné parametre, kapacitné požiadavky – TO BE

Predpokladané výkonnostné parametre a kapacitné požiadavky sú, tam kde je to relevantné, uvedené v popise aplikačnej architektúry jednotlivých aplikačných funkcií a aplikačných modulov.

3.4.3        Návrh riešenia technologickej architektúry – popísané vyššie v rámci ASIS -TOBE

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.4.4        Využívanie služieb z katalógu služieb vládneho cloudu

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

3.5        Bezpečnostná architektúra

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy, ale práve o implementáciu bezpečnostných riešení, takže všetky úrovne architektúry zároveň tvoria aj bezpečnostnú architektúru riešenia.

4.     Závislosti na ostatné ISVS / projekty

Bez závislostí na iné projekty.

5.     Zdrojové kódy

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

Riešenie nepredpokladá vývoj softvéru, ale použitie komerčných bezpečnostných produktov a zariadení.

6.     Prevádzka a údržba

Aktivita podpora Governance v oblasti KIB si nevyžaduje žiadnu budúcu prevádzku, nakoľko ide len o analytické a konzultačné práce, ktorých výstupy budú použité pre proces riadenia KIB (Governance) . Výstupy Governance aktivít samozrejme tiež budú musieť byť udržiavané a rozvíjané, to by však malo byť realizované pomocou interných zamestnancov bez priameho vplyvu na rozpočet.

Pre aktivity napr.:

• nasadenie nástroja na podporu riadenia aktív a rizík,
• poskytovanie LMS/SIEM/SOC ako služby,
• implementácia riadenia kapacít,
• nasadenie ochrany citlivých dát (DLP),
• implementácia riadenie prístupov (2FA),
• implementácia riadenie kontinuity (zálohovanie)

sú rámcové požiadavky na prevádzku a údržbu zadefinované nižšie.

6.1        Prevádzkové požiadavky

Všetky ďalšie parametre a požiadavky na prevádzku a údržbu sa týkajú už len nasledovných aktivít:

• nasadenie nástroja na podporu riadenia aktív a rizík,
• poskytovanie LMS/SIEM/SOC ako služby,
• implementácia riadenia kapacít,
• nasadenie ochrany citlivých dát (DLP),
• implementácia riadenie prístupov (2FA),
• implementácia riadenie kontinuity (zálohovanie).

6.1.1        Úrovne podpory používateľov

Táto kapitola je irelevantná pre predmet projektu – implementácia bezpečnostných riešení. Nejde o agendový alebo iný informačný systém verejnej správy.

6.1.2        Riešenie incidentov – SLA parametre

Označenie naliehavosti incidentu:

možný dopad:

 Výpočet priority incidentu je kombináciou dopadu a naliehavosti v súlade s best practices ITIL V3 uvedený v nasledovnej matici:

Vyžadované reakčné doby:

6.2        Požadovaná dostupnosť IS:

6.2.1        Dostupnosť (Availability)

Požadovaná dostupnosť pre aktivitu projektu:

• nasadenie nástroja na podporu riadenia aktív a rizík,

je:

• 96% dostupnosť znamená výpadok 15 dní.

Požadovaná dostupnosť pre aktivity projektu:

• poskytovanie LMS/SIEM/SOC ako služby,
• implementácia riadenia kapacít,
• nasadenie ochrany citlivých dát (DLP),
• implementácia riadenie prístupov (2FA),
• implementácia riadenie kontinuity (zálohovanie)

je:

• 98,5% dostupnosť znamená výpadok 8,25 dňa.

Za týmto účelom bude aj s dodávateľom služby LMS/SIEM/SOC as a service uzatvorená rovnaká dohoda o úrovni poskytovaných služieb (SLA), ktorá bude požadovať uvedenú dostupnosť poskytovanej služby.

6.2.2        RTO (Recovery Time Objective)

Zavedenie aktivity:

• nasadenie nástroja na podporu riadenia aktív a rizík,

si bude vyžadovať prvý stupeň obnovy, t. j. „cold site“ backup.

RTO pre tieto aktivity je definované na 3 dni.

Zavedenie aktivít:

• poskytovanie LMS/SIEM/SOC ako služby,
• implementácia riadenia kapacít,
• nasadenie ochrany citlivých dát (DLP),
• implementácia riadenie prístupov (2FA),
• implementácia riadenie kontinuity (zálohovanie)

si budú vyžadovať tretí stupeň, t.j. rýchlu obnovu.

RTO pre tieto aktivity je definované na 24 hodín.

6.2.3        RPO (Recovery Point Objective)

Aktivita:

• nasadenie nástroja na podporu riadenia aktív a rizík,

si bude vyžadovať len tradičné zálohovanie, avšak RPO pre tieto aktivity je definované na 3 dni.

Nasledovné aktivity:

• poskytovanie LMS/SIEM/SOC ako služby,
• implementácia riadenia kapacít,
• nasadenie ochrany citlivých dát (DLP),
• implementácia riadenie prístupov (2FA),
• implementácia riadenie kontinuity (zálohovanie)

si bude vyžadovať asynchrónnu replikáciu dát. RPO pre tieto aktivity je definované na 8 hodín.

7.     Požiadavky na personál

Požiadavky sú popísané v dokumente Projektový zámer.

8.     Implementácia a preberanie výstupov projektu

V projekte neprebieha vývoj/implementácia.

9.     Prílohy