Bezpečné výchozí konfigurace pro NIS2 a DORA

Páteční odpolední chybná konfigurace, ze které se stal problém pro řídicí orgán

V pátek v 16:40 schválil vedoucí inženýringu fintech platformy změnu firewallu, která vypadala jako běžná provozní úprava. Dočasné pravidlo bylo otevřeno kvůli řešení integrace s poskytovatelem platební analytiky. V tiketu stálo: „odstranit po testování“. Test proběhl úspěšně. Pravidlo zůstalo.

O tři týdny později externí sken zjistil, že administrátorské rozhraní je dostupné z internetu. Server byl zazáplatován. Pro běžné uživatele existovala MFA. Sken zranitelností neoznačil žádné kritické CVE. Systém však stále nebyl bezpečný, protože jeho konfigurace se odchýlila od schváleného zodolněného stavu organizace.

V pondělí ráno vedl CISO souběžně čtyři rozhovory:

1. Regulační orgán chtěl vědět, zda byla ovlivněna provozní odolnost.
2. Pověřenec pro ochranu osobních údajů chtěl vědět, zda mohly být zpřístupněny osobní údaje.
3. Řídicí orgán chtěl vědět, proč nejsou „dočasné“ změny detekovány.
4. Interní auditor ISO/IEC 27001:2022 chtěl důkazy, že bezpečné výchozí konfigurace byly definovány, schváleny, implementovány a monitorovány.

Právě zde mnoho bezpečnostních programů naráží na nepříjemnou skutečnost. Bezpečná konfigurace není jen technický hardeningový kontrolní seznam. V roce 2026 jsou bezpečné výchozí konfigurace otázkou správy a řízení, kybernetické hygieny, rizik ICT, auditních důkazů a odpovědnosti řídicích orgánů.

Druhá verze stejného problému se odehrává v mnoha regulovaných organizacích. Maria, CISO rostoucího B2B zpracovatele plateb, má silné inženýry, zazáplatované systémy a osvědčené cloudové postupy. Posouzení připravenosti na NIS2 a DORA však ukáže jedno červené zjištění: chybějící formalizované bezpečné výchozí konfigurace. Její tým ví, jak servery zodolnit, ale značná část těchto znalostí je v hlavách inženýrů, nikoli ve schválených standardech, automatizovaných kontrolách nebo sadách důkazů.

Tuto mezeru již nelze obhájit. NIS2 vyžaduje, aby řídicí orgány schvalovaly opatření řízení rizik kybernetické bezpečnosti a dohlížely na ně. DORA vyžaduje dokumentovaný rámec řízení rizik ICT a odolný provoz ICT. GDPR vyžaduje vhodná technická a organizační opatření. ISO/IEC 27001:2022 vyžaduje výběr opatření na základě rizik, implementaci, monitorování, audit a neustálé zlepšování.

Bezpečné výchozí konfigurace propojují všechny tyto povinnosti do jednoho praktického systému opatření: definovat výchozí konfiguraci, přiřadit vlastnictví, vynucovat ji při zřizování, řídit výjimky, detekovat konfigurační odchylky, dokládat důkazy a zlepšovat postupy po auditech nebo incidentech.

Jak uvádí Clarysec Zenith Blueprint: 30krokový plán auditora ve fázi Opatření v praxi, kroku 19, Technologická opatření I:

„Mnoho porušení zabezpečení nevzniká kvůli chybám softwaru, ale kvůli špatným konfiguračním rozhodnutím. Výchozí hesla ponechaná beze změny, povolené nezabezpečené služby, otevřené zbytečné porty nebo systémy vystavené internetu bez odůvodnění.“

Tato věta vystihuje, proč jsou bezpečné výchozí konfigurace dnes klíčovým opatřením odolnosti. Určují, co znamená bezpečný stav, ještě dříve, než se zeptá auditor, regulační orgán, zákazník nebo útočník.

Co bezpečná výchozí konfigurace skutečně znamená

