Bezpečné referenčné konfigurácie pre NIS2 a DORA

Piatková popoludňajšia chybná konfigurácia, z ktorej sa stal problém predstavenstva

V piatok o 16:40 schválil vedúci vývoja fintech platformy zdanlivo rutinnú zmenu firewallu. Dočasné pravidlo bolo otvorené na odstránenie problému pri integrácii s poskytovateľom platobnej analytiky. V tickete stálo: „odstrániť po testovaní“. Test prešiel. Pravidlo zostalo.

O tri týždne neskôr externý sken zistil administrátorské rozhranie dostupné z internetu. Server bol zaplátaný. MFA existovala pre bežných používateľov. Skener zraniteľností neoznačil žiadne kritické CVE. Systém však stále nebol bezpečný, pretože jeho konfigurácia sa odchýlila od schváleného hardeningovaného stavu organizácie.

Do pondelkového rána riešil CISO paralelne štyri diskusie:

1. Regulátor chcel vedieť, či bola ovplyvnená prevádzková odolnosť.
2. Zodpovedná osoba pre ochranu osobných údajov chcela vedieť, či mohli byť sprístupnené osobné údaje.
3. Predstavenstvo chcelo vedieť, prečo sa „dočasné“ zmeny nezisťujú.
4. Interný audítor ISO/IEC 27001:2022 chcel dôkazy, že bezpečné referenčné konfigurácie boli definované, schválené, implementované a monitorované.

Práve tu mnohé bezpečnostné programy narazia na nepríjemnú realitu. Bezpečná konfigurácia nie je iba technický kontrolný zoznam hardeningu. V roku 2026 sú bezpečné referenčné konfigurácie otázkou správy a riadenia, kybernetickej hygieny, rizík IKT, auditných dôkazov a zodpovednosti predstavenstva.

Druhá verzia toho istého problému sa odohráva v mnohých regulovaných organizáciách. Maria, CISO rastúceho B2B spracovateľa platieb, má skúsených inžinierov, zaplátané systémy a osvedčené cloudové postupy. Posúdenie pripravenosti na NIS2 a DORA však poukáže na jedno červené zistenie: chýbajú formalizované bezpečné referenčné konfigurácie. Jej tím vie servery hardeningovať, ale veľká časť týchto znalostí je v hlavách inžinierov, nie v schválených štandardoch, automatizovaných kontrolách alebo balíkoch dôkazov.

Takáto medzera už nie je obhájiteľná. NIS2 vyžaduje, aby riadiace orgány schvaľovali opatrenia riadenia kybernetických rizík a vykonávali nad nimi dohľad. DORA vyžaduje zdokumentovaný rámec riadenia rizík IKT a odolnú prevádzku IKT. GDPR vyžaduje primerané technické a organizačné opatrenia. ISO/IEC 27001:2022 vyžaduje výber kontrol na základe rizika, implementáciu, monitorovanie, audit a neustále zlepšovanie.

Bezpečné referenčné konfigurácie prepájajú všetky tieto povinnosti do jedného praktického systému kontrol: definovať referenčnú konfiguráciu, priradiť vlastníctvo, presadzovať ju pri zriaďovaní, riadiť výnimky, zisťovať konfiguračné odchýlky, predkladať dôkazy a zlepšovať po auditoch alebo incidentoch.

Ako uvádza Zenith Blueprint: 30-kroková cestovná mapa audítora od Clarysec vo fáze Uplatnenie kontrol v praxi, krok 19, Technologické kontroly I:

„Mnohé porušenia nevznikajú zo softvérových chýb, ale zo zlých konfiguračných rozhodnutí. Nezmenené predvolené heslá, povolené nezabezpečené služby, otvorené nepotrebné porty alebo systémy vystavené internetu bez odôvodnenia.“

Táto veta vystihuje, prečo sú bezpečné referenčné konfigurácie dnes základnou kontrolou odolnosti. Definujú, čo znamená bezpečný stav, ešte predtým, než sa na to opýta audítor, regulátor, zákazník alebo útočník.

