Jednym z naczelnych celów NIS2 jest zapewnienie ciągłości działania sieci i systemów informatycznych stosowanych w usługach i sektorach kluczowych, co ma przyczynić się do bezpieczeństwa państw Unii Europejskiej. W dzisiejszym, wysokorozwiniętym technologicznie świecie praktycznie każda usługa powszechna jest wspomagana przez system teleinformatyczny. W tym artykule radzimy, jak wdrożyć właściwe zarządzanie ciągłością działania zgodnie z NIS2. Proces ten obejmuje aspekty zarządzania kryzysowego, szybkiego podejmowania decyzji, zarządzania łańcuchem dostaw oraz utrzymania sprawności i przywracania systemów po awarii.
Czym jest ciągłość działania w IT?
W samej treści dyrektywy ustawodawca nie zawarł definicji „ciągłości działania”, przyjmując, iż jest ona na tyle oczywista, że nie wymaga doprecyzowania. Po krótkiej chwili zastanowienia można stwierdzić, że nie do końca tak jest. Przyjmując dla przykładu, że kluczową usługą teleinformatyczną w Polsce jest platforma ePuap udostępniająca obywatelom komunikację z instytucjami państwowymi, jak byśmy określili zapewnienie ciągłości jej działania? Ma działać nieprzerwanie, 24h na dobę, 7 dni w tygodniu i 365 dni w roku? W przypadku wystąpienia awarii ma zostać przywrócona natychmiast? Po przywróceniu mają zostać udostępnione jej wszystkie funkcje w jednym momencie? Czy nie mogą zdarzyć się planowane przerwy w działaniu związane z pracami konserwacyjnymi?
Tego typu pytania można mnożyć w nieskończoność, a na żadne z nich nie znajdziemy jednoznacznej odpowiedzi. Definiując zatem ciągłość działania, trzeba przyjąć pewne parametry, które określają, w jakim czasie usługa musi być sprawna i dostarczać określony, krytyczny zakres funkcjonalności dla obywateli. Z tym wiążą się parametry dostępności oraz parametry związane z przywracaniem usługi po awarii, o których opowiem w dalszej części artykułu.
Z powyższych rozważań można wywnioskować, że ciągłość działania nie jest przez wszystkich rozumiana jednoznacznie i rodzi inne oczekiwania u administratora systemu, a inne u użytkownika czy przedstawiciela biznesu. Z tego też względu w procesie związanym z zarządzaniem ciągłością działania musi występować wielu interesariuszy – zarówno osoby utrzymujące daną usługę, podwykonawcy, pracownicy IT, odpowiadające za bezpieczeństwo – jak i osoby korzystające z usługi oraz odpowiedzialne biznesowo za jej prawidłowe świadczenie. W ramach procesu zarządzania ciągłością działania prowadzi się kroki analityczne oraz uzgodnienia, a plany ciągłości działania są zawsze kompromisem pomiędzy jakością, dostępnością i kosztem zapewnienia nieprzerwanej pracy systemu.
Zarządzanie ciągłością działania zgodnie z NIS2 jako proces
Bezpieczeństwo jest procesem – z tym stwierdzeniem trudno polemizować. Bez ciągłej weryfikacji, planowania, doskonalenia nie możemy mówić o optymalnym zarządzaniu cyberbezpieczeństwem w organizacji. Ciągłość działania – jako jeden z istotnych elementów bezpieczeństwa teleinformatycznego – również stanowi swoisty proces, w którym duża część zadań jest powtarzalna w ustalonych cyklach. Zacznę jednak od początku. Jak w organizacji, w której nie zarządza się ciągłością działania IT, postawić pierwsze kroki?
W celu realizacji powtarzalnego i uporządkowanego procesu potrzeba odpowiedniej procedury zarządzania ciągłością działania, która wskaże sposób podejścia do budowania planów ciągłości działania, instrukcji odtworzeniowych na wypadek awarii, sposobów komunikacji oraz innych elementów związanych z wytworzeniem oraz testowaniem planów ciągłości działania. Metodyczne podejście do tego obszaru możemy zaczerpnąć z normy ISO 22301, która określa wymagania dotyczące systemu zarządzania ciągłością działania. Stanowi ona swoiste ramy dla utrzymania ciągłości działania organizacji w warunkach kryzysowych.
Procedura zarządzania ciągłością działania – obszary
Przybliżając Wam zakres, który obejmuje norma ISO 22301 oraz wskazując jej najistotniejsze elementy, wymienię kilka podstawowych punktów, które są jednocześnie częściami składowymi procedury:
- Polityka zarządzania ciągłością działania – dokument, w którym określony jest kontekst organizacyjny oraz podstawowe pryncypia związane z zarządzaniem ciągłością działania. Wskazuje role i odpowiedzialności, opisuje proces zarządzania ciągłością działania w organizacji oraz wskazuje odwołania do dokumentów podrzędnych, w których opisane są poszczególne działania, lub które są narzędziami wspomagającymi proces.
- Analiza ryzyka jest działaniem ściśle powiązanym z wszelkimi obszarami cyberbezpieczeństwa – w tym z ciągłością działania. Stanowi ona podstawę do identyfikacji potencjalnych, realnych scenariuszy awarii, które staną się punktem wyjścia do określania, na jakie okoliczności przygotowane zostaną plany ciągłości działania.
- Analiza wpływu na organizację (BIA – Business Impact Analysis) – jest równoległym do analizy ryzyka działaniem, jakie należy przeprowadzić w celu weryfikacji, które z systemów teleinformatycznych mają bezpośredni lub pośredni wpływ na działanie kluczowych usług biznesowych. Identyfikuje się usługi kluczowe oraz systemy wspomagające ich działanie, wykonuje dekompozycję takich systemów na poszczególne elementy infrastruktury, np.serwery, wirtualizatory, sieć, dostęp do Internetu it. oraz usługi firm zewnętrznych. Dekompozycja prowadzi do określenia pojedynczych elementów danej usługi krytycznej w kontekście ich podatności na określony scenariusz awarii wynikający z analizy ryzyka. Analiza wpływu jest również miejscem na ustalenia, jakie parametry odtworzeniowe wymagane są przez opiekunów biznesowych oraz Klientów każdej kluczowej usługi. Określa się tu takie parametry jak np.:
- RTO (Recovery Time Objective) – akceptowalny czas odtworzenia usługi po awarii krytycznej,
- RPO (Recovery Point Objective) – akceptowalny poziom utraty danych.
Po wypracowaniu wszelkich dokumentów związanych z zarządzaniem ciągłością działania – parametry odtworzeniowe podlegają negocjacjom pomiędzy osiągniętymi wynikami odtworzenia przez IT a wymaganiami biznesu. Jeżeli parametry są mocno rozbieżne – przeważnie wymagane jest poniesienie dodatkowych kosztów na podniesienie sprawności odtwarzania lub ograniczenie ryzyka wystąpienia danego scenariusza awarii.
- Plany ciągłości działania – są dokumentami, które na wysokim poziomie określają metody reakcji na określone scenariusze awarii. Często spotykam się z podejściem, gdy jeden dokument dotyczy jednej usługi, gdyż jest możliwość umocowania go na poziomie określonego właściciela biznesowego. Dokumentami podrzędnymi dla planów ciągłości działania są procedury odtworzeniowe.
- Procedury odtworzeniowe – zawierają zbiór instrukcji odtworzeniowych, szeregują działania wynikające z wykonywanych instrukcji w wymiarze chronologicznym, ustalają odpowiedzialności za wykonanie określonych instrukcji. Przeważnie dotyczą jednego systemu teleinformatycznego lub jednego obszaru w danym systemie.
- Instrukcje odtworzeniowe – opisują dokładnie kolejne kroki, jakie należy wykonać, aby zrealizować zadanie wynikające z procedury odtworzeniowej. Są potrzebne dla sprawnego przeprowadzenia działań technicznych bez potrzeby posiadania wiedzy specjalistycznej i pozwalają na realizację czynności odtworzeniowych przez osoby, które na co dzień nie wykonują danych działań.
- Komunikacja / Role i odpowiedzialności – dokumenty, które zawierają zasady postępowania w sytuacjach krytycznych. Kto stoi na czele sztabu kryzysowego, w jakim zakresie jest w stanie podejmować decyzje np. w sprawie wydatkowania środków – należy zatem zadbać o niezbędne pełnomocnictwa Zarządu. Dodatkowo trzeba ustalić, jaka jest struktura sztabu kryzysowego, jaki jest model komunikacji, kto i w jakich sytuacjach z kim się kontaktuje, a kto odpowiada za szerokie informowanie zarówno wewnątrz organizacji, jak i poza nią.
Można powiedzieć, że dokumenty dotyczące ciągłości działania są swoistą polisą, z której nikt nie chce skorzystać, ale w przypadku awarii pozwala na ochronę reputacji organizacji, jej zasobów finansowych, a w krytycznych przypadkach również zdrowia i życia ludzkiego. Z założenia zatem nie są dokumentami, które wykorzystywane są często. Z tego względu należy mieć ustalony plan testowania. Dzięki temu można się doskonalić, ćwiczyć sprawne przeprowadzenie procedur w przypadku wystąpienia sytuacji awaryjnej oraz wykrywać i usuwać błędy zawarte w dokumentach.
Plany, Procedury, Instrukcje – przykłady zapisów
Dla prawidłowego funkcjonowania procesu w organizacji należy stworzyć dla niego ramy – czyli opracować i uchwalić co najmniej: Procedurę Zarządzania ciągłością działania oraz Procedurę związaną z szacowaniem ryzyka. Następnie można przejść do wdrażania w życie ich zapisów.
Zgodnie z wymienionymi w poprzednim punkcie elementami, w pierwszej kolejności należy przeprowadzić proces analizy ryzyka. Jak prawidłowo i praktycznie się do tego zabrać, omawiałem w poprzednim artykule [link].
Mając wyniki analizy ryzyka, można przystąpić do analizy BIA, następnie przygotować plany, procedury, instrukcje.
Widząc przedstawioną wyżej hierarchię, przedstawię przykład, jakie informacje powinny znaleźć się w planach, jakie w procedurach, a jakie w instrukcjach. Powinno to przybliżyć Wam podejście i pomóc zrozumieć konstrukcję tego swoistego systemu.
Plany ciągłości działania – opisują usługę krytyczną, jej właściciela, możliwe scenariusze awarii, które mają wpływ na działanie tej usługi oraz procedury odtworzeniowe (DPR), które należy zastosować, aby uzyskać pełną sprawność po awarii.
Zakładam dla przykładu, że:
- System poczty elektronicznej jest kluczowym systemem firmy;
- Jednym ze scenariuszy może być pożar w serwerowni, którego efektem jest utrata wszystkich serwerów poczty elektronicznej;
- Na wypadek takiej sytuacji uruchamiam procedurę odtworzenia serwera pocztowego z backupu w innej lokalizacji;
- Procedura odtworzeniowa nazywa się 01_Odtworzenie_Serwera_Poczty.
Procedury DRP mówią, jakie kroki należy podjąć, aby zrealizować założenia opisane dla określonego scenariusza awarii. Wyobrażając sobie zatem zawartość procedury DRP 01_Odtworzenie_Serwera_Poczty muszę w niej odwoływać się do określonych instrukcji odtworzeniowych, gdyż te definiują działania z podziałem na pojedyncze komponenty. Dla przykładu – na potrzeby odtworzenia serwera pocztowego w innej lokalizacji należy przeprowadzić następujące czynności:
- Zainstalować nowy serwer;
- Zaaplikować wszystkie aktualne poprawki bezpieczeństwa;
- Udrożnić ruch sieciowy z nowej lokalizacji do podsieci użytkowników;
- Na serwerze zainstalować aplikacje serwera poczty;
- Odtworzyć konfigurację serwera z backupu;
- Odtworzyć bazy danych użytkowników z backupu;
- Zweryfikować poprawność działania serwera pocztowego.
Do każdego z wyżej wymienionych działań powinna zostać przygotowana odrębna instrukcja, która w sposób szczegółowy opisywać będzie oraz pokazywać na zrzutach ekranu poszczególne kroki i zadania dla administratorów.
Przechowywanie dokumentów oraz komunikacja
Plany ciągłości działania są dokumentami zawierającymi dużo szczegółowych informacji, które nie powinny dostać się w niepowołane ręce. Z drugiej strony należy zadbać o ich dostępność w przypadku wystąpienia sytuacji krytycznej.
Ustala się zatem bezpieczne miejsce ich przechowywania, ale umożliwia się do nich dostęp osobom, które na wypadek awarii mogły z nich szybko i skutecznie skorzystać.
Plany ciągłości działania komunikuje się do osób zaangażowanych w procesy związane z działaniem kryzysowym. Wskazuje się miejsce ich przechowywania, zapewnia się dostęp do osób odpowiedzialnych za reagowanie kryzysowe oraz realizację zadań związanych z odtworzeniem poprzez np. nakaz wprowadzenia listy członków zespołów kryzysowych (z dopiskiem DPR) do książki adresowej w telefonach.
Prowadzi się cykliczne testowanie procedur oraz ich doskonalenie i… zarządza się procesem bezpieczeństwa w organizacji w taki sposób, aby nigdy nie trzeba było użyć planów ciągłości działania.
Podsumowanie
Mam nadzieję, że w niniejszym artykule udało mi się przybliżyć Wam właściwe zarządzanie ciągłością działania zgodnie z NIS2. Wierzę, że nie przeraziłem Was zakresem wymaganych działań i dokumentacji. Pamiętajcie proszę, że los jest przewrotny i złośliwy. Jak nie ubezpieczycie samochodu w ramach AutoCasco – mogą Wam go ukraść, jak nie macie planów ciągłości działania – możecie przepaść w chaosie nieuporządkowanych i nieprzemyślanych działań w sytuacji wystąpienia poważnej awarii lub ataku cybernetycznego. Takie ubezpieczenie warto mieć, zwłaszcza, że możecie je wytworzyć stosunkowo niedużym kosztem.
Dziękuję, że zapoznaliście się z całą treścią artykułu, w następnym, jak zwykle w sposób praktyczny, opowiem o zarządzaniu incydentami.
Wcześniejsze artykuły na temat wdrożenia detektyw NIS@ można znaleźć tu: https://pti.org.pl/category/fortcyber/
Autor: Michał Pawlak, ekspert cyberbezpieczeństwa. Pracuje w zespole FortCyber – programie zainicjowanym przez Polskie Towarzystwo Informatyczne