Security Controls NIS2 i DORA: jak zbudować wielowarstwowe cyberbezpieczeństwo w firmie?

Od ryzyka do kontroli: jak nie zgubić celu bezpieczeństwa?

Kontrola bezpieczeństwa powinna odpowiadać konkretnemu ryzyku. Zanim firma kupi kolejne narzędzie, warto ustalić, jakie aktywa chroni, przed jakim scenariuszem i jak sprawdzi skuteczność zabezpieczenia. Taki model jest wspólny dla KSC/NIS2 i DORA, mimo różnic w zakresie podmiotowym regulacji.

Pomocna jest triada CIA: poufność, integralność i dostępność. Dla systemu płatniczego najważniejsza może być ciągłość i integralność transakcji, a dla bazy dokumentacji – także poufność. Priorytet kontroli wynika z konsekwencji awarii, nie z popularności produktu.

Warstwa 1: tożsamość, MFA i uprawnienia uprzywilejowane

Przejęcie konta pozostaje jednym z najczęstszych sposobów wejścia do organizacji. Dlatego MFA, zasada najmniejszych uprawnień, osobne konta administracyjne i cykliczny przegląd dostępów stanowią podstawę ochrony. Szczególnej kontroli wymagają konta techniczne, tokeny API i sekrety.

Warto mierzyć pokrycie MFA, liczbę kont uprzywilejowanych, kont nieużywanych i wyjątki od polityki. Wtedy zarząd otrzymuje informację o faktycznym stanie, a nie deklarację, że „mamy system IAM”.

Warstwa 2: segmentacja sieci i ograniczenie ruchu bocznego

Płaska sieć ułatwia atakującemu przemieszczanie się po przejęciu jednego urządzenia. Segmentacja oddziela użytkowników, serwery, urządzenia IoT, systemy administracyjne i strefy dostępne z internetu. Reguły powinny opierać się na potrzebie komunikacji, nie na domyślnym zezwoleniu.

W środowisku chmurowym odpowiednikiem są polityki sieciowe, grupy bezpieczeństwa, tożsamości usług i kontrola ścieżek administracyjnych. Segmentację trzeba testować, ponieważ dokument architektury może różnić się od rzeczywistej konfiguracji po kilku latach zmian.

Warstwa 3: endpointy, serwery i aktualizacje

Stacje robocze i serwery wymagają ujednoliconego zarządzania konfiguracją, aktualizacjami i ochroną przed złośliwym oprogramowaniem. EDR pomaga wykrywać zachowania, ale nie zastępuje patch managementu ani ograniczenia uprawnień lokalnych administratorów.

Proces podatności powinien rozróżniać krytyczność systemu, ekspozycję i możliwość wykorzystania luki. Sama liczba CVE nie mówi zarządowi, które ryzyko wymaga natychmiastowej decyzji biznesowej.

Warstwa 4: ochrona danych i sekretów

Szyfrowanie w tranzycie i spoczynku ma sens tylko wtedy, gdy klucze są odpowiednio zarządzane. Dostęp do kopii zapasowych, repozytoriów, tokenów i haseł administracyjnych powinien być kontrolowany niezależnie od zwykłych kont użytkowników.

Klasyfikacja danych pomaga zdecydować, gdzie można je przechowywać i jakie zasady obowiązują przy udostępnianiu. W systemach AI do tej warstwy dochodzi kontrola danych wejściowych do modeli i ochrona przed przypadkowym ujawnieniem informacji w promptach.

Warstwa 5: logowanie, SIEM i zdolność wykrycia incydentu

Organizacja nie może reagować na zdarzenie, którego nie widzi. Logi powinny obejmować systemy tożsamości, urządzenia brzegowe, serwery, aplikacje krytyczne i usługi chmurowe. Potrzebna jest synchronizacja czasu i retencja odpowiadająca ryzyku.

Centralny SIEM nie jest celem samym w sobie. Trzeba zdefiniować scenariusze detekcji, progi alarmów, dyżury i sposób eskalacji. Skuteczność mierzy się tym, czy zespół potrafi wykryć i obsłużyć realistyczny scenariusz ataku.

Warstwa 6: kopie zapasowe i odtwarzanie

Kopia, której nie da się odtworzyć, nie jest zabezpieczeniem ciągłości. Strategia powinna uwzględniać kopie odseparowane od produkcji, ochronę przed usunięciem, różne typy danych oraz docelowe RPO i RTO dla kluczowych usług.

Test odtworzenia powinien obejmować proces biznesowy, a nie tylko uruchomienie maszyny. Po ransomware może się okazać, że system działa, ale brakuje kluczy, konfiguracji integracji albo zależnej bazy danych.