Čo bezpečná referenčná konfigurácia skutočne znamená

Bezpečná referenčná konfigurácia je schválený, zdokumentovaný a opakovateľný súbor bezpečnostných nastavení pre určitý typ systému. Môže sa vzťahovať na Windows servery, Linux hosty, sieťové zariadenia, tenanty SaaS, cloudové úložisko, Kubernetes clustre, databázy, firewally, koncové zariadenia, platformy identít, IoT zariadenia a systémy prevádzkových technológií.

Silná referenčná konfigurácia odpovedá na praktické otázky:

• Ktoré služby sú predvolene vypnuté?
• Ktoré porty môžu byť vystavené externe?
• Ktoré nastavenia autentifikácie a MFA sú povinné?
• Ktoré nastavenia logovania musia byť povolené?
• Ktoré nastavenia šifrovania sú vyžadované?
• Ktoré administrátorské rozhrania sú obmedzené?
• Ktoré cloudové zdroje môžu byť verejné a na základe koho schválenia?
• Ktoré odchýlky vyžadujú akceptáciu rizika?
• Ako často kontrolujeme konfiguračné odchýlky?
• Aké dôkazy preukazujú, že referenčná konfigurácia funguje?

Najčastejším zlyhaním je zaobchádzať s referenčnými konfiguráciami ako s inžinierskymi preferenciami namiesto riadených kontrol. Kontrolný zoznam správcu Linuxu, wiki stránka cloudového architekta alebo konvencia sieťového inžiniera pre firewally môžu byť užitočné, ale auditovateľnými sa stanú až vtedy, keď sú schválené, naviazané na riziká, konzistentne uplatňované a monitorované.

Preto je ISO/IEC 27001:2022 takou užitočnou oporou. Kapitoly 4.1 až 4.3 vyžadujú, aby organizácie rozumeli interným a externým otázkam, zainteresovaným stranám a rozsahu ISMS vrátane právnych, regulačných, zmluvných požiadaviek a požiadaviek tretích strán. Kapitoly 6.1.2 a 6.1.3 vyžadujú posúdenie rizík informačnej bezpečnosti, ošetrenie rizík, výber kontrol, vyhlásenie o uplatniteľnosti a schválenie vlastníkom rizika. Kapitoly 8.2 a 8.3 vyžadujú opakovanie posúdení rizík a ošetrenia rizík v plánovaných intervaloch alebo po významných zmenách.

Príloha A následne konkretizuje technické očakávanie prostredníctvom A.8.9 riadenia konfigurácie, podporeného inventarizáciou aktív, riadením zraniteľností, riadením zmien, logovaním, monitorovaním, riadením prístupu, kryptografiou, používaním cloudových služieb a zdokumentovanými prevádzkovými postupmi.

Výsledkom je jednoduché, ale silné vyhlásenie o správe a riadení: ak organizácia nevie ukázať, čo znamená bezpečný stav pre každý významný typ systému, nedokáže presvedčivo preukázať kybernetickú hygienu podľa NIS2, riadenie rizík IKT podľa DORA, preukázateľnú zodpovednosť podľa GDPR ani účinnosť kontrol podľa ISO/IEC 27001:2022.

Prečo NIS2, DORA a GDPR robia referenčné konfigurácie nevyhnutnými

NIS2, DORA a GDPR používajú odlišný jazyk, ale zbiehajú sa pri rovnakej prevádzkovej požiadavke: systémy musia byť bezpečne nakonfigurované, priebežne monitorované a riadené prostredníctvom zodpovedného riadenia rizík.

