Bezpieczne konfiguracje bazowe dla NIS2 i DORA

Błędna konfiguracja z piątkowego popołudnia, która stała się problemem zarządu

W piątek o 16:40 kierownik zespołu inżynierii platformy w firmie fintech zatwierdził zmianę reguły zapory sieciowej, która wyglądała na rutynową. Tymczasową regułę otwarto, aby rozwiązać problem z integracją z dostawcą analityki płatniczej. W zgłoszeniu zapisano: „usunąć po testach”. Test zakończył się powodzeniem. Reguła pozostała.

Trzy tygodnie później zewnętrzny skan wykazał, że interfejs administracyjny jest dostępny z Internetu. Serwer miał wdrożone poprawki. MFA było dostępne dla zwykłych użytkowników. Skaner podatności nie zgłosił krytycznej CVE. System nadal nie był jednak bezpieczny, ponieważ jego konfiguracja odbiegała od zatwierdzonego, utwardzonego stanu organizacji.

W poniedziałek rano Dyrektor ds. bezpieczeństwa informacji prowadził równolegle cztery rozmowy:

1. Organ regulacyjny chciał wiedzieć, czy ucierpiała odporność operacyjna.
2. Inspektor Ochrony Danych (IOD) chciał wiedzieć, czy doszło do ekspozycji danych osobowych.
3. Zarząd chciał wiedzieć, dlaczego „tymczasowe” zmiany nie były wykrywane.
4. Audytor wewnętrzny ISO/IEC 27001:2022 chciał dowodów, że bezpieczne konfiguracje bazowe zostały zdefiniowane, zatwierdzone, wdrożone i są monitorowane.

W tym miejscu wiele programów bezpieczeństwa odkrywa niewygodną prawdę. Bezpieczna konfiguracja nie jest jedynie techniczną listą kontrolną utwardzania. W 2026 roku bezpieczne konfiguracje bazowe są kwestią ładu zarządczego, cyberhigieny, ryzyka ICT, dowodów audytowych i rozliczalności zarządu.

Druga wersja tego samego problemu pojawia się w wielu organizacjach regulowanych. Maria, CISO rozwijającego się procesora płatności B2B, ma doświadczonych inżynierów, systemy z aktualnymi poprawkami i dobre praktyki chmurowe. Jednak ocena gotowości do NIS2 i DORA wskazuje jedno czerwone ustalenie: brak sformalizowanych bezpiecznych konfiguracji bazowych. Jej zespół wie, jak utwardzać serwery, ale znaczna część tej wiedzy znajduje się w głowach inżynierów, a nie w zatwierdzonych standardach, zautomatyzowanych kontrolach czy pakietach dowodowych.

Taka luka nie jest już możliwa do obrony. NIS2 wymaga, aby organy zarządzające zatwierdzały i nadzorowały środki zarządzania ryzykiem cyberbezpieczeństwa. DORA wymaga udokumentowanych ram zarządzania ryzykiem ICT i odpornych operacji ICT. GDPR wymaga odpowiednich środków technicznych i organizacyjnych. ISO/IEC 27001:2022 wymaga doboru zabezpieczeń opartego na ryzyku, ich wdrożenia, monitorowania, audytu i ciągłego doskonalenia.

Bezpieczne konfiguracje bazowe łączą te obowiązki w jeden praktyczny system kontroli: zdefiniować konfigurację bazową, przypisać własność, egzekwować ją podczas nadawania dostępu i przygotowywania zasobów, zarządzać wyjątkami, wykrywać dryf konfiguracji, przedstawiać dowody oraz doskonalić po audytach lub incydentach.

Jak ujmuje to Zenith Blueprint: 30-etapowa mapa drogowa audytora Clarysec w fazie Kontrole w działaniu, krok 19, Kontrole technologiczne I:

„Wiele naruszeń nie wynika z błędów oprogramowania, lecz ze złych decyzji konfiguracyjnych. Pozostawione bez zmian hasła domyślne, włączone niezabezpieczone usługi, niepotrzebnie otwarte porty albo systemy wystawione do Internetu bez uzasadnienia”.

