Trzecim filarem DORA jest testowanie operacyjnej odporności cyfrowej. Materia ulokowana jest w rozdziale IV rozporządzenia 2022/2554 i obejmuje cztery artykuły — od art. 24 do art. 27. Z naszego doświadczenia testowanie często traktowane jest jako „cyklicznie wykonywany pen-test" — co jest poważnym uproszczeniem. DORA wymaga programu testowania jako integralnej części ram zarządzania ryzykiem ICT.

Co dokładnie wymaga art. 24 DORA?

Art. 24 DORA wymaga ustanowienia programu testowania operacyjnej odporności cyfrowej jako integralnej części ram zarządzania ryzykiem ICT.

Zgodnie z art. 24 ust. 1 DORA: „Do celów oceny gotowości do obsługi incydentów związanych z ICT, określania słabości, niedoskonałości i luk w zakresie operacyjnej odporności cyfrowej oraz niezwłocznego wdrażania środków naprawczych podmioty finansowe inne niż mikroprzedsiębiorstwa — biorąc pod uwagę kryteria określone w art. 4 ust. 2 — ustanawiają i utrzymują prawidłowy i kompleksowy program testowania operacyjnej odporności cyfrowej stanowiący integralną część ram zarządzania ryzykiem związanym z ICT, o których mowa w art. 6, oraz dokonują przeglądu tego programu".

Trzy elementy ważne dla praktyki:

  • Mikroprzedsiębiorstwa są wyłączone z wymogu utworzenia programu — nie z testowania jako takiego.
  • Program jest integralną częścią ram zarządzania ryzykiem ICT — nie odrębnym dokumentem.
  • Stosujemy zasadę proporcjonalności z art. 4 ust. 2 DORA.

Zgodnie z art. 24 ust. 4 DORA testy mają być przeprowadzane „przez niezależne strony wewnętrzne lub zewnętrzne".

Jak często testujemy?

Art. 24 ust. 6 DORA wymaga przeprowadzania testów wszystkich systemów wspierających funkcje krytyczne lub istotne co najmniej raz w roku.

Pełne brzmienie: „Podmioty finansowe inne niż mikroprzedsiębiorstwa zapewniają, co najmniej raz w roku, przeprowadzenie odpowiednich testów wszystkich systemów i aplikacji ICT wspierających krytyczne lub istotne funkcje". Z naszego doświadczenia spełnienie tego wymogu wymaga zwykle podziału testów na kilka rund w ciągu roku — testowanie „all in one go" jest operacyjnie ryzykowne i kosztowne.

Jakie testy obejmuje program z art. 25 DORA?

Art. 25 ust. 1 DORA wymienia otwarty katalog dwunastu typów testów — od oceny podatności po testy penetracyjne.

  • Oceny podatności i skanowanie pod tym kątem.
  • Analizy otwartych źródeł informacji.
  • Oceny bezpieczeństwa sieci.
  • Analizy luk.
  • Kontrole bezpieczeństwa fizycznego.
  • Kwestionariusze i rozwiązania w zakresie oprogramowania skanującego.
  • Przeglądy kodu źródłowego, gdy jest to wykonalne.
  • Testy scenariuszowe.
  • Testy kompatybilności.
  • Testy wydajności.
  • Testy kompleksowe.
  • Testy penetracyjne.

Ważne — to katalog otwarty (przepis używa słowa „takich jak"). Z naszego doświadczenia podmiot powinien wybrać z tej listy testy adekwatne do swojego profilu ryzyka i charakteru operacji, a wybór udokumentować.

Co robią mikroprzedsiębiorstwa?

Art. 25 ust. 3 DORA przewiduje dla mikroprzedsiębiorstw lżejszy reżim oparty na analizie ryzyka — bez obowiązku posiadania pełnego programu z art. 24 DORA.

Pełne brzmienie: „Mikroprzedsiębiorstwa przeprowadzają testy, o których mowa w ust. 1, łącząc podejście oparte na analizie ryzyka ze strategicznym planowaniem testowania związanego z ICT i należycie uwzględniając potrzebę utrzymania równowagi między skalą zasobów i czasem […], a pilnością, rodzajem ryzyka, krytycznością zasobów informacyjnych i świadczonych usług […]".

Czy testowanie obejmuje też procedury, czy tylko technologię?

Obejmuje jedno i drugie — celem jest „ocena gotowości do obsługi incydentów" (art. 24 ust. 1 DORA), co dotyczy zarówno warstwy technicznej, jak i procesowej.

W praktyce naszych Klientów wyróżniamy:

Testy techniczne
Pen-testy, oceny podatności, przeglądy konfiguracji, fuzz testing, testy obciążeniowe.
Testy procesowe
Tabletop exercise, simulation, war-room, testy planu komunikacji kryzysowej z art. 14 DORA.
Testy odtwarzania
Testy backupów i procedur odtwarzania z art. 12 DORA.
Testy świadomości
Kampanie phishingowe, testy wiedzy pracowników (art. 13 ust. 6 DORA).

Co zrobić z wynikami testów?

Art. 24 ust. 5 DORA wymaga procedur ustalania hierarchii, klasyfikowania i rozwiązywania problemów ujawnionych w trakcie testów oraz wewnętrznych metod zatwierdzania zamknięcia.

Z naszego doświadczenia kluczowe są dwie rzeczy:

  • Każde ustalenie z testu trafia do rejestru ustaleń z testów ICT, z przypisaną osobą odpowiedzialną i terminem usunięcia.
  • Status realizacji rejestru jest okresowo raportowany do organu zarządzającego (art. 5 ust. 2 lit. f DORA — w ramach przeglądu wyników audytów ICT).

Co teraz zrobić?

Z naszego doświadczenia projekt zgodności z trzecim filarem DORA porządkujemy tak:

  • Sporządzić program testowania operacyjnej odporności cyfrowej jako moduł ram zarządzania ryzykiem ICT (art. 24 ust. 1 DORA).
  • Skompletować taksonomię testów (techniczne, procesowe, odtwarzania, świadomości) i przypisać ich częstotliwość do funkcji krytycznych i istotnych.
  • Wyznaczyć niezależnych testerów (wewnętrznych lub zewnętrznych) z udokumentowanym planem unikania konfliktu interesów (art. 24 ust. 4 DORA).
  • Uruchomić rejestr ustaleń z testów i proces działań następczych (art. 24 ust. 5 DORA).
  • Sporządzić roczny harmonogram testów obejmujący wszystkie systemy wspierające funkcje krytyczne i istotne (art. 24 ust. 6 DORA).

W kolejnym wpisie omawiamy zaawansowane testy oparte na zagrożeniach (TLPT) z art. 26–27 DORA.

Co dalej w cyklu?