DORA jako argument do transformacji organizacji

Artykuł

DORA jako argument do transformacji organizacji

W zależności od podejścia poszczególnych organizacji do spełnienia wymagań DORA, rozporządzenie może stać się kolejnym zadaniem na liście wymagającym jedynie stworzenia dużej ilości dokumentów, albo powodem do transformacyjnych zmian w organizacji. Od podmiotów finansowych oraz dostawców ICT będzie zależało którą drogę wybiorą.

Od dnia 17 stycznia 2025 r. będą stosowane wymogi rozporządzenia Parlamentu Europejskiego i Rady UE w sprawie operacyjnej odporności cyfrowej sektora finansowego (Digital Operational Resiliency Act - DORA). Jako że DORA jest rozporządzeniem, to przepisy wynikające z tej regulacji będą obowiązywać w całości i bezpośrednio we wszystkich państwach członkowskich, bez konieczności ich implementacji.

DORA obowiązuje podmioty finansowe oraz dostawców usług technologii informacyjnych i komunikacyjnych (information and communication technologies – ICT) dla tychże podmiotów. 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 obszary takie jak:

  • zarządzanie ryzykiem ICT,
  • zarządzanie incydentami bezpieczeństwa,
  • testowanie odporności cyfrowej organizacji,
  • zarządzanie ryzykiem stron trzecich.

W zależności od stopnia dojrzałości procesów wewnątrz organizacji, zapewnienie zgodności z DORA może wymagać zmian sięgających w głąb struktur oraz procedur operacyjnych. Jako przykład można przywołać m.in. 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. Przywołane informacje zazwyczaj 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 połączenia między procesem zarządzania zmianą, a bazą danych o konfiguracji, aby dane wykorzystywane w kluczowym obszarze DORA pozostały aktualne.

Wdrożenie wymogów DORA w niektórych organizacjach, zapewne ograniczy się do dokumentacyjnej zgodności z wymaganiami rozporządzenia. Natomiast niektóre z podmiotów mogą dostrzec w DORA okazję do przyjrzenia się sposobowi w jaki zarządzają cyberbezpieczeństwem oraz operacjami IT, co może zainicjować długo odwlekany proces transformacji tego obszaru. Do przykładowych celów takiej transformacji mogłyby należeć takie aspekty jak:

  • optymalizacja procesów;
  • harmonizacja procesów ułatwiająca przepływ informacji;
  • automatyzacja;
  • ograniczenie kosztów.

Wskazane cele mogą być realizowane oddzielnie, jednak połączenie ich może być bardziej efektywne. Zależność pomiędzy tymi celami mogą być zobrazowane na podstawie zarządzania incydentami. DORA wymaga, aby podmioty objęte jej obowiązywaniem posiadały mechanizmy, które pozwalają na szybkie wykrywanie nietypowych działań, w tym problemów związanych z wydajnością sieci ICT i incydentów związanych z ICT (artykuł 10, punkt 1). Dodatkowo, podmioty powinny wdrożyć wskaźniki wczesnego ostrzegania (artykuł 17, punkt 3a).

Nietrudnym do wyobrażenia jest scenariusz, w którym użytkownik w ramach podmiotu finansowego z niską dojrzałością w odniesieniu do wymogów DORA, zgłasza do swojego działu IT z incydent dotyczący zasobów sieciowych. Dział IT poddaje analizie taki incydent i zaczyna go rozwiązywać, nie mając świadomości, że jest to element większego ataku cybernetycznego na organizację. Przez niedostępność informacji dodatkowych, dział IT nie połączy tego incydentu z innymi i nie zauważy nietypowego zachowania wskazującego na potencjalny atak. Dodatkowo należy zauważyć, że w tym samym czasie incydentem może się zajmować zespół Security Operations Center (SOC), którego rolą jest m.in. odpowiadanie na incydenty z zakresu cyberbezpieczeństwa.

Zupełnie inaczej taka sytuacja by się prezentowała, gdyby incydenty zgłoszone do działu 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 połączeniu tych danych, informacja o potencjalnym ataku byłaby automatycznie przekazana do zespołu SOC, który odpowiednio przeprowadziłby zarządzanie incydentem. 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 drugiej z opisanych potencjalnych sytuacji, mieliśmy do czynienia nie tylko ze spełnieniem wymagań DORA, ale również z:

  • optymalizacją procesu zarządzania incydentem;
  • wykluczeniem powtarzających się działań; oraz
  • harmonizacją przepływu informacji między zespołami.

Osiągniecie takiego stanu było możliwe dzięki wdrożeniu narzędzia, które będzie automatyzowało poszczególne kroki oraz dawało widoczność na więcej niż jeden obszar działania organizacji. Takim narzędziem dysponują podmioty, które podjęły już w przeszłości transformacyjne działania w obszarze cyberbezpieczeństwa. Warto jednak wskazać, że pomioty które dotychczas nie zdecydowały się na takie działania, będą mogły teraz skorzystać z takiej okazji przy adresowaniu wymogów DORA. Będzie to jednak możliwe, gdy organizacje podejmą wyzwanie DORA z odpowiednim wyprzedzeniem.

Chcąc podjąć kroki w tym kierunku, należałoby rozpocząć analizę luki względem rozporządzenia, a następnie określić na podstawie analizy dalsze plany działania umożliwiające zaadresowanie zidentyfikowanych luk. W planowaych działaniach, należy uwzględnić również akty drugiego stopnia a więc planowane RTS (Regulatory Technical Standards) oraz ITS (Implementing Technical Standards). Należy jednak wystrzegać się domykania luk jedynie poprzez dodanie dodatkowej warstwy formalnej w procesach, ponieważ nie przyniesie to pożądanych korzyści wynikających z transformacji.

Wartym przytoczenia jest przykład podany 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). Na podstawie brytyjskich doświadczeń, autorzy wskazali, że wymóg zapewnienia odporności operacyjnej w obszarze cyberbezpieczeństwa nie jest przewidziany jedynie jako lista wymagań do odznaczenia, a jest sposobem regulatorów na to, aby zarządzanie odpornością stało się jedna 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.

Przypisanie tak dużego nacisku na odporność operacyjną w obszarze cyberbezpieczeństwa jest uzasadnione wieloma okolicznościami. Nie sposób zignorować faktu, że DORA została opublikowana w momencie, w którym wyzwania geopolityczne oraz częstotliwość ataków cybernetycznych, wskazują, że ryzyko cyberbezpieczeństwa jest realnym ryzykiem i może mieć kluczowe znaczenie dla organizacji, a nawet krajów.

to activtae fullwidth component . Do not delete! This box/component contains JavaScript that is needed on this page. This message will not be visible when page is activated.

Czy ta strona była pomocna?