To zdanie pokazuje, dlaczego bezpieczne konfiguracje bazowe są dziś podstawowym zabezpieczeniem odporności. Definiują, co oznacza stan bezpieczny, zanim zapyta o to audytor, regulator, klient albo atakujący.

Czym naprawdę jest bezpieczna konfiguracja bazowa

Bezpieczna konfiguracja bazowa to zatwierdzony, udokumentowany i powtarzalny zestaw ustawień bezpieczeństwa dla określonego typu systemu. Może dotyczyć serwerów Windows, hostów Linux, urządzeń sieciowych, tenantów SaaS, zasobów pamięci masowej w chmurze, klastrów Kubernetes, baz danych, zapór sieciowych, urządzeń końcowych, platform tożsamości, urządzeń Internetu Rzeczy oraz technologii operacyjnej.

Dobra konfiguracja bazowa odpowiada na praktyczne pytania:

• Które usługi są domyślnie wyłączone?
• Które porty mogą być wystawione na zewnątrz?
• Które ustawienia uwierzytelniania i MFA są obowiązkowe?
• Które ustawienia rejestrowania muszą być włączone?
• Które ustawienia szyfrowania są wymagane?
• Które interfejsy administracyjne są ograniczone?
• Które zasoby chmurowe mogą być publiczne i za czyją zgodą?
• Które odstępstwa wymagają akceptacji ryzyka?
• Jak często sprawdzamy dryf konfiguracji?
• Jakie dowody potwierdzają działanie konfiguracji bazowej?

Najczęstszą nieskutecznością jest traktowanie konfiguracji bazowych jako preferencji inżynierskich, a nie jako nadzorowanych zabezpieczeń. Lista kontrolna administratora Linux, strona wiki architekta chmury i konwencja reguł zapory sieciowej stosowana przez inżyniera sieci mogą być użyteczne, ale stają się audytowalne dopiero wtedy, gdy są zatwierdzone, powiązane z ryzykiem, stosowane spójnie i monitorowane.

Dlatego ISO/IEC 27001:2022 jest tak użytecznym punktem odniesienia. Klauzule 4.1 do 4.3 wymagają od organizacji zrozumienia czynników wewnętrznych i zewnętrznych, stron zainteresowanych oraz zakresu SZBI, w tym wymagań prawnych, regulacyjnych, umownych i dotyczących stron trzecich. Klauzule 6.1.2 i 6.1.3 wymagają oceny ryzyka bezpieczeństwa informacji, postępowania z ryzykiem, doboru zabezpieczeń, Deklaracji stosowania oraz zatwierdzenia przez właściciela ryzyka. Klauzule 8.2 i 8.3 wymagają powtarzania ocen ryzyka i postępowania z ryzykiem w zaplanowanych odstępach albo po istotnych zmianach.

Załącznik A konkretyzuje następnie oczekiwanie techniczne poprzez A.8.9 Zarządzanie konfiguracją, wspierane przez inwentarz aktywów, zarządzanie podatnościami, zarządzanie zmianami, rejestrowanie, monitorowanie, kontrolę dostępu, kryptografię, korzystanie z chmury oraz udokumentowane procedury operacyjne.

Wynikiem jest proste, ale silne stwierdzenie z zakresu ładu zarządczego: jeżeli organizacja nie potrafi pokazać, co oznacza stan bezpieczny dla każdego głównego typu systemu, nie może przekonująco wykazać cyberhigieny w NIS2, kontroli ryzyka ICT w DORA, rozliczalności w GDPR ani skuteczności zabezpieczeń w ISO/IEC 27001:2022.

Dlaczego NIS2, DORA i GDPR czynią konfiguracje bazowe niezbędnymi

NIS2, DORA i GDPR posługują się różnym językiem, ale zbiegają się w tym samym wymaganiu operacyjnym: systemy muszą być bezpiecznie skonfigurowane, stale monitorowane i objęte rozliczalnym zarządzaniem ryzykiem.

