Metodika pre systematické zabezpečenie …...metodike sumarizujú základné body, ktoré sú pre zavedenie organizačnej bezpečnosti kľúčové. Aj v prípade, že organizácia

Metodika pre systematické zabezpečenieorganizácií verejnej správy v oblasti

informačnej bezpečnostiVerzia dokumentu 2.0

Autor: CSIRT.SK

Dátum poslednej revízie: 13.7.2017 (v2.0)

Elektronická verzia originálu: https://www.csirt.gov.sk/informacna-bezpecnost/osvedcene-postupy/metodika-zabezpecenia-ikt-8a6.html

Licencia: Creative Commons Attribution-NonCommercial-ShareAlike 4.0International (CC BY-NC-SA) (https://creativecommons.org/licenses/)

Ktokoľvek má možnosť prispôsobiť túto metodiku svojim potrebám, pričom musízachovať referenciu na zdroj (autor CSIRT.SK a originálne URL). Metodika aj jejderiváty musia byť vždy verejne prístupné a zverejnené s rovnakou licenciou.

Podieľali saMetodika pre systematické zabezpečenie organizácií verejnej správy v oblastiinformačnej bezpečnosti (ďalej len Metodika) vznikla prepracovaním a rozšírenímpodkladov z dokumentu „Požiadavky na zabezpečenie infraštruktúry a riešeniaimplementovaného v rámci OPII“, ktorý vypracoval CSIRT.SK v spolupráci s ÚPVIISR (Úrad podpredsedu vlády SR pre investície a informatizáciu) v roku 2016.

Za podnety k obsahovej aj formálnej stránke ďakujeme kolegom z:

• Ministerstva Financií SR

• Združenia CZ-NIC

• Univerzity Pavla Jozefa Šafárika v Košiciach

• Univerzity Komenského v Bratislave

• a taktiež všetkým ďalším, ktorí sa na nás obrátili so spätnou väzbou.

Verzia a vývoj dokumentuVzhľadom na neustále sa vyvíjajúce a meniace techniky útokov a obrany je tátometodika žijúcim dokumentom. K metodike sú priebežne zhromažďované podnetyna doplnenie a zmeny podľa aktuálneho vývoja. Tieto zmeny budú občasnezakomponované do novej verzie metodiky, ktorá bude zverejnená nawebstránkach https://www.csirt.sk.

Akékoľvek podnety k vylepšeniu obsahu metodiky prosím posielajte [email protected].

2

ObsahPodieľali sa.............................................................................................................2

Verzia a vývoj dokumentu......................................................................................2

Obsah..................................................................................................................... 3

Úvod....................................................................................................................... 5

Cieľ dokumentu...................................................................................................5

Rozsah a záber dokumentu.................................................................................6

Obmedzenia........................................................................................................6

Definícia významu kľúčových slov.......................................................................7

Vysvetlenie skratiek............................................................................................7

Bezpečnostné požiadavky......................................................................................9

1. Organizačné opatrenia.....................................................................................10

Všeobecné požiadavky......................................................................................10

Mechanizmus kontroly....................................................................................15

Technické opatrenia..............................................................................................17

2 Minimálne požiadavky na zabezpečenie implementovaného riešenia...........17

Bezpečnosť životného cyklu IS.......................................................................17

Interná infraštruktúra a vývojové prostredie..................................................19


3 Minimálne požiadavky na zabezpečenie služieb dostupných z externých sietí – Webové aplikácie............................................................................................22

Bezpečný návrh..............................................................................................22

Šifrovanie.......................................................................................................22

Šifrovacie kľúče a protokoly...........................................................................22

Konfigurácia webového servera.....................................................................23


4 Minimálne požiadavky na zabezpečenie infraštruktúry.................................36

Všeobecné požiadavky...................................................................................36

Konfigurácia sieťovej infraštruktúry...............................................................37

Zabezpečenie servera....................................................................................39

Monitorovanie a logovanie.............................................................................40

5 Minimálne požiadavky na zabezpečenie externej infraštruktúry...................43


3

Konfigurácia sieťovej infraštruktúry...............................................................43

Firewall...........................................................................................................44

Ochrana proti DoS útokom.............................................................................44

Zabezpečenie DNS infraštruktúry..................................................................45

Zabezpečenie mailovej infraštruktúry............................................................45

Zabezpečenie VPN infraštruktúry...................................................................46

Zabezpečenie VOIP infraštruktúry a služieb videoconference........................47

Zabezpečenie iných služieb...........................................................................48


6 Minimálne požiadavky na zabezpečenie internej infraštruktúry....................49

Implementácia architektúry riešenia..............................................................49

Hardening serverov, sieťových a bezpečnostných prvkov..............................51

Sieťové prvky.................................................................................................52

Monitoring......................................................................................................52

Tlačiarne........................................................................................................53

Windows infraštruktúra..................................................................................53


7 Minimálne požiadavky na zabezpečenie pracovných staníc pristupujúcich k implementovanému riešeniu.............................................................................55


Logovanie.......................................................................................................55

Hardening.......................................................................................................56


8 Administratívne opatrenia................................................................................58

Všeobecné požiadavky......................................................................................58


Príloha A – Politika hesiel...................................................................................62

Heslá pre účty s administrátorskými oprávneniami......................................62

Heslá pre účty s privilegovaným prístupom..................................................62

Heslá pre neprivilegované účty.....................................................................62

Príloha B - Zariadenia pre nasadenie a zabezpečenie webového servera.........63

4

ÚvodInformačné systémy a prostriedky používané v organizácií musia byťzabezpečené takým spôsobom, aby sťažovali kompromitáciu infraštruktúry a abyv prípade kompromitácie služby alebo systému boli dôsledky incidentuminimalizované. To znamená, že ak útočník kompromituje časť infraštruktúry, jepre neho zložité dostať sa ďalej a kompromitovať ďalšiu časť infraštruktúry – toznamená je obmedzená možnosť pivotingu. Je nutné implementovaťviacúrovňovú hĺbkovú ochranu.

Cieľ dokumentuTento dokument sumarizuje minimálne opatrenia potrebné na zabezpečenie informačných systémov a infraštruktúry organizácie tak aby platili princípy uvedené v úvode.

Metodika je cielená pre využitie vo verejnej správe pre organizácie so zvýšenými požiadavkami na bezpečnosť1, avšak v princípe je aplikovateľná pre akékoľvek veľké alebo stredne veľké počítačové siete, ktoré majú zvýšené požiadavky na bezpečnosť, ale potrebuju mať zabezpečenú kybernetickú bezpečnosť na úrovni odolnosti voči štandardným cieleným kybernetickým útokom.

V dokumente sa používajú kľúčové slová „musí“, „malo by byť“, „odporúča sa“. Tieto sú ohodnotením dôležitosti daného opatrenia s ohľadom na jeho implementačnú náročnosť. Ak sa organizácia rozhodne byť v súlade s metodikou, platí pre ne význam podľa vysvetlenia v kapitole „Definícia významu kľúčových slov“.

Dokument neobsahuje podrobné implementačné detaily jednotlivých opatrení. Podrobné implementačné detaily budú uvádzané v jednotlivých dokumentoch postupne zverejňovaných na stránkach špecializovaného útvaru CSIRT.SK.

Aj v prípade, že dokument nebude implementovaný ako celok, jednotlivé (najmä technické) opatrenia boli vybrané tak, aby pokrývali jeden alebo viacero vektorovútoku. V prípade správnej implementácie konkrétneho opatrenia bude infraštruktúra organizácie odolná alebo v niektorých prípadoch až imúnna voči útokom zneužívajúcim zraniteľnosť opravovanú daným opatrením.

Komu je dokument určenýDokument je určený primárne pre organizácie verejnej správy so zvýšenýmipožiadavkami na bezpečnosť. Čerpať z neho však môžu aj ďalšie organizácie ainštitúcie z rôznych sektorov, od súkromného cez verejný až po akademickú obec.Podľa toho, akú úroveň riadenia informačnej bezpečnosti organizácia

1 Napríklad v zmysle Metodiky prevencie a pripravenosti (ktorá bola vypracovaná špecializovaným útvarom CSIRT.SK v zmysle úlohy 3.1. Akčného plánu ku Koncepcií kybernetickej bezpečnosti schválenej vládou SR na roky 2015-2020).

5

implementujúca opatrenia podľa tejto metodiky už má, možno zvoliť, kto budezavedenie odporúčaní garantovať.

V prípade, že organizácia má vybudovanú istú štruktúru riadenia informačnejbezpečnosti, môže zodpovednosť za zavedenie metodiky do praxe prebraťmanažér bezpečnosti alebo ním poverená osoba/osoby. Ak však inštitúcia nemávybudované takéto kapacity, môže použiť metodiku v začiatkoch ich budovania.Zavedenie organizačných opatrení bude v kompetencii vedenia inštitúcie.Inštitúcia môže čerpať informácie o organizačnej bezpečnosti aj z iných zdrojov,napr. norma ISO 27002. Podobné dokumenty však bývajú rozsiahle, preto sametodike sumarizujú základné body, ktoré sú pre zavedenie organizačnejbezpečnosti kľúčové.

Aj v prípade, že organizácia nemá kapacity na vytvorenie hierarchie manažmentuinformačnej bezpečnosti (IB), môžu technické odporúčania metodiky použiťsamotní administrátori informačných systémov, v medziach svojich kompetenciípri spravovaní predmetných zabezpečovaných IS.

Rozsah a záber dokumentuTento dokument špecifikuje opatrenia na zabezpečenie IS nasadzovaných doinfraštruktúr organizácie verejnej správy.

Bezpečnostné opatrenia sa delia do týchto skupín:

1. Organizačné opatrenia – organizačné zabezpečenie bezpečnosti IS

2. Technické opatrenia – technické zabezpečenie bezpečnosti IS

3. Administratívne opatrenia – súhrn smerníc, politík a pracovných postupov, ktoré musia byť implementované na zabezpečenie základnej úrovne bezpečnosti IS v závislosti od jeho typu

ObmedzeniaDokument sa v tejto verzií nezaoberá špecifickými požiadavkami na: fyzickúbezpečnosť infraštruktúry, bezpečnosť mobilných zariadení, bezpečnosť Internetuvecí (IoT – Internet of Things), bezpečnosť ICS systémov (Industrial ControlSystems), zabezpečenie služieb využívajúcich IPv4 multicast, zabezpečeniewebových služieb (web services).

6

Definícia významu kľúčových slovV tomto dokumente sú použité nasledujúce kľúčové slová podľa uvedenéhovýznamu:

„musí“ – špecifikuje povinnú požiadavku (platí aj pre „je nutné“)

„nesmie“ – špecifikuje povinný zákaz

„malo by [byť]” – špecifikuje požiadavku, ktorá je povinná pokiaľneexistuje pádny dôvod prečo nemôže byť splnená. Ak existuje takýto dôvod,musí byť zdokumentovaný a schválený.

“nemalo by [byť]” - špecifikuje zákaz, ktorý je povinný pokiaľneexistuje pádny dôvod prečo nie je možné ho splniť. Ak existuje takýto dôvod,musí byť zdokumentovaný a schválený.

“odporúča sa” – špecifikuje odporúčanú požiadavku (platí aj pre “jevhodné”)

Ak je rozdiel medzi operátorom (musí / malo by byť / odporúča sa) v konkrétnomopatrení a jeho nadradeným číslovaných bodom, tak platí operátor v konkrétnejodrážke (to znamená posledný špecifikovaný). V nasledujúcom príklade pre bodb) platí operátor „malo by byť“:

1.1 V organizácii musí byť vykonávané pravidelné monitorovanie a preskúmavanie bezpečnostiIS v rozsahu:

a. Pravidelné preskúmavanie plnenia cieľov bezpečnostnej politiky aspoň raz za 12 mesiacovvedením organizácie.

b. Malo by byť vykonávané pravidelné testovanie záloh dôležitých systémov na kontrolufunkčnosti.

Vysvetlenie skratiekACL - Access Control List

AP - Access Point

CSRF - Cross-Site Request Forgery

DHCP - Dynamic Host Configuration Protocol

DMZ - Demilitarized Zone - VLAN, v ktorej sú umiestnené servery poskytujúceslužby do externej siete, ktorá je logicky oddelená od inernej siete (komunikáciaje fultrovaná sieťovým firewallom)

DNS - Domain Name System

DoS – Denial of Service

FW – Firewall

IB – Informačná bezpečnosť

ICS - Industrial Control System

MitM útok – Man in the Middle útok

7

MVC – návrhový vzor Model–View–Controller

MVP - návrhový vzor Model–View–Presenter

NAC – Network Access Control

NAP - Network Access Protection

NDP - Neighbor Discovery Protocol - protokol v IPv6, okrem iného, nahradzujúciARP z IPv4

NTP - Network Time Protocol

OS - Operačný systém

PVLAN – Private VLAN

princíp least privilege

RDP - Remote Desktop Protocol

QoS - Quality of Service

Sieťový firewall - firewall umiestnený v sieti filtrujúci komunikáciu viacerýchzariadení, prípadne sietí (nie lokálny firewall)

SNMP – Simple Network Management Protocol

SSO – Single Sign-On

Telepresence

UAC – User Access Control

VLAN – Virtual Local Area Network

VPN – Virtual Private Network

VOIP – Voice over IP

WAF – Webaplikačný firewall - špeciálny typ firewallu, prispôsobený nazabezpečenie webového servera. Ide o filter, plugin či zariadenie ktorý aplikujeset pravidiel na HTTP prevádzku.

Whitelisting - metóda kontroly prístupu k službám, ktorá povoľuje prístup ibašpecifikovaným klientom a všetkým ostatným ho zakazuje

XSS - Cross-Site Scripting

8

Bezpečnostné požiadavkyPožiadavky na bezpečnostné opatrenia na zaistenie bezpečnosti infraštruktúrya implementovaného riešenia sa delia na:

1. Organizačné opatrenia

2. Technické opatrenia

a. zabezpečenie implementovaného riešenia

b. zabezpečenie služieb dostupných z externých sietí – Webové aplikácie

c. zabezpečenie infraštruktúry

d. zabezpečenie externej infraštruktúry

e. zabezpečenie internej infraštruktúry

f. zabezpečenie pracovných staníc pristupujúcich k implementovanému riešeniu

3. Administratívne opatrenia

9

1. Organizačné opatrenia

Všeobecné požiadavky

1.2 V organizácii musia byť zavedené aspoň nasledovné opatrenia personálnejbezpečnosti:

c. Sú určené roly a zodpovednosti za informačnú bezpečnosť aspoň pre tietoroly: vrcholný predstaviteľ organizácie, manažér pre bezpečnosť, vedúcipracovník, administrátor, audítor, používateľ.

d. Roly manažéra pre bezpečnosť a audítora musia byť oddelené od oddeleniasprávy IKT.

e. Pred prijatím do pracovného pomeru je vykonávané preverenie osôb(aspoň poskytnutím výpisu z registra trestov).

f. Zodpovednosť za informačnú bezpečnosť je zahrnutá do pracovných zmlúvso zamestnancami spolu so sankciami v prípade nedodržania týchtopovinností.

g. So zamestnancami a tretími stranami (napríklad dodávateľmi) súpodpísané dohody o mlčanlivosti.

h. V prípade ukončenia pracovného pomeru sú zamestnancovi včas odobratéprístupové práva, všetky zverené aktíva a informácie sú včas navrátenéa všetky zdieľané heslá sú zmenené.

1.3 V organizácii musí byť zavedené riadenie informačných aktívs nasledovnými požiadavkami:

a. Organizácia musí mať vypracovaný inventár informačných aktív, ktorý jeúplný, aktuálny, preskúmavaný a aktualizovaný pri zmenách v IS,minimálne však každých 12 mesiacov.

b. Na vedenie, údržbu a aktualizáciu inventáru aktív by mala byť stanovenázodpovedná osoba.

c. Každé aktívum musí mať prideleného vlastníka, ktorý zodpovedá za jehobezpečnosť.

d. V organizácii musí byť implementovaný mechanizmus klasifikácieinformácií z hľadiska dôvernosti.

e. Informácie musia byť označované príslušným klasifikačným stupňom.f. Pre každý klasifikačný stupeň musí byť definovaný súbor opatrení, ktoré

popisujú požiadavky na ich ochranu pri ukladaní, prenose a spracúvaní.g. Inštalácia softvéru a hardvéru musí byť vykonávaná len povereným

administrátorom.h. V organizácii musí byť vypracovaný zoznam autorizovaného softvéru a je

dovolené inštalovať výhradne legálny softvér z tohto zoznamu získanýz dôveryhodných zdrojov .

i. V organizácii by mal byť vypracovaný zoznam autorizovaného hardvéru nazáklade sériového čísla a je dovolené používať výhradne hardvér z tohtozoznamu, pričom výnimky musia byť schválené manažérom bezpečnosti.

j. V organizácii musí byť vypracovaná a pri zmenách aktualizovanádokumentácia o sieťovej topológii a technická dokumentácia o IS.

10

k. Nepotrebné informácie a ich dátové nosiče musia byť mazané a ničenébezpečným spôsobom.

l. V organizácii by mal byť implementovaný systém pre riadenie zmien.m. V organizácii by mal byť implementovaný systém pre riadenie záplat.

1.4 V organizácii musí byť implementovaný systém manažmentu rizík, ktorýspĺňa aspoň nasledovné požiadavky:

a. Identifikácia a ohodnotenie rizík je založené na identifikácii a ohodnoteníaktív, ich zraniteľností a hrozieb, ktoré majú potenciál tieto zraniteľnostizneužiť, a potenciálnych dopadov pri zneužití zraniteľností.

b. Identifikácia a ohodnotenie rizík je vykonávané konzistentným,systematickým, vopred stanoveným a dokumentovaným spôsobom, ktorýzaručí pokrytie všetkých známych rizík a opakovateľnosť výsledkov.

c. Je stanovená a vedením schválená miera akceptovateľných rizík a všetkyriziká s vyššou hodnotou ako je miera akceptovateľných rizík sú ošetrenétak, aby zvyškové riziko nepresiahlo mieru akceptovateľných rizík.

