Regulacje cyberbezpieczeństwa w praktyce firmy

Regulacje cyberbezpieczeństwa: jak zamienić wymagania NIS2, DORA i KSC w kontrolę ryzyka, dowody zgodności i działania naprawcze w firmie bez chaosu.

W organizacji regulowanej problem zwykle nie zaczyna się od braku polityki bezpieczeństwa. Zaczyna się wtedy, gdy zarząd pyta, które systemy mogą zatrzymać usługę lub produkcję, ile krytycznych luk pozostaje otwartych po terminie i czy firma potrafi udowodnić regulatorowi skuteczność swoich kontroli. Regulacje cyberbezpieczeństwa podnoszą poprzeczkę właśnie w tym miejscu: wymagają nie deklaracji, lecz zarządzalnego procesu, przypisanej odpowiedzialności i dowodów wykonania.

Dla banku, zakładu produkcyjnego, operatora usług kluczowych czy podmiotu publicznego zgodność nie jest osobnym projektem compliance. Jest sposobem zarządzania ciągłością działania. NIS2, DORA, krajowe przepisy dotyczące krajowego systemu cyberbezpieczeństwa oraz normy takie jak ISO 27001 mają różny zakres, ale prowadzą do podobnego pytania: czy organizacja zna swoją ekspozycję, potrafi ograniczyć ryzyko i zareagować pod presją czasu?

Regulacje cyberbezpieczeństwa to obowiązki operacyjne

Najczęstszym błędem jest traktowanie regulacji jako listy dokumentów do przygotowania przed audytem. Polityki, procedury i rejestry są potrzebne, lecz same nie zatrzymają ataku ransomware, nie odetną nieautoryzowanego dostępu do sieci OT i nie skrócą czasu obsługi incydentu. Audytor lub regulator będzie oczekiwał zgodności między tym, co opisano w dokumentacji, a tym, co faktycznie dzieje się w środowisku.

Jeżeli procedura zarządzania podatnościami wskazuje krytyczne SLA, organizacja powinna pokazać kompletne źródła wykrywania podatności, sposób ich oceny, właścicieli zasobów, decyzje o akceptacji ryzyka oraz potwierdzenia zamknięcia luk. Jeżeli plan reagowania na incydent przewiduje eskalację do zarządu, potrzebne będą dowody ćwiczeń, logi działań i mierniki czasu reakcji. To właśnie różnica między dokumentacją formalnie poprawną a systemem zarządzania bezpieczeństwem, który działa.

W praktyce wymagania regulacyjne można uporządkować wokół pięciu obszarów: inwentaryzacji aktywów i usług krytycznych, oceny ryzyka, kontroli technicznych i organizacyjnych, zarządzania dostawcami oraz obsługi i raportowania incydentów. Każdy z nich musi mieć właściciela, rytm przeglądów oraz mierzalny rezultat.

NIS2, DORA i KSC: podobny kierunek, różne akcenty

Nie istnieje jedna uniwersalna checklista dla wszystkich podmiotów. Zakres obowiązków zależy od sektora, rodzaju świadczonych usług, roli w łańcuchu dostaw oraz krajowych przepisów wdrażających wymagania unijne. Dlatego pierwszym krokiem nie powinno być kopiowanie kontroli z innej organizacji, ale ustalenie, które regulacje mają zastosowanie i gdzie znajdują się granice odpowiedzialności.

NIS2 koncentruje się na podmiotach z sektorów kluczowych i ważnych oraz na zarządzaniu ryzykiem cybernetycznym na poziomie organizacji. Szczególne znaczenie mają odpowiedzialność kierownictwa, bezpieczeństwo łańcucha dostaw, obsługa incydentów, ciągłość działania i środki ochrony stosowane adekwatnie do ryzyka. Dla wielu firm oznacza to konieczność wyjścia poza ochronę infrastruktury IT i objęcie kontrolą środowisk chmurowych, aplikacji biznesowych, usług zewnętrznych oraz OT/ICS.

DORA dotyczy sektora finansowego i jego odporności operacyjnej. Wymaga spójnego zarządzania ryzykiem ICT, testowania odporności cyfrowej, kontrolowanego raportowania incydentów oraz nadzoru nad dostawcami technologii. W tym modelu kluczowe nie jest wyłącznie pytanie, czy dostawca podpisał odpowiednie zobowiązania. Trzeba także ocenić koncentrację usług, możliwość zastąpienia dostawcy, warunki dostępu do danych, scenariusze awarii i realną wykonalność planu wyjścia.

Przepisy KSC i ich ewolucja w związku z wdrażaniem NIS2 są szczególnie istotne dla podmiotów infrastruktury krytycznej, administracji i dostawców usług kluczowych. W tych środowiskach konsekwencje incydentu często wykraczają poza straty finansowe. Przestój może zakłócić dostawy energii, produkcję, usługi publiczne lub procesy logistyczne. Dlatego ocena ryzyka musi uwzględniać zależności między systemami, dostęp zdalny serwisantów i segmentację sieci przemysłowej.

Od mapy wymagań do kontrolowanej remediacji

Projekt zgodności warto rozpocząć od diagnozy, która łączy perspektywę prawną, procesową i techniczną. Sama analiza luk względem regulacji wskazuje, czego brakuje w dokumentacji. Nie odpowie jednak, czy aktywne podatności, błędne konfiguracje tożsamości lub niekontrolowane połączenia z siecią OT stwarzają ryzyko nieakceptowalne dla organizacji.