Bezpečná výchozí konfigurace je schválený, dokumentovaný a opakovatelný soubor bezpečnostních nastavení pro určitý typ systému. Může se vztahovat na servery Windows, hostitele Linux, síťová zařízení, tenanty SaaS, cloudové úložiště, clustery Kubernetes, databáze, firewally, koncová zařízení, platformy identit, IoT zařízení a provozní technologie.

Silná výchozí konfigurace odpovídá na praktické otázky:

• Které služby jsou ve výchozím stavu zakázány?
• Které porty mohou být vystaveny navenek?
• Která nastavení autentizace a MFA jsou povinná?
• Která nastavení protokolování musí být povolena?
• Která nastavení šifrování jsou vyžadována?
• Která administrátorská rozhraní jsou omezena?
• Které cloudové zdroje mohou být veřejné a na základě čího schválení?
• Které odchylky vyžadují přijetí rizika?
• Jak často kontrolujeme konfigurační odchylky?
• Jaké důkazy prokazují, že výchozí konfigurace funguje?

Nejčastějším selháním je zacházet s výchozími konfiguracemi jako s preferencemi inženýrů, nikoli jako s řízenými opatřeními. Kontrolní seznam správce Linuxu, wiki stránka cloudového architekta i firewallová konvence síťového inženýra mohou být užitečné, ale auditovatelnými se stanou až tehdy, když jsou schváleny, namapovány na rizika, konzistentně uplatňovány a monitorovány.

Proto je ISO/IEC 27001:2022 tak užitečným ukotvením. Kapitoly 4.1 až 4.3 vyžadují, aby organizace porozuměly interním a externím otázkám, zainteresovaným stranám a rozsahu ISMS, včetně právních, regulačních, smluvních požadavků a požadavků třetích stran. Kapitoly 6.1.2 a 6.1.3 vyžadují posouzení rizik bezpečnosti informací, ošetření rizik, výběr opatření, Prohlášení o použitelnosti a schválení vlastníkem rizika. Kapitoly 8.2 a 8.3 vyžadují opakování posouzení rizik a ošetření rizik v plánovaných intervalech nebo po významných změnách.

Příloha A poté převádí technické očekávání do konkrétní podoby prostřednictvím A.8.9 Configuration management, podporovaného evidencí aktiv, řízením zranitelností, řízením změn, protokolováním, monitorováním, řízením přístupu, kryptografií, používáním cloudových služeb a dokumentovanými provozními postupy.

Výsledkem je jednoduché, ale silné vyjádření správy a řízení: pokud organizace nedokáže ukázat, co znamená bezpečný stav pro každý hlavní typ systému, nemůže přesvědčivě prokázat kybernetickou hygienu podle NIS2, řízení rizik ICT podle DORA, odpovědnost podle GDPR ani účinnost opatření podle ISO/IEC 27001:2022.

Proč NIS2, DORA a GDPR činí výchozí konfigurace nezbytnými

NIS2, DORA a GDPR používají odlišný jazyk, ale sbíhají se u stejného provozního požadavku: systémy musí být bezpečně nakonfigurovány, průběžně monitorovány a řízeny prostřednictvím odpovědného řízení rizik.

NIS2 Article 20 vyžaduje, aby řídicí orgány základních a důležitých subjektů schvalovaly opatření řízení rizik kybernetické bezpečnosti, dohlížely na jejich implementaci a absolvovaly školení kybernetické bezpečnosti. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření. Bezpečné výchozí konfigurace podporují Article 21(2)(a) politiky analýzy rizik a bezpečnosti informačních systémů, Article 21(2)(e) bezpečnost při pořizování, vývoji a údržbě síťových a informačních systémů včetně řešení zranitelností, Article 21(2)(f) politiky a postupy pro posuzování účinnosti, Article 21(2)(g) základní kybernetickou hygienu a školení kybernetické bezpečnosti, Article 21(2)(h) kryptografii, Article 21(2)(i) řízení přístupu a správu aktiv a Article 21(2)(j) vícefaktorovou autentizaci a bezpečnou komunikaci.