d. Je stanovené, čo organizácia pre adekvátne ošetrenie rizika vyžaduje:môže ísť o jeho okamžité odstránenie, resp. je stanovená lehota, počasktorej môže byť riziko prítomne, nakoľko ešte nie je dostupné riešenie(napríklad vydanie záplaty dodávateľom IS, v ktorom sa objavila novákritická zraniteľnosť).

e. Je vedený zoznam zostatkových rizík a tieto riziká sú v pravidelnýchintervaloch a pri zmenách v IS a prostredí organizácie preskúmavané.

f. Riziká sú ošetrované podľa Plánu pre ošetrovanie rizík so stanovenýmikonkrétnymi opatreniami, zodpovednosťami za implementáciu týchtoopatrení, termínmi a potrebnými zdrojmi na ošetrenie rizík.

1.5 V organizácii musia byť stanovené a dodržiavané aspoň nasledovnépravidlá pre používateľov IS:

a. Pri odchode od pracovnej stanice je zamestnanec povinný ju uzamknúť.b. Pri zadávaní hesla musí zamestnanec dbať na to, aby nebolo náhodne

odpozorované.c. Heslá musia byť rôzne pre rôzne IS s výnimkou SSO (Single Sign-On).d. Heslá by nemali byť zdieľané.e. Heslá nesmú byť voľne dostupné prostredníctvom fyzických alebo

dátových prostriedkov.f. Pri prenášaní informácií a príloh citlivých z hľadiska dôvernosti

prostredníctvom e-mailu sa musí používať šifrovanie.g. Pri prenášaní informácií a príloh citlivých z hľadiska integrity alebo

autentickosti prostredníctvom e-mailu sa musí používať podpisovanie.

1.6 V organizácii by mali byť stanovené a dodržiavané aspoň nasledovnépravidlá pre používateľov IS:

a. Je zakázané používať súkromné prostriedky na služobné účely.b. Je zakázané používať služobné prostriedky na súkromné účely.c. Pri práci s e-mailom je zakázané otvárať nevyžiadanú poštu, ako aj prílohy

e-mailov a odkazy obsiahnuté v tele e-mailov z nedôveryhodných zdrojov.d. Je zakázané pristupovať k webovým portálom, ktoré môžu ohroziť

bezpečnosť pracovnej stanice (známe škodlivé webové stránky,

11

pornografické stránky, stránky poskytujúce akúkoľvek formu sťahovaniapirátskeho obsahu, stránky poskytujúce akúkoľvek formu hazardu, stránkyo hackingu a podobne)

e. Je zakázané pristupovať k sociálnym sieťam a chatovacím programoms výnimkou sociálnych sietí a chatovacích programov používaných prepracovné účely.

f. Pre prácu s Internetom je povolené používať len zabezpečený prehliadačs nainštalovanými a vhodne nakonfigurovanými bezpečnostnýmidoplnkami blokujúcimi JavaScript, reklamy a Adobe Flash. V odôvodnenýchprípadoch pokiaľ bezpečnostné doplnky bránia vo výkone pracovnýchpovinnosti, je možné pre dôveryhodné webové stránky udeliť dočasnúvýnimku pre konkrétnu doménu. Upozorňujeme, že je potrebné zaškoliťpoužívateľov ako používať tieto doplnky.

1.7 V organizácii musia byť stanovené a dodržiavané aspoň nasledovnépravidlá pre administrátorov IS:

a. V prípade odchodu a po ukončení práce so stanicou (resp. konzolou aleboterminálom) je potrebné sa odhlásiť.

b. Heslá k privilegovaným a administrátorským účtom musia spĺňaťpožiadavky uvedené v Prílohe A.

c. Je zakázané zaznamenávať a zasielať heslá v otvorenom a reverzibilnomtvare.

d. Zdieľanie hesiel by malo byť zakázané2.e. Akékoľvek zmeny v systémovej konfigurácii sú dokumentované.f. Používateľom je možné poskytnúť len prístup v minimálnom rozsahu

nevyhnutnom na vykonávanie ich pracovných činností.g. Pri ukončení pracovného pomeru s administrátorom musí byť zablokované

jeho konto na autentifikačnom serveri ako aj na zariadeniach, ktoré bolipod jeho správou a odporúča sa vykonať zmeny jemu známychautentifikačných údajov (príklad: SNMP community strings, failover kľúče,kľúče smerovacích protokolov, VPN kľúče).

h. Pri ukončení pracovného pomeru s administrátorom je nutné zablokovaťjeho účet na prístup cez VPN a zmeniť akékoľvek zdieľané správcovsképrístupové údaje.

i. Pri ukončení pracovného pomeru s administrátorom by mala byťskontrolovaná integrita konfigurácií všetkých prvkov (napr. konfiguráciaSNMP, Syslog), konfigurácia správcovských prístupových údajov akonfigurácia správcovských prístupových metód.

1.8 V organizácii musí byť zavedené riadenie fyzického a logického prístupus nasledovnými pravidlami:

a. Prideľovanie oprávnení sa vykonáva v nasledovných krokoch: návrh,schválenie a nastavenie prístupových oprávnení.

2 V prípade, že je zdieľanie hesiel nutné (napr. administrátorské a servisné účty), musia byť bezpečne skladované prostredníctvom šifrovaných zdieľaných úložísk. Zdieľanie hesiel musí byť odôvodnené a dokumentované, musí byť stanovené, kto má k zdieľaným heslám prístup a takýchto hesiel musí byť minimum

12

b. Prístupy sú prideľované len v rozsahu nevyhnutnom na vykonávaniepracovných činností.

c. Je vypracovaný a aktualizovaný zoznam privilegovaných prístupovýchoprávnení a pravidelný ročný audit ich potreby.

d. Všetky heslá k privilegovaným prístupovým účtom musia spĺňať kritériá preadministrátorské účty uvedené v Prílohe A.

1.9 V organizácii musia byť zavedené a dodržiavané postupy pre zálohovaniev rozsahu:

a. Frekvencia a rozsah zálohovania musí byť schválená vedením organizáciea musí byť dokumentovaná.

b. Zamestnanci zodpovední za zálohovanie sú určení a sú poučení o svojichpovinnostiach.

c. Musí byť stanovený interval, čas, rozsah dát, dátové médium a vedeniedokumentácie o zálohovaní.

d. Zálohy musia byť umiestnené v zabezpečenom priestore s riadenímvstupu.

e. Zálohy kritických informácií a IS musia byť uložené aj na fyzicky dostatočnevzdialenej lokalite a musia byť šifrované.

f. Musí byť pravidelne vykonávaný test obnovy záloh.

1.10 V organizácii musí byť zavedený systém riadenia kontinuity činnostís nasledovnými požiadavkami:

a. V organizácii musia byť stanovené roly a zodpovednosti pre plneniehavarijných plánov a plánov obnovy.

b. V organizácii musí byť stanovená cieľová doba obnovy (RTO) a cieľový bodobnovy (RPO) pre jednotlivé procesy, IS a aplikácie.

c. Jednotlivé postupy pri riadení kontinuity činností by mali byť pravidelnetestované prostredníctvom ohlásených alebo neohlásených cvičení.

1.11 V organizácii musia byť zavedené a dodržiavané postupy pre nahlasovaniea riešenie počítačových bezpečnostných incidentov aspoň v rozsahu:

a. Je stanovené kontaktné miesto pre nahlasovanie incidentov a rolya zodpovednosti pre zamestnancov poverených ich riešením.

b. Kontaktné údaje pre nahlasovanie počítačových incidentov sú nahlásenéšpecializovanému útvaru pre riešenie počítačových incidentov CSIRT.SKa pri zmenách kontaktných údajov sú nové kontaktné údaje opätovnenahlásené.

c. Je vedená a udržiavaná evidencia kontaktných údajov tretích stránpotrebných na riešenie počítačových incidentov a je určená osobazodpovedná za jej vedenie a udržiavanie.

d. Zamestnanci poverení riešením incidentov sú odborne spôsobilí, pravidelneškolení a zastupiteľní.

e. Incidenty sú klasifikované podľa klasifikačnej schémy definovanejv smernici pre riešenie počítačových incidentov.

f. Na detekciu a riešenie incidentov sú vyhradené dostatočné zdroje(finančné, ľudské...).

g. Incidenty sú riešené bez zbytočného odkladu podľa vopred stanovenýchpostupov.

13

h. Sú vytvorené eskalačné postupy.i. Je vedená evidencia bezpečnostných incidentov a je určená osoba

zodpovedná za jej vedenie.j. Po vyriešení incidentu je vykonaná následná analýza a sú implementované

opatrenia na predchádzanie incidentom podobného typu. k. Po vyriešení incidentu je vykonané preskúmanie postupu jeho riešenia, sú

identifikované nedostatky a návrhy na zlepšenie (napr. vhodnosť alebopotreba nových nástrojov, dostatok personálu, potreba školení a podobne),tieto sú prediskutované na stretnutí zamestnancov riešiacich bezpečnosťv organizácii a závery z tohto stretnutia sú dokumentované.

l. Sú vytvorené plány pre riešenie počítačových incidentov aspoň tohto typu:prienik, nákaza škodlivým kódom, DoS útok, sociálne inžinierstvo (phishing,impersonácia a pod) Odporúča sa implementovať postupy pre riešenieincidentov – napríklad postupy zverejnené národnou, vládnou aleborezortnou jednotkou CSIRT / CERT.

1.12 V organizácii musí byť zavedené kontinuálne zvyšovanie povedomia oinformačnej bezpečnosti, súvisiacich hrozbách a možnostiach ochrany predtýmito hrozbami aspoň v rozsahu:

a. Existujúci vedením schválený program vzdelávania s určenouzodpovednosťou za jeho plnenie a vyhradenými zdrojmi.

b. Vzdelávací proces je pravidelný, vyhodnocovaný a neustále zlepšovaný.Odporúča sa, aby boli súčasťou overenia efektivity vzdelávacieho procesupoužívateľov aj neohlásené testy (napríklad prostredníctvom sociálnehoinžinierstva a vedomostných testov).

c. Zvyšovanie povedomia zahŕňa predstavenie typov informácií, ichklasifikáciu a označovanie, predstavenie súčasných hrozieb a spôsobovochrany voči nim, poučenie o postupoch pre identifikáciu a nahlasovaniebezpečnostných incidentov a určenie kontaktného miesta pre ichnahlásenie.

1.13 Organizácia musí vykonávať audity bezpečnosti IS aspoň raz za 36mesiacov podľa nasledovných požiadaviek:

a. Je vypracovaný program auditov na obdobie troch rokov, ktorý zahŕňainterné audity, posúdenie zraniteľností a penetračné testy.

b. Pre každý interný audit je vypracovaný plán auditu, ktorý obsahuje cieleauditu, referenčné dokumenty, dátumy a miesta vykonania auditu,organizačné útvary, ktoré sú predmetom auditu, roly a zodpovednosti.

c. Audítor musí byť nezávislý3, skúsený, musí byť znalý príslušnej legislatívya štandardov a musí mať vhodné osobnostné predpoklady.

d. Správa z auditu musí obsahovať aspoň zoznam účastníkov auditu, zoznamzistených nezhôd, pozorovaní a príležitostí na zlepšenie, vyjadrenieaudítora k rozsahu v akom organizácia plní bezpečnostné požiadavkya návrh opatrení.

3 Funkcia audítora musí byť organizačne nezávislá od oblasti alebo činnosti, ktorá je predmetom auditu tak, aby umožnila jeho objektívne vykonanie a zamedzila takým vplyvom na audítora, ktoré by mohli ohroziť jeho integritu, objektivitu, profesionálny skepticizmus a úsudok.

14

e. Pre implementáciu opatrení na odstránenie zistených nedostatkov jepotrebné vypracovať plán implementácie opatrení podľa ich prioritys určením zodpovedností, termínov plnenia a zdrojov.

1.14 Prístup tretích strán ako aj ich vzdialený prístup musí byť riadený,kontrolovaný a prístupové oprávnenia musia byť udelené len v minimálnomrozsahu potrebnom na vykonávanie pracovných činností.

1.15 Tretie strany musia organizácii na požiadanie poskytnúť správu o stavezabezpečenia a funkčnosti zverených aktív v rozsahu stanovenomorganizáciou na základe povahy predmetných aktív.

1.16 Pre kritické systémy by malo byť implementované monitorovaniedostupnosti služieb a detekcia anomálií.

1.17 Pred nasadením IPv6 do prevádzky musí byť vytvorený plán nasadenia,ktorý obsahuje aj analýzu rizík spojených s IPv6 a požiadavky nabezpečnostné mechanizmy a konfiguráciu infraštruktúry.

1.18 Ak sa používa IPv6, musí byť zabezpečené, že sieťoví administrátori,operátori monitoringu aj bezpečnostný tím majú dostatočné technickéznalosti špecifík IPv6 protokolu aj podporných protokolov ako ICMPv6,DHCPv6, DNS.

1.19 Pred nasadením VOIP alebo telepresence musí byť vytvorený plánnasadenia, ktorý obsahuje aj analýzu rizík spojených s VOIP a telepresencea požiadavky na bezpečnostné mechanizmy a konfiguráciu infraštruktúry.

Mechanizmus kontroly

1.20 V organizácii musí byť vykonávané pravidelné monitorovaniea preskúmavanie bezpečnosti IS v rozsahu:

a. Pravidelné preskúmavanie plnenia cieľov bezpečnostnej politiky aspoň razza 12 mesiacov vedením organizácie.

b. Kontinuálne monitorovanie účinnosti bezpečnostných opatrení na ošetrenierizík.

c. Pravidelné preskúmavanie zostatkových rizík aspoň raz za 12 mesiacova v prípade zmien v IS.

d. Pravidelné monitorovanie log záznamov a ich analýza aspoň raz za týždeň.e. Pravidelná kontrola technického stavu zariadení a funkčnosti aplikácií

aspoň raz za mesiac.f. Pre kritické systémy musí byť vykonávané monitorovanie funkčnosti

aplikácií v reálnom čase.g. Malo by byť vykonávané pravidelné testovanie záloh dôležitých systémov

na kontrolu funkčnosti.h. Je vykonávaná pravidelná kontrola prístupových oprávnení a deaktivovanie

nepotrebných prístupových účtov aspoň každých 12 mesiacov.i. Pravidelné meranie účinnosti programu vzdelávania zamestnancov

a testovanie úrovne ich bezpečnostného povedomia.

15

j. Pravidelné preskúmavanie jednotlivých stratégií a plánov pre kontinuitučinností aspoň raz za 12 mesiacov.

1.21 Každých 24 mesiacov by malo byť vykonávané interné a externépenetračné testovanie IS organizácie. V prípade, že posledný penetračnýtest znamenal kompromitáciu dôležitého systému alebo kompromitáciuznačnej časti infraštruktúry, mal by byť vykonať ďalší penetračný test hneďpo odstránení zraniteľností – najneskôr však o 12 mesiacov.

16

Technické opatrenia

2 Minimálne požiadavky na zabezpečenie implementovaného riešenia

Bezpečnosť životného cyklu ISPri vývoji riešenia je potrebné myslieť na bezpečnosť už od začiatku a prispôsobiťtomu návrh aj implementáciu samotného riešenia počas jednotlivých fáz.

Návrh riešenia

2.1 Navrhnuté riešenie musí mať modulárnu štruktúru, pričoma. Pri návrhu jednotlivých komponentov riešenia musí byť splnený princíp

least privilege a všetky entity (t.j. používatelia aj systémy) musia maťprístup iba k údajom / aktívam, ktoré pre svoju činnosť nevyhnutnepotrebujú.

b. Architektúra riešenia by mala byť trojvrstvová – mala by pozostávať zprezentačných serverov, aplikačných serverov a databázových serverov,

c. Odporúčané je použitie overených návrhových vzorov, napr. MVC, resp.MVP

2.2 Musia byť identifikované všetky súčasti (interné aj externé4), od ktorýchzávisí riešenie. Pre jednotlivé súčasti musia byť identifikované zraniteľnosti,ktoré sa v nich môžu vyskytnúť a vyhodnotiť riziká zneužitia týchtozraniteľností na základe:

a. prístupového vektoru útočníka (lokálny prístup/sieť),b. náročnosti získania prístupu,c. potreby autentifikácie,d. dopadov úspešného útoku na dostupnosť, integritu a dôvernosť riešenia a

údajov v ňom spracovávaných.

2.3 Na základe analýzy rizík musia byť navrhnuté opatrenia, ako predchádzaťmožným incidentom a ako postupovať v prípade vzniku incidentu. Tietoopatrenia musia byť zapracované v návrhu riešenia.

Implementácia riešenia

2.4 Riešenie musí byť vyvíjané v bezpečnom vývojovom prostredí.

2.5 Pri implementácii by mali byť použité dôveryhodné (a zároveň širokorozšírené) frameworky / knižnice, ktoré kladú dôraz na bezpečnosť apredchádzanie bežným programátorským chybám a zároveň často a rýchlozverejňujú opravy bezpečnostných chýb.

4 Napr. knižnice a komponenty dodané tretími stranami; systémy, na ktorých bude riešenie postavené alebo ktoré bude využívať pri svojej prevádzke

17

2.6 V prípade, že implementované riešenie potrebuje spracovávať dôvernéúdaje (napr. osobné údaje), počas vývoja aj testovania musia byť použitéanonymizované, resp. fiktívne údaje.

2.7 Pri písaní zdrojového kódu by mal byť použitý systém na verzionovanie5,pričom:

a. jednotlivé zmeny (commity) by mali byť digitálne podpísané privátnymkľúčom autora daného commitu,

b. commity by mali mať zmysluplné popisy,c. mala by byť implementovaná automatická kontrola zdrojového kódu na

prítomnosť chýb a testovanie po každom commite.

2.8 Nemali by byť použité funkcie/volania/nástroje, ktoré sú podľa ichdokumentácie v súčasnej dobe zastarané (angl. deprecated) alebonebezpečné (angl. unsafe) a mali by byť nahradené odporúčanýmialternatívami.

2.9 Počas vývoja riešenia musia byť povolené všetky bezpečnostné vlastnostipoužitých nástrojov, najmä však:

a. zapnuté všetky varovania a ochrany vývojových nástrojov6

b. varovania vývojového prostredia

2.10 Všetky varovania z predchádzajúceho bodu by mali byť opravené.

