ISO 22301 a KSC/NIS2 – ciągłość działania jako filar cyberodporności

Cyberbezpieczeństwo nie kończy się na wdrożeniu zabezpieczeń technicznych. Dla podmiotów objętych Krajowym Systemem Cyberbezpieczeństwa kluczowe znaczenie ma nie tylko ochrona systemów informacyjnych, ale również zdolność do utrzymania świadczenia usług w czasie zakłócenia.

Najważniejsze pytanie brzmi: czy organizacja będzie w stanie nadal działać, gdy wystąpi cyberatak, awaria systemu, utrata danych, niedostępność dostawcy, przerwa w łączności albo inny incydent wpływający na usługę?

Właśnie w tym miejscu spotykają się dwa obszary: Krajowy System Cyberbezpieczeństwa oraz ISO 22301, czyli norma dotycząca systemu zarządzania ciągłością działania.

KSC określa obowiązki prawne dla podmiotów kluczowych i ważnych. ISO 22301 pokazuje natomiast, jak uporządkować, wdrożyć, udokumentować, testować i doskonalić obszar ciągłości działania. Norma nie zastępuje obowiązków ustawowych, ale może być bardzo dobrym narzędziem zarządczym i dowodowym w zakresie ciągłości świadczenia usług, planów awaryjnych, planów odtworzenia, analizy ryzyka i odporności organizacyjnej.

KSC i ISO 22301 – wspólny cel: niezakłócone świadczenie usług

KSC koncentruje się na zapewnieniu cyberbezpieczeństwa, odpowiedniego poziomu bezpieczeństwa systemów informacyjnych oraz obsługi incydentów. W przypadku podmiotów kluczowych i ważnych szczególne znaczenie ma niezakłócone świadczenie usług.

ISO 22301 patrzy na ten sam problem od strony ciągłości działania. Jej celem jest przygotowanie organizacji na zakłócenia, ograniczenie ich skutków oraz odtworzenie usług w akceptowalnym czasie i na uzgodnionym poziomie.

Wspólnym punktem obu podejść jest cyberodporność organizacji. Nie chodzi wyłącznie o to, aby zapobiegać incydentom, ale również o to, aby organizacja potrafiła działać wtedy, gdy incydent już wystąpi.

ISO 22301 pomaga przełożyć wymagania KSC na konkretne elementy zarządcze:

• identyfikację usług, procesów i systemów informacyjnych,

• analizę wpływu biznesowego,

• analizę ryzyka,

• strategie ciągłości działania,

• plany awaryjne i plany odtworzenia,

• testy i ćwiczenia,

• dowody dla audytu i nadzoru,

• działania korygujące i doskonalące.

Kontekst organizacji – od usług KSC do zakresu ciągłości działania

Pierwszym krokiem w ISO 22301 jest określenie kontekstu organizacji, stron zainteresowanych, wymagań prawnych i regulacyjnych oraz zakresu systemu zarządzania ciągłością działania.

W praktyce oznacza to, że organizacja powinna ustalić:

• jakie usługi lub zadania są kluczowe,

• które procesy wpływają na świadczenie tych usług,

• jakie systemy informacyjne wspierają te procesy,

• jakie dane są niezbędne do działania,

• którzy dostawcy są krytyczni,

• jakie skutki wywoła przerwanie usługi,

• jakie wymagania prawne, regulacyjne, umowne i sektorowe mają zastosowanie.

W przypadku podmiotów publicznych szczególne znaczenie ma to, że usługą może być również zadanie publiczne realizowane przez dany podmiot. Dlatego zakres ciągłości działania nie powinien być opisany ogólnie. Powinien odnosić się do konkretnych usług, procesów, systemów, lokalizacji, dostawców i zależności.

Bez takiego rozpoznania trudno mówić o realnej gotowości do działania w czasie incydentu.

Przywództwo i odpowiedzialność kierownictwa

Ciągłość działania nie jest wyłącznie zadaniem działu IT. Nie jest też wyłącznie zadaniem administratora, pełnomocnika ds. cyberbezpieczeństwa albo specjalisty technicznego. Jest to obszar odpowiedzialności kierownictwa, ponieważ dotyczy zdolności organizacji do realizacji jej podstawowych usług i zadań.

