Dyrektywa NIS 2 – obowiązki firm: zarządzanie ryzykiem, zgłaszanie incydentów 

Obowiązki firm: zarządzanie ryzykiem

NIS 2 wskazuje, że wszystkie podmioty muszą „podejmować odpowiednie i proporcjonalne środki techniczne i organizacyjne w celu zarządzania zagrożeniami dla bezpieczeństwa cybernetycznego sieci i systemów informatycznych”. 

Mówiąc prościej, te środki oznaczają zatrudnionych specjalistów, wdrożone procesy i procedury, systemy i rozwiązania techniczne itd. 

Opublikowany 23.04.2024 projekt nowelizacji UKSC implementującej w Polsce obowiązki wynikające z dyrektywy NIS 2 podkreśla, jak ważne jest podejście oparte na ryzyku, zobowiązując podmioty kluczowe i ważne do wprowadzenia systemu zarządzania bezpieczeństwem informacji (SZBI) w procesach służących świadczeniu przez nie usług. 

Analiza Ryzyk

Właściwym podejściem, niezależnie od wielkości firmy czy instytucji, jest przeprowadzenie analizy ryzyk (w tym cybernetycznych) oraz identyfikacja tych najbardziej krytycznych. Wymienione wcześniej środki muszą zapewniać poziom bezpieczeństwa powiązany z i wynikający wprost z występujących w danej organizacji ryzyk. 

Dyrektywa NIS 2 wymaga posiadania przez organizację udokumentowanych, aktualizowanych analiz i ewaluacji ryzyk oraz bezpieczeństwa systemów informatycznych: 

1. identyfikację ryzyk, w tym cyber i ich poziomu 
2. analizę tych ryzyk i wybranie tych najistotniejszych 
3. posiadanie planu mitygacji najbardziej krytycznych ryzyk

Dobrze przygotowana, przedyskutowana i uzgodniona z Zarządem oraz udokumentowana analiza cyberryzyk zapewnia nam spełnienie w tym zakresie wymagań NIS 2, ale przede wszystkim jest najlepszym sposobem na przekonanie Zarządu do wagi obszaru cyber w tym potrzebnych nakładów finansowych. 

Pamiętajmy, by w oszacowaniu budżetu i środków na minimalizację cyber ryzyk wykorzystać specyfikę naszej organizacji, raporty o zagrożeniach czy przypadki cyberataków na podobnych do naszej organizacji. 

Należy wziąć pod uwagę koszty przestojów, niedostępności usług, utratę produkcji, dodać odzyskiwanie danych i wysiłki potrzebne do przywrócenia normalnego działania, a także uwzględnić szacunkowe koszty kar NIS 2 i szkody dla powiązanych przedsiębiorstw itp. 

Polityki Bezpieczeństwa

Kolejny obowiązek to posiadanie udokumentowanej i aktualizowanej polityki bezpieczeństwa organizacji. Polityka bezpieczeństwa organizacji bazuje na analizie ryzyk. To z analizy ryzyk oraz przyjętej na ich podstawie polityki bezpieczeństwa wynikają już konkretne rozwiązania, zabezpieczenia organizacyjne i techniczne.  
 
Z polityki bezpieczeństwa systemów informatycznych powinny wynikać takie procesy jak: 

• inwentaryzacja zasobów i zarządzanie zasobami 
• dostęp użytkowników i zarządzania hasłami 
• zarządzanie zmianami 
• zarządzanie podatnościami i poprawkami 
• wykrywanie, monitorowanie i rejestrowanie incydentów bezpieczeństwa, a następnie ich analiza i reagowanie 
• wykorzystywanie rozwiązań do ochrony end pointów, wykorzystanie kryptografii itp 
• segmentacja sieci, tworzenie kopii zapasowych i odzyskiwanie danych 

Jak szybko zweryfikować czy obszar zarządzania ryzykiem i polityk bezpieczeństwa jest pod kontrolą?

Rekomenduję, by zadać sobie samemu następujące pytania – mini lista kontrolna: 

• Czy krytyczne procesy i ich zasoby są znane, udokumentowane, określono dla nich najważniejsze ryzyka a środki bezpieczeństwa określone i wdrożone? 
• Czy zasoby teleinformatyczne objęte zakresem zostały zidentyfikowane, są monitorowane, a podatności i zagrożenia są zarządzane? 
• Czy polityki bezpieczeństwa, procedury są dokumentowane, komunikowane i cyklicznie oceniane? 
• Czy wdrożono proces monitorowania i zgłaszania incydentów bezpieczeństwa i reagowania na nie? Czy jest on udokumentowany? 

Ciągłość działania i zarządzania kryzysowego

Dyrektywa NIS 2 odnosi się do „ciągłości działania i zarządzania kryzysowego” w swoich środkach zarządzania ryzykiem. Liczy się realna gotowość naszej organizacji do przywracania normalnego działania po wystąpieniu sytuacji nadzwyczajnej czy kryzysowej. Kluczowe jest tu posiadanie planów ciągłości działania i zarządzania kryzysowego. Równie ważne jest cykliczne testowanie planów ciągłości działania i zarządzania kryzysowego. Nawet najlepiej opracowany dokument będzie bezużyteczny, jeśli pracownicy nie będą potrafili skorzystać z niego w sytuacji kryzysowej.