DORA se použije od 17. ledna 2025 a pro dotčené finanční subjekty funguje jako sektorově specifický soubor pravidel provozní odolnosti. Articles 5 a 6 vyžadují správu a řízení a dokumentovaný rámec řízení rizik ICT. Article 8 vyžaduje identifikaci aktiv ICT, informačních aktiv, obchodních funkcí podporovaných ICT a závislostí. Article 9 vyžaduje ochranná a preventivní opatření, včetně bezpečnostních politik, postupů, protokolů a nástrojů pro systémy ICT, bezpečný přenos dat, řízení přístupu, silnou autentizaci, ochranu kryptografických klíčů, řízení změn, záplatování a aktualizace. Articles 10 až 14 rozšiřují tento model na detekci, reakci, obnovu, zálohování, obnovení, poučení a komunikaci.

GDPR přidává pohled ochrany soukromí. Articles 5 a 32 vyžadují integritu, důvěrnost, zabezpečení zpracování a odpovědnost prostřednictvím vhodných technických a organizačních opatření. Veřejná cloudová úložiště, nadměrně vystavené databáze, nezabezpečená výchozí nastavení a nadměrný administrátorský přístup nejsou pouze slabinami infrastruktury. Mohou se stát selháním ochrany osobních údajů.

Jeden program bezpečných výchozích konfigurací může podporovat všechny tři režimy, aniž by vytvářel duplicitní důkazní toky.

Model Clarysec pro výchozí konfigurace: politika, postup a důkazy z platforem

Clarysec přistupuje k bezpečné konfiguraci jako k opakovatelnému systému opatření, nikoli jako k jednorázovému hardeningovému projektu. Výchozí konfigurace musí být autorizována politikou, převedena do postupů, implementována technickými opatřeními a doložena důkazy.

Politika bezpečnosti informací nastavuje toto očekávání na úrovni celé organizace:

„Organizace musí udržovat minimální základní soubor bezpečnostních opatření odvozený z přílohy A ISO/IEC 27001, případně doplněný opatřeními z ISO/IEC 27002, NIST SP 800-53 a COBIT 2019.“
Ze sekce „Ošetření rizik a výjimky“, ustanovení politiky 7.2.1.

Toto ustanovení brání tomu, aby se hardening konfigurace stal souborem osobních preferencí. Ukotvuje minimální základní soubor bezpečnostních opatření v uznávaných rámcích.

Pro cloudová prostředí požadavek zpřesňuje Politika používání cloudových služeb:

„Všechna cloudová prostředí musí splňovat dokumentovanou výchozí konfiguraci schválenou architektem cloudové bezpečnosti.“
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.3.1.

Politika monitorování auditu a souladu následně převádí výchozí konfiguraci na monitorované opatření:

„Musí být nasazeny automatizované nástroje pro monitorování souladu konfigurace, řízení zranitelností, stavu záplat a privilegovaného přístupu.“
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.4.1.

Konfigurace je také neoddělitelná od řízení zranitelností a záplat. Politika řízení zranitelností a záplat uvádí:

„Náprava zranitelností musí být v souladu s výchozí konfigurací a standardy zodolnění systému.“
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.4.1.

Tento bod je podstatný. Systém může být zazáplatovaný, a přesto zůstat nezabezpečený, pokud je povolen SMBv1, administrátorská rozhraní jsou vystavena, protokolování je zakázáno nebo přetrvávají slabá nastavení autentizace. V Zenith Controls: průvodce napříč požadavky souladu je řízení konfigurace chápáno jako preventivní opatření chránící důvěrnost, integritu a dostupnost, s provozní schopností v oblasti bezpečné konfigurace. Zenith Controls také vysvětluje závislost mezi řízením konfigurace a řízením zranitelností:

„Řízení zranitelností závisí na známých konfiguracích. Bez definované výchozí konfigurace není možné zajistit konzistentní aplikaci záplat.“

Toto je důkazní model, který auditoři a regulační orgány stále častěji očekávají: systém opatření, nikoli izolované technické úkoly.

Mapování ISO/IEC 27001:2022 A.8.9 na podpůrná opatření

Opatření A.8.9 Configuration management v příloze A normy ISO/IEC 27001:2022 je hlavním ukotvením, nemělo by však být chápáno jako malý samostatný dokument. Závisí na širší skupině opatření.