NIS2 Article 20 wymaga, aby organy zarządzające podmiotów kluczowych i ważnych zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie i odbywały szkolenia z zakresu cyberbezpieczeństwa. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych. Bezpieczne konfiguracje bazowe wspierają Article 21(2)(a) dotyczący polityk analizy ryzyka i bezpieczeństwa systemów informatycznych, Article 21(2)(e) dotyczący bezpieczeństwa w pozyskiwaniu, rozwoju i utrzymaniu sieci oraz systemów informatycznych, w tym obsługi podatności, Article 21(2)(f) dotyczący polityk i procedur oceny skuteczności, Article 21(2)(g) dotyczący podstawowej cyberhigieny i szkoleń z cyberbezpieczeństwa, Article 21(2)(h) dotyczący kryptografii, Article 21(2)(i) dotyczący kontroli dostępu i zarządzania aktywami oraz Article 21(2)(j) dotyczący uwierzytelniania wieloskładnikowego i bezpiecznej komunikacji.

DORA obowiązuje od 17 stycznia 2025 r. i pełni funkcję sektorowego zestawu wymagań odporności operacyjnej dla objętych nim podmiotów finansowych. Articles 5 i 6 wymagają ładu zarządczego oraz udokumentowanych ram zarządzania ryzykiem ICT. Article 8 wymaga identyfikacji aktywów ICT, aktywów informacyjnych, funkcji biznesowych wspieranych przez ICT i zależności. Article 9 wymaga środków ochrony i zapobiegania, w tym polityk bezpieczeństwa, procedur, protokołów i narzędzi dla systemów ICT, bezpiecznego transferu danych, kontroli dostępu, silnego uwierzytelniania, ochrony kluczy kryptograficznych, zarządzania zmianami, wdrażania poprawek i aktualizacji. Articles 10 do 14 rozszerzają ten model na wykrywanie, reagowanie, odzyskiwanie, kopie zapasowe, odtwarzanie, uczenie się i komunikację.

GDPR dodaje perspektywę prywatności. Articles 5 i 32 wymagają integralności, poufności, bezpieczeństwa przetwarzania oraz rozliczalności poprzez odpowiednie środki techniczne i organizacyjne. Publiczne zasobniki chmurowe, nadmiernie wystawione bazy danych, niezabezpieczone ustawienia domyślne i nadmierny dostęp administracyjny nie są wyłącznie słabościami infrastruktury. Mogą stać się nieskutecznością ochrony danych osobowych.

Jeden program bezpiecznych konfiguracji bazowych może wspierać wszystkie trzy reżimy bez tworzenia zdublowanych strumieni dowodowych.

Model konfiguracji bazowej Clarysec: polityka, procedura i dowody z platform

Clarysec traktuje bezpieczną konfigurację jako powtarzalny system kontroli, a nie jednorazowy projekt utwardzania. Konfiguracja bazowa musi być autoryzowana przez politykę, przełożona na procedury, wdrożona poprzez zabezpieczenia techniczne i potwierdzona dowodami.

Polityka bezpieczeństwa informacji ustanawia to oczekiwanie na poziomie całej organizacji:

„Organizacja utrzymuje minimalny bazowy zestaw zabezpieczeń wywiedziony z Załącznika A ISO/IEC 27001, uzupełniony, gdy jest to właściwe, zabezpieczeniami z ISO/IEC 27002, NIST SP 800-53 oraz COBIT 2019”.
Z sekcji „Postępowanie z ryzykiem i wyjątki”, klauzula polityki 7.2.1.

Ta klauzula zapobiega temu, aby utwardzanie konfiguracji stało się zbiorem osobistych preferencji. Osadza minimalny bazowy zestaw zabezpieczeń w uznanych ramach.

Dla środowisk chmurowych Polityka korzystania z chmury zawęża wymaganie:

„Wszystkie środowiska chmurowe muszą być zgodne z udokumentowaną konfiguracją bazową zatwierdzoną przez architekta bezpieczeństwa chmury”.
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.3.1.

Polityka audytu i monitorowania zgodności przekształca następnie konfigurację bazową w monitorowane zabezpieczenie:

„Należy wdrożyć zautomatyzowane narzędzia do monitorowania zgodności konfiguracji, zarządzania podatnościami, statusu poprawek oraz dostępu uprzywilejowanego”.
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.4.1.

