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 – Východoslovenský onkologický ústav, a.s. má za cieľ zvýšiť úroveň informačnej a kybernetickej  bezpečnosti v zdravotníckych zariadeniach.

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“).
• 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. Východoslovenský onkologický ústav, a.s. (ďalej ako „VOU KE“) nemá zavedený governance KIB a nemá vypracovanú analýzu rizík, 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 VOU KE ž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 kontinuity činností.
  • Proces riadenia kontinuity činností a obnovy.
  • Proces zálohovania.
• Zaznamenávanie udalostí a monitorovanie.
  • Proces zberu, ukladania a riadenia logov.
  • Proces bezpečnostného monitoringu koncových staníc.
  • Proces bezpečnostného monitoringu systémov a dátových úložísk.
  • Proces bezpečnostného monitoringu sieťových prvkov a sieťovej infraštruktúry.
  • Proces bezpečnostného monitoringu aktivít používateľov.
  • Proces bezpečnostného monitoringu aktivít privilegovaných používateľov.
  • Proces vyhodnocovania udalostí a identifikácie bezpečnostných incidentov.
• Riešenie bezpečnostných incidentov.
  • Proces riešenia kybernetických bezpečnostných incidentov.

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

• governance KIB a bezpečnostná dokumentácia,
• vytvorenie úvodnej GAP analýzy voči požiadavkám aktuálnej legislatívy, najmä zákon o KB,
• zavedenie procesov riadenia KIB pre všetky relevantné oblasti riadenia.

Požiadavky na vypracovanie kontinuity činností sú nasledovné:

Predmetom tejto aktivity bude zadefinovanie stratégie obnovy pre jednotlivé IS a plánu zálohovania pre jednotlivé IS a dáta a následne vytvorenie BCP a DRP plánov.

Výsledkom bude najmä:

• Definovanie stratégie obnovy (na základe výsledkov RTO určených vlastníkmi aktív v aktivite 1.3).
• Plán zálohovania (na základe výsledkov RPO určených vlastníkmi aktív v aktivite 1.3) a smernica ohľadom postupov zálohovania.
• Vytvorenie BCP plánov pre najkritickejšie procesy (rádovo do 6 plánov).
• Vytvorenie DRP pre najkritickejšie IS a zariadenia (rádovo do 8 plánov).

Kontinuita činností musí okrem iného zadefinovať scenáre 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.

Kontinuitou musia byť zavedené postupy zálohovania na obnovu 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.

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:

• Správa dokumentov.
  • Proces evidencie a správy bezpečnostnej dokumentácie.
• Zaznamenávanie udalostí a monitorovanie.
  • Proces zberu, ukladania a riadenia logov.
  • Proces bezpečnostného monitoringu.
  • Proces vyhodnocovania udalostí a identifikácie bezpečnostných incidentov.

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 VOU KE.

Zaznamenávanie udalostí a monitorovanie (Bezpečnostný monitoring)

Tento aplikačný komponent môže byť dodaný ako dve samostatné riešenia, prípadne ako jedno ucelené riešenie obsahujúce oba požadované aplikačné komponenty LMS a SIEM. Výsledok bude závislý od víťaznej ponuky na toto riešenie.

Požiadavky na komponent LMS sú nasledovné:

Nasadenie Log manažment systému (LMS) za účelom agentského aj bez-agentského zberu logov zo systémov VOU KE, aplikácií a sieťových prvkov pre následné nasadenie Security Incident and Event Management (SIEM) systému.

LMS bude poskytovať dostatočnú kapacitu pre uloženie všetkých logov min. po dobu 6 mesiacov. Predpokladaná kapacita pre uloženie logov je 10 TB. Predpokladaný počet EPS je 500. Počet účtov v AD je cca 240.

Súčasťou nasadenia LMS bude aj vykonanie komplexnej konsolidácie všetkých logov pre efektívne a spoľahlivé fungovanie SIEM vrátane nasledovných činností:

• zmapovania súčasných logov,
• analýza a návrh spôsobu zaznamenávania logov a auditných udalostí,
• analýza ich centrálneho zberu a zhromažďovania, ukladania, uchovávania, rotácie,
• poskytovanie analýz a reportovanie počas pilotnej fázy projektu,
• parsovanie logov – pre definované OS, sieťové zariadenia, aplikácie a pod.,
• nasadenie prípadných agentov na zbieranie logov pre vybrané operačné systémy.

Súčasťou implementácie LMS budú aj analytické, integračné a konfiguračné práce na napojení, zasielaní logov z LMS do SIEM.

Základné požiadavky na LMS sú nasledovné:

• umožňuje spracovanie logov z preddefinovaných zdrojov logov aplikácií, operačných systémov a sieťového hardware minimálne v rozsahu: Windows server Active Directory; Windows server File system; Linux server,
• podporuje štandardné protokoly pre integráciu a zber logov,
• uchováva pôvodnú informáciu zo zdroja logu o časovej značke udalosti,
• vykonáva konsolidáciu logov na centrálnom mieste,
• umožňuje jednoduché vyhľadávanie v logoch a okamžité vytváranie reportov bez nutnosti dodatočného programovania,
• v prípade preťaženia systému nesmie dôjsť k strate logov,
• umožňuje prijímať a spracovávať logy, udalosti a ďalšie strojovo generované dáta prostredníctvom minimálne nasledujúcich protokolov: UDP, TCP, TCP/TLS pričom pre spomínané protokoly umožňuje výber čísla portu v rozsahu 1 – 65535,
• umožňuje zber udalostí vo formátoch RAW, Syslog, CEF, LEEF, JSON,
• umožňuje prijaté logy štandardizovať do jednotného formátu, logy sú rozdeľované do príslušných polí podľa ich typu,
• umožňuje doplnenie užívateľsky dostupného analyzátora (parser) pre zariadenia, aplikácie alebo systémy mimo uvedeného zoznamu užívateľom bez nutnosti spolupráce s výrobcom alebo dodávateľom ponúkaného systému - užívateľsky definované parsery,
• parser musí umožňovať pre hodnoty jednotlivých parsovaných polí zmeniť typ a štandardizovať minimálne tieto základné druhy:
  • číslo,
  • IP adresa,
  • URL,