Warstwa 7: dostawcy ICT i zależności zewnętrzne

Chmura, operator SOC, dostawca ERP i firma serwisowa mogą mieć dostęp porównywalny z personelem wewnętrznym. Kontrole obejmują kwalifikację dostawcy, wymagania umowne, MFA, ograniczenie zdalnego dostępu, raportowanie incydentów i plan wyjścia.

W DORA zarządzanie ryzykiem dostawców ICT ma szczególnie rozwinięty charakter. W KSC/NIS2 łańcuch dostaw również jest elementem zarządzania ryzykiem. Jedna wspólna inwentaryzacja dostawców może więc wspierać oba reżimy.

Warstwa 8: testy, metryki i materiał audytowy

Ostatnia warstwa to możliwość wykazania, że środki działają. Przydatne są wyniki skanów, raporty z testów, dowody przeglądu dostępów, protokoły odtworzenia kopii, logi ćwiczeń incydentowych i decyzje o zaakceptowaniu ryzyka.

Nie chodzi o gromadzenie zrzutów ekranu bez końca. Dowód powinien odpowiadać kontroli i mieć określony okres ważności. Dzięki temu audyt nie zaczyna się od gorączkowego zbierania plików dzień przed kontrolą.

Jak zmapować Security Controls na KSC/NIS2 i DORA?

Najpierw tworzy się katalog kontroli technicznych i organizacyjnych, a następnie mapuje je do obowiązków regulacyjnych. Jedna kontrola – na przykład zarządzanie dostępem – może wspierać kilka wymagań. Różnice między reżimami zachowuje się w kolumnach dotyczących właściciela, częstotliwości i specyficznych dowodów.

Takie podejście łączy prawo z architekturą. Wsparcie w audytach i mapowaniu kontroli: Prawo nowych technologii. Wspólny katalog kontroli ułatwia również aktualizację wymagań, gdy zmienia się infrastruktura, dostawca albo zakres zastosowania konkretnej regulacji.

Zarządzanie podatnościami – od skanu do decyzji o ryzyku

Skaner może wygenerować tysiące wyników, ale organizacja potrzebuje procesu priorytetyzacji. Na pilność wpływają nie tylko punktacja CVSS, lecz także ekspozycja systemu, dostępny exploit, znaczenie aktywa i istniejące zabezpieczenia kompensujące.

Proces powinien obejmować termin usunięcia, właściciela, wyjątki oraz ponowną weryfikację po poprawce. Dla systemów, których nie można szybko załatać, trzeba zastosować kontrolę zastępczą i jawnie zaakceptować ryzyko na określony czas.

Reakcja na incydenty jako kontrola bezpieczeństwa

Nawet najlepsza prewencja nie eliminuje wszystkich incydentów. Organizacja potrzebuje ról, kanału alarmowego, dostępu awaryjnego i procedury współpracy z dostawcami. Plan powinien wskazywać, jakie dane trzeba zabezpieczyć i kto decyduje o izolacji systemu.

Ćwiczenia pokazują, czy monitoring jest użyteczny. Jeżeli alert zawiera za mało informacji do podjęcia decyzji albo trafia do osoby bez dyżuru, formalnie działający system nie zapewnia realnej zdolności reakcji.

Kontrole w chmurze: wspólna odpowiedzialność nie oznacza przeniesienia ryzyka

Dostawca chmury zabezpiecza określone warstwy infrastruktury, ale klient nadal odpowiada za konfigurację usług, tożsamości, dane i wiele ustawień sieciowych. Błędy w uprawnieniach lub publiczny storage mogą wynikać z konfiguracji klienta mimo wysokich certyfikatów dostawcy.

Warto utrzymywać baseline konfiguracji, automatyczne wykrywanie odchyleń i centralne logowanie. Przy wielu kontach chmurowych potrzebny jest wspólny model tożsamości oraz sposób kontrolowania wyjątków.

Metryki dla zarządu: jak mierzyć stan bezpieczeństwa bez fałszywego poczucia kontroli?

Liczba zablokowanych ataków nie mówi sama w sobie, czy organizacja jest bezpieczna. Bardziej użyteczne są wskaźniki pokrycia MFA, czasu usuwania krytycznych podatności, skuteczności odtworzenia kopii, liczby uprzywilejowanych kont i czasu reakcji na alert.

Metryka powinna prowadzić do decyzji. Jeżeli zarząd widzi, że tylko część systemów krytycznych trafia do centralnego monitoringu, może przydzielić budżet i termin na domknięcie luki. W ten sposób compliance staje się mechanizmem zarządzania, a nie raportem po fakcie.

Najczęstsze pytania