Jak przygotować firmę do NIS2 bez pozorów

Atak nie musi zacząć się od spektakularnego włamania do serwerowni. Częściej jego punktem wejścia jest przejęte konto dostawcy, niezałatana usługa chmurowa albo pracownik, który nie rozpoznał wiarygodnie wyglądającego phishingu. Dlatego pytanie, jak przygotować firmę do NIS2, nie powinno prowadzić do zakupu kolejnego narzędzia bezpieczeństwa. Najpierw wymaga ustalenia, czy przedsiębiorstwo podlega regulacji, kto w organizacji odpowiada za decyzje cyberbezpieczeństwa i czy potrafi wykazać, iż zarządza ryzykiem w sposób rzeczywisty, a nie deklaratywny.

NIS2 zmienia perspektywę prawną. Cyberbezpieczeństwo przestaje być wyłącznie zadaniem działu IT, a staje się elementem governance, ciągłości działania i odpowiedzialności kadry zarządzającej. Dla spółek technologicznych, fintechów, operatorów usług cyfrowych oraz podmiotów działających w rozbudowanych łańcuchach dostaw oznacza to konieczność połączenia oceny prawnej, technicznej i biznesowej.

Jak przygotować firmę do NIS2: zacząć od adekwatnej kwalifikacji

Dyrektywa NIS2 ustanawia unijne ramy, ale konkretne obowiązki przedsiębiorstwa wynikają z przepisów krajowych wdrażających dyrektywę. W Polsce najważniejsze znaczenie ma ustawa o krajowym systemie cyberbezpieczeństwa w jej aktualnym brzmieniu. Nie wystarczy więc przeczytać samej dyrektywy i założyć, iż firma jest lub nie jest objęta regulacją.

Pierwsza analiza powinna odpowiedzieć na trzy pytania: jaką usługę faktycznie świadczy spółka, w jakim sektorze działa oraz czy osiąga progi wielkościowe przewidziane dla danego rodzaju podmiotów. NIS2 obejmuje między innymi energetykę, transport, ochronę zdrowia, usługi cyfrowe, gospodarkę odpadami, produkcję określonych produktów, usługi pocztowe i kurierskie, a także podmioty infrastruktury cyfrowej. W praktyce kwalifikacja bywa trudniejsza niż wskazuje nazwa branży wpisana do rejestru przedsiębiorców.

Przykładowo spółka tworząca oprogramowanie dla klientów z sektora regulowanego nie staje się automatycznie podmiotem objętym NIS2. Sytuacja będzie jednak inna, gdy sama świadczy usługę zarządzaną, hostingową, chmurową, jest dostawcą usług DNS lub obsługuje infrastrukturę istotną dla innych przedsiębiorstw. Znaczenie może mieć również to, czy podmiot jest częścią grupy kapitałowej oraz w jaki sposób należy liczyć zatrudnienie i dane finansowe.

Nawet jeżeli firma formalnie nie jest adresatem obowiązków, NIS2 może oddziaływać na nią pośrednio. Klient objęty reżimem będzie oczekiwał audytów, wymagań umownych, informacji o incydentach i kontroli podwykonawców. Dla dostawcy SaaS lub software house’u dojrzałość cyberbezpieczeństwa coraz częściej staje się warunkiem kontraktowym, a nie wyłącznie przewagą marketingową.

Odpowiedzialność zarządu nie może być tylko formalna

NIS2 wzmacnia odpowiedzialność organów zarządzających za zatwierdzanie środków zarządzania ryzykiem cyberbezpieczeństwa i nadzorowanie ich wdrażania. Zarząd nie musi sam konfigurować systemów bezpieczeństwa. Musi natomiast rozumieć najważniejsze ryzyka, podjąć udokumentowane decyzje oraz zapewnić organizacji zasoby potrzebne do wykonania tych decyzji.