Incydenty Bezpieczeństwa

NIS 2 wprowadza dwa rygorystyczne obowiązki dotyczące incydentów bezpieczeństwa: 

1. Obowiązek zgłaszania incydentów i raportowanie ich statusu: 

• bez zbędnej zwłoki i co ważne w czasie nie dłuższym niż 24 godziny od powzięcia wiedzy o poważnym incydencie czy zagrożeniu cybernetycznym musimy dokonać wczesnego ostrzeżenia, w którym musimy wskazać, czy poważny incydent został przypuszczalnie wywołany działaniem bezprawnym, czy działaniem w złym zamiarze oraz czy mógł wywrzeć wpływ transgraniczny 
• czas wczesnego ostrzeżenia dla przedsiębiorców telekomunikacyjnych został w nowelizacji UKSC skrócony do 12 godzin od momentu wykrycia incydentu poważnego, 
•  następnie, bez zbędnej zwłoki, w ciągu 72 godzin od powzięcia wiedzy o poważnym incydencie – zgłoszenie incydentu, z aktualizacją wcześniejszych informacji i wskazaniem wstępnej oceny poważnego incydentu, jego dotkliwości i skutków, a tam, gdzie to ma zastosowanie także wskaźników integralności systemu

2. Obowiązek przedstawienia raportu końcowego < 1 miesiąc po złożeniu pierwszego raportu, po zgłoszeniu incydentu:

Raport końcowy powinien zawierać: 

• szczegółowy opis incydentu, jego wagi, wpływu i dotkliwości oraz skutków 
• rodzaj zagrożenia, pierwotna przyczyna, która prawdopodobnie była źródłem incydentu 
• zastosowane i wdrażane środki zaradcze ograniczające ryzyko 
• wskazanie transgranicznych skutków incydentów

Poważny incydent bezpieczeństwa to takie zdarzenie, które: 

• spowodowało lub może spowodować dotkliwe zakłócenia operacyjne usług lub straty finansowe dla danego podmiotu 
• wpłynęło lub jest w stanie wpłynąć na inne osoby fizyczne lub prawne, powodując znaczne szkody majątkowe i niemajątkowe 
• mające znaczący wpływ na świadczenie usług 
• wszelkie istotne zidentyfikowane zagrożenia cybernetyczne, które mogły potencjalnie skutkować istotnym incydentem (zdarzenia potencjalnie wypadkowe) 

W projekcie nowelizacji UKSC przyjęto, że Rada Ministrów określi, w drodze rozporządzenia, progi uznania incydentu za poważny według rodzaju zdarzenia w poszczególnych sektorach i podsektorach uwzględniając:  

• inne czynniki charakterystyczne dla danego sektora lub podsektora, jeżeli występują 
• liczbę użytkowników, których dotyczy zakłócenie świadczenia usługi 
• czas oddziaływania incydentu na świadczone usługi 
• zasięg geograficzny obszaru, którego dotyczy incydent 

Do kogo firmy i instytucje mają zgłaszać incydenty bezpieczeństwa?

Incydenty poważne, ich status i raporty musimy zgłaszać do właściwego Zespołu Reagowania na Incydenty Bezpieczeństwa Komputerowego, czyli CSIRT.  W projekcie nowelizacji UKSC przyjęto, że incydenty poważne zgłaszane będą do właściwego dla danego podmiotu CSIRT sektorowego. CSIRT sektorowy z kolei w czasie nie dłuższym niż 8 godzin będzie zgłaszał incydenty poważne do odpowiedniego CSIRT poziomu krajowego, czyli:  

• CSIRT NASK
• CSIRT GOV 
• CSIRT MON 

Dodatkowo w nowelizacji UKSC przyjęto, że podmioty kluczowe i ważne będą obowiązane korzystać z systemu S46 służącego wymianie informacji o incydentach, cyberzagrożeniach i podatnościach.

Jak sprawdzić, czy jesteśmy przygotowani do zgłaszania i raportowania incydentów bezpieczeństwa?

Rekomenduję, by zadać sobie samemu następujące pytania – mini lista kontrolna: 

• Czy jestem w stanie na żądanie uprawnionych organów dostarczyć dowody? 
• Czy moja organizacja wykrywa i reaguje na incydenty w trybie operacyjnym, codziennie? Czy jestem odpowiednio szkolony w tym zakresie? 
• Czy wykrywam na bieżąco podatności, zagrożenia i zdarzenia security. Jaka jest ich jakość? Czy proces ten jest zautomatyzowany? 
• Czy moja organizacja jest w stanie zidentyfikować przyczynę źródłową incydentu? Czy obejmuje to czas i ścieżkę ataku? 
• Czy mam zdefiniowany, zakomunikowany i przećwiczony proces komunikacji w zakresie incydentów NIS 2? 

Jeśli chciałbyś poznać lepiej rozwiązania Trecom wspierające spełnienia wymogi NIS 2, zapraszamy do kontaktu.