Kierownictwo powinno zapewnić:

• politykę ciągłości działania powiązaną z cyberbezpieczeństwem,

• cele ciągłości działania,

• role i odpowiedzialności za utrzymanie usług,

• zasoby finansowe, techniczne i osobowe,

• nadzór nad analizą ryzyka,

• nadzór nad dostawcami ICT,

• decyzje dotyczące akceptacji ryzyka,

• przegląd skuteczności systemu,

• działania korygujące i doskonalące.

W kontekście KSC ważne jest również to, aby organizacja miała jasno określoną strukturę odpowiedzialności za cyberbezpieczeństwo. Może to być struktura wewnętrzna albo odpowiednio uregulowana współpraca z dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa.

Brak jasnych ról powoduje, że podczas incydentu organizacja traci czas na ustalanie, kto ma podjąć decyzję. W sytuacji cyberataku lub przerwy w świadczeniu usługi taka zwłoka może znacząco zwiększyć skutki zdarzenia.

Cele, ryzyka i zmiany

Cele ciągłości działania nie powinny być ogólnymi deklaracjami. Powinny odpowiadać na konkretne potrzeby organizacji i wymagania KSC.

Przykładowe cele mogą obejmować:

• zapewnienie ciągłości świadczenia kluczowych usług,

• ograniczenie skutków incydentów cyberbezpieczeństwa,

• utrzymanie minimalnego poziomu działania procesów krytycznych,

• odtworzenie systemów informacyjnych w określonym czasie,

• ograniczenie dopuszczalnej utraty danych,

• zapewnienie skutecznej komunikacji podczas incydentu,

• utrzymanie aktualnych planów ciągłości działania,

• testowanie planów i scenariuszy awaryjnych,

• zapewnienie ciągłości łańcucha dostaw ICT,

• gromadzenie dowodów potwierdzających skuteczność systemu.

Cele powinny być spójne z polityką ciągłości działania, mierzalne tam, gdzie to możliwe, monitorowane, komunikowane, aktualizowane i udokumentowane.

Planowanie obejmuje również zmiany. Każda istotna zmiana systemu informacyjnego, dostawcy, infrastruktury, lokalizacji, organizacji pracy albo sposobu świadczenia usługi może wpływać na ciągłość działania. Dlatego zmiany powinny być oceniane nie tylko technicznie, ale również pod kątem ryzyka dla usług i zgodności z KSC.

Analiza wpływu biznesowego – co stanie się, gdy usługa przestanie działać?

Jednym z najważniejszych narzędzi ISO 22301 jest analiza wpływu biznesowego, często określana jako BIA. Jej celem jest ustalenie, które usługi, procesy i systemy są krytyczne oraz jakie skutki wywoła ich zakłócenie.

W kontekście KSC analiza wpływu biznesowego powinna obejmować:

• usługę lub zadanie publiczne,

• procesy wpływające na świadczenie usługi,

• systemy informacyjne wykorzystywane w tych procesach,

• dane niezbędne do działania,

• zależności od dostawców ICT,

• zależności od chmury, centrum przetwarzania danych i infrastruktury,

• maksymalny tolerowany czas przerwy,

• wymagany czas odtworzenia,

• dopuszczalną utratę danych,

• minimalny poziom usługi,

• skutki społeczne, organizacyjne, finansowe, prawne i reputacyjne.

BIA pokazuje, które usługi należy odtworzyć w pierwszej kolejności i dlaczego. Bez niej organizacja może mieć plany, ale nie będzie miała uzasadnionych priorytetów działania.

Analiza ryzyka – co może doprowadzić do zakłócenia?

Analiza ryzyka uzupełnia analizę wpływu biznesowego. BIA pokazuje skutki zakłócenia, natomiast analiza ryzyka wskazuje, jakie scenariusze mogą do tego zakłócenia doprowadzić.