• umožňuje pri vyhľadávaní nad uloženými dátami typu číslo vykonať matematické operácie (súčty všetkých hodnôt, priemery, najmenšie/najväčšie a pod.)
• umožňuje uloženie užívateľom vytvorených pohľadov na dáta (dashboardov) pre budúce spracovanie,
• obsahuje predpripravené pohľady na uložené logy podľa jednotlivých kategórií zdrojových zariadení aj podľa logického členenia,
• umožňuje kapacitnú aj výkonovú škálovateľnosť,
• umožňuje definovať podmienky prekročenia prahových hodnôt alebo systémových chýb
• umožňuje vykonávať konfiguráciu systému v grafickom rozhraní jednotnej užívateľskej konzoly,
• obsahuje jednotnú centrálnu webovú konzolu pre prístup k logom a pre správu systému, z tejto konzoly sa vykonáva kompletná konfigurácia, správa a analýza logov,
• umožňuje vyhľadávať prijaté údaje na základe zadaných podmienok,
• umožňuje jednoduché vytváranie užívateľských rolí definujúcich prístupové práva k uloženým udalostiam a jednotlivým ovládacím komponentom systému,
• umožňuje definovanie korelačných pravidiel udalostí a upozornenie s hraničnými limitmi,
• riešenie umožňuje realizáciu tzv. kaskádových dotazov (kaskádové dotazy sú dotazy generované na základe údajoch vrátených z predchádzajúceho dotazu, príkladom by mohlo byť zobrazenie aktív, na ktoré sa vzťahuje alert, s následnou možnosťou rozbalenia na používateľov, ktorých sa táto stránka s výsledkami vyhľadávania týka).

Transport logov do centrálneho úložiska musí byť z dôvodu bezpečnosti šifrovaný a z dôvodu úspory šírky dátového prenosu linky komprimovaný.

Požiadavky na komponent SIEM sú nasledovné:

V rámci bezpečnostného monitoringu ide o dodanie licencií, implementačných, konzultačných a konfiguračných prác pre zavedenie systému bezpečnostného monitoringu (SIEM) pre účely agentského aj bez-agentského zberu logov zo systémov VOU KE, vrátane zaškolenia administrátora VOU KE.

Systém pre bezpečnostný monitoring (SIEM) bude poskytovať konfigurovateľnú funkcionalitu detekcie hrozieb a reakcie na bezpečnostné incidenty pomocou „real time“ vyhodnocovania a korelácie logov z LMS systému pre širokú škálu hrozieb a útokov. SIEM bude poskytovať možnosť monitorovať virtuálne, ale aj fyzické systémy infraštruktúry. SIEM bude monitorovať a korelovať všetky typy logovaných udalostí, vrátane rôznych OS (Windows, Unix) a zariadení (IDS/IPS, FW a pod.).

Tento systém bude poskytovať najmä nasledovnú funkcionalitu:

• XDR (Extended detection and response),
• ABA (Attacker Behavior Analytics),
• UBA (User Behavior Analytics),
• NTA (Network Traffic Analysis),
• FAAM (File Access Activity Monitoring),
• FIM (File Integrity Monitoring),
• Deception Technology (Honey Pots/User/File/Credential)

pre zabezpečenie komplexného monitoringu a možnosti vyhodnocovania bezpečnostných udalostí.

Je nevyhnutné, aby monitorovací systém bol úplne nezávislý od použitej sieťovej infraštruktúry a neovplyvňoval monitorovanú sieť, systémy a zariadenia v ich funkcii. Monitorovací systém nesmie byť zistiteľný z monitorovanej siete. Riešenie bude nezávislé od existujúcej sieťovej infraštruktúry (optická alebo metalická dátová kabeláž) a použitých aktívnych prvkov (typ alebo výrobca).

Systém musí podporovať infraštruktúru typu: IPv4, IPv6, VLAN, MPLS, Ethernet 10 Mb/s až 100 Gb/s.

Riešenie bude centrálne spravované a konfigurované z centrálnej jednotky a poskytne centrálny prehľad o analýze tokov, upozorneniach a hláseniach.

Systém musí umožniť detekciu na základe správania a reputácie, rýchlu reakciu na identifikované incidenty, automatické prerušenie pokročilých kybernetických útokov na úrovni jednotlivých zariadení, pokročilú analytiku a automatizáciu, prioritizáciu incidentov a pod.

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 VOU KE 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 VOU KE, a niektoré riešenia budú nasadené ako samostatný HW appliance, prípadne budú nasadení rôzni agenti do infraštruktúry VOU KE.

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.:

• implementácia LMS,
• implementácia SIEM,

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:

• implementácia LMS,
• implementácia SIEM,

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 aktivity projektu:

• implementácia LMS,
• implementácia SIEM,

je:

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

6.2.2        RTO (Recovery Time Objective)

Zavedenie aktivít:

• implementácia LMS,
• implementácia SIEM,

si budú vyžadovať tretí stupeň, t.j. rýchlu obnovu. RTO pre tieto aktivity je definované na 8 hodín.

6.2.3        RPO (Recovery Point Objective)

Nasledovné aktivity:

• implementácia LMS,
• implementácia SIEM,

si budú vyžadovať asynchrónnu replikáciu dát. RPO pre tieto aktivity je definované na 4 hodiny.

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