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ého ústavu srdcových a cievnych chorôb, a.s. (ďalej ako „VÚSCH“) má za cieľ zvýšiť úroveň informačnej a kybernetickej  bezpečnosti v sektore zdravotníckych zariadení.

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 aktivity 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 a nemá vypracovanú detailnú 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 VÚSCH ž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.
  • Proces stanovenia stratégie obnovy na základe výsledkov AR/BIA (RTO).
  • Proces definovania plánu zálohovania na základe výsledkov AR/BIA (RPO).
• Riadenie prístupov.
  • Proces MFA k VPN a pre prístup „power users“ k správe IS.
• Sieťová a komunikačná bezpečnosť.
  • Proces „virtuálneho patchovania“ – ochrany kritických prvkov infraštrukltúry („legacy“ systémov).
• Zaznamenávanie udalostí a monitorovanie.
  • Proces bezpečného ukladania a centrálneho zhrávania 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í založený na “machine learning” algoritmoch a sledovaní správania sa používateľov (“behavioral analysis”) a identifikácie kybernetických bezpečnostných incidentov.
• Riešenie bezpečnostných incidentov.
  • Proces vyhodnocovania a riešenia bezpečnostných incidentov a podozrivých udalostí aj vo väzbe na SOC.
• Identifikácia zraniteľností a bezpečnostné testovanie.
  • Proces skenovania zraniteľností jednotlivých IS a sieťových zariadení.
  • Proces zvyšovania kybernetickej odolnosti VÚSCH formou bezpečnostných testovaní (phishing-ových simulácií).

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:

• Riadenie aktív a riadenie rizík.
  • Implementácia nástroja na procesno-organizačné riadenie informačnej a kybernetickej bezpečnosti.
• Riadenie prístupov.
  • Implementácia MFA – MFA k VPN a pre prístup „power users“ k správe IS.
• Sieťová a komunikačná bezpečnosť.
  • Nasadenie bezpečnostného riešenia ochrany kritickej infraštruktúry („legacy“ systémov) formou „virtual patching“.
• Zaznamenávanie udalostí a monitorovanie.
  • Implementácia SIEM s integrovaným LMS.
• Riešenie kybernetických bezpečnostných incidentov.
  • Využitie SOC ako služby od externého subjektu.
• Identifikácia zraniteľností a bezpečnostné testovanie.
  • Implementácia vulnerability skenera.
  • Implementácia nástroja na tvorbu a testovanie phishing kampaní.

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 VÚSCH.

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.

Nástroj bude predstavovať SW riešenie pozostávajúce z funkcionality evidencie a správy informačných aktív organizácie, realizácie klasifikácie informácií a kategorizácie informačných systémov, realizácie analýzy rizík nad identifikovanými aktívami a podpory riadenia identifikovaných rizík.

Nástroj na procesno-organizačné riadenie informačnej a kybernetickej bezpečnosti musí spĺňať najmä nasledovné:

• Centrálna konzola pre používateľov systému prístupná cez web prehliadače (Chrome, Firefox, Safari alebo Edge).
• Centrálna konzola lokalizovaná v Slovenskom jazyku.
• Centrálna správa musí byť prevádzkovaná ako SaaS.
• Podpora požiadaviek legislatívy SR.
• Centrálny dashboard pre rýchle vyhodnotenie aktív (primárne a podporné), rizík podľa kategórie, rizík podľa hrozieb a zraniteľností, aktuálne dosahovaná úroveň súladu s požiadavkami zákona č. 69/2018 Z. z. a vyhlášky č. 362/2018, 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í.
• Podpora prihlásenia prostredníctvom multi-faktorovej autentifikácie.
• Podpora tvorby klasifikácie informácií a kategorizácie sietí a informačných systémov podľa zákona č. 69/2018 Z. z. a doporučení vyhlášky č. 362/2018, vytváranie registrov aktív, hrozieb.
• Parametrizácia systému:
  • Definovanie metódy na výpočet hodnotenia aktív.
  • Definovanie metódy na kategorizáciu rizík.
  • Definovanie bezpečnostnej štruktúry spoločnosti (osoby, organizačné jednotky, role).
  • Definovanie druhov aktív.
  • Definovanie typov aktív.
  • Definovanie vlastných atribútov aktív.
  • Definovanie stupnice pre hodnotenie dôvernosti, dostupnosti, integrity, dopadov, hrozieb a zraniteľností.
  • Definovanie bezpečnostných opatrení.
  • Register dodávateľov.
  • Definovanie kritérií na hodnotenie dodávateľov.