Tento vztah napříč opatřeními je důvodem, proč Clarysec doporučuje řídit bezpečnou konfiguraci jako schopnost ISMS s vlastníky, důkazy, metrikami a reportováním vedení.

Širší mapování pomáhá převést stejný program výchozích konfigurací do dalších rámců.

Praktická struktura výchozí konfigurace, kterou můžete zavést tento měsíc

Nejčastější chybou je pokus napsat dokonalý 80stránkový hardeningový standard dříve, než se začne cokoli vynucovat. Začněte minimální, ale auditovatelnou výchozí konfigurací pro každou hlavní technologickou skupinu a poté ji zralostně rozvíjejte automatizací a přezkumem.

U výchozí konfigurace cloudového úložiště může první verze zahrnovat veřejný přístup ve výchozím stavu zakázaný, šifrování v klidu povolené, protokolování přístupů povolené, administrátorský přístup omezený na schválené skupiny, MFA vyžadovanou pro privilegovaný přístup do konzole, verzování povolené tam, kde to vyžadují požadavky obnovy, replikaci omezenou na schválené regiony a změny prováděné pouze prostřednictvím schválených pipeline infrastructure-as-code.

U výchozí konfigurace Windows Server 2022 podporující zpracování plateb může první verze zahrnovat zakázaný SMBv1, zakázané nepodstatné služby, RDP omezené na zodolněný jump host, Windows Defender Firewall povolený s pravidly implicitního zamítnutí, kontrolované místní administrátorské účty, přeposílání logů událostí do SIEM, povolenou ochranu koncových bodů a administrátorské změny navázané na schválené tikety.

Pro každou výchozí konfiguraci vytvořte malou sadu důkazů:

1. Schválený dokument výchozí konfigurace.
2. Snímek obrazovky nebo exportovanou politiku ukazující aplikovanou konfiguraci.
3. Seznam aktiv pokrytých výchozí konfigurací.
4. Tiket změny ukazující, jak jsou schvalovány aktualizace.
5. Report souladu konfigurace nebo záznam manuálního přezkumu.

To je přímo v souladu s Zenith Blueprint, fází Opatření v praxi, krokem 19, kde Clarysec doporučuje organizacím vytvořit konfigurační kontrolní seznamy pro hlavní typy systémů, uplatňovat nastavení konzistentně při zřizování, pokud možno prostřednictvím automatizace, a následně pravidelně auditovat nasazené systémy. Blueprint poskytuje také praktickou auditní metodu:

„Vyberte několik reprezentativních systémů (např. jeden server, jeden přepínač, jedno koncové PC) a ověřte, že jejich konfigurace odpovídá vaší bezpečné výchozí konfiguraci. Zdokumentujte odchylky a nápravu.“

Pro MSP je tento přístup reprezentativního vzorkování často nejrychlejší cestou od neformálního hardeningu k důkazům připraveným pro audit.

Příklady hardeningu pro MSP, které rychle snižují riziko

Bezpečná konfigurace není pouze otázkou podnikového cloudu. MSP často dosáhnou největšího snížení rizika několika jasnými pravidly výchozí konfigurace.

Politika zabezpečení sítí pro MSP uvádí:

„Veřejnému internetu mohou být vystaveny pouze nezbytné porty (např. HTTPS, VPN); všechny ostatní musí být uzavřeny nebo filtrovány.“
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.3.

Vyžaduje také disciplínu při změnách:

„Všechny změny síťových konfigurací (pravidla firewallu, ACL přepínačů, směrovací tabulky) musí dodržovat dokumentovaný proces řízení změn.“
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.9.1.

A stanovuje kadenci přezkumu:

„Poskytovatel IT podpory musí provést každoroční přezkum pravidel firewallu, síťové architektury a konfigurací bezdrátové sítě.“
Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.6.1.

Výchozí konfigurace koncových bodů vyžadují stejnou pozornost. Clarysec Politika ochrany koncových bodů a ochrany před malwarem pro MSP uvádí:

„Zařízení musí zakázat zastaralé protokoly (např. SMBv1), které mohou být zneužity malwarem.“
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.2.1.3.

