Ryzyko w NIS 2

Dyrektywa NIS 2 (Network and Information Security) w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium UE wprowadza szereg wymagań w zakresie stosowanych rozwiązań organizacyjnych. Jednym z nich jest polityka analizy ryzyka.

W art. 21 ust. 2 ppkt. a zawarte jest wymaganie, które w polskiej wersji językowej jest niezgodne z wersją angielską. W tej drugiej mowa jest o „policies”, natomiast w polskim tłumaczeniu jest to polityka analizy ryzyka i bezpieczeństwa systemów informatycznych. Pozostańmy przy wersji angielskiej, jako że jest ona zgodna z dobrą praktyką w zakresie tworzenia dokumentów. Już sama polityka analizy ryzyka (poprawnie szacowania i oceny) jest dość obszernym dokumentem, kierowanym do konkretnej grupy osób. Dodanie pozostałych elementów, związanych z SZBI – systemem zarządzania bezpieczeństwem informacji może spowodować, że będzie ona nie do końca czytelna. Cele tych dwóch dokumentów są różne.

Analiza czy szacowanie i ocena?

NIS 2 w art. 25 wskazuje, aby stosować normy i specyfikacje techniczne, więc posłużymy się tym, co w nich zostało zawarte, po to, aby odpowiedzieć na pytanie, dlaczego nie mówimy o analizie, a o szacowaniu ryzyka.
Szacowanie i ocena ryzyka obejmują trzy podstawowe etapy:

• Identyfikacja ryzyka – czyli zauważenie występowania ryzyka;
• Analizę ryzyka – czyli rozważenie, na ile to ryzyko dotknie organizacji, procesów, usług i produktów;
• Ocenę ryzyka – czyli zestawienie wpływu zidentyfikowanego w analizie i rozważenie, czy jest dla organizacji akceptowalny, czy należy podjąć jakieś działania. 

Ten bardzo skrótowy opis procesu szacowania i oceny powinien wystarczyć dla zrozumienia istoty ryzyka w cyberbezpieczeństwie, wymaganego przy wdrożeniu postanowień dyrektywy.  Wymagania te nie będą zmienione, mogą zostać w przepisach krajowych jedynie uszczegółowione. Natomiast zawartość art. 21 będzie stosowana co najmniej tak, jak w obecnym zapisie.

Ryzyko w cyberbezpieczeństwie

Aby poprawnie podejść do oszacowania ryzyka dla świadczonych usług określonych jako kluczowe, należy rozważyć również środowiska, w których organizacja funkcjonuje. Od początku rozwoju bezpieczeństwa IT (information technology), a obecnie ICT (information and telecommunication technologies) należało rozpatrywać zawsze dwa środowiska:

• Środowisko fizyczne – w którym funkcjonują elementy systemu informatycznego;
• Środowisko IT -nazywane czasem logicznym, a często cyberprzestrzenią (nie do końca poprawnie, jednak tą kwestią zajmiemy się w innym artykule).

Zrozumienie tych dwóch środowisk jest konieczne do identyfikacji zasobów nazywanych aktywami, które biorą udział w przetwarzaniu informacji, w tym przesyłaniu, gromadzeniu, przechowywaniu. Mając wiedzę, jakie to urządzenia można przejść do identyfikacji zagrożeń, które mogą występować, a w ostatnim etapie połączyć zagrożenia z zasobami i znając te drugie, rozważyć, czy są podatne.

Podatności, a dokładniej zarządzanie nimi to kierunek, w którym bardzo prężnie rozwija się nauka o ryzyku i o zarządzaniu bezpieczeństwem. Poświęcimy temu kilka artykułów, ponieważ ich dobre zrozumienie i obsłużenie daje bardzo wysoki poziom skuteczności w stosowanych zabezpieczeniach. Celem dzisiejszego artykułu jest wskazanie, jak podejść do ryzyka w NIS 2. Wracając do tego celu – mamy już informacje, które z naszych zasobów są wrażliwe na zagrożenia występujące w obu środowiskach. Możemy też ocenić, jak bardzo są wrażliwe. Tym samym poznajemy źródła potencjalnych incydentów bezpieczeństwa.

Istotną kwestią jest, że funkcjonujące przepisy, czy to w obszarze środowiska fizycznego, czy środowiska IT lub ICT nie zezwalają na materializację takich incydentów. Nie możemy rozważać zagrożeń jako takich, które mogą się zadziać, bo są niegroźne, np. mały pożar czy małe włamanie do sieci. Oprócz przepisów istnieje też zarządzanie majątkiem czy zasobami. Jestem pewien, że zarządzający nie ucieszą się, gdy usłyszą, że w analizie zagrożeń dopuszczamy spalenie się urządzenia sieciowego czy np. włamanie do serwera.

Oznacza to, że obydwa środowiska posiadają już zabezpieczenia, które w założeniu mają chronić przed incydentami w swoich obszarach. Czy jest to ochrona fizyczna, czy ppoż. w środowisku fizycznym, czy RODO i ochrona informacji w środowisku IT. Zawsze jednak istnieje ryzyko, zabezpieczenie może nie zadziałać, a zagrożenie mieć większą siłę lub wystąpić częściej. Z tego powodu nadal szacujemy ryzyko, biorąc tym razem pod uwagę wartościowanie zasobów, a więc przechodząc do procesu szacowania ryzyka, identyfikujemy je na podstawie informacji o potencjalnej materializacji zagrożeń i incydentach. Skutki incydentów mogą być wcześniej rozważone i zobrazowane, a nie dopiero wtedy, kiedy wystąpią (częsty brak powiązania incydentu z oceną ryzyka).