Konfiguracja jest również nierozerwalnie związana z zarządzaniem podatnościami i poprawkami. Polityka zarządzania podatnościami i poprawkami stanowi:

„Działania naprawcze dotyczące podatności muszą być zgodne z konfiguracją bazową i standardami utwardzania systemów”.
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.4.1.

Ten punkt ma znaczenie. System może mieć wdrożone poprawki, a mimo to pozostawać niezabezpieczony, jeżeli włączono SMBv1, wystawiono interfejsy administracyjne, wyłączono rejestrowanie albo pozostawiono słabe ustawienia uwierzytelniania. W Zenith Controls: Przewodniku zgodności krzyżowej zarządzanie konfiguracją jest traktowane jako zabezpieczenie prewencyjne chroniące poufność, integralność i dostępność, z operacyjną zdolnością w obszarze bezpiecznej konfiguracji. Zenith Controls wyjaśnia także zależność między zarządzaniem konfiguracją a zarządzaniem podatnościami:

„Zarządzanie podatnościami zależy od znanych konfiguracji. Bez zdefiniowanej konfiguracji bazowej nie da się zapewnić spójnego wdrażania poprawek”.

To jest narracja dowodowa, której audytorzy i regulatorzy oczekują coraz częściej: system kontroli, a nie odizolowane zadania techniczne.

Mapowanie ISO/IEC 27001:2022 A.8.9 na wspierające zabezpieczenia

Zabezpieczenie A.8.9 Zarządzanie konfiguracją z Załącznika A ISO/IEC 27001:2022 jest punktem zakotwiczenia, ale nie należy traktować go jako niewielkiego samodzielnego dokumentu. Zależy ono od szerszej rodziny zabezpieczeń.

Ta relacja między zabezpieczeniami wyjaśnia, dlaczego Clarysec rekomenduje zarządzanie bezpieczną konfiguracją jako zdolność SZBI z właścicielami, dowodami, wskaźnikami i raportowaniem zarządczym.

Szersze mapowanie pomaga przełożyć ten sam program konfiguracji bazowych na inne ramy.

Praktyczna struktura konfiguracji bazowej, którą można wdrożyć w tym miesiącu

Najczęstszym błędem jest próba napisania doskonałego, 80-stronicowego standardu utwardzania, zanim zacznie się cokolwiek egzekwować. Zacznij od minimalnej, ale audytowalnej konfiguracji bazowej dla każdej głównej rodziny technologii, a następnie rozwijaj ją poprzez automatyzację i przeglądy.

Dla konfiguracji bazowej zasobów pamięci masowej w chmurze pierwsza wersja może obejmować domyślne wyłączenie dostępu publicznego, włączenie szyfrowania danych w spoczynku, włączenie rejestrowania dostępu, ograniczenie dostępu administracyjnego do zatwierdzonych grup, wymaganie MFA dla uprzywilejowanego dostępu do konsoli, włączenie wersjonowania tam, gdzie wymagają tego potrzeby odzyskiwania, ograniczenie replikacji do zatwierdzonych regionów oraz dokonywanie zmian wyłącznie przez zatwierdzone potoki infrastruktury jako kodu.

Dla konfiguracji bazowej Windows Server 2022 wspierającej przetwarzanie płatności pierwsza wersja może obejmować wyłączenie SMBv1, wyłączenie usług nieistotnych, ograniczenie RDP do utwardzonego serwera przesiadkowego, włączenie Windows Defender Firewall z zasadą domyślnej odmowy, kontrolę lokalnych kont administratorów, przekazywanie logów zdarzeń do SIEM, włączenie ochrony punktów końcowych oraz powiązanie zmian administracyjnych z zatwierdzonymi zgłoszeniami.

Dla każdej konfiguracji bazowej przygotuj mały pakiet dowodowy:

1. Zatwierdzony dokument konfiguracji bazowej.
2. Zrzut ekranu albo wyeksportowaną politykę pokazującą zastosowaną konfigurację.
3. Wykaz aktywów objętych konfiguracją bazową.
4. Zgłoszenie zmiany pokazujące, jak zatwierdzane są aktualizacje.
5. Raport zgodności konfiguracji albo zapis ręcznego przeglądu.