V prostředích IoT a OT zůstávají nezabezpečená výchozí nastavení opakovanou expozicí. Politika zabezpečení internetu věcí (IoT) a provozních technologií (OT) pro MSP uvádí:

„Výchozí nebo pevně zakódovaná hesla musí být změněna před aktivací zařízení.“
Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.2.

Tato ustanovení politik nejsou abstraktní prohlášení. Jsou to požadavky výchozí konfigurace, které lze testovat, dokládat a sledovat. Pro MSP připravující se na zákaznickou due diligence, dodavatelské přezkumy podle NIS2, kybernetické pojištění nebo certifikaci ISO/IEC 27001:2022 vytvářejí okamžitou hodnotu.

Ošetření výjimek: opatření, které odděluje zralost od administrativy

Každá výchozí konfigurace bude mít výjimky. Starší aplikace může vyžadovat starý protokol. Dodavatelské zařízení nemusí podporovat preferované nastavení šifrování. Dočasné otevření firewallu může být potřebné pro migraci. Otázkou není, zda výjimky existují. Otázkou je, zda jsou řízeny.

Zralý záznam výjimky obsahuje:

• Požadavek výchozí konfigurace, který je porušován.
• Obchodní odůvodnění.
• Dotčené aktivum a vlastníka.
• Posouzení rizik.
• Kompenzační opatření.
• Schvalovací pravomoc.
• Datum vypršení platnosti.
• Požadavek na monitorování.
• Plán nápravy.

Zde se propojuje ošetření rizik podle ISO/IEC 27001:2022 a proporcionalita DORA. ISO/IEC 27001:2022 vyžaduje, aby rozhodnutí o opatřeních byla odůvodněna prostřednictvím posouzení rizik, ošetření rizik, Prohlášení o použitelnosti a schválení vlastníkem rizika. DORA umožňuje přiměřenou implementaci podle velikosti, rizikového profilu a povahy, rozsahu a složitosti služeb, ale stále očekává dokumentovanou správu a řízení rizik ICT, monitorování, kontinuitu, testování a povědomí.

Proporcionalita není povolení výchozí konfigurace vynechat. Je to požadavek škálovat je inteligentně.

U mikro nebo menšího finančního subjektu ve zjednodušeném rámci řízení rizik ICT může být výchozí konfigurace stručná a podpořená manuálním vzorkováním. U většího finančního subjektu bude stejná doména pravděpodobně vyžadovat automatizované kontroly konfigurace, zapojení interního auditu, každoroční testování a reportování řídicímu orgánu.

Politika řízení změn organizacím také připomíná, aby sledovaly:

„Konfigurační odchylky nebo manipulaci po schválených změnách.“
Ze sekce „Uplatňování a dodržování“, ustanovení politiky 8.1.2.3.

Tato formulace propojuje řízení změn s detekcí konfiguračních odchylek. Změna může být schválena, a přesto vytvořit riziko, pokud se implementovaný stav liší od schváleného stavu nebo pokud dočasné nastavení zůstane po uzavření okna změny.

Vytvoření jedné auditní stopy pro mnoho povinností v oblasti souladu

Bezpečná výchozí konfigurace by neměla vytvářet pět oddělených pracovních toků souladu. Model Clarysec používá jednu auditní stopu namapovanou na více povinností.

Klíčová je dohledatelnost. Zenith Blueprint, fáze Audit, přezkum a zlepšování, krok 24, ukládá organizacím aktualizovat Prohlášení o použitelnosti a křížově jej ověřit s plánem ošetření rizik. Pokud je opatření použitelné, potřebujete zdůvodnění. Toto zdůvodnění by mělo odkazovat na riziko, právní povinnost, smluvní požadavek nebo obchodní potřebu.

U bezpečné konfigurace by položka SoA pro A.8.9 měla odkazovat na standard bezpečné výchozí konfigurace, pokryté kategorie aktiv, vlastníky výchozí konfigurace, postup řízení změn, metodu monitorování, proces výjimek, kadenci přezkumu a povinnosti napříč rámci souladu, jako jsou NIS2 Article 21, DORA Articles 6, 8 a 9, GDPR Article 32 a závazky vůči zákazníkům.