• Register rizík prostredníctvom, ktorého je možné definovať kombinácie hrozba/zraniteľnosť na konkrétne typy aktív.
• Evidencia aktív (manuálne alebo prostredníctvom importu z dátového súboru):
  • Všeobecné (druh, typ, lokalita, garant, administrátor, dodávateľ, prevádzkovateľ, závislosť aktíva na iných aktívach.
  • Hodnotenie aktíva (dôvernosť, dostupnosť a integrita).
  • Identifikácia hrozieb/zraniteľnosti manuálne alebo priamo z registra rizík.
  • Spôsob používania a manipulácie.
  • Vlastné atribúty.
• Mapa aktív pre grafické zobrazenie závislostí medzi jednotlivými aktívami:
  • Zobrazenie priameho vzťahu aktíva a jeho podriadených a nadriadených aktív.
  • Komplexné zobrazenie mapy všetkých aktív.
  • Filtrácia zobrazených aktív (druh alebo kategória aktíva).
• Hodnotenie rizík:
  • Možnosť stiahnuť súbor .pdf s identifikovanými rizikami pre jedno alebo viaceré aktíva.
  • Hodnotenie dopadu identifikovaných rizík.
  • Návrh bezpečnostných opatrení pre zníženie rizika na úrovni aktíva.
  • Výpočet rizika pred a po opatrení bezpečnostného opatrenia.
  • Rozhodnutie o akceptovaní alebo neakceptovaní rizika.
• Hodnotenie opatrení:
  • Zoznam rizík, ktoré bezpečnostné opatrenie rieši.
  • Aplikovateľnosť bezpečnostného opatrenia.
  • Zavedenie bezpečnostného opatrenia a jeho riadenie:
    • ľudské a finančné zdroje, časový harmonogram,
    • evidencia komunikácie riešiteľského tímu.
  • Plán zvládania rizík pre riadenie implementácie bezpečnostných opatrení:
    • Evidencia požiadaviek na ľudské a finančné zdroje.
    • Dátum začatia a ukončenie implementácie.
    • Diskusný priestor pre riešiteľský tím.
  • Hodnotenie dodávateľov:
    • Hodnotenie atribútov dodávateľov aktív.
    • Mapovanie dodávateľov na konkrétne aktíva.
    • Možnosť evidencie podpornej dokumentácie k dodávateľov (zmluvy, SLA,..).
  • Evidencia plnenia požiadaviek legislatívy:
    • ZoKB (zákon č.69/2018 Z. z. a vyhláška č.362/2018 Z. z.).
    • ITVS (zákon č.95/2019 Z. z. a vyhláška č. 179/2020 Z. z.).
    • Jednotlivé požiadavky môžu byť v stave zavedené, v procese zavádzania, neaplikované alebo nezavedené.
    • Ku každej požiadavke je možné pripojiť komentár a záznam zo zoznamu bezpečnostných opatrení.
    • Hodnotenie je možné exportovať do súboru .pdf.
  • Plán kontinuity:
    • Všeobecné údaje o pláne kontinuity (názov, popis, dotknuté aktíva).
    • Definovanie členov analytického, výkonného a riadiaceho tímu.
    • Popis procesu a dokumentácia.
    • Export plánu obnovy do súboru.
  • Auditný log pre zaznamenávanie aktivít v systéme:
    • Systém zaznamenáva aktivitu používateľa (pridanie, zmena, vymazanie) pre konkrétne časti systému (aktívum, atribút aktíva, riziko, ..).
    • Možnosť pozrieť stav pred vykonanou zmenou a po zmene.

Riadenie prístupov – Identifikácia a autentifikácia - Zavedenie MFA (multi-faktorová autentifikácia)

Zavedenie MFA umožní zvýšenie úrovne identifikácie a najmä autentifikácie používateľov, najmä pri vzdialených prístupoch, ale aj zvýšenie úrovne bezpečnosti pri správe IKT  z pozície tzv. „power users" a administrátorov systémov.

Kryptograficky robustná multi-faktorová autentifikácia s ochranou pred phishingom, sociálnym inžinierstvom, brute-force útokom hádania tradičných autentifikačných login mien a hesiel, resp. ochrana pred zneužitím ukradnutých hesiel.

Adaptívne autentifikačné riešenie škálujúce do dimenzií:

• S pravidlami a granularitou používateľských rolí a skupín, podľa zodpovedností a povolených prístupov toho, ktorého používateľa.
• S možnosťou voľby autentifikačnej metódy pravidlami nastavením adekvátne bezpečným spôsobom – napríklad používateľ autentifikovaný push notifikáciou jednorazového hesla dostáva úplnejší prístup, na rozdiel od používateľa autentifikovaného cez SMS, ktorý dostáva limitovaný prístup.
• Determinované aplikáciami – napríklad pre vysoko senzitívne aplikácie a dáta je vyžadovaný vyšší typ autentifikačných metód s vyšším stupňom bezpečnosti – ako sú push notifikácia a WebAuthn a podobné metódy.
• Možnosť reštriktívne obmedziť prihlasovanie a autentifikáciu z vopred definovanej povolenej geografickej lokácie a zamedziť prihlasovanie z iných domén a lokácií (iná krajina, iný kontinent, a pod.).
• Podmienečné nastavenie úrovne prihlasovania – z dôveryhodnej lokality základný stupeň bezpečnosti a overenie, z iných domén možnosť vyžadovať viac bezpečný stupeň overenia.
• Možnosť definovať sieťové rozsahy pre overenie užívateľa – výberom povoleného rozsahu IP adries (možnosť zakázať prípojné body anonymizačnej siete ToR, použitie proxy alebo neznámych VPN skrývajúcich identitu).

Spôsoby multi-faktorovej autentifikácie musia zahŕňať okrem iného aj tieto metódy:

Push notifikácia na uzamknutý mobil/tablet/koncové zariadenie. Push notifikácia je silnejší nástroj s menšou zraniteľnosťou ako zasielanie jednorazového hesla formou PIN-u alebo znakového reťazca. Tieto je totiž možné odpozorovať útočníkom a zneužiť neautorizovanou osobou.

WebAuth metóda – posúva autentifikáciu od potreby vlastniť predmet (a ten môže byť odcudzený za účelom zneužitia) k autentifikácii cez biometrické senzory (unikátne papilárne čiary na prstoch, alebo dúhovka oka a pod.). V koncových zariadeniach bez biometrických senzorov v zabudovanej podobe je možné cez štandardizované rozhranie, napríklad USB doplniť čítačku biometrických parametrov formou tokenu s daným rozhraním a rozpoznávaním biometrických údajov.

Podpora integrácie s aplikáciami: HOTP, alebo na HMAC - založené jednorazové heslá one-time password (OTP).

Podpora ZeroTrust a Single-Sign-On (SSO).

Sieťová a komunikačná bezpečnosť

Bezpečnostné riešenie ochrany kritických prvkov infraštruktúry. Zavedenie bezpečnostného riešenia pre ochranu kritických infraštruktúrnych prvkov (serverov) voči zraniteľnostiam – implementácia funkcionality „virtual patching“ pre tzv. „legacy“ systémy, na ktoré už nie sú vydávané bezpečnostné záplaty a ochrany voči tzv. „zero-day“ zraniteľnostiam a zaškolenie administrátorov VÚSCH.

Systému pre zvýšenie kybernetickej odolnosti kľúčovej infraštruktúry VUSCH musí podporovať:

• Implementovanie centrálnej správy onpremise alebo poskytovaná ako služba formou cloudu výrobcu.
• Možnosť inštalácie agenta na nasledujúce operačné systémy:
  • Windows 2000 a novšie.
• Red Hat 5 a novšie.
• Ubuntu 10 a novšie.
• CentOS 5 a novšie.
• Debian 6 a novšie.
• Amazon Linux.
• Oracle Linux 5 a novší.
• SUSE Linux 10 a novší.
• CLoud Linux 5 a novší.
• Solaris 10 a novší.
• AIX 5.3, 6.1, 7.1 a 7.2.
• Funkcionalitu pre detekciu a blokovanie správania sa používateľa/útočníka pre detekciu podozrivých aktivít na koncovom zariadení.
• Funkcionalitu web reputácie url pre detekciu a blokovanie komunikácie na potenciálne škodlivú / podozrivú cieľovú adresu
• Funkcionalitu aplikačného monitorovania a blokovania spustenia podozrivého softvéru na koncovom zariadení.
• Monitorovanie integrity súborov koncového zariadenia prostredníctvom vytvorenia baseline (stav integrity súborov definovanom čase).
• Funkcionalitu inšpekcie logov a udalostí (log manažment) na koncovom zariadení.
• Natívne typy zdrojov udalostí (windows event log) ako aj vlastné zdroje logov vrátane parsovania zdrojových dát.
• Funkcionalitu firewall pre detekciu a blokovanie škodlivej sieťovej komunikácie, pričom podporuje režim odposluchu - sieťová komunikácia nie je rušená, firewall funguje len v režime detekcie/logovania, vhodný na testovanie alebo inline režim - sieťová komunikácia prechádza cez definované pravidlá a na prevádzku sa aplikujú definované akcie na základe zásad a nastavených pravidiel.
• Detekciu a blokovanie pokusov o skenovanie siete, alebo portov alebo techník ako TCP SYNFIN,TCP XMAS, TCP null a podobných.
• Detekciu a prevenciu prienikov (IDS resp. IPS) pre podozrivú sieťovú komunikáciu.
• Automatické skenovanie, ktoré skenuje operačný systém, zisťuje verziu operačného systému, zisťuje nainštalované aktualizácie, zisťuje nainštalované programy a ich verzie a odporúča príslušné pravidlá IPS (tzv. virtuálne záplaty).
• Kontrolu sieťovej komunikácie SSL/TLS (nahraním certifikátu so súkromným kľúčom, ktorý sa používa na dešifrovanie obsahu).
• Inbound a outbound aplikačné integračné rozhranie API.
• Tvorbu vlastných politík pre všetky funkcionality a ich aplikovanie na jednotlivé koncové zariadenia alebo skupiny zariadení.

Systému musí obsahovať:

• Funkcionalitu antimalware pre detekciu a blokovanie škodlivého kódu na koncovom zariadení.
• Funkcionalitu tzv. virtual patching prostredníctvom IPS pravidiel pre blokovanie zneužitia známych zraniteľností (napr. log4shell, ...).

Bezpečnostný monitoring

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) s integrovaným centrálnym log manažmentom pre účely agentského aj bez-agentského zberu logov zo systémov VÚSCH, sieťových zariadení a koncových staníc a dostatočnú kapacitu pre uloženie všetkých logov min. po dobu 12 mesiacov.