NIS2 Article 20 vyžaduje, aby riadiace orgány základných a dôležitých subjektov schvaľovali opatrenia riadenia kybernetických rizík, dohliadali na ich implementáciu a absolvovali školenie v oblasti kybernetickej bezpečnosti. Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia. Bezpečné referenčné konfigurácie podporujú Article 21(2)(a) politiky analýzy rizík a bezpečnosti informačných systémov, Article 21(2)(e) bezpečnosť pri obstarávaní, vývoji a údržbe sietí a informačných systémov vrátane riešenia zraniteľností, Article 21(2)(f) politiky a postupy na hodnotenie účinnosti, Article 21(2)(g) základnú kybernetickú hygienu a školenie kybernetickej bezpečnosti, Article 21(2)(h) kryptografiu, Article 21(2)(i) riadenie prístupu a správu aktív a Article 21(2)(j) viacfaktorovú autentifikáciu a bezpečnú komunikáciu.

DORA sa uplatňuje od 17. januára 2025 a funguje ako odvetvovo špecifický súbor pravidiel digitálnej prevádzkovej odolnosti pre dotknuté finančné subjekty. Articles 5 a 6 vyžadujú správu a riadenie a zdokumentovaný rámec riadenia rizík IKT. Article 8 vyžaduje identifikáciu aktív IKT, informačných aktív, obchodných funkcií podporovaných IKT a závislostí. Article 9 vyžaduje ochranné a preventívne opatrenia vrátane bezpečnostných politík, postupov, protokolov a nástrojov pre systémy IKT, bezpečný prenos údajov, riadenie prístupu, silnú autentifikáciu, ochranu kryptografických kľúčov, riadenie zmien, záplatovanie a aktualizácie. Articles 10 až 14 rozširujú tento model na detekciu, reakciu, obnovu, zálohovanie, obnovenie, poučenie sa a komunikáciu.

GDPR pridáva pohľad ochrany súkromia. Articles 5 a 32 vyžadujú integritu, dôvernosť, bezpečnosť spracúvania a preukázateľnú zodpovednosť prostredníctvom primeraných technických a organizačných opatrení. Verejne dostupné cloudové úložiská, nadmerne exponované databázy, nezabezpečené predvolené nastavenia a nadmerný administrátorský prístup nie sú iba slabinami infraštruktúry. Môžu sa stať zlyhaniami ochrany osobných údajov.

Jeden program bezpečných referenčných konfigurácií dokáže podporiť všetky tri režimy bez vytvárania duplicitných tokov dôkazov.

Model referenčných konfigurácií Clarysec: politika, postup a platformové dôkazy

Clarysec pristupuje k bezpečnej konfigurácii ako k opakovateľnému systému kontrol, nie ako k jednorazovému projektu hardeningu. Referenčná konfigurácia musí byť autorizovaná politikou, premietnutá do postupov, implementovaná technickými kontrolami a preukázaná dôkazmi.

Politika informačnej bezpečnosti stanovuje toto očakávanie na úrovni organizácie:

„Organizácia musí udržiavať minimálny základný súbor kontrolných opatrení odvodený z prílohy A ISO/IEC 27001, podľa potreby doplnený o kontroly z ISO/IEC 27002, NIST SP 800-53 a COBIT 2019.“
Zo sekcie „Ošetrenie rizík a výnimky“, bod politiky 7.2.1.

Tento bod bráni tomu, aby sa hardening konfigurácie stal súborom osobných preferencií. Ukotvuje minimálny základný súbor kontrolných opatrení v uznávaných rámcoch.

Pre cloudové prostredia Politika používania cloudových služieb požiadavku spresňuje:

„Všetky cloudové prostredia musia byť v súlade so zdokumentovanou referenčnou konfiguráciou schválenou cloudovým bezpečnostným architektom.“
Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.3.1.

Politika monitorovania auditov a súladu následne premieňa referenčnú konfiguráciu na monitorovanú kontrolu:

„Na monitorovanie súladu konfigurácie, riadenia zraniteľností, stavu záplat a privilegovaného prístupu sa musia nasadiť automatizované nástroje.“
Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.4.1.