W ISO 22301 ocena ryzyka dotyczy przede wszystkim ryzyk zakłócenia działań priorytetowych i zasobów wymaganych do ich utrzymania. W KSC punkt ciężkości znajduje się na ryzyku wystąpienia incydentu oraz zarządzaniu ryzykiem cyberbezpieczeństwa. Dlatego organizacja powinna widzieć oba poziomy: ryzyko cyberbezpieczeństwa oraz ryzyko ciągłości działania.

Analiza ryzyka powinna obejmować:

• identyfikację usług i procesów narażonych na zakłócenia,

• identyfikację systemów informacyjnych wspierających usługi,

• zagrożenia, takie jak ransomware, awaria infrastruktury, błąd dostawcy, utrata łączności, podatność systemu, błąd ludzki, brak zasilania, niedostępność chmury albo utrata danych,

• podatności techniczne, organizacyjne, personalne i kontraktowe,

• skutki dla poufności, integralności, dostępności i autentyczności informacji,

• skutki dla ciągłości świadczenia usługi,

• prawdopodobieństwo scenariusza,

• poziom ryzyka,

• właściciela ryzyka,

• sposób postępowania z ryzykiem,

• środki techniczne i organizacyjne,

• ryzyko rezydualne,

• decyzję kierownictwa o akceptacji lub braku akceptacji ryzyka.

Analiza ryzyka nie może być dokumentem jednorazowym. Powinna być aktualizowana po istotnych zmianach, po incydentach, po testach, po zmianie dostawcy, po wdrożeniu nowego systemu albo po ujawnieniu istotnej podatności.

Strategie i rozwiązania ciągłości działania

Po wykonaniu BIA i analizy ryzyka organizacja powinna określić strategie i rozwiązania ciągłości działania. Nie wystarczy wiedzieć, co może się wydarzyć. Trzeba ustalić, jak organizacja będzie działać, gdy do zakłócenia dojdzie.

Strategie mogą obejmować:

• odtworzenie systemu z kopii zapasowej,

• przełączenie na środowisko zapasowe,

• pracę w trybie awaryjnym,

• obsługę ręczną wybranych spraw,

• alternatywne kanały komunikacji,

• zapasowe lokalizacje pracy,

• redundancję infrastruktury,

• zapasowe łącza,

• priorytety odtwarzania usług,

• wsparcie dostawcy w określonym czasie,

• zastępcze rozwiązania organizacyjne.

Dla KSC istotne jest, aby strategie były proporcjonalne do ryzyka. Nie każda usługa wymaga takiego samego poziomu zabezpieczeń i odtwarzania. Usługi o wysokim wpływie na bezpieczeństwo, porządek publiczny, zdrowie, prawa obywateli albo ciągłość działania organizacji wymagają silniejszych rozwiązań niż procesy pomocnicze.

Plany ciągłości działania, plany awaryjne i plany odtworzenia

KSC wymaga wdrażania, dokumentowania, testowania i utrzymywania planów ciągłości działania, planów awaryjnych i planów odtworzenia. ISO 22301 pokazuje, jak takie plany osadzić w systemie zarządzania.

Dobry plan nie powinien być ogólnym opisem intencji. Powinien być praktycznym narzędziem działania.

Powinien wskazywać:

• kiedy jest uruchamiany,

• kto podejmuje decyzję,

• kto kieruje działaniami,

• jakie działania są wykonywane,

• jaka jest kolejność odtwarzania usług,

• jakie zasoby są potrzebne,

• jakie są zależności od dostawców,

• jakie kanały komunikacji są używane,

• jak dokumentuje się działania,

• jakie dowody powstają,

• kto potwierdza odtworzenie usługi,

• kiedy następuje powrót do normalnego trybu pracy.

W kontekście KSC plany ciągłości działania powinny być powiązane z obsługą incydentów cyberbezpieczeństwa. Jeżeli incydent powoduje niedostępność systemu, plan odtworzenia nie może działać w oderwaniu od klasyfikacji incydentu, zgłoszenia do CSIRT, analizy przyczyn, zabezpieczenia dowodów i komunikacji z użytkownikami.