Jak auditoři testují bezpečné výchozí konfigurace

Bezpečná konfigurace je pro auditory atraktivní, protože je bohatá na důkazy. Lze ji testovat prostřednictvím dokumentů, rozhovorů, vzorkování a technické inspekce.

Praktické otázky jsou předvídatelné:

• Používáte při instalaci nových serverů hardeningový kontrolní seznam?
• Jak bráníte spuštění nezabezpečených služeb, jako je Telnet, na směrovačích?
• Jsou cloudové úložné zdroje ve výchozím stavu soukromé?
• Kdo může schválit odchylku od výchozí konfigurace?
• Jak detekujete konfigurační odchylku po změně?
• Můžete ukázat nedávný přezkum konfigurace?
• Můžete ukázat, že detekovaná odchylka byla napravena?
• Jsou síťové a cloudové konfigurace zálohovány a verzovány?
• Jsou postupy návratu k původnímu stavu dokumentovány a testovány?

Nejsilnější organizace udržují sadu důkazů k výchozí konfiguraci pro každou hlavní kategorii systémů. Zkracuje to audity, zlepšuje odpovědi na zákaznickou due diligence a pomáhá vedení porozumět skutečné výkonnosti opatření.

Přeměňte konfigurační odchylky na metriku kybernetické hygieny pro řídicí orgány

Řídicí orgány nepotřebují znát každé pravidlo firewallu. Potřebují vědět, zda se kybernetická hygiena zlepšuje, nebo zhoršuje.

Užitečný řídicí panel bezpečné konfigurace obsahuje:

• Procento aktiv namapovaných na schválenou výchozí konfiguraci.
• Procento aktiv úspěšně procházejících kontrolami výchozí konfigurace.
• Počet kritických odchylek od výchozí konfigurace.
• Průměrné stáří otevřených odchylek.
• Počet expirovaných výjimek.
• Počet detekovaných neautorizovaných konfiguračních změn.
• Procento privilegovaných konfiguračních změn se schválenými tikety.
• Výjimky z veřejné expozice v cloudu.
• Stav přezkumu výchozích konfigurací podle technologické skupiny.

Tyto metriky podporují hodnocení výkonnosti podle ISO/IEC 27001:2022, dohled vedení podle NIS2 a reportování rizik ICT podle DORA. Přirozeně se také mapují na výsledky správy a řízení v NIST CSF 2.0 a cíle monitorování a souladu v COBIT 2019.

Pomáhá jednoduché pravidlo pro vedení: žádný kritický systém nesmí být uveden do produkčního prostředí bez důkazů výchozí konfigurace. Lze je vynucovat prostřednictvím řízení změn, bran CI/CD, kontrol cloudových politik, přezkumu infrastructure-as-code, souladu MDM, vynucení GPO nebo přezkumu síťové konfigurace. Úroveň zralosti se může lišit, ale logika opatření by se lišit neměla.

90denní playbook pro bezpečné výchozí konfigurace

Pokud začínáte od nuly, nesnažte se vyřešit všechny konfigurační problémy najednou. Použijte 90denní plán.

Dny 1 až 30: definujte minimální výchozí konfiguraci

Identifikujte kritické kategorie aktiv. Pro každou přiřaďte technického vlastníka, vlastníka rizika a schvalovací pravomoc. Vytvořte první výchozí konfiguraci pro nastavení nejrelevantnější z hlediska odolnosti proti ransomwaru, cloudové expozice, privilegovaného přístupu, protokolování, šifrování a ochrany dat.

Vytvořte registr výchozích konfigurací a namapujte jej na rozsah ISMS, registr rizik a Prohlášení o použitelnosti. Pokud se na vás vztahuje NIS2, určete, zda jste základní nebo důležitý subjekt, případně zda zákazníci očekávají kybernetickou hygienu sladěnou s NIS2. Pokud jste finanční subjekt podle DORA, určete, která aktiva ICT podporují kritické nebo důležité funkce. Pokud zpracováváte osobní údaje, namapujte systémy na činnosti zpracování podle GDPR a kategorie dat.

