Raport Specjalny – IT@BANK 2023 | Bezpieczeństwo – Deloitte | Rozporządzenie DORA jako akcelerator pozytywnych zmian w organizacji

Udostępnij Ikona facebook Ikona LinkedIn Ikona twitter
W zależności od podejścia poszczególnych organizacji do spełnienia wymagań DORA, rozporządzenie może stać się kolejnym zadaniem wymagającym stworzenia dużej ilości dokumentów lub powodem, a nawet akceleratorem transformacji w organizacji. To od podmiotów finansowych oraz dostawców ICT będzie zależało, którą drogę wybiorą.

Szymon Mozel
Lider w obszarze DORA,
Partner Associate Risk Advisory DeloitteSzymon Mozel
Lider w obszarze DORA,
Partner Associate Risk Advisory Deloitte

Aleksandra Witowska
Cyber Security Manager
Deloitte Risk AdvisoryAleksandra Witowska
Cyber Security Manager
Deloitte Risk Advisory

17stycznia 2025 r. zakończy się okres przewidziany na wdrożenie wymagań rozporządzenia Parlamentu Europejskiego i Rady UE w sprawie operacyjnej odporności cyfrowej sektora finansowego (Digital Operational Resiliency Act – DORA), którego ostateczna wersja została opublikowana 27 grudnia 2022 r. Ze względu na status rozporządzenia, przepisy DORA będą obowiązywać w całości i bezpośrednio we wszystkich państwach członkowskich – bez konieczności dalszej ich implementacji do krajowego porządku prawnego. Rozporządzenie stosuje się od 17 stycznia 2025 r., co oznacza, że do tego momentu podmioty objęte DORA mają obowiązek zapewnienia zgodności z nową regulacją. DORA dotyczy instytucji finansowych oraz dostawców usług technologii informacyjnych i komunikacyjnych (information and communication technologies – ICT) dla tychże instytucji. Jej celem jest harmonizacja istniejących przepisów w zakresie cyberbezpieczeństwa na poziomie Unii Europejskiej oraz bezpośrednio w krajach członkowskich. Rozporządzenie DORA obejmuje takie obszary, jak:

  • Ramy zarządzania ryzykiem;
  • Zgłaszanie incydentów bezpieczeństwa;
  • Testowanie odporności;
  • Zarządzanie ryzykiem stron trzecich;
  • Udostępnianie informacji o zagrożeniach innym podmiotom na rynku.

Kluczowe zmiany

Na pierwszy rzut oka DORA dotyczy jedynie wąskiego zakresu działania instytucji finansowych i ich dostawców, jest to jednak jedynie wrażenie pozorne, gdyż w zależności od stopnia dojrzałości procesów wewnątrz organizacji, zapewnienie zgodności może wymagać kluczowych zmian sięgających w głąb struktur oraz procedur operacyjnych. Na przykład testowanie odporności i zapewnienie ciągłości działania jest w dużej mierze uzależnione od posiadania aktualnej informacji o zasobach IT przedsiębiorstwa. Te z reguły są przechowywane w bazie danych o konfiguracji. Natomiast raz uzupełnione, dezaktualizują się w miarę stosowania zmian, które ich dotyczą. Kluczowe w tym kontekście jest więc zapewnienie odpowiedniego sprzężenia między procesem zarządzania zmianą a bazą danych o konfiguracji, aby dane wykorzystywane w kluczowym obszarze DORA pozostały aktualne.

Niezależnie od potencjału DORA do uruchamiania dogłębnych zmian w organizacji, wiele podmiotów, dostosowując się do tej regulacji, postawi na zapewnienie literalnej i głównie dokumentacyjnej zgodności z wymaganiami rozporządzenia. Jest to oczywiście jedna z możliwych strategii podejścia do tego zagadnienia. Natomiast część organizacji może dostrzec w DORA okazję do gruntownego przyjrzenia się sposobowi, w jaki zarządzają cyberbezpieczeństwem oraz operacjami IT i odnajdzie dzięki temu rozporządzeniu inspirację do transformacji tego obszaru. Do przykładowych celów takiej transformacji mogłyby należeć takie aspekty, jak:

  • Przegląd i optymalizacja procesów;
  • Harmonizacja procesów ułatwiająca przepływ informacji;
  • Automatyzacja wykorzystująca narzędzia dedykowane do poszczególnych zakresów zarządzania cyberbezpieczeństwem;
  • Ograniczenie długoterminowych kosztów.

Wskazane powyżej cele mają charakter uzupełniający się. Przykładem ilustrującym zależność pomiędzy tymi celami może być np. obszar zgłaszania incydentów bezpieczeństwa. DORA wymaga, aby podmioty finansowe dysponowały mechanizmami pozwalającymi na szybkie wykrywanie nietypowych działań, w tym problemów związanych z wydajnością sieci ICT i incydentów związanych z ICT, oraz na identyfikację potencjalnych istotnych pojedynczych punktów awarii (artykuł 10, punkt 1). Dodatkowo, podmioty powinny wdrożyć wskaźniki wczesnego ostrzegania (artykuł 17, punkt 3a).

Dwa scenariusze

