NIS2 i ISO 27001: wykorzystaj kontrole ponownie, zbadaj luki

Program ISO 27001 może stanowić solidną strukturę operacyjną dla NIS2: ocenę ryzyka, odpowiedzialnych właścicieli, kontrole, dowody i doskonalenie. Kolejnym krokiem jest ocena, wymaganie po wymaganiu, tego, co ta struktura faktycznie obejmuje.

Dla CTO użyteczne pytanie nie brzmi, czy frameworki się pokrywają. Chodzi o to, czy wdrożona kontrola chroni właściwą usługę, spełnia mający zastosowanie obowiązek i dostarcza dowodów wspierających ten wniosek. Wykorzystuj wdrożenie ponownie tam, gdzie te warunki są spełnione; zachowuj różnice prawne i operacyjne tam, gdzie nie są.

Zrozum, co ustanawia każdy z frameworków

ISO/IEC 27001 określa wymagania dla systemu zarządzania bezpieczeństwem informacji (SZBI) o zdefiniowanym zakresie. Rozdziały 4–10 dotyczą jego struktury zarządczej, w tym postępowania z ryzykiem, oceny efektów działania i doskonalenia. Załącznik A zawiera 93 zabezpieczenia referencyjne w kategoriach organizacyjnych, osobowych, fizycznych i technologicznych. Stosowanie zabezpieczeń opiera się na ryzyku i nie oznacza wymogu identycznego wdrożenia każdego z nich. ISO 27002 zawiera wytyczne dotyczące wdrożenia.

NIS2 to dyrektywa UE wdrażana przez prawo krajowe. Jej stosowanie zależy od sektora, wielkości, usługi i szczególnych zasad objęcia. Załączniki I i II wskazują odpowiednie sektory, ale sam sektor nie przesądza o tym, czy organizacja jest podmiotem kluczowym, czy ważnym. Niektóre podmioty są objęte dyrektywą niezależnie od wielkości.

Praktyczne różnice są następujące:

Certyfikację przeprowadzają niezależne jednostki certyfikujące, a nie ISO. Nie przesądza ona o zgodności z NIS2, a NIS2 co do zasady nie wymaga certyfikacji ISO 27001. Egzekwowanie przepisów może obejmować środki nadzorcze i kary; certyfikacja ISO służy innemu celowi w zakresie zapewnienia.

Zacznij od dopasowania granic

Porównaj zakres certyfikowanego SZBI z podmiotami prawnymi i usługami podlegającymi NIS2. Certyfikat obejmujący zespół deweloperski może pozostawiać poza swoją granicą operacje produkcyjne, inną spółkę zależną lub dodatkowe lokalizacje.

Przygotuj porównanie zakresów zawierające:

• Objęte podmioty prawne, kraje, usługi i podstawę ich objęcia.
• Odpowiednie systemy, sieci, lokalizacje i wspierających dostawców.
• Zakres SZBI, zakres certyfikatu i wyłączenia.
• Mające zastosowanie wymogi krajowe, przepisy sektorowe i właściwe organy, w tym obowiązki rejestracyjne, wymagane informacje o podmiocie, kanały składania dokumentów i obowiązki aktualizacji.
• Kto zatwierdził ocenę stosowania i kiedy należy ją ponownie przeanalizować.

Odróżniaj lukę w zakresie od luki w kontrolach. Środowisko produkcyjne spoza SZBI może już mieć dobre kontrole dostępu, ale te kontrole nadal wymagają właściciela, oceny i dowodów w ramach prac nad NIS2.

Sprawdź przepisy sektorowe, zanim zaczniesz powielać obowiązki. Art. 4 dotyczy relacji z sektorowymi aktami prawnymi UE. W przypadku podmiotów finansowych relacja z DORA wymaga analizy właściwej dla roli. W przypadku działalności w Niemczech zapoznaj się z informacjami BSI dotyczącymi NIS2, zamiast zakładać, że istniejące obowiązki KRITIS (dotyczące infrastruktury krytycznej) i obowiązki wynikające z NIS2 są identyczne.

Mapuj wdrożone kontrole, a nie pasujące etykiety

Art. 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych. Dziesięć obszarów środków minimalnych stanowi punkt wyjścia do mapowania, ale podobne brzmienie jest użyteczną wskazówką, a nie dowodem równoważności.

Traktuj poniższe zestawienie jako punkty do przeglądu, a nie automatyczne deklaracje pokrycia:

Deklaracja stosowania dokumentuje niezbędne zabezpieczenia oraz uzasadnienie ich włączenia lub wyłączenia. Nie jest wymienna z planem postępowania z ryzykiem, ustaleniami z audytu wewnętrznego ani zapisami z przeglądu zarządzania. Korzystaj z tych artefaktów łącznie, aby wyjaśnić zarówno projekt, jak i działanie.