Łańcuch dostaw ICT

Jednym z najważniejszych obszarów KSC jest bezpieczeństwo i ciągłość łańcucha dostaw produktów ICT, usług ICT i procesów ICT. ISO 22301 wzmacnia ten obszar przez analizę zależności, zasobów oraz zdolności dostawców do wspierania ciągłości działania.

Organizacja powinna wiedzieć, od których dostawców zależy świadczenie usługi. Dotyczy to w szczególności:

• systemów dziedzinowych,

• usług chmurowych,

• centrów przetwarzania danych,

• dostawców usług zarządzanych,

• dostawców usług cyberbezpieczeństwa,

• operatorów telekomunikacyjnych,

• serwisu infrastruktury,

• dostawców kopii zapasowych,

• dostawców oprogramowania,

• dostawców sprzętu i usług utrzymaniowych.

Wymagania wobec dostawców powinny być zapisane w umowach, SLA, załącznikach bezpieczeństwa, wymaganiach dotyczących zgłaszania incydentów, wymaganiach odtworzeniowych i zasadach eskalacji.

Brak wymagań wobec dostawcy może spowodować, że organizacja formalnie posiada plan ciągłości działania, ale w praktyce nie ma wpływu na czas reakcji, czas odtworzenia albo zakres informacji otrzymywanych podczas incydentu.

Testy, ćwiczenia i odtwarzanie działania

Plan, którego nigdy nie przetestowano, jest założeniem, a nie potwierdzoną zdolnością organizacji. ISO 22301 wymaga ćwiczeń i oceny zdolności ciągłości działania. KSC wymaga, aby plany były testowane i utrzymywane.

Testy mogą obejmować:

• test odtworzenia kopii zapasowej,

• symulację ransomware,

• ćwiczenie niedostępności systemu dziedzinowego,

• test pracy zastępczej,

• test komunikacji kryzysowej,

• test zgłoszenia incydentu,

• ćwiczenie braku dostępu do budynku,

• przegląd reakcji dostawcy na incydent,

• test przełączenia na rozwiązanie zapasowe.

Największą wartość mają wnioski po ćwiczeniach. Organizacja powinna ustalić, co zadziałało, co nie zadziałało, gdzie wystąpiły opóźnienia, czy kontakty były aktualne, czy dostawca zareagował zgodnie z umową i czy czas odtworzenia był zgodny z założeniami.

Odtwarzanie nie jest wyłącznie zadaniem technicznym. Obejmuje również decyzje organizacyjne, prawne, komunikacyjne i zarządcze. Organizacja powinna wiedzieć, które usługi odtwarza jako pierwsze, jakie dane muszą zostać przywrócone, kto potwierdza poprawność odtworzenia i kto decyduje o powrocie do normalnego działania.

Dowody dla audytu i nadzoru

ISO 22301 wymaga monitorowania, pomiarów, analizy, oceny, audytu wewnętrznego i przeglądu zarządzania. W kontekście KSC ma to znaczenie dowodowe. Organizacja musi być w stanie wykazać, że jej system działa, a nie tylko istnieje w dokumentach.

Dowodami mogą być:

• zakres systemu ciągłości działania,

• wykaz usług, procesów i systemów informacyjnych,

• wyniki analizy wpływu biznesowego,

• analiza ryzyka,

• rejestr ryzyk,

• zatwierdzone cele ciągłości działania,

• zatwierdzone strategie ciągłości działania,

• plany ciągłości działania,

• plany awaryjne,

• plany odtworzenia,

• wyniki testów i ćwiczeń,

• raporty z incydentów,

• działania korygujące,

• przeglądy po incydentach,

• wymagania wobec dostawców,

• wyniki audytów wewnętrznych,

• zapisy z przeglądu zarządzania,

• decyzje kierownictwa.

Z punktu widzenia KSC istotne jest, aby dowody pokazywały pełny ciąg logiczny: usługa – proces – system informacyjny – zagrożenie – podatność – ryzyko – środek zabezpieczający – plan ciągłości działania – test – wynik – działanie doskonalące.