Implementovaný systém bezpečnostného monitoringu (SIEM) musí poskytovať najmä nasledovnú funkcionalitu:

• SIEM (Security Information & Event management).
• UBA (User Behavior Analytics).
• ABA (Attacker Behavior Analytics).
• EDR (Endpoint Detection & Response) & FIM (File Integrity Monitoring).
• NTA (Network Traffic Analysis).
• DT (Deception Technology).

Požiadavky na SIEM (Security Information & Event management):

• musí umožňovať zber aplikačných, databázových aj systémových logov zo sieťových aj bezpečnostných zariadení (napr. firewally, sieťové alebo host. IPS/IDS), pracovných staníc, serverov ako aj cloud prostredí (Microsoft Azure, Microsoft 365,..),
• musí zbierať, detegovať a vyhodnocovať udalosti ako sú pokusy o neautorizované prístupy, zmeny integrity vybraných častí operačného systému, útoky škodlivého kódu, botov, neoprávnený prístup k aplikáciám, neautorizovanú zmenu konfigurácií, detegovať chybové stavy siete, porušení bezpečnostných politík,
• musí zbierať, detegovať a vyhodnocovať udalosti ako sú pokusy o neautorizované prístupy, zmeny integrity vybraných častí operačného systému, útoky škodlivého kódu, botov, neoprávnený prístup k aplikáciám, neautorizovanú zmenu konfigurácií, detegovať chybové stavy siete, porušení bezpečnostných politík,
• musí umožňovať uchovávanie pôvodnej informácie zo zdroja logu o časovej značke udalosti,
• nesmie umožniť odstránenie alebo modifikovanie uložených logov administrátorovi systému,
• musí pre každý log mať unikátny identifikátor, pre jednoznačnú identifikáciu,
• podporuje jednoduché vyhľadávanie udalostí a okamžité vytváranie reportov bez nutnosti dodatočného programovania,
• musí podporovať pokročilé korelácie (časové, z viacerých zdrojov, atď.),
• musí podporovať integráciu s Vulnerability Management systémom pre kontextualizáciu aká zraniteľnosť na konkrétnom koncovom bode existuje,
• musí podporovať úpravy alertingu, parsingu bez nevyhnutnosti učiť sa akýkoľvek programovací/skriptovací jazyk (v súlade s požiadavkou na vykonanie týchto zmien vlastnými silami objednávateľa),
• musí podporovať detekciu sieťových incidentov na základe korelácie informácií z poskytnutých logov a bude podporovať behaviorálnu analýzu spracovaných udalostí,
• musí obsahovať Incident Management konzolu pre správu kybernetických bezpečnostných udalostí a incidentov, pričom v rámci konzoly je k dispozícií časový sled udalostí daného incidentu, možnosť prideľovať riešiteľov, možnosť vyvolať akcie pre zisťovanie ďalších informácií, dopĺňanie logov, vrátane podrobných informácií z koncového bodu,
• riešenie bude bez požiadaviek na externý databázový server,
• musí podporovať možnosť tvorby vlastných Dashboardov a Vizuálnych Analýz,
• všetky úkony užívateľa (aj interného) budú auditované,
• musí podporovať pokročilý reporting s možnosťou schedulingu a distribúcie reportu,
• musí podporovať zber dát so šifrovaným prenosom (TLS, prípadne šifrovaný obsah správ) na celej trase zdroj /kolektor/ centrálna konzola,
• musí podporovať outbound API (príkladom môže byť pripojenie sa na externé zariadenia alebo systémy napr. Azure, AWS, Microsoft 365, ticketing system),
• musí podporovať minimálne nasledujúce úrovne užívateľských oprávnení (administrátor, read/write, read/only),
• musí podporovať integráciu s Active Directory,
• podporuje vlastnú alebo externú integráciu s navrhovaným riešením pre Multifaktorovú autentifikáciu (MFA),
• podporuje integráciu na Microsoft Azure a Microsoft 365 pre účely monitoringu aktivít používateľov,
• podporuje spracovanie štruktúrovaných aj neštruktúrovaných dát,
• podporuje vkladanie a monitorovanie vlastných IoC (indikátorov kompromitácie) vrátane manipulácie cez inbound API,
• 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),
• podporuje zber udalostí v prostredí Microsoft:
• udalosti z Microsoft prostredí sú získavané pomocou agenta inštalovaného priamo na koncovom Windows systéme. Windows agent musí súčasne podporovať ako monitoring interných windows logov, tak i monitoring textových súborových logov,
• agent zaisťuje zber nemodifikovaných udalostí a detailné spracovávanie auditných informácií,
• agent zabezpečuje v prípade potreby funkcionalitu kontroly integrity súborov,
• agent zabezpečuje v prípade potreby funkcionalitu auditovania prístupov k súborom na zariadení,
• filtrácia odosielaných udalostí agentom. Nerelevantné logy sú filtrované na strane windows agenta a nie sú odosielané po sieti,
• Windows agent nevyžaduje administrátorské zásahy na koncovom systéme – je centrálne spravovaný a automaticky aktualizovaný priamo z centrálnej správcovskej konzoly systému,
• Windows agent má buffer pre prípad straty spojenia medzi koncovým systémom a centrálnym úložiskom logov,
• podporuje zber udalostí v prostredí Linux / MacOs:
• udalosti z Linux / MacOs prostredí sú získavané pomocou agenta inštalovaného priamo na koncovom Linux / MacOs systéme. Linux / MacOs agent musí súčasne podporovať ako monitoring interných,
• agent zaisťuje zber nemodifikovaných udalostí a detailné spracovávanie auditných informácií,
• agent podporuje nastavenie filtrácie odosielaných udalostí pomocou centrálnej správcovskej konzoly,
• filtrácia odosielaných udalostí agentom. Nerelevantné logy sú filtrované na strane Linux / MacOs agenta a nie sú odosielané po sieti,
• Linux / MacOs nevyžaduje administrátorské zásahy na koncovom systéme – je centrálne spravovaný a automaticky aktualizovaný priamo z centrálnej správcovskej konzoly systému,
• Linux / MacOs agent má buffer pre prípad straty spojenia medzi koncovým systémom a centrálnym úložiskom logov,
• umožňuje generovať alert na základe:
• zhoda s vyhľadávaním reťazcom,
• definovanej nečinnosti,
• definovanej zmeny,
• umožňuje nastavenie sieťových zón a sieťových politík podľa ktorých budú generované alerty,
• umožňuje nastavenie privilegovaných skupín užívateľov Active Directory podľa ktorých budú generované alerty.