Polityka ustanawia oczekiwania. Eksport konfiguracji może pokazać wdrożenie. Wyniki przeglądów uprawnień, zgłoszenia naprawcze i zapisy z testów mogą pokazać działanie. Wykorzystuj dowody ponownie tylko wtedy, gdy system, okres i cel oceny są zgodne.

Unikaj stałych procentów pokrycia. Pokrycie zależy od wdrożenia i zakresu prawnego; uniwersalna liczba nie może dowodzić gotowości.

Zbuduj ścieżkę zgłaszania incydentów, która zadziała pod presją

Plan reagowania zgodny z ISO może wspierać wykrywanie, ograniczanie skutków, dochodzenie i odtwarzanie, nie definiując zgłoszeń regulacyjnych. Art. 23 NIS2 dodaje obowiązki zgłaszania poważnych incydentów.

Etapy zgłaszania przewidziane w dyrektywie co do zasady obejmują:

• Wczesne ostrzeżenie bez zbędnej zwłoki, w ciągu 24 godzin od uzyskania wiedzy o poważnym incydencie.
• Zgłoszenie incydentu bez zbędnej zwłoki, w ciągu 72 godzin, aktualizujące wczesne ostrzeżenie i zawierające wstępną ocenę.
• Sprawozdanie końcowe co do zasady w ciągu miesiąca od przekazania zgłoszenia incydentu. W przypadku trwającego incydentu w tym terminie wymagane jest sprawozdanie z postępów, a sprawozdanie końcowe należy przekazać w ciągu miesiąca od zakończenia obsługi incydentu.

Na wniosek zespołu CSIRT lub właściwego organu należy także przekazać sprawozdanie okresowe.

Sprawdź obowiązujące przepisy krajowe i sektorowe: dyrektywa przewiduje inne terminy zgłaszania dla dostawców usług zaufania. Nie stosuj ogólnego progu awarii jako zamiennika mających zastosowanie kryteriów poważnego incydentu.

Jako praktyczną rekomendację wdrożeniową przygotuj runbook zgłoszeniowy określający osobę odpowiedzialną za ocenę, ścieżkę eskalacji, osobę upoważnioną do składania zgłoszeń, osoby zastępcze, kanał kontaktu z organem oraz informacje potrzebne na każdym etapie. Odrębnie rejestruj znaczniki czasu wykrycia, uzyskania wiedzy, oceny wagi incydentu i złożenia zgłoszenia.

Przećwicz proces przy niepełnych informacjach. Zespół powinien być w stanie złożyć wymagane zgłoszenie wstępne bez czekania na zakończenie dochodzenia kryminalistycznego. Zachowuj złożone wersje, potwierdzenia, fakty uzasadniające i decyzje o tym, czy incydent przekracza próg.

Jeśli ma zastosowanie również inny reżim zgłaszania, koordynuj dochodzenie, ale oceniaj każdy obowiązek zgłoszenia oddzielnie. Wspólny zapis incydentu nie sprawia, że adresaci, przesłanki czy terminy są identyczne.

Spraw, by zarządzanie i odporność dało się wykazać

Art. 20 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem w cyberbezpieczeństwie i nadzorowały ich wdrażanie. Dotyczy również szkoleń członków organów zarządzających. Istniejący przegląd zarządzania jest użytecznym dowodem, ale sprawdź, czy wyraźnie dokumentuje odpowiednie zatwierdzenia, nadzór, decyzje i działania następcze.

Przedstaw kierownictwu widok pozwalający podejmować decyzje: usługi, których dotyczy, istotne ryzyka, opcje postępowania, nierozwiązane wyjątki i wyniki oceny skuteczności. Protokoły ze spotkań stwierdzające jedynie, że „omówiono bezpieczeństwo”, stanowią słaby dowód rzeczywistego nadzoru. Przypisz każdemu zatwierdzonemu działaniu właściciela i termin przeglądu.

Ciągłość działania wymaga podobnie konkretnego podejścia. Art. 21 obejmuje kopie zapasowe, przywracanie sprawności po katastrofie i zarządzanie kryzysowe; nie nakłada uniwersalnego wymogu certyfikacji ISO 22301. Określ niezbędną głębokość na podstawie usługi, ryzyk i mających zastosowanie przepisów.

Testuj odtwarzanie danych i usług, a nie tylko zakończenie zadań tworzenia kopii zapasowych. Uwzględnij zależności, takie jak usługi tożsamości, DNS, wsparcie dostawców, uprzywilejowane dane uwierzytelniające i komunikacja, na wypadek gdyby normalne środowisko było niedostępne. Rejestruj osiągnięte wyniki odtworzenia i nierozwiązane przeszkody w odniesieniu do uzgodnionych celów.

