Bezpieczny stan bazowy to moment. Kontrola zmian to proces.
W poprzednim wpisie z serii NIS 2 skupiliśmy się na bezpiecznych zakupach i bezpiecznym wytwarzaniu systemów. Pokazaliśmy, że bezpieczeństwo zaczyna się dużo wcześniej niż na etapie eksploatacji.
Dziś idziemy krok dalej.
Nawet najlepiej zaprojektowany i bezpiecznie pozyskany system bardzo szybko traci swoją odporność, jeśli nikt nie pilnuje tego, jak wygląda jego konfiguracja i co się z nią dzieje w czasie.
Dlatego ENISA w rozdziałach 6.3 Configuration Management oraz 6.4 Change Management, Repairs and Maintenance traktuje te dwa obszary jako nierozerwalną całość.
1. Konfiguracja jako fundament bezpieczeństwa
Z perspektywy NIS 2 konfiguracja to nie jest lista ustawień technicznych.
To formalnie zdefiniowany, udokumentowany i monitorowany stan bazowy, który ma bezpośredni wpływ na poufność, integralność i dostępność systemów.
ENISA oczekuje, że organizacja:
- jasno określi, jak powinien wyglądać bezpieczny stan początkowy systemów,
- udokumentuje konfiguracje sprzętu, oprogramowania, usług i sieci,
- będzie w stanie wykazać, że konfiguracja jest spójna z politykami bezpieczeństwa i oceną ryzyka.
Konfiguracja obejmuje m.in.:
- uprawnienia użytkowników i kont technicznych,
- ustawienia usług, portów, protokołów i połączeń zdalnych,
- mechanizmy kryptograficzne,
- logowanie i audyt,
- harmonogramy kopii zapasowych i procedury odtwarzania.
To właśnie na tym etapie zapada decyzja, czy system jest domyślnie bezpieczny, czy tylko „działa”.
2. Bezpieczna konfiguracja to proces, nie dokument na półce
ENISA bardzo wyraźnie podkreśla, że konfiguracja musi być:
- wdrożona, a nie tylko opisana,
- egzekwowana technicznie, najlepiej centralnie,
- regularnie weryfikowana.
Dobra praktyka to stosowanie:
- mechanizmów hardeningu opartych o standardy i wytyczne producentów,
- automatyzacji konfiguracji i monitorowania odchyleń,
- bazowych konfiguracji oddzielnych dla środowisk produkcyjnych, testowych i deweloperskich.
Każde odstępstwo od konfiguracji bazowej powinno być świadomą decyzją, a nie efektem przypadku, pośpiechu lub braku kontroli.
3. Zmiana jest nieunikniona, chaos nie
I tu naturalnie przechodzimy do drugiej strony tej samej monety, czyli zarządzania zmianą.
Systemy się zmieniają.
Pojawiają się poprawki, nowe funkcjonalności, awarie, incydenty, wymagania biznesowe.
NIS 2 nie próbuje tego zatrzymać.
Próbuje to ucywilizować.
Zarządzanie zmianą według ENISA oznacza, że każda zmiana:
- ma swój wniosek i uzasadnienie,
- jest poprzedzona oceną ryzyka,
- ma określony wpływ na bezpieczeństwo,
- jest zatwierdzona przed wdrożeniem,
- jest udokumentowana po wdrożeniu.
Dotyczy to zarówno planowanych aktualizacji, jak i zmian awaryjnych.
4. Zmiany awaryjne też podlegają zasadom
Jednym z częstszych błędów organizacji jest przekonanie, że w sytuacji awaryjnej „procedury nie obowiązują”.
ENISA mówi jasno:
jeśli standardowy proces zmiany nie mógł być zastosowany, trzeba to udokumentować.
Zmiana awaryjna nadal wymaga:
- zapisu powodów odstępstwa,
- wskazania osoby decyzyjnej,
- planu cofnięcia zmiany,
- analizy ryzyka po fakcie.
To właśnie te momenty są później najczęściej analizowane przez audytorów i organy nadzorcze.
5. Konfiguracja i zmiana muszą się widzieć
Kluczowy element NIS 2 to spójność.
Zarządzanie konfiguracją i zarządzanie zmianą nie mogą istnieć jako dwa odrębne światy.
Każda zmiana:
- powinna aktualizować konfigurację bazową,
- musi być widoczna w rejestrach i logach,
- powinna być uwzględniona w kolejnych przeglądach konfiguracji.
Bez tego konfiguracja „rozjeżdża się” w czasie, a organizacja traci kontrolę nad rzeczywistym stanem systemów.
6. Przeglądy i ciągłość kontroli
ENISA oczekuje regularnych przeglądów obu obszarów:
- konfiguracje powinny być weryfikowane cyklicznie oraz po incydentach,
- procedury zmian powinny być przeglądane co najmniej co dwa lata,
- wyniki przeglądów muszą prowadzić do realnych korekt, a nie tylko raportów.
To mechanizm ciągłego utrzymywania odporności, a nie jednorazowy projekt wdrożeniowy.
Co dalej w serii NIS 2?
W kolejnym wpisie przejdziemy do obszarów, które bezpośrednio weryfikują skuteczność konfiguracji i zmian w praktyce:
6.5 Security Testing
6.6 Security Patch Management
Czyli testy bezpieczeństwa i zarządzanie poprawkami jako realny sprawdzian tego, czy nasze procedury faktycznie działają.
Twoje bezpieczeństwo to nasza pasja! 🌐 Jeśli interesuje Cię ochrona danych osobowych, bezpieczeństwo informacji czy cyberbezpieczeństwo, zajrzyj na stronę CAB oraz Platformę Cyberbezpieczeństwa. Szukasz informacji o ochronie sygnalistów? 📢 Sprawdź stronę Kanału Zgłoszeniowego. Czekają tam praktyczne porady i ekspercka wiedza!