2.11 Počas vývoja musí byť vedená vývojárska dokumentácia:a. dokumentácia musí obsahovať bližší popis kľúčových častí riešenia až na

prípadné výnimky chránené obchodným tajomstvom; tieto výnimky všakmusia byť zaznamenané v dokumentácii

b. v dokumentácii musí byť zaznamenaná každá zmena oproti pôvodnejšpecifikácií a jej dôvody a každá takáto zmena musí byť schválenáobjednávateľom.

2.12 Dokumentácia aj zdrojové kódy riešenia musia byť odovzdanéobjednávateľovi spolu so samotným riešením.

2.13 Pokiaľ je súčasťou riešenia aj databáza obsahujúca dôverné údaje:a. autentifikačné údaje musia byť uložené iba v podobe osolených hashov

(salted hash), pričom použitá hashovacia funkcia by mala byť minimálnesha256

b. ostatné osobné údaje (adresy, čísla platobných kariet, čísla občianskychpreukazov,...) je odporúčané neukladať v čistej podobe, ale chránenéšifrovaním7,

2.14 Musí byť implementované logovanie a logy by mali zaznamenávaťminimálne:

a. (Úspešné aj neúspešné) Prihlásenie a odhlásenie

5 angl. „Version control system“, napr. git6 Napr. stack protection, DEP, PIE, nonexecutable stack7 Je možné použiť aj niektoré „Format-Preserving Encryption“ algoritmy

18

b. (Úspešné aj neúspešné) Vytvorenie, modifikáciu alebo zmazaniepoužívateľa alebo skupiny

c. (Úspešné aj neúspešné) Pokusy pristúpiť k citlivým údajom (údajeklasifikované hornými dvomi klasifikačnými stupňami v rámci organizácie)

d. (Úspešné aj neúspešné) Pokusy o kritické operácie

2.15 Logy musia byť centrálne ukladané a archivované minimálne 6 mesiacov

2.16 Riešenie musí podporovať aj logovanie vo formáte syslog a musípodporovať preposielanie týchto logov na externý syslog server

Testovanie a verifikácia riešenia

2.17 Po ukončení vývoja musí prejsť aplikácia testovaním a verifikáciou:a. Vývojári by mali overiť aspoň pomocou automatizovaných nástrojov

štandardné zraniteľnosti. Malo by prebehnúť minimálne testovanie vstupov(fuzzing) a kontrola práce s pamäťou (memory leaky, memory corruption).

b. Vývojári musia zabezpečiť realizáciu opatrení vyplývajúcich z analýzy rizíkvypracovanej pri návrhu riešenia.

c. Musí byť vykonané penetračné testovanie externou organizáciou.d. Zraniteľnosti a problémy zistené na základe testovania musia byť

odstránené a ich oprava musí byť potvrdená opakovaným testovaním.

Nasadenie a prevádzka riešenia

2.18 Hotové riešenie s odstránenými nájdenými zraniteľnosťami musí byťnasadené v prostredí zabezpečenom na základe odporúčaní v kapitolácho zabezpečení služieb a infraštruktúry.

2.19 Musí byť zabezpečené pravidelné monitorovanie nových zraniteľnostíjednotlivých (najmä externých) súčastí riešenia a pravidelné aplikovaniebezpečnostných záplat vydaných vývojármi, resp. tretími stranami.Aplikovanie týchto záplat musí podliehať opatreniam uvedeným v smernicipre riadenie záplat.

Interná infraštruktúra a vývojové prostredie

Interná infraštruktúra riešenia

2.20 Jednotlivé vrstvy (databázová, aplikačná, prezentačná) by mali byťumiestnené v separátnych segmentoch a komunikácia medzi nimi musí byťfiltrovaná

2.21 Jednotlivé servery musia byť hardenované minimálne v rozsahu:a. Vypnuté všetky nepotrebné procesy a službyb. Implementovaný host-based firewall, ktorý kontroluje všetku komunikáciu

IN aj OUT a je nakonfigurovaný na princípe „least privilege“c. Všetky administrátorské účty spĺňajú politiku hesiel pre administrátorské

účty (Príloha A)d. Servery a všetok softvér je aktualizovaný minimálne raz za 6 mesiacov,

odporúča sa aktualizovať aspoň raz za mesiac.

19

e. Na serveroch by malo byť implementované anti-malware riešenie, ktoré jecentrálne spravované a centrálne logované.

f. Všetky servery majú nastavené lokálny NTP server ako autoritatívny zdrojčasu a pre preklad doménových mien na IP adresy používajú lokálne DNSservery

g. Všetky zariadenia musia byť hardenované podľa odporúčaní výrobcu.

Vývojové prostredie

2.22 Vo vývojovom prostredí musia byť použité iba nástroje spĺňajúcenasledovné:

a. musia byť získané legálnym spôsobom z dôveryhodných zdrojov,b. musia byť stále podporované výrobcom (t.j. výrobca poskytuje

bezpečnostné aktualizácie) nástroja a nesmú byť označené ako zastarané,c. musia byť aktualizované minimálne raz za 6 mesiacov a musia byť

aplikované bezpečnostné záplaty vydané výrobcom nástroja.

2.23 Vo vývojovom prostredí (vývojárske nástroje a podporné informačnésystémy vrátane použitých knižníc tretích strán), v ktorom bude vyvíjanériešenie, musia byť implementované tieto opatrenia:

a. Musia byť implementované príslušné opatrenia na zabezpečenie integrityvyvíjaného riešenia na základe najvyššej požadovanej úrovne ochranydôvernosti, integrity a dostupnosti informácií, ktoré budú spracovávané vovyvíjanom riešení.

b. Ak samotné vyvíjané riešenie obsahuje informácie, ktoré je potrebnéchrániť z hľadiska dôvernosti8, musia byť vo vývojovom prostredíimplementované opatrenia na zaistenie dôvernosti na základe požadovanejúrovne ochrany dôvernosti týchto údajov.


2.24 Kontrola vykonaných opatrení sa vykonáva dvoma spôsobmi:a. pri odovzdávaní projektu na mieste dohodnutom medzi objednávateľom

a dodávateľom,b. počas implementácie projektu na mieste, kde prebieha vývoj riešenia.

2.25 Kontrola pri odovzdávaní projektu pozostáva z:a. kontroly projektovej dokumentácie obsahujúcej minimálne návrh riešenia

s popisom jednotlivých súčastí, vývojársku dokumentáciu a dokumentáciupre používateľov a správcov

b. kontroly analýzy rizík a implementácie navrhnutých opatreníc. kontroly verzionovanej histórie vývoja projektu pozostávajúcej minimálne

z kontroly podpísaných commitov a z kontroly, či zmeny vykonanév danom commite súvisia s jeho popisom.

d. Kontroly zdrojových kódov na použité zastarané/nebezpečné funkcie.e. Kontroly formátu citlivých údajov v databázef. kontroly výsledkov testovania implementovaného riešenia

8 Napr. prihlasovacie údaje k databázam.

20

2.26 Kontrola počas implementácie projektu na mieste, kde prebieha vývojriešenia, pozostáva z:

a. kontroly použitých vývojárskych nástrojov, ich pôvodu, legálnostia aktuálnosti

b. kontroly implementovaných opatrení na zabezpečenie integrity vyvíjanéhoriešenia, prípadne aj jeho dôvernosti

c. kontroly anonymizácie použitých testovacích údajov počas implementácieriešenia

d. kontroly zapnutých bezpečnostných vlastností použitých nástrojov(varovania, ochrany)

e. Kontrolu by mala vykonávať osoba, ktorá je dostatočne technicky zdatná amá minimálne 5 rokov prax v IT odbore, je bezúhonná a nezávislá.

21

3 Minimálne požiadavky na zabezpečenie služieb dostupných z externých sietí – Webové aplikácie

Bezpečný návrh

3.1 Webová stránka by mala pozostávať z verejných a neverejných zón anavigácia medzi nimi by nemala umožniť tok citlivých informácií medzitýmito zónami.

3.2 Citlivé informácie by mali byť uchovávané v zašifrovanej podobe.

3.3 Validácia vstupov musí byť vykonávaná na strane servera a odporúča sa,aby bola vykonávaná aj na strane klienta.

3.4 Prezentačný server musí byť umiestnený v zabezpečenej demilitarizovanejzóne (DMZ), ku ktorej môžu pristupovať len autorizované osoby. Aplikačný adatabázový server by mali byť umiestnené v internej sieti neprístupnej zInternetu.

3.5 Kód musí byť udržiavaný, prehľadný a dokumentovaný. Viď sekciu 5.11.

3.6 Prezentačná vrstva musí byť oddelená od aplikačnej a databázovej vrstvy.

Šifrovanie

3.7 Webový portál musí byť prístupný prostredníctvom protokolu HTTPS.

3.8 K webovému portálu by sa nemalo pristupovať prostredníctvom HTTP.

3.9 Identita webového portálu musí byť zabezpečená platným, dôveryhodnýmcertifikátom vydaným na doménu, na ktorej je dostupný webový portál.

3.10 Identita webového portálu by mala byť zabezpečená certifikátoms Extended Validation.

3.11 Webový portál nesmie používať nedôveryhodné alebo vypršané SSL/TLScertifikáty.

3.12 Údaje, ktoré sú citlivé z hľadiska integrity alebo dôvernosti sa musiaprenášať iba prostredníctvom zašifrovaného spojenia SSL/TLS.

3.13 Citlivé údaje (zvlášť prihlasovacie údaje) musia byť prenášané výhradneprostredníctvom zašifrovaného kanála.

3.14 Webový portál by nemal ukladať citlivé informácie v nezašifrovanej podobena strane klienta, ani na strane servera.

3.15 Webový portál by nemal vkladať nešifrované zdroje bez SSL/TLS do stránokpoužívajúcich SSL/TLS.

Šifrovacie kľúče a protokoly

3.16 Webový server nesmie podporovať protokoly SSLv2 a SSLv3.

22

3.17 Webový server musí podporovať TLS 1.0 a TLS 1.1.

3.18 Webový server by mal podporovať TLS 1.2.

3.19 Webový server by nemal podporovať šifry s kľúčom kratším ako 112 bitov ablokom kratším ako 64bitov.

3.20 Webový server nesmie podporovať NULL ciphers a anonymný Diffie-Hellmanalgoritmus.

3.21 Webový server nesmie podporovať tzv. Export (EXP) šifry

3.22 Použité šifry a protokoly SSL/TLS by mali byť odolné voči známym typomútokov, ako napríklad: FREAK, BEAST (používanie TLS 1.2, pri TLS 1.0nepoužívanie šifry s AES), BREACH (Pri SSL/TLS musí byť vypnutá httpkompresia), POODLE, LOGJAM, TLS Crime (TLS kompresia by mala byťvypnutá).

3.23 Dĺžka kľúča asymetrickej šifry RSA, DSA v X.509 certifikáte musí byť aspoň2048 bitov. Toto neplatí pre ECDSA, kedy na dosiahnutie vysokejbezpečnosti postačujú kratšie kľúče – napríklad 256 bitov.

3.24 X.509 certifikáty musia byť hashované bezpečnými hashovacími funkciami(napr. kvôli možnosti kolíznych útokov nesmie byť použitý algoritmus MD5).

3.25 Webový server by mal podporovať šifry, ktoré majú vlastnosť PerfectForward Secrecy (PFS).

3.26 Webový server by nemal podporovať RC4, DES a 3DES.

3.27 Pre všetky kryptografické operácie musia byť použité kryptograficky silnégenerátory pseudonáhodných čísel.

3.28 Konfiguráciu odporúčame otestovať v SSL/TLS teste9.

3.29 Pri správe SSL/TLS je nutné sledovať a v konfigurácii reflektovať aktuálneodporúčania. V prípade použitia WAF/FW pre SSL/TLS preň platia všetkyvyššie uvedené požiadavky.

Konfigurácia webového servera

Systém

3.30 Systém, nainštalované aplikácie a frameworky musia byť pravidelneaktualizované z pohľadu bezpečnosti.

3.31 Používané verzie softvéru musia byť podporované, resp. im nesmie končiťpodpora.

3.32 Počas doby, kedy prebieha údržba, rozsiahlejšia alebo mimoriadnaaktualizácia OS/SW a/alebo nasadzovanie bezpečnostných záplat, by mali

9 Je možné využiť napríklad bezplatný test od Qualys: https://www.ssllabs.com/ssltest/index.html

23

byť webové servery oddelené od zvyšku siete organizácie alebo byťumiestnené v izolovaných sieťach.

3.33 Na serveri musia byť deaktivované všetky nepoužívané služby, frameworky,doplnky a funkcionality.

3.34 Na serveri musia byť zatvorené všetky nepotrebné porty.

3.35 Autentifikácia používateľov na OS servera musí zodpovedať nasledujúcimpožiadavkám:

3.36 Nepotrebné implicitné účty musia byť odstránené alebo zneplatnené.

3.37 Neaktívne kontá musia byť zneplatnené.

3.38 Na serveri by mali byť nakonfigurované používateľské skupiny, kontrolaprístupu a udeľovanie privilégií by mali byť pre konkrétnych používateľovriadené ich zaradením do týchto skupín.

3.39 Heslo ku kontu musí zodpovedať požiadavkám organizácie na komplexnosťhesiel a má byť znemožnený útok hádaním či hrubou silou, viď prílohadokumentu.

3.40 Právo na vykonávanie systémových úkonov musí byť obmedzené napoverených administrátorov. Tí by sa navyše vzdialene mali prihlasovať ibav restricted režime, ak sa používa RDP (RDP restricted admin).

3.41 Lokálny administrátor webservera musí byť unikátny pre každý webovýserver.

3.42 Servery s OS Windows buď nesmú byť v doméne alebo musia byťspravované RO doménovým radičom (RODC – read-only domain controller).

Webový server

3.43 Pri inštalácií webového servera a bezprostredne po nej by mali byťvykonané nasledovné kontroly a akcie:

f. SW webového servera má byť inštalovaný na dedikovanom hostiteľskomzariadení alebo na dedikovanom virtualizovanom OS.

g. Musia byť aplikované dostupné záplaty a aktualizácie na eliminovanieznámych zraniteľností

h. Pre webový obsah by mal byť vytvorený dedikovaný fyzický disk alebologická partícia (separátne od OS a SW webového servera).

i. Všetky služby inštalované popri webovom serveri, ktoré nie sú potrebné(napr. FTP server alebo služba vzdialenej administrácie) musia byť vypnutéalebo odstránené.

j. Nepotrebné východzie účty vytvorené pri inštalácií by mali byť odstránenéalebo vypnuté.

k. Z webového servera majú byť odstránené testovacie a ukážkové súboryvrátane vykonateľných súborov a skriptov a dokumentácia výrobcu.

24

l. Odporúčame na server aplikovať hardenovací skript alebo bezpečnostnúšablónu, vhodný pre daný OS a webový server. Info možno čerpaťz príručiek dostupných na webstránke CSIRT.SK10.

m. Banner HTTP služby by mal byť rekonfigurovaný, podľa potreby aj s ďalšímibannermi tak, aby nereportovali typ a verziu webového serveraa podkladového OS.

3.44 Webový server by mal podporovať iba HTTP metódy POST a GET.

3.45 Webový server nesmú podporovať (musia byť vypnuté) HTTP metódyOPTIONS, TRACK a TRACE.

3.46 Webový server musí byť odolný voči SlowHTTP DoS útokom (limitácia počtuspojení z jednej IP adresy, nastavenie timeoutu na HTTP requesty,implementácia loadbalancerov)

3.47 Z webového servera musia byť odstránené všetky nadbytočné a nepotrebnésúbory a zložky, obzvlášť konfiguračné súbory a zálohy, ladiace výstupy,dočasné súbory, nepotrebné zdrojové kódy a zálohy súborov.

3.48 Ladiace funkcionality (napríklad ASP.NET Application Trace) musia byťvypnuté.

3.49 Na serveri musí byť nakonfigurovaný defaultný virtuálny host na obsluhuprístupu na webserver prostredníctvom IP adresy (cez prehliadač). Nesmiebyť zobrazovaná defaultná stránka použitého frameworku a pod.

3.50 Webový server musí zobrazovať v prípade chyby servera iba všeobecnéchybové hlásenia.

3.51 Webový server by nemal podporovať funkcionalitu listovania adresára(Directory listing, Microsoft IIS tilde directory enumeration).

3.52 Súbor robots.txt nesmie obsahovať odkazy na citlivé zdroje aplikácie(napríklad prihlasovanie administrátora a podobne).

3.53 Webový server by mal byť chránený WAF (web aplikačný firewall)minimálne s nasledujúcou funkcionalitou:

a. Detekcia a prevencia známych útokov (Code injection – SQL, XSS,Command, XPATH, ...),

b. Kontrola používateľských vstupov prostredníctvom whitelistingu a ichprekódovanie do HTML entít alebo podobných bezpečných náhrad.

3.54 Webový server s aplikáciou spracúvajúcou citlivé údajov a/aleboklasifikované informácie, musí byť chránený WAF, ktorého konfigurácia musíbyť reštriktívna (kontrola business logiky a pod).

3.55 Na zvýšenie dostupnosti webového servera odporúčame použiť loadbalancery. Podľa možnosti môžu byť rozšírené o web cache. V prípade

10 https://www.csirt.gov.sk/informacna-bezpecnost/osvedcene-postupy/nase-publikacie-85a.html

25

podpory web cache nesmú byť cacheované administrátorské stránky,prístupové údaje a podobné citlivé informácie.

3.56 Na zvýšenie dostupnosti webového servera môžu byť ako bezpečnostnébrány použité reverzné proxy. Podľa možnosti môžu byť rozšírené o funkcieakcelerácie šifrovania, používateľskej autentifikácie alebo filtrovaniaobsahu.

3.57 Webový server nesmie podporovať klientom iniciovanú SSL/TLSrenegociáciu šifrovacích kľúčov (kvôli DoS útoku).

3.58 Webový server musí dodržiavať negociačný postup negociácie TLSspojenia, popísaný v RFC 5746, kvôli zraniteľnosti Insecure renegociation ariziku útoku typu MitM.

3.59 Webový server by mal podporovať bezpečnú renegociáciu (Securerenegotiation)

