CyberSec Update #40: Ciągłość działania, RTO i RPO | KWKR

CyberSec Update: ciągłość działania – arkę buduje się przed potopem (finał cyklu)

Noe zaczął budować arkę, gdy niebo było jeszcze czyste. Gdyby czekał na pierwsze krople, żadna ilość desek już by go nie uratowała. Cała mądrość tej historii mieści się w jednym słowie: wcześniej.

W poprzednich częściach cyklu zbudowaliśmy „mur graniczny” w postaci klauzuli cyberbezpieczeństwa, zważyliśmy ryzyko za pomocą kategorii A–D oraz uzgodniliśmy wspólny język incydentów dzięki parametrom projektu i matrycy zdarzeń. Dziś schodzimy do warstwy, która często decyduje o przetrwaniu organizacji po incydencie cyberbezpieczeństwa: ciągłości działania.

Jak sensownie ustawić RTO i RPO, przygotować plany BCP i DRP oraz organizować testy odtworzeniowe dla systemów o znaczeniu operacyjnym? I gdzie kończy się proporcjonalność, a zaczyna twardy wymóg?

Po co ciągłość działania w klauzuli cyber?

Incydent prędzej czy później nastąpi. Kluczowe pytanie brzmi: jak szybko organizacja wróci do działania?

Dlatego dla wszystkich systemów objętych klauzulą kontrahent powinien zapewnić środki ciągłości działania adekwatne do ich znaczenia operacyjnego, w szczególności:

• plan ciągłości działania (BCP),
• plan odtwarzania po awarii (DRP),
• backup danych i systemów.

Stanowi to umowne odzwierciedlenie ustawowego obowiązku utrzymywania planów ciągłości i odtworzenia działalności, wymaganego od podmiotów kluczowych i ważnych na gruncie KSC i NIS2.

RTO i RPO – dwie liczby, które trzeba uzgodnić

RTO (docelowy czas przywrócenia) oraz RPO (docelowy punkt przywrócenia) stanowią fundament każdej rozmowy o ciągłości działania i odporności operacyjnej.

W praktyce sprawdza się prosty mechanizm:

• dla każdego systemu krytycznego operacyjnie kontrahent proponuje wartości RTO/RPO, a zatwierdza je zamawiający zgodnie z minimalnymi parametrami wskazanymi w parametrach projektu;
• w przypadku braku indywidualnych ustaleń stosuje się domyślne wartości maksymalne określone w parametrach projektu;
• wartości te pozostają elementem „warstwy zmiennej” projektu, a nie trzonem samej klauzuli.

Gdzie kończy się proporcjonalność, a zaczyna twardy wymóg?

To sedno dzisiejszego odcinka. Nie każdy system wymaga identycznego reżimu bezpieczeństwa. Jednak w przypadku systemów krytycznych operacyjnie proporcjonalność ma swoje granice.

• systemy krytyczne operacyjnie – pełny BCP i DRP, regularnie testowane; testy odtworzeniowe (disaster recovery) nie rzadziej niż raz w roku, wraz z dokumentowaniem wyników i ich udostępnianiem na żądanie;
• pozostałe systemy o znaczeniu operacyjnym – proporcjonalny plan kontynuacji działania, adekwatny do kategorii ryzyka kontrahenta, zakresu dostępu oraz wpływu systemu na realizację umowy;
• zakres obowiązków powinien wynikać z realnego wpływu na działalność, a nie wyłącznie z faktu objęcia systemu klauzulą.

Innymi słowy: im bliżej „serca” operacji znajduje się system, tym mniej miejsca pozostaje na uznaniowość.

Co to jest system krytyczny operacyjnie?

Warto precyzyjnie zdefiniować tę kategorię, ponieważ to od niej zależy poziom wymagań dotyczących cyberbezpieczeństwa i ciągłości działania.

System krytyczny operacyjnie to system, którego niedostępność, awaria albo utrata integralności, poufności lub dostępności danych mogłyby spowodować:

• istotne zakłócenie działalności,
• zagrożenie bezpieczeństwa osób, mienia lub infrastruktury,
• przerwanie ciągłości działania,
• znaczące straty organizacyjne lub finansowe.

System taki może zostać wskazany przez zamawiającego w parametrach projektu albo zakwalifikowany na podstawie analizy wpływu na działalność (BIA), oceny ryzyka lub dokumentacji zamówienia.

Ciągłość działania w czasie: realizacja, utrzymanie i gwarancja

Obowiązki związane z ciągłością działania nie kończą się wraz z odbiorem projektu. Powinny być jednak racjonalnie rozłożone w czasie.

• pełne obowiązki związane z ciągłością działania obowiązują przez cały okres realizacji umowy oraz utrzymania;
• w okresie gwarancji i rękojmi stosuje się je proporcjonalnie do zakresu odpowiedzialności kontrahenta za dane środowisko; jeżeli kontrahent nie odpowiada za utrzymanie, obowiązki dotyczące BCP, DRP oraz parametrów RTO/RPO powinny zostać odpowiednio ograniczone;
• wybrane obowiązki, takie jak bezpieczne usunięcie danych czy wsparcie przy kontroli organów, mogą obowiązywać także po zakończeniu umowy.

Wyjście z umowy też jest częścią ciągłości działania

Największe ryzyko dla ciągłości działania często pojawia się na końcu współpracy, podczas zmiany dostawcy.

Dlatego dla systemów o znaczeniu operacyjnym warto przewidzieć plan zakończenia współpracy (phase-out lub exit plan), obejmujący:

• bezpieczne przekazanie systemów, dokumentacji i wiedzy następcy,
• zapewnienie ciągłości usług podczas migracji,
• w uzasadnionych przypadkach możliwość czasowego przejęcia kontroli operacyjnej przez zamawiającego (mechanizm step-in).

To ostatnia deska ratunku – nomen omen – dla całej arki.

KSC, NIS2 i RODO – wspólny mianownik ciągłości działania

Testowane plany ciągłości działania, backup oraz zarządzanie kryzysowe stanowią elementy zarządzania ryzykiem wymagane od podmiotów kluczowych i ważnych.

W obszarze ochrony danych osobowych kwestie te łączą się również z art. 32 RODO, który wskazuje zdolność do szybkiego przywrócenia dostępności danych po incydencie jako jeden z podstawowych środków bezpieczeństwa.

Co dalej? Słowo na zakończenie cyklu

Arka Noego przypomina, że ciągłość działania nie jest reakcją na katastrofę, lecz przygotowaniem do niej. RTO, RPO, BCP, DRP i testy odtworzeniowe działają wyłącznie wtedy, gdy powstają odpowiednio wcześnie. Szczególnie w przypadku systemów krytycznych operacyjnie.

Tym odcinkiem zamykamy miniserię poświęconą klauzuli cyberbezpieczeństwa. Wspólnie przeszliśmy drogę od:

• klauzuli jako umownego muru granicznego między organizacją a kontrahentem,
• kategorii ryzyka A–D jako sposobu ważenia wymogów,
• parametrów projektu i matrycy zdarzeń jako wspólnego języka incydentów,
• ciągłości działania jako gwarancji powrotu do działania po incydencie.

Wniosek pozostaje niezmienny: dobra klauzula cyberbezpieczeństwa nie jest listą zakazów. To przemyślana architektura zarządzania ryzykiem – stanowcza tam, gdzie stawką jest bezpieczeństwo, i proporcjonalna tam, gdzie pozwala na to charakter zagrożenia.

Dziękujemy, że byliście z nami przez cały cykl CyberSec Update. Przed nami kolejne tematy i kolejne wyzwania analizowane przez pryzmat cyberbezpieczeństwa.