W tym miejscu nagminnie dochodzi do pewnego niezrozumienia. Identyfikacja ryzyka to nie tylko ten skutek, który możemy nazwać pierwotnym. Może wystąpić również skutek dalszy, który dopiero po którymś z kolei kroku odpowie nam na pytanie – jakie jest ryzyko w badanym obszarze?

Przykład z obszaru RODO. Pożar archiwum. Zmaterializować się może niezależnie od naszej ochrony, np. z powodu zwarcia instalacji elektrycznej. W wyniku pożaru zniszczone zostają dane osobowe.

Skutek pierwszego poziomu (w wyniku niedozwolonego i niezgodnego z prawem zniszczenia) – utrata dostępu do danych. Problem w tym, że to nie jest skutek, jaki w RODO powinniśmy oszacować. Aby wiedzieć, jaki skutek owa utrata przyniesie, musimy wiedzieć dokładnie, jakie dane tam się znajdowały. Załóżmy, że były to dane o wynagrodzeniach i warunkach pracy.

Skutek 2 poziomu – wynikający z utraty dostępu do danych: brak informacji o okresach składkowych osób, których dane były w archiwum.

Nadal to nie jest skutek dla osoby, bo sama utrata niewiele znaczy. Ważniejsze jest to, co z tej utraty może wynikać.

Skutek 3 poziomu, czasem nazywany wpływem na osobę, choć jest raczej konsekwencją: brak możliwości wnioskowania o wyższe świadczenie (np. emeryturę w związku z pracą w szczególnych warunkach).

Gdy zidentyfikowaliśmy ryzyko (skutek poziomów 1 i 2) i przeanalizowaliśmy je (skutek poziomu 3), możemy przejść do oceny ryzyka. Czy jest ono dla osoby akceptowalne? Zdecydowanie nie. Należy więc wdrożyć środki ochronne, we wszystkich etapach, w których możemy oddziaływać na ryzyko, aby nie doszło do skutku poziomu 3.

Mam nadzieję, że ten krótki przykład pokazuje, w jaki sposób podchodzimy do ryzyka.
Czas na połączenie tego z wymaganiami dyrektywy NIS 2.

Usługa kluczowa

Usługa kluczowa jest fundamentem działania w obszarze cyberbezpieczeństwa, wymaganym dyrektywą. Oznacza to, że na podstawie spełnienia parametrów opisanych w dyrektywie (i być może w przepisach krajowych, które uszczegółowią niektóre zasady), mamy wskazaną usługę, którą należy dostarczyć. Czy w sposób ciągły? O tym w kolejnym artykule.

Tak wskazana usługa jest odpowiednikiem zagadnienia, które wykonujemy na samym początku wdrożeń np. ISO 27001 lub ISO 22301, a więc wskazania celu i zakresu systemu (tej części organizacji, która musi spełniać wymagania).

Schodząc w dół po procesie szacowania i oceny ryzyka, wybieramy te zasoby, części, elementy obu środowisk, które biorą udział w tworzeniu i dostarczaniu usługi kluczowej. Mając wcześniej dobrze wykonane czynności z zakresu analizy zagrożeń, wiemy już, które incydenty, mogą wywołać konkretne skutki. Wybieramy te, które mogą mieć wpływ na usługę kluczową i z tego punktu widzenia poszukujemy ryzyka, które uniemożliwi nam jej świadczenie.

Co ważne, tu jeszcze nie mamy do czynienia z oceną wpływu na usługę. To działanie nazywa się analizą wpływu, najczęściej na biznes (BIA – business impact analysis). Różni się od ryzyka tym, że poza skutkiem w postaci przerwania świadczenia usługi, oceniany jest również właśnie wpływ na odbiorców usługi kluczowej, ale z funkcją czasu (ile czasu ta usługa może nie być świadczona?)

Informacje wyjściowe z BIA w postaci czasu maksymalnego przestoju czy zakłócenia, stanowią wytyczną do zarządzania incydentami, ciągłością oraz planami odtworzenia po awarii tak, aby zdążyć przywrócić usługę, zanim zaistnieją negatywne skutki.

To właśnie temat naszego kolejnego artykułu.

Podsumowanie

Mamy nadzieję, że w tym krótkim artykule wskazaliśmy najważniejsze aspekty związane z szacowaniem i oceną ryzyka w NIS 2. W szczególności zależało nam na wskazaniu, że identyfikacja, analiza i ocena ryzyka ma się odnosić tylko do obszaru, który jest związany ze świadczoną usługą kluczową. Tego będzie wymagać dyrektywa i przepisy krajowe.

Na sam koniec pozostawiamy Was z pytaniem do przemyślenia: jeśli mamy już dobrze zrobione analizy i w ich wyniku wdrożone systemy zarządzania, czy nie warto jest poszerzyć je na całość działalności biznesowej?