Wyobraźmy sobie scenariusz, w którym użytkownik instytucji nie w pełni spełniającej wymagania DORA zgłasza do swojego działu wsparcia IT z pozoru błahy incydent dotyczący zasobów sieciowych. Dział IT podejmuje taki incydent i zaczyna go rozwiązywać, mogąc nie wiedzieć, że jest to element większego ataku cybernetycznego na organizację. Bez dostępu do odpowiednich informacji dodatkowych dział IT może nie połączyć tego incydentu z innymi i nie zauważyć nietypowego zachowania wskazującego na potencjalny atak. Z drugiej strony, istnieje też szansa, że w tym samym czasie incydentem zajmuje się już zespół Security Operations Center (SOC), którego rolą jest m.in. odpowiadanie na incydenty z zakresu cyberbezpieczeństwa.

Jakże inaczej prezentowałaby się ten scenariusz, gdyby incydenty zarejestrowane przez dział wsparcia IT były jednocześnie analizowane pod kątem otwartych podatności na urządzeniu objętym incydentem przez system informatyczny wspierający obszary operacji i bezpieczeństwa (Security Operations – SecOps). Po skorelowaniu tych danych informacja o potencjalnym ataku mogłaby być automatycznie przekazana do zespołu SOC, który kontynuowałby analizę incydentu lub w razie konieczności odpowiedział na niego oraz mógłby precyzyjnie śledzić skalę ataku. Dodatkowo, w sytuacji, w której byłby to jeden z pierwszych symptomów ataku, działania te byłyby dobrym przykładem wypełnienia wymagania DORA dotyczącego posiadania wskaźników wczesnego ostrzegania.

W drugim z opisanych scenariuszy mieliśmy do czynienia nie tylko ze spełnieniem wymagań DORA, ale również z:

  • optymalizacją procesu polegającą na przekazaniu rozwiązania incydentu do najodpowiedniejszego zespołu w organizacji,
  • eliminacją duplikacji działań,
  • harmonizacją procesu, w ramach której odpowiednie informacje w sposób płynny i zautomatyzowany były przekazywane między zespołami.

To wszystko było możliwe dzięki wdrożeniu narzędzia, które automatyzowało poszczególne kroki oraz dało widoczność na więcej niż jeden obszar działania organizacji.

Warto przypomnieć, że drugi wariant tego scenariusza będzie dostępny głównie dla tych organizacji, które podjęły już w przeszłości transformacyjne działania w obszarze cyberbezpieczeństwa bądź takie działania podejmą, np. wykorzystując w tym celu okazję, którą przynosi DORA.

Odpowiednie wyprzedzenie czasowe

Wydaje się, że kluczowym czynnikiem umożliwiającym wykorzystanie okazji do optymalizacji wynikającej z rozporządzenia będzie czas. Umożliwienie zmian transformacyjnych w obszarach zainteresowania DORA będzie możliwe jedynie wtedy, gdy organizacje podejmą wyzwanie z odpowiednim wyprzedzeniem. Wstępne kroki, które mogłyby na to pozwolić, uwzględniają analizę luki względem rozporządzenia, a następnie określenie na podstawie analizy tychże luk planów działania (map drogowych) umożliwiających ich domknięcie. Jeśli to możliwe, plan działania powinien uwzględniać zapisy dokumentów wdrożeniowych DORA, czyli regulacyjnych standardów technicznych (Regulatory Technical Standards – RTS) oraz wykonawczych standardów technicznych (Implementing Technical Standards – ITS), nawet w wersji roboczej. Takie podejście ma na celu zapewnienie jak najpełniejszego zaadresowania wymagań. Obszar cyberbezpieczeństwa niesamowicie dynamicznie się rozwija, dlatego warto zachować elastyczność w podejściu i gotowość do aktualizacji planów działania w trakcie ich realizacji i w miarę publikowania ostatecznych wersji dokumentów wdrożeniowych.

Może to zapobiec obserwowanemu często w przypadku wdrożenia nowych przepisów prawa zjawisku, gdzie późne rozpoczęcie prac zmusza do reaktywności w działaniu, która wymaga dużo czasu i energii zespołów. Z reguły kończy się jednak tylko dodaniem dodatkowej warstwy formalnej w procesach, nie przynosząc korzyści wynikających z transformacji.

W tym kontekście warto sięgnąć do przykładu opisanego przez oddział Deloitte Central Europe w Pradze, który porównał DORA z ramami odporności, które zostały wdrożone w Wielkiej Brytanii (The UK Government Resilience Framework). Jak wskazują autorzy tej publikacji, powołując się na doświadczenia brytyjskie, wymóg zapewnienia odporności operacyjnej w obszarze cyberbezpieczeństwa nie jest przewidziany jedynie jako lista wymagań do odznaczenia (tick-box exercise), a jest sposobem regulatorów na to, aby zarządzanie odpornością stało się jedną z krytycznych funkcji w organizacji. Powinno się to przełożyć na uczynienie z zapewnienia odporności celu biznesowego, wpływając na modele operacyjne organizacji oraz sposób działania działów  IT i bezpieczeństwa. Jako kluczowy cel biznesowy organizacji, odporność operacyjna powinna też wejść na agendę zarządów organizacji podlegających DORA.

Oczekiwanie aż tak dużej uwagi względem odporności operacyjnej w obszarze cyberbezpieczeństwa wydaje się uzasadnione chociażby faktem, że DORA została opublikowana w momencie, w którym wyzwania geopolityczne oraz częstotliwość ataków cybernetycznych udowadniają nam, że ryzyko cyberbezpieczeństwa nie jest jedynie ryzykiem teoretycznym i może mieć kluczowe znaczenie dla organizacji, a nawet państw.

Źródło: Miesięcznik Finansowy BANK