Jest to bezpośrednio zgodne z Zenith Blueprint, fazą Kontrole w działaniu, krok 19, w której Clarysec rekomenduje organizacjom ustanowienie list kontrolnych konfiguracji dla głównych typów systemów, spójne stosowanie ustawień podczas nadawania dostępu i przygotowywania zasobów z użyciem automatyzacji tam, gdzie to możliwe, a następnie rutynowe audytowanie wdrożonych systemów. Blueprint podaje także praktyczną metodę audytu:

„Wybierz kilka reprezentatywnych systemów (np. jeden serwer, jeden przełącznik, jeden komputer użytkownika końcowego) i zweryfikuj, czy ich konfiguracja odpowiada Twojej bezpiecznej konfiguracji bazowej. Udokumentuj odstępstwa i działania naprawcze”.

Dla MŚP takie reprezentatywne próbkowanie jest często najszybszą ścieżką od nieformalnego utwardzania do dowodów gotowych do audytu.

Przykłady utwardzania w MŚP, które szybko ograniczają ryzyko

Bezpieczna konfiguracja nie jest wyłącznie problemem chmury w dużych przedsiębiorstwach. MŚP często osiągają największą redukcję ryzyka dzięki kilku jasnym regułom bazowym.

Polityka bezpieczeństwa sieci - MŚP stanowi:

„Tylko niezbędne porty (np. HTTPS, VPN) mogą być wystawione do publicznego Internetu; wszystkie pozostałe muszą być zamknięte albo filtrowane”.
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.3.

Wymaga również dyscypliny zmian:

„Wszystkie zmiany konfiguracji sieciowych (reguły zapory sieciowej, listy kontroli dostępu przełączników, tablice routingu) muszą być realizowane zgodnie z udokumentowanym procesem zarządzania zmianami”.
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.9.1.

Oraz ustanawia cykl przeglądu:

„Dostawca wsparcia IT musi przeprowadzać coroczny przegląd reguł zapory sieciowej, architektury sieci i konfiguracji sieci bezprzewodowych”.
Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.6.1.

Konfiguracje bazowe punktów końcowych wymagają takiej samej uwagi. Polityka ochrony punktów końcowych przed złośliwym oprogramowaniem - MŚP Clarysec stanowi:

„Urządzenia muszą wyłączać przestarzałe protokoły (np. SMBv1), które mogą zostać wykorzystane przez złośliwe oprogramowanie”.
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.1.3.

W środowiskach IoT i OT niezabezpieczone ustawienia domyślne pozostają powtarzalnym źródłem ekspozycji. Polityka bezpieczeństwa Internetu Rzeczy (IoT) / technologii operacyjnej (OT) - MŚP stanowi:

„Domyślne lub twardo zakodowane hasła muszą zostać zmienione przed aktywacją urządzeń”.
Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.3.2.

Te klauzule polityk nie są abstrakcyjnymi deklaracjami. Są wymaganiami konfiguracji bazowej, które można testować, dokumentować dowodowo i śledzić. Dla MŚP przygotowującego się do due diligence klienta, przeglądów dostawców w kontekście NIS2, cyberubezpieczenia albo certyfikacji ISO/IEC 27001:2022 tworzą natychmiastową wartość.

Obsługa wyjątków: kontrola odróżniająca dojrzałość od dokumentacji papierowej

Każda konfiguracja bazowa będzie miała wyjątki. Aplikacja legacy może wymagać starego protokołu. Urządzenie dostawcy może nie obsługiwać preferowanego ustawienia szyfrowania. Tymczasowe otwarcie zapory sieciowej może być potrzebne na czas migracji. Pytanie nie brzmi, czy wyjątki istnieją. Pytanie brzmi, czy są objęte nadzorem.

Dojrzały zapis wyjątku obejmuje:

• Wymaganie konfiguracji bazowej, które zostało naruszone.
• Uzasadnienie biznesowe.
• Aktywo, którego dotyczy wyjątek, oraz jego właściciela.
• Ocenę ryzyka.
• Środki kompensujące.
• Organ zatwierdzający.
• Datę wygaśnięcia.
• Wymaganie monitorowania.
• Plan działań naprawczych.