Požiadavky na UBA (User Behavior Analytics):

• Podporuje minimálne nasledujúce korelačné pravidlá pre analýzu správania sa užívateľa: Vytvorenie/Zablokovanie/ Resetovanie / Povolenie / Únik účtu.
• Podporuje minimálne nasledujúce korelačné pravidlá pre analýzu správania sa užívateľa:
• Eskalácia privilégií.
• Prijatie podozrivého odkazu v emailovej správe.
• Prístup na podozrivý odkaz cez web.
• Brute Force útok na heslá – lokálny účet.
• Brute Force útok na heslá – doménový účet.
• Autentifikácia užívateľa z podozrivej databázy.
• Manipulácia s lokálnymi udalosťami (event logs).
• Prvé prihlásenie na aktívum.
• Prvé prihlásenie z inej krajiny.
• Prihlásenie z viacerých krajín súčasne.
• Detegovaný hash z podozrivej databáz.
• Spustenie procesu z podozrivej databázy.
• Impersonizácia administrátora.
• Autentifikácia servisným účtom.
• Autentifikácia doménovým účtom.
• Komunikácia s podozrivou IP.
• Spustenie vzdialeného súboru.
• Protokol poisoning.
• Alert z Microsoft Defender ATP.
• Spearphishing URL detegovaná.
• Podporuje úpravu špecifických korelačných pravidiel (vytvorenie investigatívy, vytvorenie informácie, ...).
• Vytvára rizikový profil užívateľa na základe jeho správania.
• Vytvára rizikový profil privilegovaného užívateľa na základe jeho správania.
• Podporuje podrobný monitoring definovaných užívateľov.
• Podporuje podrobný monitoring aktivít privilegovaného užívateľov v lokálnom aj cloud prostredí.