3.60 V prípade viacerých virtuálnych hostov musí byť oddelené úložisko cookiesminimálne na úrovni adresárov.

Administrácia, logovanie a zálohovanie

3.61 Správcovské rozhrania na všetky služby musia byť dostupné iba zdôveryhodných lokalít (potrebná reštrikcia na lokálne siete).

3.62 Z produkčných systémov musia byť odstránené všetky testovacie apôvodné účty.

3.63 Všetky servery a syslog servery musia byť synchronizované sdôveryhodným NTP serverom.

3.64 Webové správcovské rozhrania musia byť dostupné iba prostredníctvomSSL/TLS.

3.65 Na serveri musí byť aktívne logovanie:a. Malo by byť použité kombinované logovanie na ukladanie Transfer logov

(formát podporujúci prispôsobenie formátu logu). Ak takýto formát nie jedostupný, je potrebné zabezpečiť aby bolo logované aj hlavičky Referer aUser-Agent.

b. Pre každý virtuálny host na fyzickom webserveri by mal existovaťseparátny log.

c. V logoch musia byť uvedené: timestamp, kedy udalosť nastala, vrátaneurčenia časovej zóny, verejná IP adresa používateľa, dopytovanástránka/URL, HTTP kód odpovede servera, veľkosť odpovede serverav bytoch, obsahy hlavičiek User-Agent a Referer. V prípade záznamovo udalostiach súvisiacich s autentifikáciou alebo s činnosťou autentifikovaného používateľa je nutné zaznamenať účet a akciu, aká bolavykonaná.

d. Logy musia byť uchovávané na separátnom zariadení, resp. na separátnejlogickej partícii.

e. Na uchovávanie logov musí byť vyhradená dostatočná kapacita.

26

f. Logy by mali byť byť archivované po dobu stanovenú pravidlamiorganizácie, minimálne však počas 6 mesiacov.

g. Logy musia byť prezerané v pravidelných intervaloch v závislosti odpolitiky organizácie, minimálne však raz týždenne. V prípade služieb, ktoréspracúvajú citlivé údaje alebo ich správna činnosť ovplyvňuje kritickéaktíva organizácie, by mali byť logy kontrolované denne.

3.66 Webový server musí byť pravidelne zálohovaný nasledovným spôsobom:a. Zálohovanie servera má byť upravené organizačnými opatreniami

organizácie.b. Archívna záloha musí byť vytvorená minimálne raz ročne.c. Diferenciálna alebo zmenová záloha webového servera má byť vytvorená

na dennej až týždennej báze.d. Plný backup webového servera by mal byť vytváraný v týždňových až

mesačných intervaloch.e. Zálohy servera by mali byť periodicky archivované na externé médiá.f. Mala by byť uchovávaná autoritatívna kópia webovej stránky/stránok

Kontrola prístupu OS a webového servera

3.67 Proces webového servera aj proces backendovej databázy musí byťkonfigurovaný tak, aby bežal pod unikátnym používateľským kontoms limitovanou množinou privilégií.

3.68 Webový server by mal byť konfigurovaný tak, aby súbory s webovýmobsahom boli procesom prislúchajúcim službe webového servera prístupnéna čítanie, no nie na zápis. Procesy webového servera by nemali mať právozápisu do priečinkov, kde je uchovávaný verejný webový obsah (webcontent).11

3.69 OS by mal byť nakonfigurovaný tak, aby proces webového servera moholvytvárať log záznamy, no nemohol ich čítať.

3.70 OS by mal byť podľa možnosti nakonfigurovaný, aby dočasné súboryvytvorené procesmi webového servera boli obmedzené na určený a vhodnezabezpečený priečinok. Ak je to možné, prístup k dočasným súborom bymal byť obmedzený na procesy, ktoré ich vytvorili.

3.71 Webový obsah a všetky logy ním vytvárané by mali byť umiestnené naseparátnom pevnom disku alebo na inej logickej partícii, ako OS a webovýserver.

3.72 Odporúča sa webový server izolovať od iných procesov použitímprostriedkov ako napríklad chroot, kontajnery, virtualizácia a pod.

3.73 Pre externé skripty a programy, vykonávané ako časť obsahu webovéhoservera by mal byť vytvorený samostatný priečinok (napr. JavaScriptknižnice a pod).

11 Iba procesy určené na správu webservera (nie procesy bežiacej webovej služby) bymali mať právo zapisovať do súborov s webovým obsahom.

27

3.74 Mal by byť stanovený maximálny počet procesov webového servera a/alebosieťových spojení, ktoré by server mal povoliť.

3.75 Spúšťanie skriptov, ktoré nie sú výlučne pod kontrolou administratívnehokonta, malo by byť zakázané (napr. vytvorením a kontrolou prístupuk separátnemu priečinku, obsahujúcom autorizované skripty).

3.76 Použitie symbolických linkov by malo byť pre procesy webového serverazakázané12.

3.77 Odporúčame vytvoriť kompletnú maticu prístupov k webovému obsahu(access matrix). V nej by malo byť definované, ktoré súbory a priečinkymajú byť prístupné a pre koho.

3.78 V odôvodnených prípadoch odporúčame zaviesť kontrolu proti botom (napr.CAPTCHA, nofollow, filtrovanie kľúčových slov).

HTTP hlavičky a cookies

3.79 Server by mal pri SSL/TLS používať HSTS - HTTP Strict Transport Security.Nastavené by mali byť direktívy:

a. max-age=<číslo> – počet sekúnd, počas ktorých má prehliadačautomaticky konvertovať všetky HTTP požiadavky do HTTPS

b. includeSubDomains – indikuje, že všetky subdomény aplikácie musiapoužívať HTTPS

3.80 V odpovediach webového servera sa nesmú nachádzať hlavičkyprezrádzajúce použitú technológiu a / alebo jej verziu (Server, X-Powered-By, X-AspNet-Version a pod.)

3.81 V hlavičkách sa nesmú nachádzať informácie o použitých technológiách,backendových serveroch, internej infraštruktúre, ani bezpečnostnýchprvkoch.

3.82 Server by mal používať hlavičky:a. X-Frame-Options: SAMEORIGIN (alebo DENY)b. X-XSS-Protection: 1c. X-Content-Type-Options: nosnifd. Strict-Transport-Security

3.83 V odpovediach webového servera by sa nemali nachádzať hlavičky X-Forwarded-For a HTTP_PROXY

Aplikácia (webový portál)

3.84 Aplikácia musí ošetrovať všetky chyby a výnimky.

3.85 Aplikácia musí zobrazovať v prípade chyby aplikácie iba všeobecné chybovéhlásenia.

3.86 V generovanom kóde nesmú byť prítomné komentáre, citlivé informácie aodkazy na vnútorné IP adresy.

12 Príklad pre konfiguráciu Apache: odstrániť Options FollowSymLinks

28

3.87 Aplikácia musí pristupovať k ďalším aplikáciám a serverom prostredníctvomdoménového mena (nie IP adresy, obzvlášť internej).

3.88 Aplikácia nesmie reflektovať obsahy hlavičiek v odpovedi servera.

3.89 Pre posielanie citlivých a autentifikačných údajov musí byť vynucovanéHTTPS spojenie.

3.90 Aplikácia nesmie ukladať citlivé údaje (napríklad identifikátor relácie) v URLadrese. V prípade zakázania cookies v prehliadači musí stránka zobraziťhlásenie o nutnosti použitia cookies (ak sa používajú).

3.91 Aplikácia by nemala používať odkazy na externé zdroje (zdroje mimo správyprevádzkovateľa alebo inštitúcie verejnej správy na SR).

3.92 Aplikácie nesmie používať odkazy na nedôveryhodné externé zdroje.

3.93 Všetky činnosti privilegovaných používateľov a administrátorov by mali byťzaznamenávané do log súborov prostredníctvom vzdialených logovacíchserverov (syslog, Windows Event Forward).

3.94 Aplikácia nesmie používať funkciu eval() alebo jej alternatívy.

3.95 Z aplikácie musia byť odstránené všetky ladiace výstupy, dočasné súbory,nepotrebné zdrojové kódy a zálohy súborov.

Autentifikácia a autorizácia

3.96 Aplikácia musí pre všetky autorizačné mechanizmy implementovať politiku,pri ktorej je zakázané všetko, čo nie je explicitne povolené (default-deny).

3.97 Aplikácia musí vyžadovať autentifikáciu pre každú privilegovanú operáciu(napr. meno a heslo na prvotné prihlásenie, token).

3.98 Aplikácia musí implementovať autorizáciu a autentifikáciu na straneservera.

3.99 Musia byť odstránené všetky testovacie a pôvodné účty z produkčnýchsystémov.

3.100 Pre všetky citlivé operácie musia byť implementované anti-CSRF tokeny,ktoré musia byť pri vykonaní operácie overované.

3.101 Pre webové aplikácie, ku ktorým je na prístup nutná autentifikácia, jenutné zabezpečiť, aby žiadna webová stránka, ktorá má byť prístupné až poautentifikácii, nebola dostupná bez vykonania kompletného procesuautentifikácie.

3.102 Autentifikácia musí prebiehať prostredníctvom protokolu HTTPS.

3.103 Aplikácia musí vyžadovať používanie silných hesiel, viď Príloha A –Politika hesiel.

29

3.104 V prípade použitia iniciálnych náhodne generovaných hesiel pre novéhopoužívateľa musí aplikácia pri prvom prihlásení vyžadovať zmenu tohtohesla, v súlade s definovanými pravidlami pre tvorbu hesiel.

3.105 Aplikácia musí umožňovať administrátorom i používateľom zmeniť ichheslo.

3.106 Aplikácia musí vyžadovať pravidelnú zmenu hesla, musí byť nastavenýminimálny a maximálny interval na zmenu hesla.

3.107 Aplikácia musí pri zmene hesla vyžadovať zadanie starého hesla.

3.108 Aplikácia musí pri zmene hesla vyžadovať opakované zadanie novéhohesla (2 krát), pričom nové zadané heslá sa musia zhodovať.

3.109 Odporúčame pri zmene hesla používať viacfaktorové potvrdenie,napríklad Out-Of-Band kanálom (mail, SMS, ...)

3.110 Aplikácia musí po zmene hesla vydať nový identifikátor relácie, cez ktorúzmena hesla nastala. Ostatné relácie príslušného používateľa musia byťzneplatnené.

3.111 Aplikácia by mala pri zmene hesla notifikovať používateľaprostredníctvom Out-Of-Band kanála.

3.112 Aplikácia musí uložené heslá hashovať prostredníctvom štandardnýchkryptografických hashovacích funkcií a musí používať soľ (angl. salt).

3.113 Aplikácia musí implementovať funkcionalitu pre odhlásenie (log-out) ajpre automatické odhlásenie po istej dobe nečinnosti. Funkcia odhlásenia mábyť jednoducho identifikovateľná a dostupná z každej stránky, prístupnej poautentifikácii.

3.114 Aplikácia musí po odhlásení zneplatniť všetky relácie daného používateľa.

3.115 Odporúča sa, aby aplikácia podporovala simultánne paralelné prihláseniek jednému účtu iba z jednej verejnej IP adresy. Odporúča sa, aby aplikáciapri zmene verejnej IP adresy prihláseného používateľa požadovalareautentifikáciu13.

3.116 Odporúča sa naviazanie relácie na parameter User-Agent.

3.117 Aplikácia musí podporovať spustenie mechanizmu zamknutia účtu(lockout) po istom počte neúspešných pokusov (maximálne 5) o prihlásenie.

3.118 Zamknutie účtu po stanovenom počte neúspešných pokusov o prihláseniemusí trvať aspoň 10 minút.

3.119 Zamknutie účtu po stanovenom počte neúspešných pokusov o prihláseniedo kritického systému by malo trvať aspoň hodinu.

13 Upozorňujeme, že funkcionalita zviazania zdrojovej IP adresy s reláciou je problematická ak k aplikácii pristupujú klienti, ktorých ISP dynamicky mení zdrojovú verejnú IP adresu. Taktiež môže byť problematická ak sa používa IPv6.

30

3.120 Je nutné vytvárať log záznamy všetkých pokusov o autentifikáciu (log-in,log-out, neúspešný log-in, lockout konta, žiadosť o zmenu hesla).

3.121 V prípade zamknutia účtu by aplikácia mala notifikovať zodpovednúosobu, resp. administrátora aplikácie.

3.122 Pre privilegované účty sa musia používať používateľské mená, ktoré nie jemožné jednoducho dedukovať (napr. štandardné loginy ako admin,administrator, user a pod, názov alebo typ aplikácie, kombinácie uvedenýcha pod.).

3.123 Aplikácia nesmie pre kritické systémy umožniť funkcionalitu zapamätaniasi hesla.

3.124 Používateľské kontá by mali byť po určitej dobe nečinnosti znefunkčnené.

3.125 Používateľské kontá, ktoré neboli použité do 3 mesiacov od ich vytvorenia(používateľ sa počas danej doby nikdy neprihlásil), by mali byťdeaktivované.

3.126 Každý používateľ a administrátor musia mať jedinečné ID.

3.127 Aplikácia nesmie umožniť vytváranie účtov s používateľským menompodobným administrátorským či servisným kontám. Napríklad: admin,administrator, helpdesk, support a pod.

3.128 Aplikácia musí korektne inštruovať prehliadač, aby neukladal citlivéinformácie, prenášané prostredníctvom HTTPS, do cache (a aby neboli bezkontroly opäť prístupné z histórie prehliadania) minimálne v rozsahu:

a. Server musí nastavovať vo svojich odpovediach hlavičky ◦ Cache-Control: no-cache, no-store, private, must-re-validate, max-

age=0, no-transform◦ Expires: 0◦ Pragma: no-cache

Používateľské vstupy

3.129 Všetky používateľské vstupy musia byť kontrolované na strane serveraprostredníctvom whitelistov alebo regulárnych výrazov v kontexte, vktorom sú použité.

3.130 Aplikácia musí brať ako vstupy a primerane ošetrovať všetkypoužívateľom ovplyvniteľné časti dopytu, vrátane HTTP hlavičiek, URL,Cookies a pod. Bez ošetrenia nesmú byť reflektované v odpovedi servera.Napríklad:

a. Aplikácia musí byť odolná voči HTTP Spitting/Smuggling útokomb. Aplikácia by mala byť odolná voči HTTP Parameter Pollution (HPP) útokom.c. Aplikácia/webový server musí byť odolný voči Host Header útoku.

3.131 Aplikácia by mala používať parametrizované SQL požiadavky (queries),tzv. prepared statements.

31

3.132 Aplikácia nesmie na tvorenie SQL dotazov využívať používateľské vstupybez ich dôkladnej kontroly a ošetrenia.

3.133 Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím.Minimálne:

a. Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím vnázvoch súborov a zložiek.

b. Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím vakomkoľvek skripte, databázovom dopyte alebo parametri príkazuoperačného systému.

c. Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím vkontexte HTML.

d. Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím vkontexte JavaScript.

e. Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím vkontexte REST API.

f. Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím v XMLdokumentoch.

g. Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím v XPathpožiadavkách (query).

h. Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím v XSL(T)style sheets.

i. Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím v SSI(Server-Side Inclusion statements) príkazoch, ak je použitie SSI nutné apovolené.

j. Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím v HTTPhlavičkách.

k. Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím v HTTPparametroch.

l. Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím v LDAPpožiadavkách.

m. Aplikácia musí ošetrovať vstupy od používateľa pred ich použitím vregulárnych výrazoch.

n. Aplikácia musí ošetrovať vstupy/dátové prúdy prechádzajúce medzimodulmi aplikácie.

Relácie

3.134 Aplikácia by mala používať CSRF tokeny o veľkosti aspoň 128 bitov.

3.135 Aplikácia by nemala povoliť požiadavky spôsobujúce zmenu údajov,alebo citlivú operáciu bez platného CSRF tokenu.

3.136 Aplikácia nesmie povoliť požiadavky na privilegované operácie bezplatného CSRF tokenu.

3.137 Na generovanie CSRF tokenov musí aplikácia používať kryptografickysilný generátor pseudonáhodných čísel.

32

3.138 Pri prihlásení musí aplikácia znovu vygenerovať nový identifikátor relácie.Identifikátor predchádzajúcej neautentifikovanej relácie musí byťzneplatnený.

3.139 Pri zmene prihlasovacích údajov (používateľské meno, heslo) musíaplikácia znovu vygenerovať identifikátor relácie.

3.140 Pri zmene prihlasovacích údajov (používateľské meno, heslo) musíaplikácia zneplatniť ostatné relácie príslušného používateľa.

3.141 Pre relačné (session) cookies musí aplikácia nastaviť Secure flag.

3.142 Pre relačné (session) cookies musí aplikácia nastaviť HttpOnly flag.

3.143 Pre relačné (session) cookies musí aplikácia nastaviť reštriktívnu doménu.

3.144 Pre relačné (session) cookies musí aplikácia nastaviť reštriktívnu cestu(path).

3.145 Pre generovanie relačných identifikátorov musí aplikácia používaťkryptograficky silné generátory pseudonáhodných čísel.

3.146 Aplikácia by mala používať relačné identifikátory o veľkosti aspoň 128bitov.

3.147 Aplikácia musí zamietať neznáme relačné identifikátory zo strany klienta.

3.148 Relačné identifikátory musí aplikácia prenášať iba cez zabezpečenépripojenia. Aplikácia musí vynucovať periodickú exspiráciu a zneplatnenierelácií.

Nahrávanie súborov

3.149 Aplikácia musí nahrávané súbory ukladať mimo koreňového súboru predokumenty (document root) na separátnu partíciu disku (inú, ako jevyhradené na zápis logov), kde súčasne nesmie byť možnosť listovaniaadresára a nesmie byť možnosť interpretovať nahraté súbory ako napríkladskripty (PHP, ASP, JSP, ...).

3.150 Aplikácia nesmie spúšťať a vyhodnocovať (evaluate) nahraté súbory.

3.151 Aplikácia musí vynucovať limit pre veľkosť nahratých súborov.

3.152 Aplikácia by mala obmedzovať počet súborov nahraných za hodinu.