Dny 31 až 60: vynucujte a shromažďujte důkazy

Aplikujte výchozí konfiguraci na vzorek vysoce rizikových systémů. Používejte automatizaci tam, kde je to možné, ale nečekejte na dokonalé nástroje. Exportujte konfigurace, pořizujte snímky obrazovky, ukládejte nastavení politik a zaznamenávejte tikety změn.

Pro každou výjimku vytvořte záznam rizika s datem vypršení platnosti. Pro každou odchylku vytvořte tiket nápravy.

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

Proveďte přezkum konfigurace. Vyberte vzorek jednoho serveru, jednoho koncového bodu, jednoho síťového zařízení a jednoho cloudového prostředí. Porovnejte skutečná nastavení se schválenou výchozí konfigurací. Zdokumentujte odchylky a nápravná opatření.

Reportujte soulad výchozích konfigurací vedení. Aktualizujte Prohlášení o použitelnosti a plán ošetření rizik. Opakující se odchylky zahrňte do analýzy kořenové příčiny. Pokud chybná konfigurace způsobila incident nebo k němu přispěla, aktualizujte příslušnou výchozí konfiguraci jako součást získaných poznatků.

Tím auditorům poskytnete něco testovatelného, regulačním orgánům něco srozumitelného a vedení něco řiditelného.

Závěrečná myšlenka: bezpečná konfigurace je kybernetická hygiena s důkazem

NIS2 používá jazyk opatření řízení rizik kybernetické bezpečnosti a základní kybernetické hygieny. DORA používá jazyk rizik ICT, odolnosti, monitorování, kontinuity a testování. GDPR používá jazyk vhodných opatření a odpovědnosti. ISO/IEC 27001:2022 používá jazyk ošetření rizik, opatření, dokumentovaných informací, hodnocení výkonnosti a neustálého zlepšování.

Bezpečné výchozí konfigurace je všechny propojují.

Ukazují, že systémy nejsou nasazovány s nezabezpečenými výchozími nastaveními. Ukazují, že změny jsou řízené. Ukazují, že konfigurační odchylky jsou detekovány. Ukazují, že výjimky jsou přijaty na základě rizika. Ukazují, že důkazy existují dříve, než se zeptá auditor.

Především snižují skutečné provozní riziko. Páteční odpolední pravidlo firewallu, veřejné cloudové úložiště, zapomenuté nastavení SMBv1, výchozí heslo IoT a neprotokolovaná administrátorská konzole nejsou teoretická auditní zjištění. Jsou to praktická místa selhání.

Clarysec pomáhá organizacím převést tato místa selhání na řízené, monitorované a auditovatelné výchozí konfigurace.

Další kroky

Pokud vaše organizace potřebuje prokázat bezpečnou konfiguraci pro ISO/IEC 27001:2022, kybernetickou hygienu podle NIS2, řízení rizik ICT podle DORA, odpovědnost podle GDPR nebo zajištění pro zákazníky, začněte se sadou nástrojů Clarysec:

• Použijte Zenith Blueprint: 30krokový plán auditora k implementaci řízení konfigurace ve fázi Opatření v praxi, kroku 19, a k jeho ověření ve fázi Audit, přezkum a zlepšování, kroku 24.
• Použijte Zenith Controls: průvodce napříč požadavky souladu k mapování řízení konfigurace na podpůrná opatření ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 a auditní metodiky.
• Použijte politiky Clarysec, jako jsou Politika bezpečnosti informací, Politika používání cloudových služeb, Politika monitorování auditu a souladu, Politika řízení zranitelností a záplat, Politika zabezpečení sítí pro MSP, Politika ochrany koncových bodů a ochrany před malwarem pro MSP a Politika zabezpečení internetu věcí (IoT) a provozních technologií (OT) pro MSP, abyste definovali, prosazovali a dokládali požadavky na své výchozí konfigurace.

Bezpečná výchozí konfigurace není jen hardeningový kontrolní seznam. Je to důkaz, že vaše organizace ví, jak vypadá bezpečný stav, konzistentně jej uplatňuje a dokáže jej prokázat, když na tom záleží.