W tym miejscu postępowanie z ryzykiem w ISO/IEC 27001:2022 i proporcjonalność DORA działają razem. ISO/IEC 27001:2022 wymaga, aby decyzje dotyczące zabezpieczeń były uzasadnione oceną ryzyka, postępowaniem z ryzykiem, Deklaracją stosowania i zatwierdzeniem przez właściciela ryzyka. DORA dopuszcza proporcjonalne wdrożenie zależne od wielkości, profilu ryzyka oraz charakteru, skali i złożoności usług, ale nadal oczekuje udokumentowanego nadzoru nad ryzykiem ICT, monitorowania, ciągłości działania, testowania i świadomości.

Proporcjonalność nie jest zgodą na pomijanie konfiguracji bazowych. Jest wymaganiem skalowania ich w sposób racjonalny.

Dla mikro lub mniejszego podmiotu finansowego objętego uproszczonymi ramami ryzyka ICT konfiguracja bazowa może być zwięzła i wspierana ręcznym próbkowaniem. Dla większego podmiotu finansowego ten sam obszar prawdopodobnie będzie wymagał zautomatyzowanych kontroli konfiguracji, udziału audytu wewnętrznego, corocznych testów i raportowania do organu zarządzającego.

Polityka zarządzania zmianami przypomina również organizacjom, aby zwracały uwagę na:

„Dryf konfiguracji lub manipulację po zatwierdzonych zmianach”.
Z sekcji „Egzekwowanie i zgodność”, klauzula polityki 8.1.2.3.

Ta fraza łączy kontrolę zmian z wykrywaniem dryfu konfiguracji. Zmiana może być zatwierdzona, a mimo to tworzyć ryzyko, jeżeli wdrożony stan różni się od zatwierdzonego albo jeżeli ustawienie tymczasowe pozostaje po zamknięciu okna wdrożeniowego.

Budowanie jednej ścieżki dowodowej dla wielu obowiązków zgodności

Bezpieczna konfiguracja bazowa nie powinna tworzyć pięciu odrębnych strumieni pracy w obszarze zgodności. Model Clarysec wykorzystuje jedną ścieżkę dowodową mapowaną na wiele obowiązków.

Kluczowa jest identyfikowalność. Zenith Blueprint, faza Audyt, przegląd i doskonalenie, krok 24, instruuje organizacje, aby aktualizowały Deklarację stosowania i weryfikowały ją krzyżowo z planem postępowania z ryzykiem. Jeżeli zabezpieczenie ma zastosowanie, potrzebne jest uzasadnienie. To uzasadnienie powinno łączyć się z ryzykiem, obowiązkiem prawnym, wymogiem umownym albo potrzebą biznesową.

Dla bezpiecznej konfiguracji wpis SoA dla A.8.9 powinien odwoływać się do standardu bezpiecznej konfiguracji bazowej, objętych kategorii aktywów, właścicieli konfiguracji bazowych, procedury zarządzania zmianami, metody monitorowania, procesu wyjątków, cyklu przeglądu i obowiązków zgodności krzyżowej, takich jak NIS2 Article 21, DORA Articles 6, 8 i 9, GDPR Article 32 oraz zobowiązania wobec klientów.

Jak audytorzy będą testować bezpieczne konfiguracje bazowe

Bezpieczna konfiguracja jest atrakcyjna dla audytorów, ponieważ jest bogata dowodowo. Można ją testować poprzez dokumenty, wywiady, próbkowanie i inspekcję techniczną.

Praktyczne pytania są przewidywalne:

• Czy podczas instalowania nowych serwerów używacie listy kontrolnej utwardzania?
• Jak zapobiegacie uruchamianiu niezabezpieczonych usług, takich jak Telnet, na routerach?
• Czy zasoby pamięci masowej w chmurze są domyślnie prywatne?
• Kto może zatwierdzić odstępstwo od konfiguracji bazowej?
• Jak wykrywacie dryf konfiguracji po zmianie?
• Czy możecie pokazać niedawny przegląd konfiguracji?
• Czy możecie pokazać, że wykryte odstępstwo zostało skorygowane?
• Czy konfiguracje sieciowe i chmurowe są objęte kopiami zapasowymi i wersjonowaniem?
• Czy procedury wycofania zmian są udokumentowane i przetestowane?