3.153 Aplikácia musí umožniť nahrávanie iba špecifických typov súborov akontrolovať nielen ich príponu, ale aj MIME typ.

3.154 Aplikácia by mala nahrávané súbory kontrolovať na prítomnosť škodlivéhokódu prostredníctvom antimalware riešenia.

3.155 Nahrávané súbory by sa nemali ukladať pod pôvodným názvom.

Obsah

33

3.156 Aplikácia by mala pre všetky poskytované zdroje explicitne definovať typobsahu.

3.157 Aplikácia by mala pre všetky poskytované stránky definovať „characterset“.

3.158 Zabezpečenie aktívneho obsahu (skripty, spustiteľné súbory):a. Právo na čítanie a zápis do súborového systému by malo byť limitované

alebo zakázané.b. Mala by byť povolená žiadna alebo len limitovaná interakcia s inými

programami.c. Nemala by byť potrebná žiadna akcia so SUID privilégiami (OS UNIX/Linux).d. Skripty by pri spúšťaní externých programov mali používať absolútne cesty

alebo nepoužívať žiadne cesty a spoliehať sa na premennú PATH, pričom támusí obsahovať len bezpečné adresáre.

e. Žiadne priečinky nesmú mať súčasne práva na zápis a vykonávanie.f. Spustiteľné súbory by mali byť umiestnené vo vyhradených priečinkoch.g. SSI (Server-Side Inclusion) by mali byť zakázané, resp. nie je možné ich

spúšťať.

3.159 Spracovanie XMLa. Aplikácia nesmie podporovať XML External entity expansion.b. Aplikácia nesmie podporovať parsovanie XML External DTD.c. Aplikácia nesmie podporovať všetky nadbytočné alebo nebezpečné XML

rozšírenia.d. Aplikácia by mala používať XML parser, ktorý neexpanduje entity

rekurzívne.

Rôzne

3.160 Aplikácia by nemala podporovať presmerovanie na používateľomposkytnuté externé umiestnenia.

3.161 Aplikácia by mala obmedziť (krížový) prístup k (cudzím) doménamprostredníctvom whitelistingu.

a. Ak je na riadenie prístupu medzi doménami používané CORS (Cross OriginResource Sharing), konfigurácia by mala byť obmedzená na dôveryhodnédomény. Napr. nemala by byť použitá direktíva Access-Control-Allow-Origin:*

b. Ak aplikácia používa na kontrolu prístupu k zdrojom na externýchdoménach súbory crossdomain.xml a/alebo clientaccesspolicy.xml, obsahby mal mať obmedzený na nutné domény, porty a protokoly. Nemali by byťpoužívané nadmerne voľné pravidlá s „*“. Crossdomain.xml aclientaccesspolicy.xml nesmú byť prístupné koncovému používateľovi.

3.162 Aplikácia by mala pre všetky emailové funkcionality implementovať ratelimiting.

3.163 Aplikácia by mala pre všetky funkcionality vyžadujúce veľa zdrojov(napríklad CPU čas) implementovať rate limiting.

34

3.164 Pri implementácii rate limitingu sa musí brať ohľad na predchádzanieneúmyselnému odopretiu služby.


3.165 Bezpečnosť webových aplikácií je nutné pravidelne preverovať externýmskenom zraniteľností.

3.166 Externým penetračným testom by mal prejsť každý projekt ešte prednasadením do ostrej prevádzky.

3.167 Komplexný kontrolný externý penetračný test odporúčame vykonať razročne.

3.168 V prípade, že webový server sa nachádza v infraštruktúre organizácie,bezpečnosť podkladového OS má byť preverovaná tak, ako je uvedenév kapitole o zabezpečení internej infraštruktúry organizácie.

3.169 Bezpečnostný audit servera a aplikácie by mal byť vykonaný minimálneraz ročne.

35

4 Minimálne požiadavky na zabezpečenie infraštruktúryV tejto kapitole sú uvedené požiadavky na zabezpečenie infraštruktúry, ktoré súspoločné pre internú infraštruktúru aj pre externú infraštruktúru.

Výnimkou k požiadavkám uvedeným v tomto dokumente je labová sieť – t.j.testovacia sieť určená na testovanie nových technológií. Takáto sieť – ak sapoužíva – by mala byť fyzicky oddelená od siete organizácie a mala by využívaťvlastné pripojenie do externých sietí. Nesmú existovať prepojenia medzikoncovými stanicami internej siete organizácie a labovou sieťou.


4.1 Prístup k službe musí byť filtrovaný aspoň na centrálnom FW, na lokálnomFW systému a v konfigurácii danej služby.

4.2 Všetok softvér a firmvér musí byť pravidelne aktualizovaný. Musia byťdodržané tieto princípy:

a. Aktualizácia systémov musí prebiehať prostredníctvom kanálazabezpečujúceho integritu a autentickosť.

b. Odporúča sa vopred otestovať vplyv aktualizácii na systém na testovacomzariadení.

c. V prípade infraštruktúry Windows a použitia lokálneho aktualizačnéhoservera (WSUS) je nutné implementovať šifrovanie aj metadát aimplementovať používanie certifikátov podpísaných dôveryhodnoucertifikačnou autoritou.

4.3 Na zariadeniach musí byť zapnuté minimálna množina služieb potrebná presprávne fungovanie. Všetka nepotrebná funkcionalita by mala byťneimplementovaná/neinštalovaná - musí byť aspoň vypnutá.

4.4 Konfiguračné súbory musia byť zabezpečené minimálne takto:a. Konfiguračné súbory by mali byť modifikovateľné len správcom.b. Súbory obsahujúce heslá, kryptografické kľúče a iné tajomstvá musia byť

modifikovateľné a čitateľné len oprávnenými používateľmi.

4.5 Správcovské a monitorovacie rozhrania sieťových prvkov a serverov nesmúbyť prístupné priamo z externej siete. Správcovské a monitorovacierozhrania musia byť prístupné len zo špecifikovaných sietí (napr.administrátorská sieť).

4.6 Správcovské rozhrania služieb by nemali byť priamo prístupné z externejsiete. V prípade potreby dostupnosti takýchto rozhraní sa odporúča využiťsprávcovská VPN. V prípade nutnosti sprístupnenia priamo z externej sieteje nutné sprístupniť to len dočasne pre špecifikované zdrojové IP adresy aodporúča sa využiť dodatočnú formu autentifikácie ako je napríklad použitieklientskych certifikátov.

4.7 Správcovské rozhrania zariadení a služieb by nemali byť prístupné ceznešifrované kanály. Pre prístup na správcovské rozhrania sa odporúča

36

využívať autentifikáciu pomocou asymetrickej kryptografie (napr. RSAkľúče, alebo klientske certifikáty). Mal by byť nakonfigurovaný maximálnytimeout pre platnosť neaktívneho spojenia. Musia byť logované všetkypokusy o prihlásenie na správcovské rozhrania.

4.8 Všetky autentifikačné mechanizmy musia používať silnú autentifikáciu. Vprípade hesiel a zdieľaných tajomstiev platia požiadavky na komplexnosť adĺžku hesla, v prípade certifikátov a kryptografických kľúčov platiapožiadavky na minimálnu dĺžku a použitý hashovací algoritmus (požiadavkysú uvedené v prílohe A).

4.9 Ak sa nepoužíva IPv6, musí byť vypnutá podpora IPv6 v celej infraštruktúre.To znamená, že koncové stanice musia mať vypnutý IPv6 stack, switche asmerovače nesmú spracovávať a preposielať IPv6, na sieťových firewallochmusia byť nastavené pravidlá zahadzujúce IPv6 komunikáciu vrátane IPv6komunikácie tunelovanej cez IPv4.

4.10 Ak sa používa IPv6, všetky bezpečnostné prvky (napr. FW, IPS, ACL)filtrujúce komunikáciu musia rozoznávať a kontrolovať aj IPv6.

4.11 Všetky koncové zariadenia by mali byť nakonfigurované tak, abynespracovávali ICMP Redirect a ICMPv6 Redirect správy.

4.12 Fyzická bezpečnosť zariadení musí byť zabezpečená aspoň v tomtorozsahu:

a. Prístup k zariadeniu musí mať len autorizovaný personál (aspoň na úrovniprístupu do miestnosti, v prípade zdieľaných miestností aj na úrovnistojanového rozvádzača).

b. Musia byť zabezpečené vhodné prevádzkové podmienky zabezpečujúcestabilitu systému určené na základe odporúčaní výrobcu. Minimálne musíbyť kontrolovaná teplota, vlhkosť, prašnosť a bezpečný prívod elektrickejenergie.

Konfigurácia sieťovej infraštruktúry