To wymaga wyznaczenia właścicieli konkretnych obszarów. Inaczej odpowiada osoba za bezpieczeństwo informacji, inaczej administrator infrastruktury, inaczej dział prawny, compliance, HR oraz właściciele procesów biznesowych. Największym problemem nie jest zwykle brak polityki, ale brak jasności, kto ma prawo zatrzymać wdrożenie produktu, odłączyć zagrożony system lub zawiadomić adekwatny organ o incydencie.

Warto przyjąć cykl raportowania do zarządu: katalog ryzyk, status działań naprawczych, wyniki testów, istotne zdarzenia oraz ryzyka związane z dostawcami. Raport powinien pozwalać na podjęcie decyzji, a nie być technicznym zestawieniem nieczytelnych wskaźników. Dobra praktyka to okresowe szkolenie członków zarządu i osób pełniących funkcje kierownicze, ponieważ decyzje biznesowe – na przykład o szybkim wdrożeniu usługi AI lub migracji do chmury – mogą istotnie zmienić profil ryzyka.

Audyt ryzyka przed zakupem narzędzi

Ocena ryzyka powinna dotyczyć nie tylko sieci i serwerów. Należy rozpoznać aktywa, bez których firma nie może realizować podstawowych usług: dane klientów, kod źródłowy, systemy produkcyjne, konta uprzywilejowane, urządzenia pracowników, środowiska chmurowe, kopie zapasowe oraz zależności od dostawców.

Następnie trzeba ustalić prawdopodobne scenariusze szkody. Dla kancelarii lub platformy legaltech szczególnie dotkliwy może być wyciek tajemnicy zawodowej i danych klientów. Dla fintechu krytyczne będą niedostępność systemu transakcyjnego, przejęcie tożsamości użytkownika albo manipulacja danymi. Dla producenta konsekwencją może być zatrzymanie systemów operacyjnych i przerwanie dostaw.

Rezultatem audytu ma być plan traktowania ryzyka. Część zagrożeń firma ograniczy technicznie, część zaakceptuje po świadomej decyzji biznesowej, a część przeniesie na dostawcę lub ubezpieczyciela. Przeniesienie ryzyka w umowie nie zwalnia jednak z obowiązku zweryfikowania, czy dostawca rzeczywiście zapewnia wymagany poziom ochrony.

Środki bezpieczeństwa powinny być proporcjonalne do skali działalności, wartości aktywów i potencjalnych skutków incydentu. W praktyce szczególnej uwagi wymagają co najmniej:

• zarządzanie dostępami, w tym uwierzytelnianie wieloskładnikowe i regularny przegląd uprawnień;
• aktualizacje, zarządzanie podatnościami oraz bezpieczne konfigurowanie środowisk IT i chmurowych;
• kopie zapasowe testowane pod kątem realnego odtworzenia, a nie tylko wykonywania;
• szyfrowanie, segmentacja sieci i monitorowanie zdarzeń bezpieczeństwa;
• zasady bezpiecznego wytwarzania oprogramowania, kontrola kodu i zarządzanie zależnościami open source;
• szkolenia pracowników oraz procedury reagowania na phishing i nadużycia wewnętrzne;
• plan ciągłości działania i odtwarzania po awarii;
• okresowe testy skuteczności przyjętych środków, w tym ćwiczenia reagowania na incydent.

Nie każda mała spółka potrzebuje od razu rozbudowanego centrum operacji bezpieczeństwa. Nie każda może też bezpiecznie ograniczyć się do zewnętrznego dostawcy. Wybór modelu zależy od krytyczności usługi, kompetencji zespołu i możliwości nadzoru nad usługodawcą.

Dostawcy są częścią powierzchni ataku

W wielu przedsiębiorstwach najważniejsze procesy realizują dostawcy chmury, systemów księgowych, CRM, poczty, płatności, narzędzi do zdalnej pracy i wsparcia IT. jeżeli firma nie wie, kto ma dostęp do jej danych lub infrastruktury, nie ma pełnego obrazu swojego ryzyka.