Konfigurácia je zároveň neoddeliteľná od riadenia zraniteľností a záplat. Politika riadenia zraniteľností a záplat uvádza:

„Náprava zraniteľností musí byť zosúladená s referenčnou konfiguráciou a štandardmi hardeningu systému.“
Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.4.1.

Na tomto bode záleží. Systém môže byť zaplátaný a stále zostať nezabezpečený, ak je povolené SMBv1, administrátorské rozhrania sú vystavené, logovanie je vypnuté alebo sú ponechané slabé nastavenia autentifikácie. V Zenith Controls: Sprievodca krížovým súladom sa riadenie konfigurácie považuje za preventívnu kontrolu chrániacu dôvernosť, integritu a dostupnosť, s prevádzkovou spôsobilosťou v oblasti bezpečnej konfigurácie. Zenith Controls tiež vysvetľuje závislosť medzi riadením konfigurácie a riadením zraniteľností:

„Riadenie zraniteľností závisí od známych konfigurácií. Bez definovanej referenčnej konfigurácie nie je možné zabezpečiť konzistentné aplikovanie záplat.“

Toto je dôkazový príbeh, ktorý audítori a regulátori čoraz častejšie očakávajú: systém kontrol, nie izolované technické úlohy.

Mapovanie ISO/IEC 27001:2022 A.8.9 na podporné kontroly

Kontrola A.8.9 Riadenie konfigurácie v prílohe A ISO/IEC 27001:2022 je oporným bodom, ale nemá sa považovať za malý samostatný dokument. Závisí od širšej skupiny kontrol.

Tento vzťah medzi kontrolami je dôvodom, prečo Clarysec odporúča riadiť bezpečnú konfiguráciu ako spôsobilosť ISMS s vlastníkmi, dôkazmi, metrikami a reportovaním manažmentu.

Širšie mapovanie pomáha premietnuť ten istý program referenčných konfigurácií do ďalších rámcov.

Praktická štruktúra referenčnej konfigurácie, ktorú môžete zaviesť tento mesiac

Najčastejšou chybou je snaha napísať dokonalý 80-stranový štandard hardeningu skôr, než sa začne čokoľvek presadzovať. Začnite minimálnou, ale auditovateľnou referenčnou konfiguráciou pre každú významnú technologickú skupinu a potom ju rozvíjajte automatizáciou a preskúmaním.

Pri referenčnej konfigurácii cloudového úložiska môže prvá verzia zahŕňať predvolene vypnutý verejný prístup, povolené šifrovanie v pokoji, povolené logovanie prístupov, administrátorský prístup obmedzený na schválené skupiny, povinnú MFA pre privilegovaný prístup ku konzole, verziovanie povolené tam, kde to vyžadujú požiadavky obnovy, replikáciu obmedzenú na schválené regióny a zmeny vykonávané iba prostredníctvom schválených pipeline infrastructure-as-code.

Pri referenčnej konfigurácii Windows Server 2022 podporujúcej spracovanie platieb môže prvá verzia zahŕňať vypnuté SMBv1, vypnuté nepodstatné služby, RDP obmedzené na hardeningovaný bastion host, Windows Defender Firewall povolený s pravidlami zásady predvoleného zamietnutia, riadené lokálne administrátorské účty, event logy odosielané do SIEM, povolenú ochranu koncových zariadení a administrátorské zmeny naviazané na schválené tickety.

Pre každú referenčnú konfiguráciu vytvorte malý balík dôkazov:

1. Schválený dokument referenčnej konfigurácie.
2. Snímku obrazovky alebo exportovanú politiku dokazujúcu uplatnenú konfiguráciu.
3. Zoznam aktív pokrytých referenčnou konfiguráciou.
4. Ticket zmeny ukazujúci, ako sa schvaľujú aktualizácie.
5. Správu o súlade konfigurácie alebo záznam z manuálneho preskúmania.