Požiadavky na ABA (Attacker Behavior Analytics):

• podporuje korelačné pravidlá pre analýzu správania sa útočníka ako príklad (Zistenie externej IP pomocou príkazového riadku, Spustenie klúča z registra Windows , Spúšťanie procesov pomocou MMC konzole, Rundl32.exe spúšťa súbor s adresára Program Data, Premenovanie netcat, Windows debug v príkazovom riadku a dalšie,
• umožňuje mapovať správanie sa útočníka podľa taktík z metodiky MITRE ATT&CK:
• Reconnaissance,
• Resource Development,
• Initial Access,
• Execution,
• Persistence,
• Privilege Escalation,
• Defense Evasion,
• Credential Access,
• Discovery,
• Lateral Movement,
• Collection,
• Command And Control,
• Exfiltration,
• Impact,
• podporuje úpravu korelačných pravidiel prostredníctvom výnimiek,
• databáza korelačných pravidiel správania sa útočníka je kontinuálne aktualizovaná o nové techniky používane útočníkmi.

Požiadavky na EDR (Endpoint Detection & Response) & FIM (File Integrity Monitoring):

• podporuje základnú funkcionalitu odozvy na incident (zrušenie bežiaceho procesu, karanténa aktíva) prostredníctvom Windows/Linux agenta priamo z centrálnej konzole,
• podporuje funkcionalitu vyšetrovania incidentu prostredníctvom zberu dôkazov minimálne v rozsahu:
• Arp Cache
• Current Process
• Directory Entry
• Dns Cache
• Installed Service
• Network Connection
• Prefetch Entry
• Registry Key
• Scheduled Task
• User Session
• podporuje funkcionalitu vyšetrovania incidentu prostredníctvom zberu dôkazov preverovaného uživateľa o nasledujúce udalosti:
• Account modified
• Advanced malware alert
• Asset authentication
• Cloud service account modified
• DNS query
• Firewall
• IDS
• Ingress authentication
• Virus infection
• Web proxy
• podporuje rozšírenú funkcionalitu odozvy na incident (spustenie automatizačného workflow,..),
• podporuje funkcionalitu auditovania integrity súborov pre nasledujúce typy súborov Windows:
• .bat
• .cfg
• .conf
• .config
• .dll
• .exe
• .ini
• .sys
• podporuje funkcionalitu auditovania integrity súborov pre nasledujúce typy súborov Linux:
• /bin
• /boot
• /etc
• /sbin
• /usr/bin
• /usr/local/bin
• /usr/local/sbin
• /usr/sbin
• /usr/share/keyrings
• /var/spool/cron

Požiadavky na NTA (Network Traffic Analysis):

• podporuje zber nasledujúcich sieťových udalostí:
• IDS udalosti
• DHCP udalosti
• DNS udalosti
• IPv4 Flows
• môže byť nasadené do internej či externej časti siete bez licenčného obmedzenia množstva nasadených zariadení,
• poskytuje špecifické korelačné pravidlá pre SIEM súvisiace s analýzou sieťovej prevádzky,
• poskytuje špecifické vyhľadávacie vzory (queries) pre SIEM súvisiace s analýzou sieťovej prevádzky,
• poskytuje špecifické šablóny pre tvorbu dashboard v SIEM súvisiace s analýzou sieťovej prevádzky,
• zariadenie pre monitoring môžeme inštalovať do fyzického, virtualizačného alebo cloud prostredia.

Požiadavky na DT (Deception Technology):

• podporuje tvorbu nasledujúcich pascí pre identifikovanie aktivít útočníka:
• HoneyPots
• HoneyFiles
• HoneyUsers
• HoneyCredentials
• poskytuje špecifické korelačné pravidlá pre SIEM súvisiacich s pascami,
• umožňuje vyhladávať vzory (queries) pre SIEM súvisiacich s pascami,
• pasce môžu byť nasadené do internej časti siete bez licenčného obmedzenia množstva nasadených zariadení.

Zavedenie služby SOC as a service

Vybudovanie funkčného a spoľahlivého Security Operation Centra vyžaduje nemalé finančné prostriedky potrebné nielen na nákup technológie samotnej, ale aj na ľudské zdroje. Získať a predovšetkým udržať skúsený personál, schopný efektívne spracovávať veľké množstvo dát a byť schopný intuitívne rozoznať potrebu investigovania kritických situácií, je v dnešnej dobe veľmi zložité.

Práve s ohľadom na uvedené skutočnosti bude opatrenie Security Operation Center (SOC) zabezpečené formou služby od externého subjektu. Predpokladá sa obstaranie rámcovej zmluvy, ktorá sa bude čerpať podľa potrieb a požiadaviek VÚSCH.

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.

Vulnerability manažment

Obstaranie nástroja na skenovanie zraniteľností (vulnerability scaner) pre testovanie interných systémov, vrátane pracovných staníc používateľov a rovnako aj IP adries VÚSCH dostupných zo siete internet. Nástroj musí byť podporovaný výrobcom a musí mať prístup k aktuálnym databázam hrozieb a zraniteľností systémov.

Systém určený na Vulnerability Management musí podporovať:

• Scanovanie minimálne nasledujúcich zariadení a systémov:
  • Windows server.
  • Linux server.
  • Network switch (ako je: Cisco, MikroTik, Fortigate).
  • Firewally (ako je: Fortigate, Cisco alebo MikroTik.
  • SIP/IP telefónia (PBX + terminály).
  • Web server (IIS, Apache).
  • Mail server (ako je MS Exchange, Postfix).
  • Windows/ Linux/ MacOS desktopy a notebooky.
  • Tlačiarne.
• Inštaláciu na Windows alebo Linux operačné systémy.
• Hodnotenie CVSS, CVSSv2, CVSSv3 možnosť zneužitia aktív a náchylnosť k súborom škodlivého softvéru.
• Hybridné formy nasadenia ako fyzické, virtualizované a cloud prostredie.
• Automatické zisťovanie aktív, pričom sa zohľadnia minimálne tieto parametre: adresy IP, adresy MAC a názvu hostiteľa, aby sa zabránilo duplicite.
• Centrálnu správu v geograficky rozptýlenom nasadení skenerov.
• Možnosť skenovania aktív bez-agentským spôsobom.
• Hodnotenie kritickosti aktív definované používateľom, ktoré sa musí zohľadniť v hodnotení rizík.
• Prístup založený na rolách s preddefinovanými aj vlastnými rolami.
• Automatizáciu pracovných postupov, ako je plánovanie skenovania, upozornenia na udalosti a zraniteľnosti skenovania a generovanie a distribúcia správ.
• Neinvazívne aj invazívne kontroly (administrátor môže určiť rušivosť akéhokoľvek skenovania úpravou výkonu skenovania a vykonávaných kontrol pričom administratívne poverenia možno použiť na hĺbkové autentifikované skenovanie, ktoré kontroluje aktíva na širší rozsah zraniteľností alebo porušení bezpečnostných politík).
• Možnosť skenovania s aj bez autentizácie.
• Podpora opakovaných skenovaní v určitých časových oknách a intervaloch.
• Integrácia s virtualizačnými prostrediami.
• Integrácia s produktmi na analýzu topológie siete a rizík.
• Integrácia s platformami na penetračné testovanie.
• Inbound a outbound API.
• Natívna integrácia s navrhovaným SIEM riešením.
• Schvaľovanie výnimiek spôsobom žiadateľ a schvaľovateľ.
• Identifikácia a správa výnimiek zo zraniteľnosti.
• Vlastné modely hodnotenia rizík definované používateľom.
• Aspoň 2FA autentifikácie používateľov.
• Možnosť vytvárania vlastných politík určených pre skenovanie.
• Možnosť vytvárania používateľom definovaných zraniteľností a kontrol zraniteľnosti.
• Automatické zisťovanie a inventarizácia majetku (pomocou IP adresy, MAC adresy).
• Vytváranie používateľom definovaných zraniteľností a kontrol zraniteľnosti.
• Pokrytie zraniteľností z NVD, CERT, SANS, Bugtraq a Secunia.
• Pri skenovaní cez IPv4 musí zistiť systémy s podporou IPv6 a naopak.
• Možnosť tvorby dynamických dashboardov pre potrebu práce so živými dátami.
• Distribuované skenery musí spravovať centrálna konzola.
• Automatické korelovanie a konsolidovanie jednotlivých zraniteľnosti plánu prostredníctvom nápravného opatrenia.
• Vykonávať automatizované testovanie zraniteľnosti zariadení.
• Testovanie dynamicky prideľovaných IP adries prostredníctvom služby DHCP a monitorovanie ich histórie a podávanie správ pomocou "DNS name" alebo "Host name“.
• Umožniť automatickú aktualizáciu tagov v databáze aktív podľa týchto pravidiel dynamického označovania.
• Umožniť automatické aktualizácie všetkých SW komponentov celej architektúry riešenia s najnovšími dostupnými verziami jednotlivých SW komponentov.
• Umožniť automatickú centralizáciu všetkých nájdených aktívnych systémov a ich atribútov: verzií operačného systému, verzií aplikácií, otvorených portov TCP a UDP a sieťových protokolov do jednej databázy aktív s možnosťou definovať statické a dynamické hierarchické tagy a podľa týchto tagov vykonávať filtrovanie aktív, testovanie a vykazovanie výsledkov.
• Možnosť stanovenia cieľov nápravných opatrení podľa kritérií ako sú:
  • stanovený termín ukončenia realizácie nápravných opatrení,
  • odstránenie zraniteľností podľa závažností,
  • odstránenie konkrétnych zraniteľností,
  • odstránenie aktív s nepodporovaným operačným systémov.

Súčasťou aktivity bude aj vykonanie iniciálneho vulnerability testu (scanu) interných systémov, pracovných staníc a sieťovej infraštruktúry a zaškolenie administrátora VÚSCH.

Nástroj na bezpečnostné testovanie

Nástroj na bezpečnostné testovanie musí spĺňať najmenej nasledovné:

• Platforma musí umožňovať vytváranie phishing-ových kampaní.
• Platforma obsahuje predpripravené email šablóny a stránky najčastejšie sa vyskytujúcich podvodov.
• Phishing-ová kampaň sa môže realizovať manuálne alebo prostredníctvom plánovača.
• Minimálne ukazovatele pre vyhodnocovanie phishing-ových kampaní sú:
• Počet odoslaných emailov.
• Počet doručených emailov.
• Počet otvorených emailov.
• Počet kliknutí na odkaz.
• Počet kliknutí na prílohu.
• Počet odpovedí na email.
  • Reporting pre vyhodnocovanie úspešnosti phishing-ových kampaní.
  • Platforma podporuje import používateľov z Active Directory.
  • Možnosť nastaviť akciu po úspešnom phishingu používateľa (napr. po kliknutí na podozrivú linku sa objaví vysvetlenie čo nesprávne používateľ vykonal).
  • Možnosť vytvorenia skupín používateľov, ktorí budú účastníkmi phishing-ovej kampane.
  • Možnosť nastavenia školenia po absolvovaní phishing-ovej kampane.

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 VÚSCH 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 alebo ako cloudová služba výrobcu. Predpokladom však je, že väčšina bezpečnostných riešení bude nasadená do virtuálneho prostredia VÚSCH, a niektoré riešenia budú nasadené ako samostatný HW appliance alebo v rámci cloudovej infraštruktúry výrobcu, prípadne budú nasadení rôzni agenti do infraštruktúry VÚSCH.

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 procesno-organizačné riadenie informačnej a kybernetickej bezpečnosti,
• MFA,
• implementácia SIEM s integrovaným LMS,
• vulnerability skener,
• bezpečnostné testovanie phishing kampaní

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 procesno-organizačné riadenie informačnej a kybernetickej bezpečnosti,
• MFA,
• implementácia SIEM s integrovaným LMS.

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

• nasadenie nástroja na procesno-organizačné riadenie informačnej a kybernetickej bezpečnosti,
• nasadenie nástroja na skenovanie zraniteľností,
• nasadenie nástroja pre bezpečnostné testovanie phishing kampaní

je:

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

Požadovaná dostupnosť pre aktivity projektu:

• MFA,
• implementácia SIEM s integrovaným LMS,

je:

• 99,9% ("tri deviatky") dostupnosť znamená výpadok 8,76 hodín.

Za týmto účelom bude aj s dodávateľom služby 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 aktivít:

• nasadenie nástroja na procesno-organizačné riadenie informačnej a kybernetickej bezpečnosti,
• MFA,
• implementácia SIEM s integrovaným LMS.

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)

Aktivity:

• nasadenie nástroja na procesno-organizačné riadenie informačnej a kybernetickej bezpečnosti,
• MFA,

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

Nasledovná aktivita:

• implementácia SIEM s integrovaným LMS,

si bude 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