Umowy powinny określać nie tylko zakres usługi i odpowiedzialność finansową. Potrzebne są postanowienia o wymaganiach bezpieczeństwa, zgłaszaniu incydentów, współpracy przy ich obsłudze, podwykonawcach, lokalizacji danych, prawie audytu oraz obowiązku zwrotu lub usunięcia danych po zakończeniu współpracy. Warto przy tym unikać kopiowania ogólnych klauzul, które nie odpowiadają rzeczywistemu modelowi technicznemu dostawcy.

Szczególnej kontroli wymagają dostawcy z dostępem administracyjnym oraz podmioty przetwarzające dane o wysokiej wrażliwości. W ich przypadku warto sprawdzić, czy prowadzą własne testy bezpieczeństwa, jak zarządzają podatnościami i czy ich procedura powiadamiania nie jest ograniczona wyłącznie do nieprecyzyjnego zwrotu „bez zbędnej zwłoki”.

Incydent trzeba umieć zgłosić, zanim się wydarzy

Procedura reagowania nie może kończyć się na adresie e-mail do działu IT. Pracownik powinien wiedzieć, komu zgłosić podejrzenie incydentu, a zespół reagowania musi umieć gwałtownie ustalić jego skalę, zabezpieczyć dowody, ograniczyć skutki i podjąć decyzję o komunikacji.

NIS2 przewiduje model stopniowego raportowania poważnych incydentów, obejmujący wczesne ostrzeżenie, zgłoszenie oraz raport końcowy. Terminy i tryb trzeba każdorazowo odczytywać przez pryzmat krajowych przepisów wdrażających oraz adekwatności organu. Równolegle może powstać obowiązek oceny naruszenia ochrony danych osobowych na gruncie RODO, obowiązki kontraktowe wobec klientów albo obowiązki informacyjne wynikające z regulacji sektorowych.

Warto przeprowadzić ćwiczenie typu tabletop. Scenariusz może dotyczyć ransomware, wycieku repozytorium kodu lub przejęcia konta administratora chmury. Celem nie jest znalezienie winnego, ale sprawdzenie, czy organizacja potrafi podjąć decyzje pod presją czasu: kto kontaktuje się z dostawcą, kto ocenia obowiązek zgłoszenia, kto komunikuje się z klientami i kto zatwierdza treść komunikatu.

Plan przygotowania firmy do NIS2 na 90 dni

Pierwsze 30 dni warto przeznaczyć na kwalifikację prawną, inwentaryzację aktywów i dostawców oraz wskazanie właścicieli ryzyka. W kolejnym etapie należy wykonać analizę luk między obecnym stanem a wymaganym poziomem organizacyjnym i technicznym. Priorytet powinny otrzymać braki, które pozwalają na łatwe przejęcie kont uprzywilejowanych, utratę danych lub długotrwałą niedostępność podstawowej usługi.

Ostatni etap to wdrożenie procedur, aktualizacja umów, ćwiczenie obsługi incydentu i przygotowanie dokumentacji dowodowej. Ta dokumentacja powinna pokazywać nie tylko, iż polityka istnieje, ale również iż jest wykonywana: protokoły przeglądów, wyniki testów odtwarzania kopii, rejestry szkoleń, decyzje zarządu, oceny dostawców oraz rejestry incydentów.

Najczęstszy błąd polega na potraktowaniu NIS2 jak projektu jednorazowego. Zgodność nie wynika z folderu z politykami ani z jednego audytu. Wynika z powtarzalnego procesu, w którym firma rozpoznaje zmianę ryzyka, podejmuje decyzję, wdraża środek ochrony i potrafi wykazać, dlaczego uznała go za wystarczający.

Najlepszym pierwszym krokiem jest więc nie deklaracja „jesteśmy zgodni z NIS2”, ale jedno konkretne pytanie skierowane do zarządu: którego krytycznego procesu nie potrafilibyśmy bezpiecznie odtworzyć po incydencie i co zrobimy w tym kwartale, aby to zmienić?