To priamo zodpovedá Zenith Blueprint, fáze Uplatnenie kontrol v praxi, krok 19, kde Clarysec odporúča organizáciám zaviesť konfiguračné kontrolné zoznamy pre hlavné typy systémov, uplatňovať nastavenia konzistentne pri zriaďovaní, podľa možnosti automatizovane, a následne rutinne auditovať nasadené systémy. Blueprint uvádza aj praktickú auditnú metódu:

„Vyberte niekoľko reprezentatívnych systémov (napr. jeden server, jeden prepínač, jeden počítač koncového používateľa) a overte, že ich konfigurácia zodpovedá vašej bezpečnej referenčnej konfigurácii. Zdokumentujte odchýlky a nápravné opatrenia.“

Pre MSP je tento prístup reprezentatívneho vzorkovania často najrýchlejšou cestou od neformálneho hardeningu k dôkazom pripraveným na audit.

Príklady hardeningu pre MSP, ktoré rýchlo znižujú riziko

Bezpečná konfigurácia nie je iba témou podnikového cloudu. MSP často dosahujú najväčšie zníženie rizika niekoľkými jasnými pravidlami referenčnej konfigurácie.

Politika bezpečnosti sietí - MSP uvádza:

„Verejnému internetu môžu byť vystavené iba nevyhnutné porty (napr. HTTPS, VPN); všetky ostatné musia byť zatvorené alebo filtrované.“
Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.1.3.

Vyžaduje aj disciplínu pri zmenách:

„Všetky zmeny sieťových konfigurácií (pravidlá firewallu, ACL prepínačov, smerovacie tabuľky) musia prechádzať zdokumentovaným procesom riadenia zmien.“
Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.9.1.

A vytvára interval preskúmania:

„Poskytovateľ IT podpory musí vykonávať ročné preskúmanie pravidiel firewallu, sieťovej architektúry a bezdrôtových konfigurácií.“
Zo sekcie „Požiadavky na správu a riadenie“, bod politiky 5.6.1.

Referenčné konfigurácie koncových zariadení si vyžadujú rovnakú pozornosť. Endpoint Protection - Malware Policy - SME od Clarysec uvádza:

„Zariadenia musia vypnúť zastarané protokoly (napr. SMBv1), ktoré môže zneužiť malvér.“
Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.2.1.3.

V prostrediach IoT a OT zostávajú nezabezpečené predvolené nastavenia opakujúcou sa expozíciou. Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME uvádza:

„Predvolené alebo pevne zakódované heslá sa musia zmeniť pred aktiváciou zariadení.“
Zo sekcie „Požiadavky na správu a riadenie“, bod politiky 5.3.2.

Tieto body politík nie sú abstraktné vyhlásenia. Sú to požiadavky referenčnej konfigurácie, ktoré možno testovať, dokladovať a sledovať. Pre MSP pripravujúci sa na zákaznícke due diligence, dodávateľské preskúmania podľa NIS2, kybernetické poistenie alebo certifikáciu ISO/IEC 27001:2022 vytvárajú okamžitú hodnotu.

Ošetrenie výnimiek: kontrola, ktorá oddeľuje zrelosť od papierovania

Každá referenčná konfigurácia bude mať výnimky. Staršia aplikácia môže vyžadovať starý protokol. Zariadenie dodávateľa nemusí podporovať preferované nastavenie šifrovania. Dočasné otvorenie firewallu môže byť potrebné pri migrácii. Otázkou nie je, či výnimky existujú. Otázkou je, či sú riadené.

Zrelý záznam o výnimke obsahuje:

• Požiadavku referenčnej konfigurácie, ktorá sa porušuje.
• Obchodné odôvodnenie.
• Dotknuté aktívum a vlastníka.
• Posúdenie rizík.
• Kompenzačné kontroly.
• Schvaľovaciu autoritu.
• Dátum uplynutia platnosti.
• Požiadavku na monitorovanie.
• Plán nápravy.

