Dlaczego „sprawdzamy” i „łatamy” zanim sprawdzi nas incydent
W poprzednim wpisie serii NIS 2 pisaliśmy o bezpiecznej konfiguracji i zarządzaniu zmianą. O tym, jak ustalić bezpieczny stan bazowy systemów i jak go nie rozmontować każdą kolejną zmianą.
Ten tekst idzie krok dalej.
Bo nawet najlepiej zaprojektowany i skonfigurowany system starzeje się w dniu uruchomienia. Pojawiają się nowe podatności, nowe techniki ataku, nowe zależności.
Dlatego ENISA w NIS 2 bardzo wyraźnie rozdziela dwa, ale ściśle powiązane obszary:
- testowanie bezpieczeństwa, czyli sprawdzanie, czy nasze założenia nadal działają,
- zarządzanie poprawkami, czyli reagowanie na to, co testy i rynek ujawniają.
To nie są działania „techniczne dla IT”. To mechanizmy utrzymania odporności organizacji w czasie.
Testowanie bezpieczeństwa – nie audyt, tylko stały proces
ENISA nie traktuje testów jako jednorazowego wydarzenia ani „ćwiczenia pod audyt”. Testowanie ma być ciągłym procesem zarządczym, opartym na ryzyku.
Polityka testów jako punkt wyjścia
Każda organizacja objęta NIS 2 powinna posiadać formalną politykę testowania bezpieczeństwa, która określa:
- jakie systemy i procesy podlegają testom,
- jak często są testowane,
- jakie typy testów są stosowane,
- kto odpowiada za ich realizację i akceptację wyników.
Skala i dojrzałość programu testów powinna być proporcjonalna do wielkości organizacji, krytyczności usług i profilu ryzyka. ENISA wyraźnie zaznacza, że nie chodzi o „jak najdroższe testy”, tylko o adekwatne testy we właściwym miejscu.
Dobór testów na podstawie ryzyka
NIS 2 nie narzuca jednego typu testów. Wręcz przeciwnie, oczekuje świadomego wyboru spośród narzędzi takich jak:
- testy podatności,
- testy penetracyjne,
- przeglądy kodu,
- testy bezpieczeństwa aplikacji,
- ćwiczenia typu red team lub symulacje ataków,
- testy odporności procesów i reakcji organizacji.
Kluczowe jest to, że zakres i częstotliwość testów wynikają z oceny ryzyka, a nie z kalendarza audytowego.
Dokumentowanie i reagowanie na wyniki
Test, który nie kończy się decyzją, jest stratą czasu.
ENISA oczekuje, że organizacja:
- dokumentuje wyniki testów w sposób zrozumiały dla eksperta zewnętrznego,
- klasyfikuje podatności według krytyczności,
- przypisuje działania korygujące,
- aktualizuje ocenę ryzyka i plany postępowania z ryzykiem.
Szczególnie istotne jest zamykanie pętli zwrotnej: wnioski z testów muszą wracać do konfiguracji, zmian, szkoleń i procedur.
Zarządzanie poprawkami – decyzje, nie automatyzm
Jeżeli testowanie pokazuje, gdzie jesteśmy słabi, patch management odpowiada na pytanie: co z tym robimy i kiedy.
ENISA bardzo jasno odchodzi od myślenia „łatamy wszystko natychmiast”. Zamiast tego wymaga zarządzanego procesu decyzyjnego.
Procedura patchowania oparta na ryzyku
Organizacja powinna posiadać procedury, które określają:
- jak identyfikowane są nowe poprawki,
- jak oceniana jest ich krytyczność,
- w jakim czasie są wdrażane,
- jak są testowane przed wdrożeniem,
- jak dokumentowane są decyzje.
Poprawki muszą pochodzić z zaufanych źródeł, a ich integralność powinna być weryfikowana. W praktyce oznacza to kontrolę podpisów, certyfikatów i komunikatów producenta.
Testy, harmonogramy i strategie wdrożeń
ENISA wyraźnie wskazuje, że poprawki:
- powinny być testowane przed wdrożeniem na produkcji,
- muszą być spójne z procesem zarządzania zmianą,
- mogą być wdrażane różnymi strategiami, od stopniowych wdrożeń po pilne hotfixy.
Istotne jest też planowanie poprawek w kontekście ciągłości działania, a nie wyłącznie bezpieczeństwa technicznego.
Kiedy nie łatamy i dlaczego
NIS 2 dopuszcza sytuacje, w których poprawka nie jest wdrażana, ale pod jednym warunkiem:
decyzja musi być udokumentowana, uzasadniona i zarządzana.
Jeżeli ryzyko destabilizacji systemu jest wyższe niż ryzyko podatności, organizacja powinna:
- zastosować środki kompensacyjne,
- udokumentować ryzyko rezydualne,
- monitorować sytuację i wrócić do decyzji w odpowiednim momencie.
To bardzo ważny sygnał dla zarządów: brak patcha bez decyzji to błąd, brak patcha z decyzją może być świadomą strategią
Testy i poprawki jako jeden mechanizm
ENISA patrzy na testowanie i patchowanie jak na jeden zamknięty cykl:
- testy wykrywają słabości,
- poprawki je adresują,
- decyzje są dokumentowane,
- ryzyko jest aktualizowane,
- organizacja uczy się na własnych systemach.
To dokładnie ten moment, w którym cyberbezpieczeństwo przestaje być „projektem IT”, a staje się systemem zarządzania odpornością.
Co dalej w serii NIS 2
W kolejnym wpisie przejdziemy do obszarów ochrony infrastruktury w czasie rzeczywistym:
6.7 Network security
6.8 Network segmentation
Czyli o tym, jak projektować i utrzymywać sieć w sposób, który ogranicza skutki incydentów, zamiast je eskalować.
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!