Najsilniejsze organizacje utrzymują pakiet dowodowy konfiguracji bazowej dla każdej głównej kategorii systemów. Skraca to audyty, usprawnia odpowiedzi na due diligence klientów i pomaga kierownictwu zrozumieć rzeczywistą skuteczność kontroli.

Przekształć dryf konfiguracji w zarządczą metrykę cyberhigieny

Zarządy nie potrzebują każdej reguły zapory sieciowej. Muszą jednak wiedzieć, czy cyberhigiena poprawia się, czy pogarsza.

Użyteczny pulpit bezpiecznej konfiguracji obejmuje:

• Odsetek aktywów przypisanych do zatwierdzonej konfiguracji bazowej.
• Odsetek aktywów przechodzących kontrole konfiguracji bazowej.
• Liczbę krytycznych odstępstw od konfiguracji bazowej.
• Średni wiek otwartych odstępstw.
• Liczbę wygasłych wyjątków.
• Liczbę wykrytych nieautoryzowanych zmian konfiguracji.
• Odsetek uprzywilejowanych zmian konfiguracji z zatwierdzonymi zgłoszeniami.
• Wyjątki dotyczące publicznej ekspozycji chmury.
• Status przeglądu konfiguracji bazowej według rodziny technologii.

Te wskaźniki wspierają ocenę wyników w ISO/IEC 27001:2022, nadzór zarządczy NIS2 oraz raportowanie ryzyka ICT w DORA. Naturalnie mapują się również na wyniki ładu zarządczego NIST CSF 2.0 i cele monitorowania oraz zgodności COBIT 2019.

Pomaga prosta zasada dla kierownictwa: żaden system krytyczny nie trafia na produkcję bez dowodów konfiguracji bazowej. Można ją egzekwować przez zarządzanie zmianami, bramki CI/CD, kontrole polityk chmurowych, przegląd infrastruktury jako kodu, zgodność MDM, egzekwowanie GPO albo przegląd konfiguracji sieciowej. Poziom dojrzałości może się różnić, ale logika kontroli nie powinna.

90-dniowy playbook bezpiecznej konfiguracji bazowej

Jeżeli zaczynasz od zera, nie próbuj rozwiązać wszystkich problemów konfiguracji naraz. Zastosuj plan 90-dniowy.

Dni 1 do 30: zdefiniuj minimalną konfigurację bazową

Zidentyfikuj krytyczne kategorie aktywów. Dla każdej przypisz właściciela technicznego, właściciela ryzyka i organ zatwierdzający. Utwórz pierwszą konfigurację bazową dla ustawień najważniejszych dla odporności na ransomware, ekspozycji chmurowej, dostępu uprzywilejowanego, rejestrowania, szyfrowania i ochrony danych.

Utwórz rejestr konfiguracji bazowych i zmapuj go na zakres SZBI, rejestr ryzyk i Deklarację stosowania. Jeżeli podlegasz NIS2, określ, czy jesteś podmiotem kluczowym lub ważnym, albo czy klienci oczekują cyberhigieny zgodnej z NIS2. Jeżeli jesteś podmiotem finansowym objętym DORA, określ, które aktywa ICT wspierają funkcje krytyczne lub ważne. Jeżeli przetwarzasz dane osobowe, zmapuj systemy na czynności przetwarzania GDPR i kategorie danych.

Dni 31 do 60: egzekwuj i zbieraj dowody

Zastosuj konfigurację bazową do próbki systemów wysokiego ryzyka. Używaj automatyzacji tam, gdzie to możliwe, ale nie czekaj na idealne narzędzia. Eksportuj konfiguracje, wykonuj zrzuty ekranu, zapisuj ustawienia polityk i rejestruj zgłoszenia zmian.

Dla każdego wyjątku utwórz zapis ryzyka z datą wygaśnięcia. Dla każdego odstępstwa utwórz zgłoszenie działań naprawczych.