Taki ciąg dowodowy pokazuje, że organizacja nie traktuje KSC jako obowiązku formalnego, lecz jako system zarządzania ryzykiem i ciągłością świadczenia usług.

ISO 22301, ISO/IEC 27001 i KSC – jeden system, trzy perspektywy

ISO/IEC 27001 koncentruje się na systemie zarządzania bezpieczeństwem informacji. Chroni poufność, integralność i dostępność informacji przez zarządzanie ryzykiem.

ISO 22301 koncentruje się na ciągłości działania. Odpowiada na pytanie, jak organizacja utrzyma lub odtworzy usługi po zakłóceniu.

KSC łączy te perspektywy i nadaje im wymiar obowiązku prawnego dla podmiotów kluczowych i ważnych. Wymaga zarządzania bezpieczeństwem informacji w systemach informacyjnych wykorzystywanych w procesach wpływających na świadczenie usług, zarządzania ryzykiem, proporcjonalnych środków technicznych i organizacyjnych, ciągłości łańcucha dostaw oraz planów ciągłości działania i odtworzenia.

Najlepszym podejściem nie jest tworzenie osobnych, niespójnych dokumentów. Najlepszym podejściem jest zintegrowany system, w którym:

• KSC określa obowiązki,

• ISO/IEC 27001 porządkuje zarządzanie bezpieczeństwem informacji,

• ISO 22301 porządkuje ciągłość działania i odtwarzanie usług,

• ISO/IEC 27002 wspiera dobór zabezpieczeń,

• audyt wewnętrzny sprawdza skuteczność całego mechanizmu.

Co powinna zrobić organizacja objęta KSC?

Organizacja objęta KSC powinna potraktować ISO 22301 jako praktyczny model wykonania części obowiązków dotyczących ciągłości świadczenia usług. W praktyce powinna:

1. Zidentyfikować usługi, zadania, procesy i systemy informacyjne objęte KSC.

2. Określić kontekst organizacji i strony zainteresowane.

3. Ustalić wymagania prawne, regulacyjne, umowne i sektorowe.

4. Określić zakres systemu ciągłości działania.

5. Przyjąć politykę i cele ciągłości działania.

6. Przypisać role, odpowiedzialności i uprawnienia.

7. Zapewnić zasoby, kompetencje, świadomość i komunikację.

8. Wykonać analizę wpływu biznesowego.

9. Przeprowadzić systematyczną analizę ryzyka incydentów i zakłóceń.

10. Określić strategie i rozwiązania ciągłości działania.

11. Opracować plany ciągłości działania, plany awaryjne i plany odtworzenia.

12. Powiązać plany z obsługą incydentów cyberbezpieczeństwa.

13. Ustalić wymagania wobec dostawców ICT.

14. Testować plany i dokumentować wyniki.

15. Monitorować skuteczność systemu.

16. Przeprowadzać audyty wewnętrzne.

17. Wykonywać przeglądy zarządzania.

18. Wdrażać działania korygujące i doskonalące.

Podsumowanie

KSC/NIS2 wymaga od organizacji nie tylko wdrożenia zabezpieczeń, ale również zdolności do utrzymania usług w warunkach zakłócenia. ISO 22301 daje sprawdzony model, jak tę zdolność zaplanować, wdrożyć, przetestować, udokumentować i doskonalić.

Dlatego podmiot kluczowy lub ważny nie powinien traktować ciągłości działania jako dodatku do cyberbezpieczeństwa. Powinien traktować ją jako jeden z filarów cyberodporności.

Organizacja dobrze przygotowana do KSC to taka, która potrafi odpowiedzieć nie tylko na pytanie: „czy mamy zabezpieczenia?”, ale również: „czy wiemy, jak utrzymać lub odtworzyć usługę, gdy zabezpieczenia zawiodą?”

ISO 22301 nie daje automatycznej zgodności z KSC. Daje jednak uporządkowany, audytowalny i praktyczny mechanizm wykazania, że organizacja zarządza ciągłością działania w sposób świadomy, systemowy i powiązany z ryzykiem cyberbezpieczeństwa.