4.13 Nepoužívaný verejný IP rozsah organizácie by mal byť null-routed (t.j.nesmerovaný .

4.14 Servery poskytujúce služby či už do externej alebo internej siete musia maťsmerom do externej siete povolenú len potrebnú komunikáciu na základewhitelistingu.

4.15 Správcovské rozhrania sieťových prvkov by mali byť dostupné len cezdedikované manažmentové rozhranie a z fyzicky oddelenej správcovskejsiete.

4.16 Pre prístup by nemal byť použitý telnet ani HTTP, odporúča sa využívaťSSHv2 alebo HTTPS. Pre zálohovanie by nemalo byť použité TFTP, odporúčasa SCP alebo SFTP.

37

4.17 Pre autentifikáciu prístupov sa odporúča implementovať autentifikačnýserver (napríklad TACACS+ alebo Radius). Lokálne heslo nakonfigurovanépre offline prístup by malo byť unikátne pre každé zariadenie a prístupnélen v prípade potreby a nedostupnosti služby autentifikačného servera. Vrámci infraštruktúry by nemali byť používané zdieľané administrátorskéheslá. Kedykoľvek je to možné, musia byť heslá v konfigurácii zariadeniauložené v šifrovanej / hashovanej forme. Pričom hash nesmie byťreverzibilný (ako je napr. Cisco password type 7).

4.18 Aktívne sieťové prvky musia byť pred nasadením do prevádzkyhardenované a to aspoň v rozsahu:

a. Vypnutie nepotrebných služieb (napríklad bootp, CDP, DHCP klient, HTTPserver, SNMP a iné).

b. Nastavenie manažment rozhrania, prístupových metód a ACL.c. Vypnutie password-recovery precedúry.d. Nastavenie žiadanej úrovne logovania bezpečnostných udalostí.e. Odporúča sa hardenovať podľa odporúčaní výrobcu.

4.19 Kontrolné správy vymieňané sieťovými prvkami zapojenými v móde "highavailability" (napr. hraničné smerovače vo failover móde) musia maťzabezpečenú autentickosť a mali by mať zabezpečenú aj dôvernosť(napríklad využitím silného failover kľúča). Taktiež by mali na komunikáciupoužívať separátny na to určený kanál.

4.20 Komunikácia v rámci použitých smerovacích protokolov musí byťautentifikovaná.

4.21 Pri každej zmene v sieťovej infraštruktúre je nutné aktualizovať ACL a FWpravidlá.

4.22 Odporúča sa dokumentovať účel a potrebu FW pravidiel a ACL pravidiel vkomentároch daných pravidiel.

4.23 Ak sa používa IPv6, musia byť aplikované IPv6 ACL a FW pravidlá v celejinfraštruktúre a musia brať ohľad na špecifiká IPv6. IPv6 infraštruktúra musíbyť hardenovaná minimálne v rozsahu:

a. princípy architektúry siete a filtrovania komunikácie na základe „leastpriviledge“ sú obdobné ako pre IPv4 a mali by byť dodržané základnépravidlá uvedené v tomto dokumente

b. Hraničné routre musia byť nakonfigurovaná podľa pravidiel uvedených preIPv4 routre s týmto rozdielom: musia byť schopné odosielať ICMPv6 PacketToo Big správu.

c. Mal by byť implementovaný anti-bogon filtering na vstupoch z externýchsietí.

d. V sieti by nemali byť používané ani povolené „deprecated“ IPv6funkcionality. Nesmie sa používať Extension Header Routing type 0 a musíbyť zahadzovaný na sieťových firewalloch.

e. Nemali by byť používané ani preposielané žiadne IPv6 Extension Headers svýnimkou ESP a AH ak je používaný IPSec.

f. Klientské stanice nesmú byť prístupné priamo z Externých sietí.

38

g. Klientské stanice by mali pristupovať do Externých sietí cez proxyh. Sieťové firewally musia byť schopné mapovať k povoleným spojeniam

prípadné vracajúce sa ICMPv6 Error správy. Sieťové firewally narozhraniach vnútornych a externých sietí musia rozoznávať a filtrovať IPv6extension headers.

i. Pri prideľovaní IPv6 adries serverom by mal byť dodržaný princíp riedkejalokácie adries. Ak sa používa DHCPv6 pre klientské počítače, odporúča savyužiť princíp riedkej alokácie adries.

j. Pakety s multicastovou zdrojovou IPv6 adresou musia byť zahadzované.k. Smerovače musia rešpektovať IPv6 unicast aj multicast scope (napr. paket

s Link Local zdrojovou IP adresou nesmie byť smerovaný ďalej)l. Zariadenia v sieti by nemali odpovedať na ICMPv6 echo request s

multicastovou cieľovou IPv6 adresoum. Ak sa nepoužíva QoS, odporúča sa normalizácia polí Flow Label a ToS v

IPv6 hlavičkách spojení s Externými sieťami.

Zabezpečenie servera

4.24 Odporúča sa aby každá služba bežala na samostatnom serveri. Ak jepotrebné využiť jeden server pre viacej služieb, musia na ňom bežať službys podobným určením a požiadavkami na hardvérovú a softvérovúkonfiguráciu.

4.25 Všetky servery dostupné z externých sietí musia byť hardenované podľaodporúčaní výrobcu. Všetky servery by mali byť hardenované podľaodporúčaní výrobcu.

4.26 Každá sieťovo prístupná služba by mala byť spúšťaná pod dedikovanýmpoužívateľom a tento používateľ by mal mať obmedzené práva v rámcisystému na nutné minimum. Všetky ostatné služby a aplikácie bežiace nadanom serveri by mali bežať s právami obmedzenými na nutné minimum.

4.27 Všetky používateľom kontrolované vstupy by mali byť ukladané na diskovúpartíciu inú od systémovej partície (na ktorej sú súbory OS a aplikácií).

4.28 Pri inštalovaní nového servera sa odporúča začínať od minimálnej inštaláciea doinštalovať programy a služby podľa potreby.

4.29 Pri inštalovaní nového servera alebo nasadzovaní novej služby je nutnévykonať to v separátnej sieti (VLAN) na to určenej. Do tejto siete a z tejtosiete musí byť povolená len minimálna nutná komunikácia na správcovskýprístup, inštaláciu aktualizácii a testovanie služby.

4.30 Servery s OS Windows v DMZ (so službami dostupnými z externých sietí)musia byť spravované RO doménovým radičom (RODC – read-only domaincontroller), alebo ak to nie je možné, tak nesmú byť zaradené v doméne.

4.31 Na kritických serveroch s OS Windows ako sú doménové kontrolery, DNSservery apod. musí byť implementovaný whitelisting spúšťateľných súborov(napr. Applocker od Microsoft) tak, aby bolo možné spúšťať ibadôveryhodné povolené aplikácie.

39

4.32 Na kritických serveroch s OS Windows ako sú doménové kontrolery, DNSservery apod. musí byť nainštalovaný a nakonfigurovaný nástroj EMET (odMicrosoft) so zapnutými všetkými ochranami, ktoré je možné zapnúť. Akpre niektorý používaný program nie je možné zapnúť všetky ochrany,odporúča sa prehodnotiť potrebu jeho používania.

4.33 Na kritických serveroch ako sú servery s externe dostupnými službami,doménové kontrolery, DNS servery apod, by mali byť aktualizácie amitigácie pre kritické zraniteľnosti (s vysokým dopadom) aplikované do 72hodín od ich zverejnenia.

Monitorovanie a logovanie

4.34 V prípade neobvyklej udalosti by mal byť notifikovaný systémovýadministrátor a to minimálne v týchto prípadoch:

a. blížiace sa zaplnenie kapacity úložného priestorub. neštandardne vysoká záťaž systému (load)c. detegovaná neobvyklá bezpečnostná udalosť

4.35 Logy by mali byť posielané zabezpečeným kanálom a/alebo dedikovanousprávcovskou linkou.

4.36 Odporúča sa implementovať unifikovaný centrálny monitorovací systém snastavenými metrikami pre každé monitorované zariadenie/systém.Príklady nastavenia metrík: upozornenie e-mailom pri 80% zaplneniadiskovej partície, SMS alert pri 95% zaplnení diskovej partície, upozorneniepri 50% využití CPU počas 5 minút, SMS alert pri nedostupnosti kritickejslužby viac ako 5 minút.

4.37 Musia byť monitorované všetky centrálne sieťové prvky a servery a službyprístupné do externých sietí ako aj kritické interné servery a služby. Mali bybyť monitorované všetky sieťové prvky a servery a služby.

4.38 Musí byť určený personál zodpovedný za monitorovanie logov a upozornenía vykonanie potrebnej akcie v prípade incidentu. Odporúča sa vytvoriť prvúlíniu operátorov, ktorý budú obsluhovať monitorovací systém a korigovaťnápravné opatrenia.

4.39 Odporúča sa nastaviť monitorovací systém tak aby v prípade vážnychudalostí produkoval aj upozornenie ce "out-of-band" kanál (napríklad e-maila SMS).

4.40 Logy musia obsahovať korektné informácie o dátume, čase a použitejčasovej zóne. Pre korektné nastavenie času sa odporúča nastaviťsynchornizáciu s dôveryhodným NTP serverom. Odporúča sa využiťautentifikovanú NTP synchronizáciu.

4.41 Granularita logovania musí zodpovedať požiadavkám danej služby alebozariadenia a jeho kritickosti.

40

4.42 Logovanie musí byť nastavené tak, aby prípadné zaplnenie logovaciehomiesta neovplyvnilo stabilitu OS. Možné opatrenia: samostatná diskovápartícia, rotovanie logov a maximálna veľkosť logov.

4.43 Logy z kritických služieb a serverov musia byť synchronizované nasamostatné logovacie zariadenie.

4.44 Logovacie súbory by mali byť zabezpečené aspoň takýmto spôsobom:a. Mali by byť čitateľné len administrátorom.b. Nemali by byť prepisovateľné a vymazateľné (mal by byť možný len zápis

na koniec súboru)14.c. Odporúča sa komprimovať a šifrovať archivované logovacie súbory. Pri

ručnej archivácii sa odporúča aj podpisovať logovacie súbory. 4.45 Bezpečnostný monitoring by mal zbierať aspoň tieto informácie z

pracovných staníc a serverov (v zátvorkach uvádzame príklady Event ID pre OS Windows 6.0+)

a. Vytvorenie nového používateľa (Windows Security event ID 4720, 4724, 4738)

b. Pridanie používateľa do privilegovanej skupiny (Windows Security Event ID 4728, 4732)

c. informácie o zmazaní logov (Windows Security Event ID 1102)

d. Nainštalovanie novej služby (Windows System Event ID 7045, 7030)

e. Vypnutie lokálneho firewallu (Windows Event ID 2003)

f. Nepovolenie spustenia vykonateľného súboru, kvôli whitelisting pravidlu (Windows Applocker: Event ID 8004)

g. Detekcia a zabránenie vykonania potenciálne škodlivého kódu, alebo vypnutie programu anti-exploit komponentom (Microsoft EMET: Windows Application Log Provider EMET ID 2)

h. Detekcia škodlivého kódu antimalware riešením

i. informácie o všetkých spustených procesoch aj s plným príkazovým riadkom

j. odporúča sa implementovať logovanie prístupu k citlivým aktívam (napríklad súbory, riadky databázovej tabuľky apod.)

4.46 Odporúča sa aby bezpečnostný monitoring zbieral aspoň tieto informácie zosieťového monitoringu:

a. skenovanie sietí a portov, pokus o prístup do nevyužitého IP rozsahuorganizácie, pokus o prístup na honeypot

14 Upozorňujeme, že pri používaní logrotate je potrebná dodatočná konfigurácia.

41

b. história dotazov na DNS mená a vyhodnocovanie podozrivých DNS mien(napríklad na základe entropie, reputačných databáz, alebo štatistikyvyužitia)

4.47 Odporúča sa do citlivých interných sietí (napríklad VLAN interných serverov)umiestniť honeypot (t.j. nepoužívaný počítač, ktorého účelom je detegovaťprístomnosť útočníka v sieti) a pravidelne alebo automaticky vyhodnocovať,či nebol detegovaný pokus o prístup.

4.48 Informácie získané bezpečnostným monitoringom by mali byťvyhodnocované operátorom a v prípade detegovanej zmeny, ktorá nie jezaznamenaná Zmenovým riadením (CM – Change management) by mal byťokamžite spsutený proces riešenia bezpečnostného incidentu.

42

5 Minimálne požiadavky na zabezpečenie externej infraštruktúry

Nutnou súčasťou požiadaviek na zabezpečenie externej infraštruktúry sú ajpožiadavky v kapitole „Minimálne požiadavky na zabezpečenie infraštruktúryorganizácie“.


5.1 Pre servery s verejne prístupnými službami je nutné aplikovať bezpečnostnéaktualizácie prioritne a to hneď ako je to možné (minimálne raz za mesiac).

5.2 Verejne prístupné zdroje (web, bannery, DNS apod.) nesmú obsahovaťinformácie o použitých technológiách, vnútorných IP adresách a použitýchTCP/UDP portoch.

5.3 Verejne dostupné služby by mali byť dostupné takým spôsobom, ktorýumožňuje používateľovi overiť identitu služby a autentickosť údajov (napr.web, VPN). Odporúča sa verejne prístupné služby sprístupňovať len takýmtospôsobom.

Konfigurácia sieťovej infraštruktúry

5.4 Služby dostupné verejnosti (napríklad webové servery) by mali používať inépripojenie do Internetu ako to, ktoré používa organizácia na prístup kInternetu alebo iným externým sieťam.

5.5 ACL na hraničných sieťových prvkoch aplikované na všetku komunikáciuprichádzajúcu z externých sietí musí obsahovať aspoň:

a. Zahadzovať komunikáciu so zdrojovými IP adresami z rozsahu RFC 1918(privátne IP adresy)

b. Filtrovať komunikáciu z rozsahu RFC 3330 (IP adresy rezervované prešpeciálne použitie)

c. Zahadzovať komunikáciu so zdrojovými IP adresami z rozsahu používanéhov sieti organizácie

d. Zahadzovať ICMP protokol s výnimkou ICMP echo request. Echo requestmusí byť povolený len ak je to potrebné a len do DMZ sietí. Taktiež preňmusí byť implementovaný rate-limiting

e. odporúča sa implementovať anti-bogon filtering (*oficiálna databáza jeudržiavaná na https://www.team-cymru.org/bogon-reference.html)

5.6 Hraničné sieťové prvky by nemali nijak odpovedať na pokusy o pripojeniena neexistujúci TCP/UDP port. Nesmú odosielať správy "ICMP unreachable".

5.7 Z externých sietí nesmie byť povolený ICMP protokol. Výnimkou môže byťpovolenie "ICMP echo request" na konkrétne servery v DMZ, pričom musíbyť limitovaný počet požiadaviek za daný čas.

5.8 Mal by byť implementovaný Unicast Reverse Path Forwarding.

43

5.9 Všetky servery so službami priamo prístupnými z externých sietí musia byťv samostatných sieťových segmentoch (DMZ). V rovnakom segmente bymali byť iba servery s rovnakými bezpečnostnými požiadavkami apodobným účelom.

Firewall

5.10 Všetky prepoje medzi segmentami a externými sieťami musia byť chránenéfirewallom a všetky spojenia (IN aj OUT) musia byť povoľované iba naprincípe least privilege.

5.11 Smerom do vnútra musia byť povolené len špecifikované služby umiestnenév DMZ (politika "default deny")

5.12 Smerom do externých sieti by mala byť povolená len špecifikovanákomunikácia (pre interné siete by to malo byť len HTTP a HTTPS).

5.13 Všetky spojenia do externých sietí musia byť smerované cez dedikovanýsieťový firewall. Všetky spojenia do externých sietí okrem VoIP by mali byťsmerované aj cez IPS (ak je IPS použité) - výnimkou je VoIP, pre ktoré satoto odporúča ak to výkon a funkcionalita IPS dovoľuje.

5.14 Musí byť obmedzená táto komunikácia:a. DNS požiadavky smerom do externých sietí (dport UDP/TCP 53) môžu

iniciovať len autorizované rekurzívne DNS servery.b. SMTP správy smerom do externých sietí (dport TCP 25) môžu posielať len

autorizované (t.j. na to určené) SMTP servery.c. SMTP smerom do externých sietí môžu iniciovať len autorizované SMTP

servery.d. Odporúča sa nepovoľovať smerom do externých sietí komunikáciu na

TCP/445 (SMB), TCP/6697 (IRC).

Ochrana proti DoS útokom

5.15 Pre organizácie so systémami alebo službami s vysokými nárokmi nadostupnosť je nutné zabezpečiť anti-DoS službu na strane poskytovateľapripojenia do externej siete, ktorá zablokuje objemové DoS a DDoS útokyešte pred vstupom do siete organizácie. Pre ostatné organizácie je takátoslužba odporúčaná.

5.16 On-site by mala byť implementovaná anti-DoS ochrana chrániacia verejnedostupné služby aj proti ostatným typom DoS útokov ako sú zahltenieaplikácie, pomalé útoky ("low & slow") a SSL/TLS útoky. Takéto riešenie musíbyť zabezpečené pre systémy a služby s vysokými nárokmi na dostupnosť(napr. právne záväzné elektronické služby občanom).

5.17 Anti-DoS riešenie musí notifikovať dedikovaný personál o výskyteprebiehajúceho útoku, alebo inej anomálie v sieťovej prevádzke. Anti-DoSriešenie musí logovať informácie o zablokovaných pokusoch o útok.

44

5.18 Odporúča sa implementovať vhodný rate-limiting na lokálnych acentrálnych FW.

Zabezpečenie DNS infraštruktúry

5.19 Autoritatívny DNS server by nemal byť zároveň rekurzívnym DNS serverom.

5.20 Autoritatívny DNS server musí povoľovať príjem požiadaviek na DNS Zonetransfer len zo špecifikovaných IP adries a na Zóny, pre ktoré jeautoritatívny. Musí povoľovať vykonať DNS transakciu "Zone transfer" len našpecifikované IP adresy.

5.21 Pre požiadavky aj odpovede na "Zone transfer" sa odporúča zabezpečiťautentifikáciu a integritu. Pre požiadavky aj odpovede na "Update" requestby mala byť zabezpečená autentifikácia a integrita. Je možné podpisovaťdopyty a odpovede zdieľaným kľúčom (využiť napr HMAC a RR TSIG). Prekaždého klienta autoritatívneho servera by mal byť nakonfigurovaný inýkľúč.

5.22 Odporúča sa aby boli nakonfigurované ACL pre všetky typy DNS transakcií,ktoré povoľujú len požiadavky od špecifikovaných klientov.

5.23 DNS dopyty na name servery sa odporúča limitovať počtom z jednej IPadresy za špecifikovaný čas

5.24 Odpovede na DNS requesty by mali odchádzať z náhodného TCP/UDP portu

5.25 Odporúča sa aby autoritatívny a sekundárne DNS servery boli logicky ageograficky oddelené.

5.26 DNS záznamy o vnútorných zariadeniach nesmú byť prístupné z externchsietí (je možné využiť napríklad SPLIT DNS architektúru, alebo dve rôznezóny).

5.27 Rekurzívny (cache) DNS server nesmie prijímať požiadavky z externýchsietí. Nemal by byť z externých sietí vôbec prístupný.

5.28 Veľmi citlivé informácie nesmú byť uložené v rámci DNS (napr. špecifickéHINFO alebo TXT záznamy)

5.29 DNS server by nemal zverejňovať informácie o použitom softvéri -minimálne nesmie odpovedať na špecifické dotazy typu "Version Query".

5.30 Musí byť rezervované doménové meno wpad.{doména}, kde {doména} jedoménové meno používané v organizácii a publikované v odpovediachDHCP serverov. Rovnako pre všetky používané subdomény – t.j. wpad.{subdoména}.{doména}.

Zabezpečenie mailovej infraštruktúry

5.31 SMTP banner by nemal obsahovať informácie o použitom softvéri ani inécitlivé informácie. Nesmie byť možné zistiť verziu použitého softvéruprostredníctvom help príkazov.

45

5.32 Mailové správy odchádzajúce z organizácie by nemali obsahovať informácieo infraštruktúre organizácie (napríklad privátne IP adresy v hlavičkeReceived-From).

5.33 Odpoveď na príkaz VRFY by nemala obsahovať informáciu o existenciíadresy alebo používateľského mena. Odporúča sa odpovedať kódom 252 sgenerickou hláškou.

5.34 Nemala by byť povolená metóda EXPN.

5.35 SMTP server by nemal preposlať e-mail, ktorý neobsahuje zdrojovúhlavičkovú e-mailovú adresu.

5.36 SMTP server musí prijímať správy na doručenie z externých sietí len prespravované domény.

5.37 SMTP server musí prijímať správy na preposlanie len od autentifikovanýchpoužívateľov alebo z určených SMTP serverov.

5.38 Server by mal detegovať a blokovať pokusy o rozoslanie veľkého množstvae-mailov.

5.39 SMTP server musí kontrolovať správy pomocou anti-spam filtra.

5.40 SMTP server musí kontrolovať správy na prítomnosť škodlivého kódu

5.41 SMTP server musí logovať všetky detegované anomálie.

5.42 SMTP server musí logovať informácie o spracovávaných e-mailoch a tietoinformácie by mali byť uchovávané aspoň 6 mesiacov. Musia byťuchovávané aspoň 3 mesiace.

5.43 Prístup k e-mailovým účtom musí byť možný len prostredníctvomšifrovaného kanála.

5.44 Odporúča sa na prístup k e-mailovej schránke nepoužívať proprietárneprotokoly.

5.45 Z externých sietí by sa malo pristupovať na e-mail len prostredníctvomHTTPS alebo použitím štandardných protokolov POP3S alebo IMAPS.Odporúča sa autentifikovať klienta aj na základe certifikátu alebo vyžadovaťpoužitie VPN. V prípade použitia iných protokolov by sa malo pristupovaťprostredníctvom VPN pripojenia.

Zabezpečenie VPN infraštruktúry

5.46 Všetky VPN spojenia musia byť šifrované. Odporúča sa implementovať avyžadovať šifrovanie spojenia s využitím Forward Secrecy.

5.47 Ak je potrebný vzdialený prístup k správcovským rozhraniam alebo dosprávcovskej siete, mala by byť využitá autentifikácia s využitím klientskychcertifikátov. Aj pre bežných používateľov sa odporúča využiť autentifikáciu

46

na základe klientskych certifikátov. Použité certifikáty musia používať aspoňRSA-2048, odporúča sa RSA-4096.

5.48 Ak sa používa PSK, musí byť použitý silný pre-shared key s entropiou aspoň128 bitov. Odporúča sa náhodne generovaný reťazec.

5.49 VPN spojenia musia byť ukončované v samostatnom segmente.

5.50 Musia byť špecifikované FW pravidlá oddeľujúce sieť používateľov VPN azvyšok internej siete a to metódou whitelistingu in aj out na princípe „leastprivilege“.

5.51 Ak sa používa SSL/TLS, mal by byť sa používaný len protokol TLS1.2.Nesmie byť použitý protokol SSL.

5.52 Nesmie byť možné vynegociovať použitie slabých šifier (ako sú napríkladsady šifier využívajúce RC4, DES a 3DES).

5.53 Na šifrovanie komunikácie by mal byť použitý protokol AES a to minimálneAES-128 (odporúča sa použiť AES-256). Pre prístup k citlivým IS alebo presprávcovskú VPN by mal byť na šifrovanie komunikácie použitý aspoň AES-256.

5.54 Mal by byť použitý hashovací algoritmus minimálne SHA-256

5.55 Ako algoritmus na výmenu kľúča by mal byť použitý DH (Diffie-Hellman) sdĺžkou aspoň 2048b.

5.56 Ďalšie požiadavky na zabezpečenie IPSec VPN:a. VPN server nesmie umožniť využiť Aggresive mód nadviazania spojeniab. Mal by sa používať len IKEv2c. Platnosť šifrovacieho kľúča by mala byť nastavená na maximálne jeden

deňd. Odporúča sa skontrolovať politiky, ktoré sú k dispozícii pre IKE fázu 1 a

odstániť politiky, ktoré umožňujú nastavenie málo bezpečných parametrov

5.57 Ďalšie požiadavky na zabezpečenie SSL VPN alebo Openvpn:a. Klient musí overovať certifikát VPN serverab. VPN server musí overovať platnosť klientskych certifikátov a mal by ju

overovať aj voči CRL.c. V klientskej konfigurácii OpenVPN sa odporúča používať perzistentné

TUN/TAP rozhrania.

Zabezpečenie VOIP infraštruktúry a služieb videoconference

5.58 VOIP komunikácia z a do externých sietí by mala byť šifrovaná. Odporúča sašifrovať aj internú VOIP komunikáciu (napr. SIP over TLS a SRTP a SRTCP).

5.59 VOIP zariadenia by mali byť z externých sietí do siete organizácie pripájanélen cez VPN .

5.60 Všetky VOIP a telepresence zariadenia musia byť pred pripojením do sietehardenované (napr. podľa odporúčaní výrobcu).

47

5.61 Riadiaca komunikácia musí byť autentifikovaná (t.j. call signalling a webservices signalling) a mala by byť aj šifrovaná.

5.62 Správcovské heslá telefónov musia byť komplexné a rôzne pre každézariadenie.

5.63 Centrálny firewall by mal vedieť filtrovať VoIP komunikáciu. Odporúča sanasadiť riešenie na filtrovanie VoIP spamu (SPIT - Spam over IP Telephony)

5.64 Pre konfiguračné súbory sťahované do telefónov by mala byť zabezpečenáintegrita a koncové zariadenia by mali overovať integritu týchto súborov.

5.65 Videoconferencing meeting by mal byť povinne šifrovaný (t.j. ak tozariadenie účastníka nepodporuje, nemôže sa zúčastniť).

5.66 Mal by byť použitý VOIP-aware firewall, ktorý umožňuje inšpekciu SIPprotokolu.

5.67 SIP server musí byť na portoch TCP/UDP 5060/5061 dostupný len zpotrebných zariadení.

5.68 Mal by byť použitý SBC (session border controller) a mal by ukončovaťvšetky prichádzajúce telefonáty a preposielať dáta cieľu (B2BUA)

5.69 Pohyblivá kamera na zariadení ako aj zapnutie mikrofónu nesmie byťovládateľné na diaľku prostredníctvom siete.

5.70 Zariadenia pre videoconference by mali byť do siete pripájané len vtedy keďje to potrebné pre potreby videokonferencie alebo servisných zásahov.

5.71 Používané kamery, alebo zariadenia s kamerami, musia viditeľne indikovať,že sú zapnuté a snímajú.

Zabezpečenie iných služieb

5.72 Pre prístup k neštandardným službám, ktoré nie je možné hardenovať azabezpečiť štandardným spôsobom (napr TLS) sa odporúča využiť prístupcez VPN.


5.73 Otvorené porty do Internetu by mali byť revidované aspoň raz za pol rok.Súčasťou revízie je sken otvorených portov do externých sietí aohodnotenie, či sú naďalej potrebné.

5.74 Penetračné testy externej infraštruktúry by mali byť vykonané aspoň raz zarok.

5.75 Aspoň raz za rok by mali byť kontrolované verejne prístupné zdroje s cieľomskontrolovať, či nie sú zverejnené dôverné alebo citlivé informácie.

48

6 Minimálne požiadavky na zabezpečenie internej infraštruktúry

Implementácia architektúry riešenia

6.1 Sieť musí byť segmentovaná na základe účelu zariadení v jednotlivýchsegmentoch a rovnakých bezpečnostných požiadaviek. Minimálne takto:

a. Samostatné subsiete/VLAN pre oddeleniab. Samostatné subsiete/VLAN pre manažment infraštruktúry a zálohovaniec. Samostatné subsiete/VLAN pre manažment serverov a ich zálohovanie d. Samostatné subsiete/VLAN pre servery s rovnakými bezpečnostnými

požiadavkamie. Samostatné subsiete/VLAN pre doménové radiče (okrem RODC)f. Samostatné subsiete/VLAN pre manažment bezpečnostných prvkovg. Samostatné subsiete/VLAN pre manažment virtualizačných serverovh. Samostatné subsiete pre DMZi. Samostatné subsiete pre ICS/SCADA systémyj. Samostatné subsiete pre VOIPk. Samostatné subsiete pre wireless AP

6.2 Prepoje medzi jednotlivými segmentami sú chránené prostredníctvom ACL,ktoré sú nakonfigurované ne princípe „Least Privilege“.

6.3 Pre pripojenia pracovných staníc a všetky dostupné sieťové porty mimozabezpečených priestorov by malo byť implementované Port Security,Dynamic ARP inspection a DHCP snooping. Ak sa používa IPv6, mali by byťimplementované: NDP inspection a snooping, DHCPv6 snooping, RA Guard(Router Advertisement Guard).

6.4 Servery prístupné z externých sietí musia byť v iných segmentoch akoservery vnútornej infraštruktúry. Medzi týmito segmentami musí byťimplementovaný firewall a ACL na princípe „Least Privilege“

6.5 V sieti by mal byť implementovaný OOBM (Out of band manažment).

6.6 Servery prístupné z externých sietí by mali byť na iných virtualizačnýchserveroch ako servery internej infraštruktúry

6.7 V sieti by mal byť implementovaný SSO (Single Sign-On) pre všetkysystémy okrem kritických. Pre kritické systémy by mala vyžadovaná ďalšiaúroveň autentifikácie prostredníctvom iného mena a hesla.

6.8 Pre prihlásenie do siete (do pracovnej stanice a na služby v doméne)odporúčame využívať dvojfaktorovú autentifikáciu.

6.9 V rámci implementácie architektúry by organizácia mala dodržiavať:a. multi-vendor princíp pre bezpečnostné prvkyb. musí byť dodržané oddelenie DMZ, Perimetra (prvky, ktoré majú priamy

prístup do Ineternetu) a interných častí siete.

49

c. VPN pripojenia musia byť ukončované v separátnych segmentoch aprístupy k ďalším častiam siete je možné iba prostredníctvom ACL naprincípe „Least Privilege“.

d. Vnútorné servery ani pracovné stanice by nemali mať priamy prístup doInternetu ani externých sietí. Všetky pripojenia by mali prechádzaťprostredníctvom perimetrových zariadení (Web a email proxy serveryProxy, aplikačné port forwardery pre potrebné iné služby)

6.10 V sieti by mali byť implementované lokálne NTP servery.

6.11 V sieti by mali byť implementované lokálne DNS servery.

6.12 V sieti by mali byť implementované lokálne Syslog servery.

6.13 V sieti by mali byť implementované lokálne update servery pre OS Windowsaj Linux.

6.14 V sieti musia byť implementované:a. Firewally na všetkých pripojeniach medzi sieťou organizácie a externými

sieťamib. Firewally na všetkých pripojeniach do kritických segmentov siete

6.15 V sieti by mali byť implementované:a. IPS na všetkých pripojeniach medzi sieťou organizácie a externými sieťamib. IPS/IDS na všetkých pripojeniach do kritických segmentov sietec. Centralizované Anti malware riešenie na všetkých serveroch a pracovných

staniciach.d. Odporúčame ďalej implementovať sieťovú behaviorálnu analýzu na

všetkých významných uzloch siete najmä však na známych perimetroch,prepojoch medzi DMZ, perimetrovými sieťami a vnútornou sieťou.

6.16 V infraštruktúre musia byť pravidelne aktualizované OS a všetky aplikácie aaspoň:

a. Raz za mesiac pre OS na platforme Windowsb. Raz za mesiac pre OS na platforme Linux a Unixc. Raz denne pre antivírové riešenia na klientskych pracovných staniciachd. Raz za týždeň pre antivírové riešenia na serveroche. Raz za 6 mesiacov pre OS bezpečnostných prvkov, sieťových prvkov a

iných zariadení pripojených do infraštruktúryf. Raz za mesiac všetky aplikácie na klientskych zariadeniachg. Raz za rok všetky aplikácie a služby na serveroch

6.17 V infraštruktúre sa musia používať iba podporované verzie OS a aplikácií.Všetky výnimky musia byť schválené a implementované bezpečnostnéopatrenia tak, aby nebolo možné tieto verzie zneužiť na kompromitáciuinfraštruktúry.

6.18 Všetky účty, ktoré majú administrátorské oprávnenia musia spĺňať politikuhesiel pre účty s administrátorským prístupom.

6.19 Všetky účty, ktoré neboli použité do troch mesiacov (a zmenené heslo) odich vytvorenia musia byť zablokované.

50

Hardening serverov, sieťových a bezpečnostných prvkov

6.20 Všetky nepoužívané a nepotrebné služby musia byť vypnuté.

6.21 Všetky firmware musia byť pravidelne aktualizované a hardenované podľaodporúčaní výrobcu.

6.22 Administračné rozhrania typu ILO resp. iDRAC musia byť aktualizované aprístupné iba z administrátorskej siete a musia byť v samostatnýchsegmentoch.

6.23 Prístup k administrátorským rozhraniam musí byť iba zo sieteadministrátorov, ktorá je rozdielna od siete používateľov.

6.24 Servery nesmú umožniť prihlásenie anonymného používateľa (Guestprístup)

6.25 Servery musia mať nakonfigurovaný a udržiavaný host-based firewall(napríklad iptables v Linux alebo Windows firewall vo Windows) na princípe„least privilege“ pre spojenia dnu aj von.

6.26 Servery by mali mať partície na diskoch v RAID 1,5, 6, 10 alebo 50.

6.27 Všetky zariadenia by mali používať lokálne DNS servery.

6.28 Všetky zariadenia musia byť synchronizované s NTP serverom.

6.29 Všetky zariadenia by na synchronizáciu mali používať lokálny NTP server.

6.30 Všetky zariadenia by mali posielať logy na vzdialený logovací server:a. Pre zariadenia ktoré podporujú syslog na vzdialený syslog serverb. Pre zariadenia Windows na vzdialený Windows Log server prostredníctvom

funkcionality Windows Event Forwarding

6.31 Všetky servery by mali mať nainštalované antimalware riešenies centrálnym manažmenotom a zberom logov .

6.32 Syslog servery:a. Musia mať dostupnú dostatočnú diskovú kapacitu na uloženie dát aspoň na

6 mesiacovb. Musia byť synchronizované s NTP serveromc. Logy musia byť pravidelne zálohované (minimálne raz za mesiac)d. Logy musia byť pre všetkých používateľov syslog serveru nastavené ibana

čítanie

6.33 Administračné rozhrania by mali byť prístupné iba prostredníctvomšifrovaných sieťových kanálov.

a. Šifrované kanály sa musia prezentovať dôveryhodným verejným kľúčomalebo certifikátom

b. V prípade, že nie je možné používať šifrované kanály by malo byťimplementované ACL na princípe "Least privilege" a vyčlenené tietorozhrania do samostatných segmentov

51

6.34 Logovanie musí zaznamenávať15:a. (Úspešné aj neúspešné) Prihlásenie a odhlásenieb. (Úspešné aj neúspešné) Spustenie procesu alebo službyc. (Úspešné aj neúspešné) Vytvorenie, modifikáciu alebo zmazanie

používateľa alebo skupiny d. (Úspešné aj neúspešné) Pokusy pristúpiť k citlivým údajom (údaje

klasifikované hornými dvomi klasifikačnými stupňami v rámci organizácie)e. (Úspešné aj neúspešné) Spustenie a ukončenie procesuf. (Úspešné aj neúspešné) Prihlásenie sa zo systému na iný systém alebo

službu

Sieťové prvky

6.35 Všetky nepotrebné služby musia byť vypnuté alebo odinštalované.

6.36 OS/firmvéry by mali byť pravidelne aktualizované.

6.37 Používateľské heslá by nemali byť uložené v reverzibilnom formáte.

6.38 Mala by byť implementovaná centrálna SSO (Single sign-on) autentifikáciaprostredníctvom protokolov Radius, Tacacs+ alebo Diameter.

6.39 Pre pripojenie pracovných staníc by mala organizácia využívať NAC(napríklad NAP alebo 802.1x).

6.40 Vo všetkých manažmentových segmentoch by mala byť implementovanáPVLAN.

6.41 Vo všetkých používateľských segmentoch by mala byť implementovanáPVLAN.

Monitoring

6.42 V sieti by mal byť implementovaný dohľad nad funkčnosťou zariadení aslužieb.

6.43 V rámci siete by mal byť implementovaný bezpečnostný monitoring ktorýbude monitorovať aspoň:

a. Bezpečnostné prvky b. Sieťové prvky v organizácií c. Doménu Windows

6.44 V sieti by nemalo byť používané SNMPv2 a malo by byť používané SNMPv3.a. V prípade použitia SNMPv2 musia community reťazce spĺňať politiku hesiel

pre účty s administrátorským prístupom.b. Community reťazce musia byť unikátne pre sieťový segment a účel použitia

6.45 Pre všetky dátové toky a služby v rámci monitoringu musia byťimplementované ACL na princípe "Least privilege".

15 Ak to uvedená technológia umožňuje

52

Tlačiarne

6.46 Tlačiarne by mali byť umiestnené v samostatnom segmente.

6.47 Správcovské rozhrania by mali byť prístupné iba z administrátorskej siete amusí byť na správcovskom rozhraní implementovaná autentifikácia a účtymusia spĺňať politiku hesiel pre používateľov.

6.48 Tlačiarne by mali byť prístupné klientom iba prostredníctvom tlačovýchserverov.

Windows infraštruktúra

6.49 Na všetkých serveroch musí byť zakázaný prístup na čítanieprostredníctvom neautentifikovaného používateľa (napíklad ošetrená tzv.CIFS null zraniteľnosť)

6.50 Na doménových kontroleroch nesmú byť ukladané heslá prostredníctvomGroup Policy Preferences v aplikovaných doménových politikách.

6.51 Všetky interné servery by mali byť v doméne.

6.52 Autentifikácia na servery by mala byť iba prostredníctvom Kerberosu

6.53 Autentifikácia prostredníctvom NTLM by mala byť zakázaná

6.54 SMB podpisovanie musí byť vyžadované

6.55 Na všetkých serveroch musia byť implementované dôveryhodné certifikátyna prístup ku všetkým službám (RDP, HTTPS,LDAPS,..)

6.56 Doménoví administrátori a enterprise administrátori musia mať zakázanýprístup a autentifikáciu na všetky pracovné stanice.

6.57 Servery prístupné z externých sietí nie sú v doméne alebo sa autentifikujúvoči RODC, ktorý je v samostatnom segmente (DMZ) a je prístupný ibaz ostatných DMZ.

6.58 Administrátorské a používateľské účty administrátorov musia byť oddelenéa mať rozdielne heslá

6.59 Doménoví administrátori by mali využívať dvojfaktorovú autentifikáciu

6.60 Počítače musia byť do domény pridávané pod samostatným účtom, ktorýma oprávnenie iba pridávať počítače do domény. Žiadni iní používatelianesmú mať právo pridať počítač do domény.

6.61 V sieti by malo byť vypnuté prostredníctvom GPO automatickévyhľadávanie proxy servera WPAD. Konfigurácia proxy servera by mala byťnakonfigurovaná prostredníctvom GPO.

6.62 Implementácia nového softvéru na servery by mala prebiehaťprostredníctvom balíčkovacích nástrojov (Deployment services resp. Systemcenter)

53

6.63 Remote powershell execution by malo byť povolené len z administrátorskejsiete.

6.64 V prípade používania RDP musí byť možné prihlasovanie iba v restrictedrežime (RDP restricted admin).

6.65 GPO preferences musia byť vypnuté


6.66 Mal by byť interný penetračný test aspoň raz za 2 roky. Aplikovanieodporúčaní výsledkov penetračného testu.

6.67 Odporúča sa vykonať interný technický audit splnenia požiadaviekplynúcich z tohto dokumentu.

54

7 Minimálne požiadavky na zabezpečenie pracovných staníc pristupujúcich k implementovanému riešeniu


7.1 Na pracovných staniciach musí byť nainštalované anti-malware riešeniea. Riešenie musí byť pravidelne aktualizované (aspoň jeden krát za deň)b. Riešenie musí byť pravidelne využité na skenovanie pracovnej stanice

(aspoň raz za týždeň)c. Riešenie musí podporovať rezidentnú ochranu16 a táto musí byť aktívnad. Riešenie by malo byť centrálne spravované a malo by mať centrálne

vyhodnocované výsledky skenov a detekcie hroziebe. Logy z anti-malware riešenia musia byť archivované minimálne 6

mesiacov

7.2 OS, všetky jeho súčasti a nainštalované aplikácie musia byť vo verziáchpodporovaných výrobcom a pravidelne aktualizované (najviacs oneskorením jeden mesiac).

7.3 Aktualizácie a mitigácie pre kritické zraniteľnosti (s vysokým dopadom) bymali byť aplikované do 72 hodín od ich zverejnenia na pracovnýchstaniciach, z ktorých je možný prístup ku kritickým systémom a dátam. Malby byť vedený zoznam takýchto staníc.

7.4 Na pracovných staniciach by malo byť zapnuté automatické sťahovaniea inštalácia aktualizácií.

7.5 Na pracovných staniciach musí byť implementovaný lokálny firewall:a. Všetky prichádzajúce aj odchádzajúce spojenia musia byť zakázané okrem

spojení, ktoré sú potrebné na štandardnú činnosť aplikácie.b. Pravidlá vo firewalli by mali byť centrálne spravované a implementované

na princípe „least privilege“c. Všetky zakázané spojenia musia byť archivované minimálne na dobu 6

mesiacov.d. Informácie o zakázaných spojenia by mali byť archivované na centrálnom

úložisku

Logovanie

7.6 Bezpečnostné Logy z pracovných staníc by mali byť odosielané na centrálnyserver a ukladané minimálne po dobu 6 mesiacov.

7.7 Na pracovných staniciach by malo byť logovanie nastavené minimálnev rozsahu:

a. (Úspešné aj neúspešné) Prihlásenie a odhlásenieb. (Úspešné aj neúspešné) Spustenie procesu alebo službyc. (Úspešné aj neúspešné) Vytvorenie, modifikáciu alebo zmazanie

používateľa alebo skupiny d. (Úspešné aj neúspešné) Pokusy o prihlásenie prostredníctvom RDP, SSH

16 t.j. detekciu škodlivého kódu pri otváraní súborov a spúšťaní programov

55

Hardening

7.8 Pracovná stanica musí byť hardenovaná minimálne v rozsahua. Všetky Windows pracovné stanice musia byť pripojené do doményb. Všetky služby, ktoré nie sú potrebné sú odinštalované alebo aspoň

zakázané alebo vypnuté.c. Všetky programy a súčasti OS, ktoré nie sú potrebné sú odinštalovanéd. Všetky programy boli povolené a otestované bezpečnostným útvarom

organizáciee. Používatelia nemajú administrátorské oprávneniaf. Lokálne administrátorské účty sú neaktívne. Ak musia byť z nejakého

dôvodu aktívne heslá k týmto účtom spĺňajú požiadavky na heslá pre účtys administrátorským prístupom17

g. Pracovné stanice musia na prihlásenie vyžadovať heslo h. Po dobe nečiinosti (najviac 30 minút) musí byť spustený šetrič obrazovky

a uzamknutá pracovná plocha

7.9 V prípade pracovných staníc s OS Windows musí byť pracovná stanicahardenovaná minimálne v rozsahu:

a. Používatelia nemajú právo inštalácie softvéru b. Používatelia ani administrátori nemajú oprávnenie Debug procesuc. Na pracovnej stanici je počet uložených hashov prihlasovacích účtov

nastavený na maximálne dva18.d. Na pracovnej stanici by mal byť implementovaný whitelisting

spúšťateľných súborov (napr. Applocker alebo Software Restriction Policies[SRP]) tak, aby bolo možné spúšťať iba dôveryhodné povolené aplikácie.

e. Na pracovnej stanici musí byť zapnutý UAC (User Access Control) a mal bybyť nastavený na najvyššiu hodnotu.

f. Na pracovnej stanici by mal byť nainštalovaný a nakonfigurovaný nástrojEMET (od Microsoft) so zapnutými všetkými ochranami, ktoré je možnézapnúť. Ak pre niektorý používaný program nie je možné zapnúť všetkyochrany, odporúča sa prehodnotiť potrebu jeho používania.

g. Doménový administrátori a ostatní privilegovaní používatelia nemajúoprávnenie na prihlásenie sa na pracovné stanice.

h. Na pracovnej stanici je vypnuté automatické spúšťanie programov povložení vymeniteľného média (Autoplay)

i. IPv6 by malo byť vypnuté, pokiaľ nie je používanéj. NetBios nad IPv4 by mal byť vypnutýk. Makrá v MS Office by mali byť vypnuté a nemalo by byť možné ich povoliť.

Ak sú makrá používané, malo by byť ich vykonávanie povolené len prekonkrétneho používateľa a len z dôveryhodných špecifikovaných lokalít(nie z Internetu), prípadne implementovať podpisovanie makier pomocouPKI.

l. Lokálne účty nesmú byť zlinkované s MICROSOFT IDm. Dáta na pracovnej stanici nesmú byť synchronizované prostredníctvom

verejných služieb (OneDrive, DROPBox, google drive, MEga a podobne)

17 Viď prílohu Politika hesiel18 ǩľúč registra HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows_NT\ CurrentVersion\Winlogon\CachedLogonsCount

56

7.10 Prenosné pracovné stanice musia byť hardenované minimálne v rozsahu:a. Disk musí byť šifrovaný (Full disk encryption)b. Záložný kľúč k šifrovanému disku by mala mať organizácia k dispozícií

(Implementovaný key escrow mechanizmus)c. BIOS/UEFI by mal byť chránený heslom pri prenosných zariadeniach.

7.11 Webové prehliadače by mali mať implementovanú funkcionalitu aleborozšírenia:

a. Rozšírenie na blokovanie spúšťania skriptov (napr. NoScript)b. Rozšírenie na blokovanie reklamy (napr. Adblock, UBlock Origin)c. Rozšírenie na blokovanie trackerov (napr. Privacy Badger)

Mechanizmus kontrolyRovnaký ako pre internú infraštruktúru.

57

8 Administratívne opatrenia


8.1 V organizácii musí byť vytvorená, vedením schválená, implementovaná,dokumentovaná a dodržiavaná Bezpečnostná politika, ktorá spĺňa aspoňnasledovné požiadavky:

a. Je adekvátna veľkosti, typu, zameraniu a činnostiam organizácie.b. Definuje bezpečnostné ciele, spôsob ich schvaľovania, dosahovania a

merania účinnosti ich dosahovania.c. Vyjadruje záväzok vedenia organizácie dosahovať stanovené bezpečnostné

ciele a spĺňať požiadavky všetkých zainteresovaných strán.d. Definuje rozsah a pravidelnosť školení zamestnancov a iných aktivít

zameraných na zvyšovanie povedomia o informačnej bezpečnosti,súvisiacich hrozbách a možnostiach ochrany pred týmito hrozbami.

e. Je publikovaná na mieste prístupnom všetkým zamestnancom a jepropagovaná v rámci organizácie a v rámci školení – a to aspoň každých 12mesiacov – je adekvátne komunikovaná všetkým zamestnancom.

f. Definuje roly a zodpovednosti za informačnú bezpečnosť. Musia byťdefinované zodpovednosti aspoň pre tieto roly: vrcholný predstaviteľorganizácie, manažér pre bezpečnosť, vedúci pracovník, administrátor,audítor, používateľ.

g. Definuje spôsob riadenia informačných aktív a spôsob vedeniainventáru/zoznamu týchto aktív.

h. Definuje spôsob vykonávania manažmentu rizík informačnej bezpečnosti.i. Definuje spôsob nahlasovania a reakcie na bezpečnostné incidenty.j. Definuje spôsob vykonávania a frekvenciu preskúmavania bezpečnostnej

politiky.k. Definuje spôsob vykonávania a frekvenciu vykonávania interných auditov

informačnej bezpečnosti.

8.2 V organizácii musí byť vytvorená, vedením schválená, implementovaná,dokumentovaná a dodržiavaná Smernica pre manažment rizík informačnejbezpečnosti, ktorá spĺňa aspoň nasledovné požiadavky:

a. Definuje spôsob identifikácie a ohodnotenia informačných aktív.b. Definuje spôsob identifikácie a ohodnotenia hrozieb, ktoré vplývajú na

informačné aktíva.c. Definuje spôsob identifikácie a ohodnotenia zraniteľností, ktoré informačné

aktíva obsahujú.d. Definuje spôsob ohodnotenia rizík na základe identifikovaných hrozieb

a zraniteľností.e. Definuje postup pre výber spôsobu ošetrenia identifikovaných rizík (napr.

redukcia rizika, akceptácia rizika, vyhnutie sa riziku, resp. prenos rizika nainú stranu).

f. Definuje spôsob pre vytvorenie Plánu pre ošetrenie rizík, ktorý stanovujekonkrétne opatrenia, zodpovednosti za implementáciu týchto opatrení,termíny a potrebné zdroje na ošetrenie rizík.

58

g. Definuje spôsob vyhodnotenia efektívnosti implementovaných opatrení.

8.3 V organizácii musí byť vytvorená, vedením schválená, implementovaná,dokumentovaná a dodržiavaná Smernica pre bezpečné používanie aktív,ktorá spĺňa aspoň nasledovné požiadavky:

a. Definuje pravidlá pre bezpečné používanie e-mailu, služieb v Internete ainých komunikačných prostriedkov.

b. Definuje pravidlá pre bezpečnú prácu s heslami.c. Definuje pravidlá pre inštaláciu hardvéru a softvéru.d. Stanovuje zákaz inštalácie alebo používania neautorizovaného alebo

nelegálneho softvéru.e. Definuje pravidlá pre ochranu pred škodlivým softvérom a základnými

útokmi na používateľa.f. Definuje pravidlá pre bezpečné používanie aktív mimo priestorov

organizácie.g. Je publikovaná na mieste prístupnom všetkým zamestnancom a je

propagovaná v rámci organizácie a v rámci školení – a to aspoň každých 12mesiacov – je adekvátne komunikovaná všetkým zamestnancom.

h. Je pravidelne preskúmavaná aspoň každých 12 mesiacov a v prípadezmien v organizácii alebo zmien v jej IS alebo v prípade výskytubezpečnostných incidentov je aktualizovaná a jej zmena je komunikovanávšetkým zamestnancom organizácie.

8.4 V organizácii musí byť vytvorená, vedením schválená, implementovaná,dokumentovaná a dodržiavaná Smernica pre riadenie prístupu, ktorá spĺňaaspoň nasledovné požiadavky:

a. Definuje spôsob žiadania o prístup, schvaľovania a prideľovania prístupuk jednotlivým IS v organizácii a fyzickým priestorom na základe objektívnejpotreby a zamýšľaného používania IS či potreby prístupu do fyzickýchpriestorov.

b. Definuje zodpovednosti za prideľovanie, monitorovanie, pravidelnépreskúmavanie prístupových práv do IS a odstraňovanie neplatných účtov.

c. Definuje spôsob monitorovania prístupov do IS, monitorovania používaniaIS a vyhodnocovania auditných log záznamov.

d. Definuje spôsob riadenia jednotlivých typov prístupových účtova manažment privilégií.

e. Definuje spôsob implementácie oddelenia povinností (Separation of Duties)s cieľom predchádzať škodlivej aktivite a chybám.

f. Definuje spôsob implementácie minimálnych privilégií (Least Privilege) scieľom zaistiť prístup len k tým aktívam, IS a aplikáciám, ktoré sú potrebnéna vykonávanie pracovných úloh.

g. Definuje spôsob časového obmedzenia používania aktív, IS a aplikáciía spôsob uzamknutia relácie pri definovanom čase nečinnosti používateľa.

h. Definuje spôsob vzdialeného prístupu k aktívam, IS a aplikáciám,monitorovanie vzdialeného prístupu a bezpečnostné požiadavky prevzdialený prístup.

i. Definuje spôsob riadenia prístupu k bezdrôtovým sieťam.j. Definuje spôsob riadenia prístupu mobilných zariadení.

59

k. Definuje spôsob riadenia prístupu k IS organizácie s verejne dostupnýmobsahom (napr. webové sídlo, účet na sociálnych sieťach a pod.).

8.5 V organizácii musí byť vytvorená, vedením schválená, implementovaná,dokumentovaná a dodržiavaná Smernica pre riešenie počítačovýchbezpečnostných incidentov, ktorá spĺňa aspoň nasledovné požiadavky:

a. Definuje spôsob klasifikácie incidentov, ktorý obsahuje aspoň nasledovnétypy incidentov: nežiaduci obsah, škodlivý kód, získavanie informácií,pokus o prienik, prienik, nedostupnosť, ohrozenie bezpečnosti informácií,podvod, sprenevera.

b. Definuje spôsob komunikácie, komunikačné kanály a postupy nahlasovaniaincidentov.

c. Definuje roly a zodpovednosti pri riešení incidentov.d. Definuje spôsob riešenia incidentov.e. Definuje spôsob zaistenia dôkazov.f. Definuje spôsob vedenia dokumentácie o bezpečnostných incidentoch.g. Definuje spôsob vyšetrovania bezpečnostných incidentov, spôsob

vyvodzovania zodpovednosti a ukladaní sankcií za spôsobený incident.

8.6 V organizácii musí byť vytvorená, vedením schválená, implementovaná,dokumentovaná a dodržiavaná Smernica pre riadenie kontinuity činností,ktorá spĺňa aspoň nasledovné požiadavky:

a. Definuje roly a zodpovednosti za jednotlivé činnosti pri riadení kontinuityčinností.

b. Definuje ciele riadenia kontinuity činností.c. Definuje požiadavky na vykonanie analýzy dopadov a analýzy rizík.d. Definuje spôsob určenia cieľovej doby obnovy (RTO – recovery time

objective) a cieľového bodu obnovy (RPO – recovery point objective) prejednotlivé procesy, IS a aplikácie.

e. Definuje spôsob tvorenia stratégie kontinuity činností.f. Definuje spôsob vytvorenia havarijných plánov a plánov obnovy.g. Definuje komunikačné plány v prípade mimoriadnej udalosti (prerušenia

činností).h. Definuje frekvenciu vykonávania cvičení a testovania plánov kontinuity

činností a školení.i. Definuje frekvenciu preskúmavania a aktualizácie plánov kontinuity

činností.

8.7 Zmluvy s dodávateľmi musia ustanoviť právo organizácie vykonaťu dodávateľa audit bezpečnosti informačných systémov a kontroludodržiavania bezpečnostných požiadaviek. Taktiež musia zaväzovaťdodávateľa opraviť prípadné nájdené nedostatky.

8.8 Organizácia musí, pri dodávaní služieb súvisiacich s IKT, s dodávateľomuzavrieť dohodu o úrovni poskytovania služieb (SLA), ktorá musí obsahovaťaspoň19:

a. Bezpečnostné opatrenia, ktoré je dodávateľ povinný dodržiavať.

19 Template SLA (časť informačná bezpečnosť) je dostupný na webstránkach https://www.csirt.sk.

60

b. Požiadavky na monitorovanie súladu s SLA a aktívne hlásenie nedodržaniabezpečnostných požiadaviek a bezpečnostných incidentov súvisiacichs poskytovaním služieb.

c. Dohodu, že aktivity vykonávané dodávateľom sú ním dokumentované apodliehajú kontrole a auditu zo strany organizácie.

d. Finančné pokuty za nedodržanie dohody.e. Právo na odstúpenie od dohody v prípade, že nie sú naplnené jej

podmienky.

8.9 V organizácii musia byť zavedené nasledovné predpisy:a. Bezpečnostná politika pre prácu tretích strán a ich účasť v procesoch

organizácie.b. Smernica pre vzdialený prístup do IS organizácie.c. Smernica pre zálohovanie.d. Smernica pre klasifikáciu informácií.

8.10 V organizácii by mali byť zavedené nasledovné predpisy:a. Smernica pre výkon interného auditu.b. Smernica pre BYOD a prácu na diaľku.c. Smernica pre ničenie informácií a ich nosičov.d. Smernica pre riadenie zmien.e. Smernica pre riadenie zraniteľností a implementáciu záplat.

8.11 V organizácii musia byť vedené aspoň nasledovné záznamy:a. Záznamy o školeniach, kvalifikácii a skúsenostiach zamestnancov.b. Výsledky monitorovania a merania informačnej bezpečnosti.c. Program interných auditov a výsledky (správy) z vykonania interných

auditov.d. Log záznamy, záznamy o bezpečnostných udalostiach a bezpečnostných

incidentoch.


8.12 Bezpečnostná politika a bezpečnostné smernice musia byť pravidelnepreskúmavané manažérom bezpečnosti aspoň raz za každých 12 mesiacova vždy v prípade zmien v organizácii alebo v jej informačných systémoch,alebo v prípade výskytu bezpečnostných incidentov.

8.13 Dodržiavanie bezpečnostnej politiky a bezpečnostných smerníc musí byťpravidelne kontrolované prostredníctvom pravidelných interných auditovinformačnej bezpečnosti.

61

Príloha A – Politika hesiel

Heslá pre účty s administrátorskými oprávneniami Dĺžka hesla musí byť aspoň 14 znakov Heslá musia obsahovať

o aspoň jedno veľké písmenoo aspoň jedno malé písmenoo aspoň jednu číslicu o aspoň jeden špeciálny znak

Odporúčame aby heslo obsahovaloo aspoň jeden znak s diakritikou (ak je heslo používané v rámci

homogénneho prostredia) Zmena hesla

o Odporúča sa aby heslá boli menené aspoň raz za 3 mesiaceo Heslá by mali byť zmenené aspoň raz za rok o Odporúča sa aby zmenené heslá mali od pôvodného hesla

editačnú vzdialenosť aspoň 7 (t.j. počet operácií vymazania, vloženia alebo prepísania znaku, ktorými sa z pôvodného hesla dá získať nové)

o Zmenené heslo by nemalo byť jedným z posledných 24 hesiel v histórii hesiel pre daný účet

o Heslo je možné zmeniť najviac raz za 1 deň.

Heslá pre účty s privilegovaným prístupom Dĺžka hesla musí byť aspoň 12 znakov (20 znakov pre systémové

a technické účty) Heslá musia obsahovať

o aspoň jedno veľké písmenoo aspoň jedno malé písmenoo aspoň jednu číslicu o aspoň jeden špeciálny znak

Zmena heslao Heslá by mali byť menené aspoň raz za 3 mesiaceo Heslá musia byť zmenené aspoň raz za 2 roky o Zmenené heslá musia mať zmenené viac ako polovicu znakov

oproti pôvodnému hesluo Zmenené heslo nesmie byť jedným z posledných 24 hesiel v

histórii hesiel pre daný účet

Heslá pre neprivilegované účty Dĺžka hesla musí byť aspoň 12 znakov Heslá musia obsahovať

o aspoň jedno veľké písmenoo aspoň jedno malé písmeno

62

o aspoň jednu číslicu o aspoň jeden špeciálny znak

Zmena heslao Heslá by mali byť menené aspoň raz za 6 mesiacovo Heslá musia byť zmenené aspoň raz za rok o Zmenené heslo nesmie byť jedným z posledných 12 hesiel v histórii hesiel

pre daný účeto Heslo je možné zmeniť najviac raz za 1 deň.

Príloha B - Zariadenia pre nasadenie a zabezpečenie webového servera Je dostupných mnoho typov bezpečnostných zariadení, určených nazabezpečenie webových serverov. Vyššie uvedené bezpečnostné odporúčaniamožno do istej miery implementovať pomocou nich. Tieto zariadenia umocňujúúčinok opatrení. Môžu zabrániť v prístupe útočníka k webovému serveru, čo jevýhodné najmä počas doby odstraňovania novozisteného bezpečnostnéhonedostatku.

Medzi najznámejšie funkcie zariadení určených na zabezpečenie webovéhoservera patria:

SSL akcelerátory – preberajú náročné výpočty potrebné na nadviazanie SSL/TLS spojení

Bezpečnostné brány – monitorujú HTTP prevádzku v smere do a od webového servera, v prípade podozrenia na útok vykonajú opatrenia podľa potreby

Content filtre – monitorujú prevádzku webového servera v oboch smeroch, po stránke obsahovej: v prípade zaznamenania citlivých či nevhodných dát podľa potreby vykonajú opatrenia

Autentifikačné brány – rôznymi mechanizmami autentifikujú používateľov, riadia prístup k URL na webovom serveri

V mnohých prípadoch sú vyššie uvedené funkcie kombinované v jedinomzariadení, často označovanom ako reverzné proxy.

Na zjednodušenie a zvýšenie bezpečnosti už pri prvotnej inštalácií webovéhoservera možno použiť niektoré spomedzi balíčkov, kombinujúcich hardenovanýoperačný systém a webový server. Spravidla ide o zabezpečený univerzálny OS(Linux, Windows, ... ) prispôsobený na podporu bezpečnekonfigurovaného webového servera (Apache, IIS, ... ). Podobné riešenia saopierajú o

Bezpečnú defaultnú konfiguráciu Hardenovaný OS/TOS Hardenovaný software webového servera

63

Rozšírené možnosti auditu Aplikačné wrappery Sieťové wrappery a/alebo funkcia host-based firewallu Host-based IDS Zjednodušená administrácia bezpečnosti (napr. GUI či menu)

Webaplikačné firewally (WAF) sú špeciálnym typom firewallu, prispôsobeným nazabezpečenie webového servera. Ide o filter, plugin či zariadenie ktorý aplikujeset pravidiel na HTTP prevádzku. Všeobecne tieto pravidlá pokrývajú útoky akoXSS a SQL Injection. Prispôsobením potrebám aplikácie môže byť pomocou WAFmnožstvo útokov eliminovaných. WAF sa pôvodne zameriavali na monitorovanieprevádzky na aplikačnej vrstve, teda na úrovni HTTP protokolu. V súčasnosti safunkcie tradičného WAF kombinujú s inými robustnými sieťovými technológiami,ako sú load balancing, sieťové firewally či aplikačné servery.

K bezpečnosti webových služieb môžu výrazne prispieť prvky použité nazabezpečenie externej infraštruktúry, ako firewally či IDS/IPS riešenia. Venuje saim nasledujúca kapitola tohto dokumentu.

Nasadenie HW a SW zariadení na zvýšenie ochrany webového servera možnoodporúčať. Konfigurácia zariadenia však musí zodpovedať požiadavkám nazabezpečenie konkrétneho servera a musí byť v súlade s opatreniami, uvedenýmivyššie v tejto kapitole. Pri použití predpripravených balíčkov OS s webovýmserverom je potrebné preveriť súlad východzej konfigurácie s popísanýmipožiadavkami a podľa potreby nastavenia upraviť. Kontrola továrenskýchnastavení a konfigurácia podľa definovaných požiadaviek je potrebná priakomkoľvek spomínanom bezpečnostnom riešení.

Pozn. V tomto dokumente sa nevenujeme problematike tzv. web appliances, tedazariadení špeciálne určených iba na beh webového servera. Ide o zariadenia sozjednodušeným operačným systémom a s množinou služieb nutnou na behwebového servera. Optimalizovaný OS a minimum nadbytočnýchservisov, konfiguračných možností a jednoduchá správa z týchto zariadení robíriešenie vhodné pre malé až stredné aplikácie. Cieľom dokumentu je všakposkytnúť komplexné odporúčania, vhodné i pre zložité, viacvrstvové modelywebových aplikácií, pre ktorých funkciu jednoduché jednoúčelové zariadenienepostačuje.

64

Documents

Metodika pre systematické zabezpečenie …...metodike sumarizujú základné body, ktoré sú pre zavedenie organizačnej bezpečnosti kľúčové. Aj v prípade, že organizácia