Dni 61 do 90: monitoruj, raportuj i doskonal

Przeprowadź przegląd konfiguracji. Pobierz próbkę obejmującą jeden serwer, jeden punkt końcowy, jedno urządzenie sieciowe i jedno środowisko chmurowe. Porównaj rzeczywiste ustawienia z zatwierdzoną konfiguracją bazową. Udokumentuj odstępstwa i działania korygujące.

Zaraportuj zgodność z konfiguracją bazową kierownictwu. Zaktualizuj Deklarację stosowania i plan postępowania z ryzykiem. Powtarzające się odstępstwa skieruj do analizy przyczyny źródłowej. Jeżeli błędna konfiguracja spowodowała incydent albo się do niego przyczyniła, zaktualizuj właściwą konfigurację bazową w ramach wniosków po incydencie.

Daje to audytorom coś testowalnego, regulatorom coś zrozumiałego, a kierownictwu coś, czym można zarządzać.

Myśl końcowa: bezpieczna konfiguracja to cyberhigiena poparta dowodami

NIS2 posługuje się językiem środków zarządzania ryzykiem cyberbezpieczeństwa i podstawowej cyberhigieny. DORA używa języka ryzyka ICT, odporności, monitorowania, ciągłości działania i testowania. GDPR używa języka odpowiednich środków i rozliczalności. ISO/IEC 27001:2022 używa języka postępowania z ryzykiem, zabezpieczeń, udokumentowanej informacji, oceny wyników i ciągłego doskonalenia.

Bezpieczne konfiguracje bazowe łączą je wszystkie.

Pokazują, że systemy nie są wdrażane z niezabezpieczonymi ustawieniami domyślnymi. Pokazują, że zmiany są kontrolowane. Pokazują, że dryf konfiguracji jest wykrywany. Pokazują, że wyjątki są objęte akceptacją ryzyka. Pokazują, że dowody istnieją, zanim zapyta o nie audytor.

Co najważniejsze, ograniczają realne ryzyko operacyjne. Piątkowa reguła zapory sieciowej, publiczny zasobnik chmurowy, zapomniane ustawienie SMBv1, domyślne hasło IoT i nierejestrowana konsola administracyjna nie są teoretycznymi ustaleniami z audytu. Są praktycznymi punktami nieskuteczności.

Clarysec pomaga organizacjom przekształcić te punkty nieskuteczności w kontrolowane, monitorowane i audytowalne konfiguracje bazowe.

Następne kroki

Jeżeli Twoja organizacja musi wykazać bezpieczną konfigurację dla ISO/IEC 27001:2022, cyberhigieny NIS2, zarządzania ryzykiem ICT w DORA, rozliczalności GDPR albo zapewnienia dla klientów, zacznij od zestawu narzędzi Clarysec:

• Użyj Zenith Blueprint: 30-etapowej mapy drogowej audytora, aby wdrożyć zarządzanie konfiguracją w fazie Kontrole w działaniu, krok 19, i zweryfikować je w fazie Audyt, przegląd i doskonalenie, krok 24.
• Użyj Zenith Controls: Przewodnika zgodności krzyżowej, aby zmapować zarządzanie konfiguracją na wspierające zabezpieczenia ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 i metodyki audytu.
• Użyj polityk Clarysec, takich jak Polityka bezpieczeństwa informacji, Polityka korzystania z chmury, Polityka audytu i monitorowania zgodności, Polityka zarządzania podatnościami i poprawkami, Polityka bezpieczeństwa sieci - MŚP, Polityka ochrony punktów końcowych przed złośliwym oprogramowaniem - MŚP oraz Polityka bezpieczeństwa Internetu Rzeczy (IoT) / technologii operacyjnej (OT) - MŚP, aby definiować, egzekwować i dokumentować dowodowo wymagania konfiguracji bazowej.

Bezpieczna konfiguracja bazowa nie jest tylko listą kontrolną utwardzania. Jest dowodem, że organizacja wie, jak wygląda stan bezpieczny, stosuje go konsekwentnie i potrafi to wykazać wtedy, gdy ma to znaczenie.