Dobra ocena stanu obecnego powinna zestawić wymagania z rzeczywistymi dowodami: konfiguracją, wynikami skanów, raportami z pentestów, logami SOC, rejestrami zmian, umowami z dostawcami i zapisami ćwiczeń. Następnie należy przypisać braki do usług biznesowych oraz scenariuszy ryzyka. Krytyczna luka w systemie odizolowanym wymaga innej reakcji niż podatność o podobnej ocenie technicznej w systemie obsługującym płatności, sterowanie linią produkcyjną lub dane wrażliwe.

To pozwala prowadzić triage według SLA i wpływu biznesowego, zamiast budować niekończącą się listę zadań dla IT. Plan remediacji powinien wskazywać właściciela działania, termin, zależności, wymagane okno serwisowe, sposób walidacji oraz decyzję na wypadek, gdy usunięcie podatności nie jest od razu możliwe. Wtedy akceptacja ryzyka ma uzasadnienie, termin wygaśnięcia i zestaw kontroli kompensacyjnych, a nie postać nieformalnego wyjątku.

Dowody muszą powstawać w trakcie pracy

Najdroższym wariantem jest odtwarzanie dowodów kilka tygodni przed audytem. Zespoły szukają wtedy potwierdzeń w skrzynkach pocztowych, arkuszach i zamkniętych zgłoszeniach, a niepełne dane rodzą kolejne ryzyko. Znacznie skuteczniejszy jest model, w którym dowody procesów są wytwarzane automatycznie w ramach zwykłej pracy operacyjnej.

Przykładowo, system zgłoszeniowy może dokumentować klasyfikację podatności, zgodę właściciela usługi na termin naprawy i potwierdzenie retestu. SOC może dostarczać raporty dotyczące pokrycia źródeł logów, czasu detekcji i eskalacji. Zespół zarządzający dostawcami może utrzymywać ocenę krytyczności, wyniki weryfikacji i terminy przeglądów. Zarząd otrzymuje wtedy obraz ryzyka oparty na wskaźnikach, a nie na deklaracji, że działania są realizowane.

Zarząd odpowiada za decyzje, nie za konfigurację firewalla

Regulacje wzmacniają odpowiedzialność kadry zarządzającej, ale nie oznacza to, że członkowie zarządu mają oceniać reguły zapory sieciowej. Ich zadaniem jest zatwierdzenie apetytu na ryzyko, zapewnienie zasobów, rozstrzyganie konfliktów priorytetów oraz nadzór nad realizacją programu.

Raportowanie do zarządu powinno być krótkie, porównywalne w czasie i osadzone w skutkach biznesowych. Liczba wszystkich alertów SOC ma ograniczoną wartość. Więcej mówi udział krytycznych aktywów objętych monitoringiem, liczba podatności krytycznych po SLA, czas ograniczenia incydentu, odsetek dostawców wysokiego ryzyka po ocenie czy wyniki ćwiczeń odtworzeniowych.

Ważne są również decyzje, które nie zostały podjęte. Jeżeli konieczna segmentacja sieci wymaga przestoju, a organizacja odkłada projekt bez kontroli kompensacyjnych, ryzyko powinno zostać przedstawione i formalnie zaakceptowane na właściwym poziomie. Taka transparentność chroni zarówno biznes, jak i osoby odpowiedzialne za nadzór.

Szczególne ryzyka: chmura, dostawcy i OT

Środowiska hybrydowe powodują, że granica organizacji przestaje pokrywać się z granicą jej sieci. Tożsamość uprzywilejowana w chmurze, konto serwisowe dostawcy, niewłaściwie skonfigurowane repozytorium danych lub integracja SaaS mogą mieć większe znaczenie niż klasyczny serwer w centrum danych. Kontrole powinny obejmować zarządzanie tożsamością, logowanie zdarzeń, szyfrowanie, kopie zapasowe, testy odtworzeniowe i okresową weryfikację konfiguracji.

W OT/ICS priorytety są inne niż w IT. Aktualizacja systemu sterowania może wymagać certyfikacji producenta, zatrzymania procesu lub być niemożliwa w krótkim terminie. Nie zwalnia to z obowiązku ograniczenia ryzyka. W takich przypadkach szczególnego znaczenia nabierają segmentacja, kontrola dostępu zdalnego, monitoring komunikacji przemysłowej, lista dopuszczonych połączeń i procedury reakcji uzgodnione z utrzymaniem ruchu.

Dostawcy wymagają równie praktycznego podejścia. Ankieta bezpieczeństwa jest przydatna, ale nie zastąpi oceny krytyczności usługi, zapisów umownych o incydentach, prawa do audytu, testowania planu ciągłości oraz kontroli dostępu. Im silniej firma zależy od jednego operatora chmury, integratora lub dostawcy oprogramowania, tym bardziej istotny jest realistyczny scenariusz awarii i wyjścia.

Pierwszym krokiem nie jest zakup kolejnego narzędzia ani przygotowanie obszernej polityki. Jest nim ustalenie, które usługi są krytyczne, jakie regulacje ich dotyczą, gdzie są największe braki dowodowe i które działania obniżą ryzyko w najbliższym kwartale. Dopiero na tej podstawie można zbudować program, który wytrzyma audyt, incydent i pytania zarządu.