Práve tu spolu fungujú ošetrenie rizík podľa ISO/IEC 27001:2022 a proporcionalita podľa DORA. ISO/IEC 27001:2022 vyžaduje, aby rozhodnutia o kontrolách boli odôvodnené prostredníctvom posúdenia rizík, ošetrenia rizík, vyhlásenia o uplatniteľnosti a schválenia vlastníkom rizika. DORA umožňuje proporcionálnu implementáciu podľa veľkosti, rizikového profilu a povahy, rozsahu a komplexnosti služieb, ale stále očakáva zdokumentovanú správu a riadenie rizík IKT, monitorovanie, kontinuitu činností, testovanie a povedomie.

Proporcionalita nie je povolením vynechať referenčné konfigurácie. Je to požiadavka škálovať ich inteligentne.

Pre mikro alebo menší finančný subjekt v zjednodušenom rámci riadenia rizík IKT môže byť referenčná konfigurácia stručná a podporená manuálnym vzorkovaním. Pri väčšom finančnom subjekte bude rovnaká oblasť pravdepodobne vyžadovať automatizované kontroly konfigurácie, zapojenie vnútorného auditu, ročné testovanie a reportovanie riadiacemu orgánu.

Politika riadenia zmien tiež pripomína organizáciám, aby sledovali:

„Konfiguračné odchýlky alebo manipuláciu po schválených zmenách.“
Zo sekcie „Uplatňovanie politiky a súlad“, bod politiky 8.1.2.3.

Táto formulácia prepája riadenie zmien s detekciou konfiguračných odchýlok. Zmena môže byť schválená a stále vytvárať riziko, ak sa implementovaný stav líši od schváleného stavu alebo ak dočasné nastavenie zostane po uzavretí okna zmeny.

Vybudovanie jednej auditnej stopy pre mnohé povinnosti súladu

Bezpečná referenčná konfigurácia by nemala vytvoriť päť samostatných pracovných tokov súladu. Model Clarysec používa jednu auditnú stopu mapovanú na viaceré povinnosti.

Kľúčová je sledovateľnosť. Zenith Blueprint, fáza Audit, preskúmanie a zlepšovanie, krok 24, inštruuje organizácie aktualizovať vyhlásenie o uplatniteľnosti a krížovo ho overiť s plánom ošetrenia rizík. Ak je kontrola uplatniteľná, potrebujete odôvodnenie. Toto odôvodnenie má byť naviazané na riziko, zákonnú povinnosť, zmluvnú požiadavku alebo potrebu organizácie.

Pri bezpečnej konfigurácii by položka SoA pre A.8.9 mala odkazovať na štandard bezpečnej referenčnej konfigurácie, pokryté kategórie aktív, vlastníkov referenčných konfigurácií, postup riadenia zmien, metódu monitorovania, proces výnimiek, interval preskúmania a povinnosti krížového súladu, ako sú NIS2 Article 21, DORA Articles 6, 8 a 9, GDPR Article 32 a záväzky voči zákazníkom.

Ako budú audítori testovať bezpečné referenčné konfigurácie

Bezpečná konfigurácia je pre audítorov atraktívna, pretože je bohatá na dôkazy. Dá sa testovať prostredníctvom dokumentov, rozhovorov, vzorkovania a technickej kontroly.

Praktické otázky sú predvídateľné:

• Používate pri inštalácii nových serverov kontrolný zoznam hardeningu?
• Ako bránite spusteniu nezabezpečených služieb, ako je Telnet, na smerovačoch?
• Sú zdroje cloudového úložiska predvolene súkromné?
• Kto môže schváliť odchýlku od referenčnej konfigurácie?
• Ako zisťujete konfiguračné odchýlky po zmene?
• Viete ukázať nedávne preskúmanie konfigurácie?
• Viete ukázať, že zistená odchýlka bola opravená?
• Sú sieťové a cloudové konfigurácie zálohované a verziované?
• Sú postupy návratu do pôvodného stavu zdokumentované a otestované?