Prowadź widoczny rejestr różnic

Dla każdego wymagania zapisz jego źródło i wersję, zmapowane kontrole, zakres, odniesienia do dowodów, recenzenta i uzasadnienie ponownego wykorzystania. Rozróżniaj pokrycie poparte dowodami, pokrycie częściowe, brak wdrożenia, brak dowodów i uzasadnioną decyzję o niestosowaniu. Brak dokumentu nie zawsze oznacza brak kontroli, ale zawsze wymaga zbadania.

Każda luka potrzebuje właściciela, wymaganej zmiany, oczekiwań co do dowodów, terminu i recenzenta zamknięcia. Priorytetowo traktuj niedociągnięcia zagrażające usługom lub uniemożliwiające terminowe zgłaszanie, zamiast traktować każde zadanie dokumentacyjne jako równie pilne.

Typowe błędy to mapowanie wyłącznie załącznika A przy pominięciu wymagań dotyczących zarządzania, akceptowanie certyfikatu dostawcy bez sprawdzenia jego zakresu, traktowanie zeszłorocznych dowodów jako aktualnych oraz zamykanie zadania po opublikowaniu polityki, mimo że proces nie został przetestowany. Rejestracji ani certyfikacji nigdy nie należy traktować jako dowodu wdrożenia operacyjnego.

Przykład: rozszerzenie istniejącego SZBI

Założenia poglądowe: dostawca usług zarządzanych ma certyfikowany SZBI zgodny z ISO 27001, obejmujący jego główny zespół operacyjny. Ocena stosowania wykazuje, że usługa świadczona przez dodatkowy podmiot prawny podlega NIS2. Podmiot ten korzysta z tej samej platformy tożsamości i tego samego zespołu ds. incydentów, ale ma odrębne rozwiązania w zakresie odtwarzania.

Zespół najpierw porównuje granice usług. Istniejące konfiguracje uwierzytelniania mogą wspierać oba zakresy, ale recenzent sprawdza, czy uwzględniono administratorów, konta awaryjne i konta usługowe dodatkowego podmiotu. Eksport z przeglądu uprawnień obejmujący wyłącznie pierwotny zespół nie może dowodzić pełnego pokrycia.

Następnie właściciel procesu obsługi incydentów zachowuje ustaloną procedurę reagowania i dodaje ocenę poważnego incydentu oraz ścieżkę zgłoszenia do organu. Ćwiczenie sztabowe symuluje awarię u dostawcy o niepewnym wpływie na klientów. Uczestnicy zapisują, kiedy uzyskali wiedzę o istotnych faktach, kto zdecydował o wadze incydentu i w jaki sposób zostałoby złożone wczesne ostrzeżenie.

Na koniec właściciel infrastruktury przeprowadza ćwiczenie odtworzeniowe dla usługi dodatkowego podmiotu. Test ujawnia, że dane uwierzytelniające do odtwarzania zależą od niedostępnej platformy tożsamości. Rejestr luk przypisuje działanie korygujące i wymaga udanego ponownego testu przed zamknięciem.

Powstałe produkty to porównanie zakresów, zweryfikowane mapowania, rozszerzone dowody z przeglądów uprawnień, zapisy z ćwiczeń zgłaszania, wyniki odtworzenia oraz zatwierdzenie przez kierownictwo pozostałych działań w zakresie postępowania z ryzykiem. Wspólne kontrole pozostają wspólne; dowody i decyzje właściwe dla podmiotu pozostają widoczne.

Przekształć ocenę w utrzymywaną pracę

Powiązany model wymagań i dowodów w Secani zapewnia zespołom strukturę do zachowania wspólnej pracy i decyzji właściwych dla poszczególnych frameworków. Zamodeluj usługi i zależności, powiąż istniejące dowody z odpowiednimi kontrolami i przekształć brakujące pokrycie w zadania z przypisanym właścicielem. Utrzymuj wyraźne zatwierdzanie przez człowieka w przypadku mapowań i wniosków dotyczących dowodów, w tym sugestii wspieranych przez AI. Nasz przewodnik po identyfikowalnym mapowaniu między frameworkami wyjaśnia, jak zachować uzasadnienie ponownego wykorzystania.

Zacznij od jednej usługi regulowanej. Uwzględnij jej zakres, postępowanie z ryzykiem, deklarację stosowania, runbook dotyczący incydentów i najnowsze dowody z testów we wspólnym przeglądzie technicznym i compliance. Przygotuj zweryfikowany rejestr różnic, a następnie wykorzystuj zwykłe cykle przeglądu SZBI do jego utrzymywania w miarę zmian usług, dostawców i wymagań.