Najsilnejšie organizácie udržiavajú balík dôkazov referenčných konfigurácií pre každú významnú kategóriu systémov. Skracuje audity, zlepšuje odpovede na zákaznícke due diligence a pomáha manažmentu pochopiť skutočnú výkonnosť kontrol.

Premeňte konfiguračné odchýlky na metriku kybernetickej hygieny pre predstavenstvo

Predstavenstvá nepotrebujú poznať každé pravidlo firewallu. Potrebujú však vedieť, či sa kybernetická hygiena zlepšuje alebo zhoršuje.

Užitočný dashboard bezpečnej konfigurácie obsahuje:

• Percento aktív namapovaných na schválenú referenčnú konfiguráciu.
• Percento aktív, ktoré úspešne prešli kontrolami referenčnej konfigurácie.
• Počet kritických odchýlok od referenčnej konfigurácie.
• Priemerný vek otvorených odchýlok.
• Počet výnimiek po uplynutí platnosti.
• Počet zistených neautorizovaných konfiguračných zmien.
• Percento privilegovaných konfiguračných zmien so schválenými ticketmi.
• Výnimky z verejnej expozície v cloude.
• Stav preskúmania referenčných konfigurácií podľa technologických skupín.

Tieto metriky podporujú hodnotenie výkonnosti podľa ISO/IEC 27001:2022, dohľad manažmentu podľa NIS2 a regulačné oznamovanie rizík IKT podľa DORA. Prirodzene sa mapujú aj na výsledky správy a riadenia v NIST CSF 2.0 a ciele monitorovania a súladu v COBIT 2019.

Pomáha jednoduché pravidlo pre vrcholový manažment: žiadny kritický systém nejde do produkcie bez dôkazov o referenčnej konfigurácii. Možno ho presadzovať prostredníctvom riadenia zmien, brán CI/CD, kontrol cloudových politík, preskúmania infrastructure-as-code, súladu MDM, vynucovania GPO alebo preskúmania sieťovej konfigurácie. Úroveň zrelosti sa môže líšiť, ale logika kontroly by sa meniť nemala.

90-dňový playbook bezpečnej referenčnej konfigurácie

Ak začínate od nuly, nesnažte sa vyriešiť každý konfiguračný problém naraz. Použite 90-dňový plán.

Dni 1 až 30: definujte minimálnu referenčnú konfiguráciu

Identifikujte kritické kategórie aktív. Pre každú priraďte technického vlastníka, vlastníka rizika a schvaľovaciu autoritu. Vytvorte prvú referenčnú konfiguráciu pre nastavenia najrelevantnejšie pre odolnosť voči ransomvéru, cloudovú expozíciu, privilegovaný prístup, logovanie, šifrovanie a ochranu údajov.

Vytvorte register referenčných konfigurácií a namapujte ho na rozsah ISMS, register rizík a vyhlásenie o uplatniteľnosti. Ak podliehate NIS2, určte, či ste základný alebo dôležitý subjekt, alebo či zákazníci očakávajú kybernetickú hygienu zosúladenú s NIS2. Ak ste finančný subjekt podľa DORA, identifikujte, ktoré aktíva IKT podporujú kritické alebo dôležité funkcie. Ak spracúvate osobné údaje, namapujte systémy na spracovateľské činnosti a kategórie údajov podľa GDPR.

Dni 31 až 60: presadzujte a zbierajte dôkazy

Uplatnite referenčnú konfiguráciu na vzorku vysoko rizikových systémov. Použite automatizáciu tam, kde je to možné, ale nečakajte na dokonalé nástroje. Exportujte konfigurácie, vytvorte snímky obrazovky, uložte nastavenia politík a zaznamenajte tickety zmien.

Pre každú výnimku vytvorte záznam rizika s dátumom uplynutia platnosti. Pre každú odchýlku vytvorte ticket nápravy.

Dni 61 až 90: monitorujte, reportujte a zlepšujte

Vykonajte preskúmanie konfigurácie. Vyberte vzorku jedného servera, jedného koncového zariadenia, jedného sieťového zariadenia a jedného cloudového prostredia. Porovnajte skutočné nastavenia so schválenou referenčnou konfiguráciou. Zdokumentujte odchýlky a nápravné opatrenia.

Reportujte súlad referenčných konfigurácií manažmentu. Aktualizujte vyhlásenie o uplatniteľnosti a plán ošetrenia rizík. Opakujúce sa odchýlky zapracujte do analýzy koreňovej príčiny. Ak chybná konfigurácia spôsobila incident alebo k nemu prispela, aktualizujte príslušnú referenčnú konfiguráciu ako súčasť poučení z incidentu.

To dá audítorom niečo testovateľné, regulátorom niečo zrozumiteľné a manažmentu niečo riaditeľné.

Záverečná myšlienka: bezpečná konfigurácia je kybernetická hygiena s dôkazmi

NIS2 používa jazyk opatrení riadenia kybernetických rizík a základnej kybernetickej hygieny. DORA používa jazyk rizík IKT, odolnosti, monitorovania, kontinuity činností a testovania. GDPR používa jazyk primeraných opatrení a preukázateľnej zodpovednosti. ISO/IEC 27001:2022 používa jazyk ošetrenia rizík, kontrol, zdokumentovaných informácií, hodnotenia výkonnosti a neustáleho zlepšovania.

Bezpečné referenčné konfigurácie ich všetky prepájajú.

Ukazujú, že systémy sa nenasadzujú s nezabezpečenými predvolenými nastaveniami. Ukazujú, že zmeny sú riadené. Ukazujú, že konfiguračné odchýlky sa zisťujú. Ukazujú, že výnimky sú akceptované na základe rizika. Ukazujú, že dôkazy existujú skôr, než sa opýta audítor.

Najdôležitejšie je, že znižujú reálne prevádzkové riziko. Piatkové popoludňajšie pravidlo firewallu, verejne dostupné cloudové úložisko, zabudnuté nastavenie SMBv1, predvolené heslo IoT a administrátorská konzola bez logovania nie sú teoretické auditné zistenia. Sú to praktické body zlyhania.

Clarysec pomáha organizáciám premeniť tieto body zlyhania na riadené, monitorované a auditovateľné referenčné konfigurácie.

Ďalšie kroky

Ak vaša organizácia potrebuje preukázať bezpečnú konfiguráciu pre ISO/IEC 27001:2022, kybernetickú hygienu podľa NIS2, riadenie rizík IKT podľa DORA, preukázateľnú zodpovednosť podľa GDPR alebo uistenie zákazníkov, začnite sadou nástrojov Clarysec:

• Použite Zenith Blueprint: 30-kroková cestovná mapa audítora na implementáciu riadenia konfigurácie vo fáze Uplatnenie kontrol v praxi, krok 19, a jeho overenie vo fáze Audit, preskúmanie a zlepšovanie, krok 24.
• Použite Zenith Controls: Sprievodca krížovým súladom na mapovanie riadenia konfigurácie na podporné kontroly ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 a auditné metodiky.
• Použite politiky Clarysec, ako sú Politika informačnej bezpečnosti, Politika používania cloudových služieb, Politika monitorovania auditov a súladu, Politika riadenia zraniteľností a záplat, Politika bezpečnosti sietí - MSP, Endpoint Protection - Malware Policy - SME a Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME na definovanie, presadzovanie a dokladovanie požiadaviek vašej referenčnej konfigurácie.

Bezpečná referenčná konfigurácia nie je iba kontrolný zoznam hardeningu. Je to dôkaz, že vaša organizácia vie, ako vyzerá bezpečný stav, uplatňuje ho konzistentne a vie ho preukázať vtedy, keď na tom záleží.