Rozporządzenie DORA. Poradnik o strategii, polityce i zarządzaniu.

Zastanawiasz się jak możesz zapewnić zgodność z DORA w Twojej organizacji? Przygotowaliśmy dla działów prawnych (w tym compliance) i bezpieczeństwa (lub Cyber Security) praktyczny poradnik podzielony na 17 części, który pomoże przemyśleć strategię przygotowania organizacji finansowej na zmiany związane z rozporządzeniem DORA (Digital Operational Resilience Act), nowego dokumentu Unii Europejskiej dotyczącego finansów cyfrowych.

Czym jest rozporządzenie DORA?

Uchwalone pod koniec 2022 roku Rozporządzenia w sprawie operacyjnej odporności cyfrowej sektora finansowego (Digital Operational Resilience Act) jest częścią pakietu dotyczącego finansów cyfrowych (DFP). Zaprezentowany przez Komisję Europejską zestaw obejmuje strategię finansów cyfrowych, propozycje legislacyjne dotyczące kryptoaktywów i cyberodporności oraz odnowioną strategię płatności detalicznych.

Który akt prawny ma pierwszeństwo DORA czy NIS 2?

Dyrektywa w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa w całej Unii, czyli NIS 2 została przyjęta w tym samym czasie co DORA zaostrza wymagania dotyczące cyberbezpieczeństwa w krajach Unii Europejskiej, również w przypadku sektora finansowego.

DORA stanowi „lex specialis” wobec NIS 2, w myśl zasady, według której prawo szczegółowe ma pierwszeństwo nad prawem ogólnym. DORA wyjaśnia i uzupełnia NIS 2.

„W związku z tym niniejsze rozporządzenie stanowi lex specialis względem dyrektywy (UE) 2022/2555. Jednocześnie, utrzymanie silnego związku między sektorem finansowym a unijnymi horyzontalnymi ramami w zakresie cyberbezpieczeństwa, określonymi obecnie w dyrektywie (UE) 2022/2555” – DORA, punkt 16 motywujący.

Jaki jest cel rozporządzenia DORA?

Cel DORA jest wyraźnie określony w motywie 105 (preambule poprzedzającej akt prawny i wyjaśniającej jego motywacje): „osiągnięcie wysokiego poziomu operacyjnej odporności cyfrowej w odniesieniu do regulowanych podmiotów finansowych”.

Co oznacza „operacyjna odporność cyfrowa„? Zgodnie z tekstem DORA, oznacza ona:

„zdolność podmiotu finansowego do budowania, gwarantowania i weryfikowania swojej operacyjnej integralności i niezawodności przez zapewnianie, bezpośrednio albo pośrednio – korzystając z usług zewnętrznych dostawców usług ICT – pełnego zakresu możliwości w obszarze ICT niezbędnych do zapewnienia bezpieczeństwa sieci i systemów informatycznych, z których korzysta podmiot finansowy i które wspierają ciągłe świadczenie usług finansowych oraz ich jakość, w tym w trakcie zakłóceń;” – DORA, Artykuł 3(1).

Lepiej zapobiegać niż leczyć

Co oznacza definicja operacyjnej odporności cyfrowej? Podmioty finansowe nie tylko powinny tylko skupiać się na obronie, muszą być w stanie również zapobiegać zagrożeniom. Prawdziwym wyzwaniem w przypadku DORA jest niezawodność i integralność usług finansowych, nawet w przypadku zakłóceń, incydentów czy ataków. Sektor finansowy powinien być w stanie bronić swoje zasoby (dane, oprogramowanie i sprzęt), ale samo to już nie jest celem samym w sobie. W przypadku DORA obrona służy wyższemu celowi: odporności.

Kiedy wchodzi w życie DORA?

Rozporządzenie weszło w życie już w styczniu 2023 r., a zacznie być stosowane w styczniu 2025 r. Datę możesz sprawdzić w Artykule 64.

EUN i ENISA: Wyjaśnienie standardów technicznych regulacyjnych na początku 2024 roku

Możesz zauważyć, że niektóre z polityk i procedur wprowadzonych przez DORA nie były jasne w ubiegłym roku. Niemniej jednak, powinny one stać się bardziej zrozumiałe na początku 2024 roku.

Artykuł 15 stanowi, że Europejskie Urzędy Nadzoru (EUN) i Agencja Unii Europejskiej ds. Cyberbezpieczeństwa (ENISA) muszą przedstawić wspólne projekty technicznych standardów regulacyjnych (regulatory technical standards, “RTS”) do 17 stycznia 2024 roku. Będą one precyzować działania wynikające z DORA, począwszy od szczegółów w ramach planów reakcji i odtwarzania ICT, aż po testowanie planów ciągłości działania procesów związanych z ICT.

Niemniej jednak rozporządzenie samo w sobie przy swojej obszerności definiuje szereg zadań do zrealizowania, dlatego warto zacząć działania tak szybko, jak to możliwe.

Zgodność z DORA:
17-etapowy plan działań

Rozporządzenie jest tak skonstruowane, że wskazuje na kroki, które musisz podjąć w celu osiągnięcia “operacyjnej odporności cyfrowej” w Twojej organizacji według DORA. Kroki wskazywane w rozporządzeniu można podzielić na 17 obszarów, które pomogą Ci usystematyzować pracę nad zapewnieniem zgodności z dokumentem.

Proponowana lista to najważniejsze obszary DORA, które wymagają analizy w kontekście strategii odporności cyfrowej Twojej organizacji i oceny jej zgodności ICT.

1. Dowiedz się, czy DORA dotyczy Twojej organizacji

Zanim rozpoczniesz prace mające na celu dostosowanie do DORA, powinieneś sprawdzić, czy firma, w której pracujesz jest objęta jej postanowieniami. Rozporządzenia w sprawie operacyjnej odporności cyfrowej sektora finansowego dotyczy 21 rodzajów podmiotów. Opisano je w Artykule 2:

• instytucje kredytowe;
• instytucje płatnicze, w tym instytucje płatnicze zwolnione zgodnie z dyrektywą (UE) 2015/2366;
• dostawcy świadczący usługę dostępu do informacji o rachunku;
• instytucje pieniądza elektronicznego, w tym instytucje pieniądza elektronicznego zwolnionych zgodnie z dyrektywą 2009/110/WE;
• firmy inwestycyjne;
• dostawcy usług w zakresie kryptoaktywów, którzy uzyskali zezwolenie na mocy rozporządzenia Parlamentu Europejskiego i Rady w sprawie rynków kryptoaktywów oraz zmieniającego rozporządzenia (UE) nr 1093/2010 i (UE) nr 1095/2010 oraz dyrektywy 2013/36/UE i (UE) 2019/1937 i emitenci tokenów powiązanych z aktywami;
• centralne depozyty papierów wartościowych;
• kontrahenci centralni;
• systemy obrotu;
• repozytoria transakcji;
• zarządzający alternatywnymi funduszami inwestycyjnymi;
• spółki zarządzające;
• dostawcy usług w zakresie udostępniania informacji;
• zakłady ubezpieczeń i zakłady reasekuracji;
• pośrednicy ubezpieczeniowi, pośrednicy reasekuracyjni i pośrednicy oferujący ubezpieczenia uzupełniające;
• instytucje pracowniczych programów emerytalnych;
• agencje ratingowych;
• administratorzy kluczowych wskaźników referencyjnych;
• dostawcy usług finansowania społecznościowego;
• repozytoria sekurytyzacji;
• zewnętrzni dostawcy usług ICT.

DORA: lista wyjątków

Pewne podmioty są wyraźnie wyłączone z zakresu DORA na mocy Artykułu 2(3). Zachęcamy do zapoznania się z poniższą listą, aby sprawdzić, czy jesteś w tej grupie.

Z zakresu DORA są wyłączone:

• zarządzający alternatywnymi funduszami inwestycyjnymi, o których mowa w art. 3 ust. 2 dyrektywy 2011/61/UE;
• zakłady ubezpieczeń i zakłady reasekuracji, o których mowa w art. 4 dyrektywy 2009/138/WE;
• instytucje pracownicze programów emerytalnych, które obsługują programy emerytalne liczące łącznie nie więcej niż 15 uczestników;
• osoby fizyczne lub prawne zwolnionych zgodnie z art. 2 i 3 dyrektywy 2014/65/UE;
• pośrednicy ubezpieczeniowi, pośrednicy reasekuracyjni i pośrednicy oferując ubezpieczenia uzupełniające będący mikroprzedsiębiorstwami, małymi lub średnimi przedsiębiorstwami;
• instytucje świadczące żyro pocztowe, o których mowa w art. 2 ust. 5 pkt 3 dyrektywy 2013/36/UE.

Należy zaznaczyć, że Państwa Członkowskie mogą wyłączyć z zakresu DORA niektóre, konkretne podmioty, o których mowa w Artykule 2(5) Dyrektywy 2013/36/UE. W Polsce są to Spółdzielcze Kasy Oszczędnościowo-Kredytowe oraz Bank Gospodarstwa Krajowego.

2. Poznaj wymagania określone przez DORA

Jak już wcześniej wspomnieliśmy, celem DORA jest podniesienie operacyjnej odporności cyfrowej podmiotów finansowych. W tym celu Artykuł 1 określa konkretne wymagania dotyczące bezpieczeństwa sieci i systemów informatycznych, a mianowicie:

• wymogi mające zastosowanie do podmiotów finansowych w odniesieniu do:
  • zarządzania ryzykiem związanym z wykorzystaniem technologii informacyjno-komunikacyjnych (ICT);zgłaszania poważnych incydentów związanych z ICT właściwym organom oraz dobrowolnego informowania ich o znaczących cyberzagrożeniach;zgłaszania właściwym organom przez podmioty finansowe poważnych incydentów operacyjnych lub poważnych incydentów bezpieczeństwa związanych z płatnościami;testowania operacyjnej odporności cyfrowej;wymiany informacji i analiz w związku z cyberzagrożeniami i podatnościami w tym obszarze;
• wymogi w odniesieniu do ustaleń umownych zawartych między zewnętrznymi dostawcami usług ICT a podmiotami finansowymi;
• zasady dotyczące ustanowienia i funkcjonowania ram nadzoru nad kluczowymi zewnętrznymi dostawcami usług ICT świadczącymi usługi na rzecz podmiotów finansowych;
• zasady współpracy między właściwymi organami oraz zasady nadzoru i egzekwowania przepisów przez właściwe organy w odniesieniu do wszystkich kwestii objętych niniejszym rozporządzeniem.
• środków na rzecz należytego zarządzania ryzykiem ze strony zewnętrznych dostawców usług ICT.

Jak można się spodziewać, te wymagania stanowią główny temat pozostałej części tego artykułu.

3. Stwórz ramy zarządzania ryzykiem związanym z technologiami informacyjnymi (ICT)

DORA podkreśla bezwzględną konieczność posiadania ram zarządzania ryzykiem związanym z ICT.

„Podmioty finansowe dysponują – jako częścią swojego ogólnego systemu zarządzania ryzykiem – solidnymi, kompleksowymi i dobrze udokumentowanymi ramami zarządzania ryzykiem związanym z ICT, które umożliwiają im szybkie, skuteczne i kompleksowe reagowanie na ryzyko związane z ICT oraz zapewnienie wysokiego poziomu operacyjnej odporności cyfrowej.” – DORA, Artykuł 6(1)

Zgodnie z definicją, ryzyko związane z ICT oznacza:

„Każda dająca się racjonalnie określić okoliczność związaną z użytkowaniem sieci i systemów informatycznych, która – jeżeli dojdzie do jej urzeczywistnienia – może zagrozić bezpieczeństwu sieci i systemów informatycznych, dowolnego narzędzia lub procesu zależnego od technologii, bezpieczeństwu operacji i procesów lub świadczeniu usług poprzez wywoływanie negatywnych skutków w środowisku cyfrowym lub fizycznym” – DORA, Artykuł 3(5)

DORA: ochrona oprogramowania, sprzętu i danych

Ramy te muszą zawierać szczegóły dotyczące środków wprowadzonych w celu ochrony zasobów informacyjnych i zasobów ICT organizacji. Ponownie, Artykuł 3 zawiera ich definicję:

• „zasoby informacyjne” oznaczają zbiór informacji, w formie materialnej lub niematerialnej, który jest wart ochrony;
• „zasób ICT” oznacza oprogramowanie lub zasoby komputerowe w sieci i systemach informatycznych wykorzystywanych przez dany podmiot finansowy.

Innymi słowy, przedstawiciele sektora finansowego muszą chronić nie tylko oprogramowanie i sprzęt fizyczny organizacji (serwery, urządzenia końcowe, itp.), ale także dane.

Co powinno się zawierać w ramach zarządzania ryzykiem związanym z ICT?

Zgodnie z Artykułem 6, obowiązkowe ramy zarządzania ryzykiem związanym z ICT muszą zawierać co najmniej:

• strategie, polityki, procedury, protokoły ICT i narzędzia niezbędne do ochrony:
  • wszystkich zasobów informacyjnych i ICT, w tym oprogramowania, sprzętu, serwerów itp.;
  • wszystkich aktywów fizycznych i infrastruktur związanych z ochroną tych aktywów, takich jak pomieszczenia lub centra danych.

Można powiedzieć, że DORA działa jak matrioszka, ponieważ składa się z wielu polityk. Te polityki składają się z różnych dokumentów i procedur dotyczących poszczególnych tematów, począwszy od ciągłości działania po plany odzyskiwania. Sprawdzisz jak wygląda struktura dokumentacji w opracowanym przez nas materiale wdrożeniowym do pobrania.

Należy zaznaczyć, że podmiot finansowy, którego działanie jest regulowane przez DORA musi przechowywać dokumentację dostępną dla właściwych organów, które mogą zażądać dostępu do niej. Mogą także zażądać raportu z przeglądu dokumentacji dotyczącej zarządzania ryzykiem związanym z ICT, co przenosi nas do następnego punktu.

Aktualizuj dokumentację co najmniej raz w roku

Nie może wystąpić sytuacja, w której wymagane przez DORA polityki i procedury zostały przygotowane i odłożone na półkę. Dokumenty muszą być aktualizowane co najmniej raz w roku (lub okresowo dla mikroprzedsiębiorstw);

• lub w przypadku wystąpienia poważnych incydentów związanych z ICT
• lub na podstawie decyzji instrukcji nadzorczych
• lub wniosków wynikających z odpowiednich testów cyfrowej odporności operacyjnej
• lub procesów audytu.

Wdrożenie ISMS z myślą o DORA

Jeśli jeszcze tego nie zrobiłeś, konieczne jest wdrożenie Systemu Zarządzania Bezpieczeństwem Informacji (Information Security Management System, “ISMS”), aby wesprzeć obszar zarządzania ryzykiem wprowadzonym przez DORA. Posiadanie ISMS pomaga zmniejszyć ryzyko związane z ICT, poprzez strukturyzację zarządzania bezpieczeństwem informacji organizacji za pomocą podejścia systemowego.

Standard ISO 27001

NIS 2 sugeruje przyszłe europejskie ramy certyfikacji w dziedzinie cyberbezpieczeństwa. Jednak do czasu ich wprowadzenia, międzynarodowy standard ISO 27001 pozostaje głównym odnośnikiem dla tworzenia ISMS. Uzyskanie certyfikatu ISO 27001 jest czasochłonne i wymaga dużego nakładu pracy, więc powinien to być jeden z priorytetów każdego specjalisty bezpieczeństwa informacyjnego (np. CISO, szefa działu bezpieczeństwa) zajmującego się cyberbezpieczeństwem.

Uproszczona struktura zarządzania ryzykiem związanym z ICT dla wyznaczonych podmiotów

Niektóre podmioty mają prawo do „uproszczonej struktury zarządzania ryzykiem związanym z technologią informacyjną” zgodnie z Artykułem 16 DORA. Jest to lżejsza wersja obowiązkowej struktury zarządzania wymaganej przez Rozporządzenie.

Oto lista podmiotów uprawnionych do uproszczonej struktury:

• małe i niepowiązane wzajemnie firmy inwestycyjne,
• instytucje płatnicze zwolnione zgodnie z dyrektywą (UE) 2015/2366;
• instytucje zwolnione zgodnie z dyrektywą 2013/36/UE, w odniesieniu do których państwa członkowskie podjęły decyzję o niewykorzystywaniu możliwości, o której mowa w art. 2 ust. 4 niniejszego rozporządzenia;
• instytucje pieniądza elektronicznego zwolnione zgodnie z dyrektywą 2009/110/WE; oraz
• małe instytucje pracownicze programów emerytalnych – te, które prowadzą programy emerytalne z łączną liczbą członków poniżej 100.

4. Audytuj ramy zarządzania ryzykiem związanym z ICT regularnie

Ramy zarządzania ryzykiem związanym z ICT „podlegają regularnemu audytowi wewnętrznemu przez audytorów” Artykuł 6(6). Powinno istnieć jasne rozgraniczenie między funkcjami zarządzania ryzykiem związanym z ICT, funkcjami kontroli, a funkcjami audytu wewnętrznego. W tym celu Artykuł 6(4) DORA proponuje podmiotom finansowym przyjęcie modelu Trzech Linii Obrony (Three Lines of Defense – 3LoD).

Przyjmij model Trzech Linii Obrony

Model 3LoD umożliwia organizacyjne oddzielenie odpowiedzialności i zarządzania ryzykiem. W praktyce:

• Pierwsza linia obrony to zespoły operacyjne, osoby, które obsługują przedmioty analizy ryzyka. Są odpowiedzialni za uproszczenie zarządzania ryzykiem dla kolejnych linii, uwzględniając czynniki ryzyka. Na przykład dla zespołu ds. rozwoju może to oznaczać jasne określenie odpowiedzialności osobistej każdej osoby lub przyjęcie kultury cyberbezpieczeństwa w projektowaniu, stosując bezpieczne metody rozwoju.
• Druga linia obrony to funkcje zarządzania ryzykiem i zgodności, takie jak CISO. Druga linia jest odpowiedzialna za kontrolowanie pierwszej. Obejmuje to tworzenie procesów monitorowania, wdrażanie ogólnej strategii zarządzania ryzykiem podmiotu lub zapewnienie działania wszystkich obszarów firmy zgodnie z politykami zarządzania ryzykiem; np: w takich działach jak HR, sprzedaż, marketing czy też kadra zarządzająca.
• Trzecia linia obrony to niezależni audytorzy wewnętrzni. Muszą oni zapewnić, że środki obrony wprowadzone przez dwie poprzednie linie są wystarczająco mocne. Innymi słowy ich zadaniem jest holistyczna kontrola stosowanego zarządzania ryzykiem. Audytorzy muszą zweryfikować procesy i ich prawidłowe wykonanie, a następnie sporządzić szczegółowe raporty audytowe. Zrozumiałe również jest, że DORA wyraźnie zaznacza, że audytorzy wewnętrzni muszą posiadać „wystarczającą wiedzę, umiejętności i ekspertyzę” w zakresie zarządzania ryzykiem związanym z ICT.

Aby model 3LoD wdrożyć z sukcesem, każda z linii musi być całkowicie niezależna, zwłaszcza ostatnia. DORA stwierdza, że organizacje muszą zapewnić „odpowiednie oddzielenie i niezależność funkcji zarządzania ryzykiem związanym z ICT, funkcji kontroli i funkcji audytu wewnętrznego„, aby uniknąć konfliktów interesów.

Trudno jest szczegółowo określić uniwersalny model 3LoD, który można by replikować wszędzie, ponieważ musi on być ściśle związany z działalnością, strukturą i funkcjami każdej organizacji. W Internecie znajduje się wiele źródeł, które mogą pomóc w tym zakresie. Najnowszy model od IIA (Institute of Internal Auditors) stanowi dobry punkt wyjścia.

Odpowiedzialność podmiotu (włączając dostawców zewnętrznych i outsourcing)

DORA pozwala na outsourcing „zadań polegających na weryfikacji zgodności z wymaganiami zarządzania ryzykiem związanym z ICT„, zarówno w stosunku do podmiotów zewnętrznych, jak i wewnętrznych. Jednak podmiot finansowy pozostaje w pełni odpowiedzialny za tę weryfikację. Innymi słowy, nie ma możliwości, żeby odpowiedzialność można było przenieść na dostawcę, zawsze spoczywa ona na zleceniodawcy.

5. Zdefiniuj strategię cyfrowej odporności operacyjnej

Ramowy system zarządzania ryzykiem ICT musi być wzbogacony o strategię cyfrowej odporności operacyjnej. Są to dwie strony tego samego medalu: tam, gdzie ramowy system zarządzania ryzykiem ma podejście holistyczne, strategia odporności ma podejście praktyczne. Powinna określać metody wprowadzone w celu radzenia sobie z ryzykiem i osiągnięciu określonych celów.

Zgodnie z Artykułem 6(8), strategia odporności musi:

• wyjaśniać, w jaki sposób ramy zarządzania ryzykiem związanym z ICT wspierają strategię biznesową i cele biznesowe podmiotu finansowego;
• ustalać limitu tolerancji ryzyka w odniesieniu do ryzyka związanego z ICT, zgodnie z gotowością podmiotu finansowego do podejmowania ryzyka, oraz analizować tolerancję wpływu zakłóceń w funkcjonowaniu ICT;
• określić jasne cele w polityce bezpieczeństwa informacji, w tym najważniejsze wskaźniki efektywności i kluczowe wskaźniki ryzyka;
• objaśnić referencyjną architekturę ICT oraz wszelkie zmiany niezbędne do osiągnięcia konkretnych celów biznesowych;
• przedstawić poszczególne mechanizmy wprowadzone w celu wykrywania incydentów związanych z ICT, zapobiegać ich skutkom i chronić przed nimi;
• dokumentować obecną sytuację w zakresie operacyjnej odporności cyfrowej na podstawie liczby zgłoszonych poważnych incydentów związanych z ICT oraz skuteczności środków zapobiegawczych;
• wdrażać testowanie operacyjnej odporności cyfrowej, zgodnie z rozdziałem 4 rozporządzenia;
• przedstawić strategię komunikacji w przypadku incydentów związanych z ICT, których ujawnienie jest wymagane zgodnie z Artykułem 14.

W zależności od skali współpracy z podmiotami zewnętrznymi, możliwe jest wprowadzenie jednej, ogólnej strategii odnoszącej się do wielu dostawców. Strategia powinna wówczas wyjaśniać racjonalne uzasadnienie tego wyboru i szczegółowo opisywać kluczowe zależności od różnych dostawców.

Monitorowanie i poprawa skuteczności strategii w czasie

Artykuł 13 nakazuje jednostkom finansowym monitorowanie skuteczności wdrożenia własnej strategii cyfrowej odporności operacyjnej. Obejmuje to mapowanie zmian ryzyka ICT w czasie oraz analizę częstotliwości występowania, rodzajów, skali i ewolucji incydentów. Szczególny nacisk nałożony jest na śledzenie ataków cybernetycznych i ich wzorców, w celu zrozumienia ewolucji poziomu narażenia jednostki na ryzyko, zwłaszcza w przypadku krytycznych, istotnych funkcji.

Strategię należy ciągle ulepszać na podstawie wniosków wyciągniętych z:

• obowiązkowych przeglądów po wystąpieniu poważnego incydentu;
• trudności napotkanych podczas aktywacji planów ciągłości działania oraz planów reakcji i odzyskiwania;
• monitoringu zagrożeń cybernetycznych i ustaleń dotyczących udostępniania informacji;
• testów odporności operacyjnej;

Co najmniej raz w roku (zgodnie z Artykułem 13(5)) należy sporządzić raport dla organu zarządzającego jednostki. Powinien on zawierać wyniki analizy opisanej wyżej, a także rekomendacje.

6. Wdrożenie mechanizmów ochrony i odporności aktywów

Strategia odporności powinna „nakreślać różne mechanizmy wprowadzone w celu wykrywania incydentów związanych z ICT, zapobiegania ich wpływom i zapewniania ochrony przed nimi.” Twoim zadaniem jest praca z odpowiednimi procedurami i narzędziami.

Minimalne wymagania dotyczące ochrony i odporności aktywów

Aby chronić aktywa zgodnie z Artykułem 9, rozwiązania i procesy muszą przynajmniej:

• zapewniać bezpieczeństwo środków przekazywania danych;
• minimalizować ryzyko uszkodzenia lub utraty danych, nieuprawnionego dostępu i usterek technicznych, które mogą utrudniać prowadzenie działalności gospodarczej;
• zapobiegać brakowi dostępności, osłabianiu autentyczności i integralności, naruszeniom poufności i utracie danych;
• zapewniać ochronę danych przed ryzykiem związanym z zarządzaniem danymi, w tym ryzykiem związanym z niewłaściwym administrowaniem, przetwarzaniem i błędem ludzkim.

W celu zapobiegania cyberatakom, infrastruktura sieciowa musi być zaprojektowana tak, aby można ją było natychmiast odłączyć lub podzielić, zwłaszcza w przypadku wzajemnie powiązanych procesów operacyjnych. Do tego niezbędny jest rejestr procesów. Innymi słowy, w przypadku problemów, zespół powinien móc w krótkim czasie wyłączyć sieć.

Rosnąca ilość polityk do wdrożenia

W trakcie tworzenia polityk istotne jest odpowiednie uporządkowanie ich w ramach zarządzania ryzykiem. Pomocny w tym może być materiał zawierający wykaz dokumentów wymaganych przez rozporządzenie w podziale na określone w DORA polityki. W planowaniu wdrożenia polityk na początku ważne jest zarówno opracowanie i skompletowanie wszystkich dokumentów, jak również przypisanie ich do odpowiednich kategorii polityk.

DORA wymaga od jednostek finansowych udokumentowania odpowiednich polityk:

• politykę bezpieczeństwa informacji, określającą zasady ochrony dostępności, autentyczności, integralności i poufności aktywów i danych, w tym danych klientów, jeśli dotyczy;
• polityki ograniczające dostęp (fizyczny lub logiczny) do aktywów i danych na podstawie funkcji i ról;
• polityki i protokoły dotyczące silnych mechanizmów uwierzytelniania i środków ochrony kluczy szyfrujących;
• polityki, procedury i kontrole dotyczące zarządzania zmianami w ICT, w tym zmian w oprogramowaniu, sprzęcie, komponentach firmware, systemach lub parametrach bezpieczeństwa.

Powinny one opierać się na podejściu opartym na ocenie ryzyka i stanowić integralną część ogólnego procesu zarządzania zmianami organizacji. Proces zarządzania zmianami w ICT musi być zatwierdzony przez właściwy organ decyzyjny; odpowiednie i kompleksowe udokumentowane polityki dotyczące wdrażania łatek i aktualizacji.

7. Wdrażanie rozwiązań do wykrywania zagrożeń

Właściwa ochrona aktywów wymaga zdolności do wykrywania anomalii, incydentów i cyberataków. Oznacza to konieczność posiadania EDR (Endpoint Detection and Response), XDR (Extended Detection and Response), skanerów, SIEM (Security Information and Event Management) itp. Artykuł 10 DORA określa, że jednostki finansowe muszą alokować „wystarczające zasoby i zdolności” w tym celu.

Aby spełnić wymagania Rozporządzenia, mechanizmy wykrywania muszą:

• umożliwiać wielopoziomową kontrolę, definiować progi alarmowe i kryteria wyzwalające i inicjować procesy reagowania na incydenty, w tym automatyczne mechanizmy alarmowe dla odpowiednich pracowników (na przykład SOC – Centrum Operacji Bezpieczeństwa);
• być regularnie testowane.

8. Opracuj politykę ciągłości działania ICT

Rozporządzenie DORA nakłada zadanie:

„podmioty finansowe wprowadzają kompleksową strategię na rzecz ciągłości działania w zakresie ICT, która może zostać przyjęta jako specjalna odrębna strategia stanowiąca integralną część ogólnej strategii na rzecz operacyjnej ciągłości działania podmiotu finansowego.” – DORA, Artykuł 11

Polityka ciągłości działania ICT musi umożliwiać:

• ciągłość krytycznych lub istotnych funkcji podmiotu finansowego;
• szybką i skuteczną reakcję na wszystkie incydenty związane z ICT w sposób ograniczający szkody i priorytetyzujący wznowienie działalności oraz działania odzyskiwania;
• aktywowanie dedykowanych planów w celu opanowania każdego rodzaju incydentu i zapobieżenia dalszym szkodom, a także odpowiednich procedur reagowania i odzyskiwania;
• oszacowanie wstępnych skutków, szkód i strat;
• właściwe zarządzanie kryzysowe i środki komunikacji wewnętrznej dla zespołów, zainteresowanych stron trzecich i odpowiednich organów.

Testuj plany ciągłości działania co najmniej raz w roku

Plany ciągłości działania muszą być udokumentowane, ale także przetestowane pod kątem skuteczności. Artykuł 11(6) nakazuje podmiotom finansowym przeprowadzenie testów:

• planów ciągłości działania ICT oraz planów reagowania i odzyskiwania ICT:
  • co najmniej raz w roku;
  • oraz w przypadku istotnych zmian w systemach ICT obsługujących krytyczne lub istotne funkcje.
• a także planów komunikacji kryzysowej.

Testowanie planów musi uwzględniać scenariusze cyberataków i przełączania się między główną infrastrukturą ICT, a redundantnymi zasobami, kopiami zapasowymi i redundantnymi obiektami wymaganymi przez DORA.

Zachowaj rejestr działań w przypadku zakłóceń

Jeśli wspomniane plany zostaną aktywowane, podmioty finansowe muszą prowadzić “łatwo dostępną ewidencję działań prowadzonych przed wystąpieniem zakłóceń i w trakcie ich wystąpienia” zgodnie z Artykułem 11(8). Organizacje muszą również przedstawić oszacowanie łącznych rocznych kosztów i strat poniesionych w wyniku poważnych incydentów, jeśli zostanie to zażądane przez odpowiednie organy.

9. Zapewnienie procedur tworzenia kopii zapasowych, przywracania i odzyskiwania (oraz powiązanych polityk)

Rozporządzenie DORA ma na celu minimalizację zakłóceń i przestojów w działaniu systemów i przetwarzaniu danych. Konkretnie oznacza to trzy strumienie pracy: tworzenie kopii zapasowych, przywracanie i odzyskiwanie. Są one podzielone na różne polityki, które stanowią część polityki ciągłości działania ICT.

Dlatego jednostki finansowe muszą wprowadzić:

• polityki i procedury tworzenia kopii zapasowych, które określają:
  • zakres danych objętych kopią zapasową;
  • a także minimalną częstotliwość tworzenia kopii, w zależności od krytyczności informacji lub poziomu poufności danych;
• procedury i metody przywracania oraz odzyskiwania.

Rozpoczęcie przywracania kopii zapasowej nie powinno wpłynąć na dostępność, autentyczność, integralność ani na poufność danych. Oznacza to brak zatrzymania działania usług podczas przywracania systemu. Ponadto DORA (Artykuł 12(4)) wprowadza obowiązek redundancji zdolności ICT. Muszą one być zdublowane, aby zapewnić płynne przejście w przypadku awarii oryginalnego systemu.

Jeśli chodzi o przywracanie, to jeśli jednostka postanowi wykorzystywać własne zasoby do przywracania kopii zapasowej, musi zapewnić, że są one fizycznie i logicznie odseparowane od systemu źródłowego.

Wreszcie, wszystkie procedury tworzenia kopii zapasowych, przywracania i odzyskiwania muszą być regularnie testowane zgodnie z Artykułem 12(2).

Należy zauważyć, że większość tych wymagań nie dotyczy mikroprzedsiębiorstw lub mogą być oceniane na podstawie ich profilu ryzyka. Z drugiej strony centralne depozyty papierów wartościowych podlegają dodatkowym wymaganiom, takim jak posiadanie drugiego miejsca przetwarzania danych. Zostało to opisane w Artykule 12(5).

10. Przygotuj plany komunikacji kryzysowej

Artykuł 14 DORA precyzuje obowiązki podmiotów finansowych w zakresie komunikacji podczas incydentów.

„Podmioty finansowe posiadają plany działań informacyjnych na wypadek wystąpienia sytuacji kryzysowej umożliwiające odpowiedzialne ujawnianie, co najmniej, poważnych incydentów związanych z ICT lub podatności klientom i kontrahentom, a także, w stosownych przypadkach, opinii publicznej.” – DORA, Artykuł 14(1)

Oprócz planów komunikacji skierowanej ogólnie do otoczenia, organizacje powinny mieć podobne plany na użytek wewnętrzny i dla zainteresowanych stron zewnętrznych. W przypadku incydentu, polityka komunikacji wewnętrznej powinna odróżniać:

• pracowników, którzy muszą zostać poinformowani o zdarzeniu;
• a pracowników aktywnie zaangażowanych w zarządzanie ryzykiem ICT, zwłaszcza w zakresie reagowania i odzyskiwania.

Wyznacz osobę odpowiedzialną za komunikację kryzysową

DORA wymaga, aby przynajmniej jedna osoba została wyznaczona do zarządzania zagadnieniem komunikacji kryzysowej. Warto jest współpracować z zespołami prawnymi, komunikacji i marketingu w kwestii przyjętej postawy i procesów do wdrożenia.

„Co najmniej jednej osobie w podmiocie finansowym powierza się zadanie wdrożenia strategii komunikacyjnej w zakresie incydentów związanych z ICT i w tym celu pełni ona funkcję osoby ds. kontaktów z opinią publiczną i mediami.” – DORA, Artykuł 14(3)

11. Ustal proces zarządzania incydentami

W przypadku DORA podmioty finansowe mają obowiązek wdrożyć proces zarządzania incydentami związanymi z ICT. Wpływa na politykę ciągłości działania ICT i strategię odporności, które same w sobie stanowią część ram zarządzania ryzykiem ICT.

DORA: Obowiązek rejestrowania wszystkich zdarzeń

Proces ten nie jest celem samym w sobie: musi rejestrować wszystkie istotne cyberzagrożenia i wszystkie zarejestrowane incydenty.

Zgodnie z Artykułem 17, proces zarządzania incydentami obejmuje:

• wprowadzenie wskaźników wczesnego ostrzegania;
• ustanowienie procedur identyfikowania, śledzenia, rejestrowania, kategoryzowania i klasyfikowania incydentów związanych z ICT według ich priorytetu i dotkliwości oraz krytyczności usług, na które incydenty te mają wpływ;
• przydzielenie ról i obowiązków, które należy wprowadzić w przypadku różnych rodzajów incydentów związanych z ICT i odnośnych scenariuszy;
• określenie planów działań informacyjnych skierowanych do pracowników, interesariuszy zewnętrznych i mediów oraz planów powiadamiania klientów, planów dotyczących wewnętrznych procedur eskalacji, w tym skarg klientów związanych z ICT, jak również, w stosownych przypadkach, dostarczania informacji podmiotom finansowym działającym jako kontrahenci;
• zapewnienie zgłaszania co najmniej poważnych incydentów związanych z ICT właściwej kadrze kierowniczej wyższego szczebla oraz informowanie organu zarządzającego co najmniej o poważnych incydentach związanych z ICT wraz z wyjaśnieniem wpływu, reakcji i dodatkowych kontroli, które należy ustanowić w wyniku takich incydentów związanych z ICT;
• ustanowienie procedur reagowania na incydenty związane z ICT w celu złagodzenia wpływu i zapewnienia przywrócenia operacyjności i bezpieczeństwa usług w rozsądnym terminie.

Klasyfikacja incydentów w ramach DORA

Zgodnie z Artykułem 18 DORA podmioty finansowe muszą klasyfikować zdarzenia w oparciu o następujące kryteria:

1. liczba lub znaczenie klientów lub kontrahentów finansowych oraz, w stosownych przypadkach, kwota lub liczba transakcji, których dotyczy incydent związany z ICT, oraz to, czy taki incydent spowodował skutki reputacyjne;
2. czas trwania incydentu związanego z ICT, w tym przerwa w świadczeniu usług;
3. zasięg geograficzny incydentu związanego z ICT, w szczególności jeżeli dotyczy on więcej niż dwóch państw członkowskich;
4. utrata danych w wyniku incydentu związanego z ICT w kontekście dostępności, autentyczności, integralności lub poufności danych;
5. krytyczność usług, których dotyczy incydent związany z ICT, w tym transakcji i operacji podmiotu finansowego;
6. skutki gospodarcze incydentu związanego z ICT, w szczególności bezpośrednie i pośrednie koszty i straty, zarówno w kategoriach bezwzględnych, jak i względnych.

Organizacje muszą również określić, czy cyberzagrożenie jest znaczące, na podstawie podobnej listy jak powyżej.

DORA ustala ogólne wytyczne dotyczące klasyfikacji incydentów, ale dokładne progi są nadal niejasne. Zostaną one określone przez Europejskie Urzędy Nadzoru, EBC i ENISA, które do 17 stycznia 2024 r. mają czas na przedstawienie Komisji swoich rekomendacji.

Obowiązkowe przeglądy po incydencie

Artykuł 13 nakłada na organizacje obowiązek przeprowadzania obowiązkowych przeglądów po wystąpieniu poważnego incydentu zakłócającego ich podstawową działalność.

Przeglądy te muszą określić:

• czy przestrzegano ustalonych procedur;
• i czy były skuteczne pod względem:
  • szybkości reagowania na alerty bezpieczeństwa i określania skutków zdarzenia oraz jego wagi;
  • jakości i szybkości wykonywania analizy kryminalistycznej;
  • skuteczności eskalacji incydentów w podmiocie finansowym;
  • skuteczności komunikacji wewnętrznej i zewnętrznej.

Zmiany wprowadzone w wyniku przeglądów po incydencie powinny być udostępniane właściwym organom.

12. Napisz plan reagowania na incydenty

Jedną z pierwszych rzeczy, które powinieneś zrobić, aby usprawnić proces zarządzania incydentami, jest sporządzenie (lub zweryfikowanie) planu reagowania na incydenty (IRP). Okaże się on nieoceniony w sytuacji konieczności udzielenia odpowiedzi – czy to partnerom, klientom, czy właściwym organom.

W Internecie dostępnych jest wiele przydatnych zasobów umożliwiających utworzenie protokołu IRP. Należy pamiętać, że musi on spełniać obowiązki w zakresie odpowiedzi wprowadzone przez DORA, co prowadzi nas bezpośrednio do następnego punktu.

Dowiedz się, do jakiego właściwego organu powinieneś się zgłosić

Przede wszystkim należy zauważyć, że właściwe organy nie są takie same dla wszystkich podmiotów finansowych. Temat jest zbyt szeroki, abyśmy mogli je tutaj wszystkie szczegółowo opisać. Dlatego odsyłamy do Artykułu 46 DORA, trafnie nazwanego „Właściwe organy”, który wyjaśni Twoją sytuację. Należy pamiętać, że ma tu zastosowanie zasada proporcjonalności, o której mówiliśmy wcześniej. Jeżeli podlegasz więcej niż jednemu organowi w kraju, państwo będzie musiało zdecydować, który z nich ma pierwszeństwo.

Ponadto, zgodnie z Artykułu 19(1), państwa mogą nałożyć na jeden lub więcej podmiotów finansowych na swoim terytorium obowiązek podwójnego reagowania:

• właściwemu organowi w ramach DORA;
• ale także właściwym organom lub Centrom Reagowania na Incydenty Bezpieczeństwa Komputerowego (CSIRT) wyznaczonym w ramach NIS 2.

Nie jest to obowiązkowe, ale możliwe. Do każdego podmiotu należy zatem weryfikacja własnej sytuacji.

Obowiązki informacyjne względem odpowiedniego organu

Powinieneś już wiedzieć, z jakim właściwym organem masz do czynienia. Pozostaje pytanie, kiedy się z nim skontaktować.

W przypadku poważnego zdarzenia, Artykuł 19(4) stanowi, że podmioty finansowe mają obowiązek przedłożyć właściwemu organowi:

• wstępne powiadomienie;
• raport pośredni, gdy tylko status pierwotnego incydentu ulegnie znaczącej zmianie lub sposób postępowania z poważnym incydentem ulegnie zmianie w oparciu o nowe dostępne informacje
  • w stosownych przypadkach aktualizowane powiadomienia za każdym razem, gdy dostępna jest odpowiednia aktualizacja statusu, a także na specjalne żądanie właściwego organu;
• raport końcowy, po zakończeniu analizy przyczyn źródłowych, niezależnie od tego, czy wdrożono już środki łagodzące, i kiedy dostępne są rzeczywiste dane dotyczące wpływu, które mogą zastąpić szacunki.

Podmioty finansowe mogą również dobrowolnie zgłaszać odpowiedniemu właściwemu organowi istotne zagrożenia cybernetyczne, jeżeli uznają to za istotne dla systemu finansowego, użytkowników usług lub klientów.

Należy również zauważyć, że rozporządzenie DORA umożliwia outsourcing obowiązków sprawozdawczych zewnętrznemu usługodawcy – zobacz Artykuł 19(5). Niemniej jednak podmiot finansowy pozostaje w pełni odpowiedzialny za przestrzeganie jego wymogów. W tym przypadku nie można zrzucać winy na dostawcę.

Jakie są terminy wykonywania obowiązków informacyjnych związanych z DORA?

Ramy czasowe obowiązujące dla poszczególnych powiadomień nie są jeszcze znane i muszą zostać określone przez Europejskie Urzędy Nadzoru, ENISA i EBC do 17 stycznia 2024 r. Niemniej jednak uważamy, że można bezpiecznie założyć, że terminy w ramach DORA będą podobne do tych wprowadzonych przez Dyrektywę NIS 2, która wymaga:

• wstępne powiadomienie w ciągu 24 godzin od wystąpienia poważnego incydentu;
• powiadomienie pośrednie w ciągu 72 godzin;
• sprawozdanie końcowe najpóźniej miesiąc po pierwszym powiadomieniu.

Obowiązki informacyjne względem klientów

DORA nakłada obowiązki powiadomienia nie tylko właściwych organów, ale także klientów. Zostało to określone w tym fragmencie:

„W przypadku gdy wystąpi poważny incydent związany z ICT, który ma istotny wpływ na interesy finansowe klientów, podmioty finansowe bez zbędnej zwłoki, gdy tylko się o nim dowiedzą, informują swoich klientów o poważnym incydencie związanym z ICT oraz o środkach, które podjęto w celu złagodzenia negatywnych skutków takiego incydentu.

W przypadku znaczącego cyberzagrożenia podmioty finansowe, w stosownych przypadkach, informują swoich klientów, których może ono dotyczyć, o wszelkich odpowiednich środkach ochrony, których podjęcie klienci ci mogą rozważyć.”

– DORA, Artykuł 19(3)

Dotarcie do klienta będzie oczywiście musiało opierać się na planach komunikacji kryzysowej, które omówiliśmy w punkcie 10.

13. Monitoruj cyberzagrożenia

Atakujący prześcigają się w pomysłowości, aby osiągnąć swoje cele, a niedocenianie ich byłoby dużym błędem. Dlatego działy Compliance i Security (CCO, CISO) muszą być świadome zmieniającego się krajobrazu zagrożeń cybernetycznych. Monitoring musi być wytrwały, zbiorowy i ciągły.

Cyberinteligencja to temat poruszony przez DORA w Artykule 13. Stanowi on, że podmioty finansowe muszą posiadać zdolność i odpowiednią kadrę do gromadzenia informacji na temat własnych słabych punktów i zagrożeń cybernetycznych. Muszą także stale monitorować rozwój technologiczny, aby określić wpływ, jaki może mieć wdrożenie nowych rozwiązań na wymogi w zakresie cyberbezpieczeństwa i operacyjnej odporności cyfrowej.

Raport roczny dotyczący najważniejszych incydentów w sektorze finansowym opublikowany przez ESAS

Artykuł 22 DORA nakłada na Europejskie Urzędy Nadzoru obowiązek publikowania rocznego, anonimowego oraz zbiorczego sprawozdania na temat poważnych incydentów ICT. Raport powinien zawierać liczbę poważnych incydentów, ich charakter i skutki, podjęte działania naprawcze oraz koszty. Towarzyszyć mu będą ostrzeżenia i „dane statystyczne wysokiego poziomu”.

Można bezpiecznie założyć, że raport roczny będzie jedną z podstaw dla zespołów cybersecurity w sektorze finansowym.

Ustalenie zasad wymiany informacji pomiędzy podmiotami finansowymi dotyczący cyber zagrożeń

DORA zachęca do wzajemnej pomocy w ramach systemu finansowego. Rozdział 6 stanowi, że podmioty finansowe mogą wymieniać między sobą informacje na temat zagrożeń cybernetycznych, w tym wskaźników kompromisu, technik i taktyk oraz procedur i narzędzi.

Taka wymiana informacji pomiędzy instytucjami finansowymi powinna:

• mieć na celu zwiększenie operacyjnej odporności cyfrowej podmiotów finansowych;
• odbywać się w zaufanych grupach podmiotów finansowych;
• opierać się na mechanizmach chroniących potencjalnie wrażliwy charakter udostępnianych informacji.

Sprawdź w przygotowanym wykazie dokumentów jakie konieczne procedury w zakresie monitorowania zagrożeń wymienia rozporządzenie DORA.

Wymiany informacji należy prowadzić z pełnym poszanowaniem tajemnicy biznesowej, RODO i wytycznych dotyczących polityki konkurencji. Ustalenia dotyczące udostępniania muszą określać konkretne sposoby udostępniania (gdzie, jak?) oraz warunki uczestnictwa, których należy przestrzegać – w przypadku podmiotów finansowych, a także organów publicznych i dostawców usług ICT. Ponadto każdy podmiot finansowy, niezależnie od uczestnictwa w takim programie, musi powiadomić odpowiednie władze o zdarzeniu.

14. Przeprowadź badanie operacyjnej odporności cyfrowej

Testowanie operacyjnej odporności cyfrowej jest integralną częścią strategii operacyjnej odporności cyfrowej i DORA poświęca im cały Rozdział 4. Należy zaznaczyć, że większość tych wymagań nie dotyczy mikroprzedsiębiorstw. Jeśli tak jest w Twoim przypadku, zapraszamy do przeczytania Rozdziału 4 (zwłaszcza Artykuł 25(3)) w celu ustalenia, które punkty mają zastosowanie w Twoim przypadku.

Zmapuj swój system informatyczny

Przed przetestowaniem zasobów cyfrowych musisz je zidentyfikować. Bez zmapowania całego środowiska IT nie jest możliwe przeprowadzenie skutecznego testu. Jest to obowiązek wynikający z DORA, ponieważ stanowi obowiązkowy element ram zarządzania ryzykiem ICT. Ten krok pozwoli Ci:

• mieć wysokopoziomowy pogląd na aktywa organizacji;
• następnie sklasyfikować je według krytyczności i poziomu ryzyka.

Badanie operacyjnej odporności cyfrowej powinno być wykonywane co najmniej raz w roku

Według słów DORA podmioty finansowe zapewniają „ co najmniej raz w roku, przeprowadzenie odpowiednich testów wszystkich systemów i aplikacji ICT wspierających krytyczne lub istotne funkcje”. (Artykuł 24(6)).

Przeglądy te są pogrupowane w cyfrowy program testów operacyjnej odporności cyfrowej, w którym należy przyjąć podejście oparte na ryzyku. Powinien obejmować „szereg ocen, testów, metodologii, praktyk i narzędzi”.

Artykuł 25 DORA określa niektóre typologie testów, takie jak:

• oceny i skanowanie podatności;
• analizy open source;
• oceny bezpieczeństwa sieci;
• analizy luk;
• przeglądy bezpieczeństwa fizycznego;
• kwestionariusze i oprogramowanie do skanowania;
• przeglądy kodu źródłowego, jeśli to możliwe;
• testy oparte na scenariuszach;
• testowanie kompatybilności;
• test wydajności;
• kompleksowe testowanie;
• i testy penetracyjne.

Testy mogą być wykonywane wewnętrznie lub przez dostawców zewnętrznych. Jeżeli testowanie przeprowadza wewnętrzny tester, podmioty finansowe powinny przeznaczyć wystarczające zasoby na test i zapewnić uniknięcie konfliktu interesów na etapie projektowania i wykonywania testu.

DORA: obowiązek reakcji na zidentyfikowane luki i naprawy bezpieczeństwa

Wykrywanie luk w zabezpieczeniach nie ma sensu, jeśli nie zostaną one później załatane. DORA formalizuje naprawę wszystkich luk wykrytych podczas testów:

„Podmioty finansowe inne niż mikroprzedsiębiorstwa ustanawiają procedury i zasady ustalania hierarchii, klasyfikowania i rozwiązywania wszystkich problemów ujawnionych w trakcie przeprowadzania testów oraz ustanawiają wewnętrzne metody zatwierdzania w celu dopilnowania, aby w pełni usunięto wszystkie stwierdzone słabości, niedoskonałości lub luki.”

– DORA, Artykuł 24(5)

Oznacza to, że nie można pominąć nawet „niskich” lub „średnich” podatności. Naprawa musi być całkowita. Jest to temat, którym należy się zająć we współpracy z zespołami programistycznymi, CIO i innym odpowiednim menedżerem.

Daj zespołowi czas na naprawę

Zdarza się, że łatanie podatności jest postrzegane jako „dodatkowe” zadanie, które należy wykonać, gdy programista ma trochę wolnego czasu. Jest to jednak coś, co należy w pełni uwzględnić w harmonogramie zespołów IT.

Chociaż najbardziej krytyczne luki muszą zostać usunięte natychmiast, pozostałe można na przykład usunąć podczas tygodniowego lub miesięcznego sprawdzenia błędów, w zależności od wielkości zespołów. Niezależnie od wybranego podejścia ważne jest, aby zdać sobie sprawę, że usuwanie luk w zabezpieczeniach jest co najmniej tak samo ważne, jak opracowywanie nowych funkcji.

Zachęcaj do wykorzystania bezpiecznych metod rozwoju systemów

Cyberbezpieczeństwo w fazie projektowania to temat, który jest omawiany szeroko i nie bez powodu. Ważne jest, aby od samego początku uwzględniać bezpieczeństwo produktów i usług. Jest to podejście zalecane przez NIS 2, ale także unijną ustawę o cyberbezpieczeństwie z czerwca 2019 r.

Oczywiście nie można oczekiwać, że CISO przeszkoli zespoły programistów w zakresie praktyk bezpiecznego programowania. Niemniej jednak nic nie stoi na przeszkodzie, aby pójść o krok dalej i uświadomić ludziom to zagadnienie. Jest to zagadnienie, które można realizować wspólnie z CTO zespołami SOC, lub ekspertami ds. bezpieczeństwa wewnętrznego. Od szkoleń po warsztaty i CTF (Capture The Flag) możliwości jest mnóstwo.

15. Stwórz plan testów penetracyjnych

W poprzedniej sekcji omówiliśmy „tradycyjne” testowanie, za które co roku odpowiadają wszystkie podmioty działające w ramach DORA. Jednak niektóre organizacje podlegają dodatkowym wymogom testowania, zwanym także „testami penetracyjnymi opartymi na zagrożeniach” (TLPT).

Jakie podmioty podlegają zaawansowanym testom bezpieczeństwa?

Wszystko zależy od właściwych organów. Artykuł 26(8) DORA nakłada na nie obowiązek „identyfikacji podmiotów finansowych, które są zobowiązane do wykonania TLPT […] na podstawie oceny”:

• czynników związanych z wpływem, w szczególności zakresu, w jakim świadczone usługi i działaniami podejmowane przez podmiot finansowy mają wpływ na sektor finansowy;
• ewentualnych obaw dotyczących stabilności finansowej, w tym systemowego charakteru podmiotu finansowego na poziomie unijnym lub krajowym, stosownie do przypadku;
• specyficznego profilu ryzyka związanego z ICT, poziomu zaawansowania podmiotu finansowego pod względem ICT lub zastosowanych rozwiązań technologicznych.

Właściwe organy powinny stosować zasadę proporcjonalności przy podejmowaniu decyzji o podmiotach podlegających zaawansowanym testom.

Czym jest test penetracyjny oparty o scenariusze realizacji zagrożeń?

Oficjalna definicja podana przez DORA:

„testy penetracyjne pod kątem wyszukiwania zagrożeń (TLPT)” oznaczają ramy naśladujące taktykę, techniki i procedury stosowane w rzeczywistości przez agresorów uznanych za stanowiących rzeczywiste cyberzagrożenie, które zapewniają kontrolowane, dostosowane do konkretnych zagrożeń, oparte na analizie zagrożeń (red team) testy działających na bieżąco krytycznych systemów produkcji podmiotu finansowego;”

– DORA, Artykuł 3(17)

Obowiązkowe kryteria dla testu penetracyjnego opartego o scenariusze realizacji zagrożeń

Oficjalna definicja wyjaśnia koncepcję, ale nie szczegóły techniczne. Na szczęście Artykuł 26 określa pewne obowiązkowe kryteria testu penetracyjnego opartego na zagrożeniach:

• Test musi „obejmować kilka lub wszystkie krytyczne lub ważne funkcje” podmiotu finansowego;
• Zakres określa sam podmiot, ale zatwierdzają go właściwe władze;
  • Jeżeli zakres obejmuje usługi ICT stron trzecich, podmiot musi podjąć „niezbędne środki i zabezpieczenia w celu zapewnienia udziału” odpowiedniego dostawcy. Pełna odpowiedzialność pozostaje po stronie podmiotu.
• Testowanie należy przeprowadzić w działających środowiskach produkcyjnych;
• Test należy przeprowadzać przynajmniej co 3 lata. Właściwe organy mogą zmniejszyć lub zwiększyć tę częstotliwość w przypadku konkretnego podmiotu w oparciu o jego profil ryzyka lub okoliczności operacyjne.
• Na zakończenie testu podmiot finansowy musi przedłożyć właściwym organom podsumowanie odpowiednich ustaleń, plany działań naprawczych oraz dokumentację wykazującą, że test został przeprowadzony zgodnie z wymogami.
• W zamian władze wydają certyfikat „w celu umożliwienia wzajemnego uznawania testów penetracyjnych na podstawie zagrożeń pomiędzy właściwymi organami”.

Łączone testy dla dostawców usług ICT

Może się zdarzyć, że dostawca usług ICT nie będzie mógł zostać uwzględniony, ponieważ miałoby to wpływ na bezpieczeństwo jego usług lub jakość testu. Podobnie mogą zaistnieć przypadki, w których dostawca jest dostawcą na rzecz różnych podmiotów finansowych. W takich przypadkach DORA stanowi wyjątek.

Dostawca może przeprowadzić „grupowe TLPT” obejmujące kilka podmiotów finansowych, dla których świadczy usługi. Dostawca musi wówczas:

• zgodzić się na test na piśmie z różnymi podmiotami;
• podpisać umowy kontraktowe z zewnętrznym testerem;
• zapewnić, że test obejmuje wszystkie usługi ICT wspierające krytyczne i ważne funkcje podmiotów finansowych;
• przeprowadzić test pod nadzorem wyznaczonego podmiotu finansowego.

Jeżeli tak, Artykuł 26(4) stanowi, że test grupowy uznaje się jako „TLPT przeprowadzony przez podmioty finansowe biorące udział w tym testowaniu zbiorczym”.

Ramy TYBER-UE dotyczące wymogów operacyjnych

DORA ustala wytyczne dotyczące testów penetracyjnych opartych na zagrożeniach, ale wymagania operacyjne spełniają inne ramy europejskie. Ramy TIBER-UE określają zasady dotyczące zakresu testu, metodologii i podejścia, które należy zastosować na każdym konkretnym etapie testu, od budowy po naprawę.

Ramy TIBER-UE są obecnie wdrażane w różnych krajach UE i mają obowiązywać wszystkich członków wspólnoty. Na przykład TIBER-BE dla Belgii, TIBER-LU dla Luksemburga, TIBER-DK dla Danii itp. Należy zauważyć, że obecnie w Europie nie ma agencji certyfikującej dla dostawców testów TIBER-EU.

Jak wybrać na rynku testera do przeprowadzenia testu penetracyjnego opartego o scenariusze realizacji zagrożeń?

Przede wszystkim, warto zaznaczyć, że podmioty finansowe mogą korzystać z testerów wewnętrznych, przy czym co trzeci test musi być przeprowadzony przez testera zewnętrznego. Wyjątkiem od tej reguły są instytucje kredytowe sklasyfikowane jako duże, które muszą zawsze polegać na zewnętrznym testerze.

Mając to na uwadze, Artykuł 27 DORA szczegółowo określa wymagania wobec testerów, którzy mogą przeprowadzać testy penetracyjne oparte na zagrożeniach. Testerzy muszą:

• posiadać najwyższą reputację;
• posiadać możliwości techniczne i organizacyjne oraz wykazać się specjalistyczną wiedzą w zakresie wywiadu o zagrożeniach, testów penetracyjnych i testów Red Team;
• przestrzegać formalnych kodeksów postępowania lub ram etycznych lub posiadać certyfikat jednostki akredytującej w Państwie Członkowskim;
• przedstawić niezależne zapewnienie lub raport z audytu w związku z należytym zarządzaniem ryzykiem związanym z realizacją TLPT, w tym należytą ochroną informacji poufnych podmiotu finansowego i zadośćuczynieniem za ryzyko biznesowe podmiotu finansowego;
• być należycie i w pełni objęci odpowiednim ubezpieczeniem od odpowiedzialności zawodowej, w tym od ryzyka niewłaściwego postępowania i zaniedbania.

16. Edukuj pracowników i kierownictwo w zakresie cyberbezpieczeństwa

Istotne jest zaplanowanie szkoleń, zarówno dla pracowników na poziomie zarządu, jak i dla wszystkich pracowników – w zależności od umiejętności i obowiązków każdej osoby. Ryzyko związane z pracownikami organizacji jest co najmniej równe – jeśli nie większe – ryzyku związanemu z cyberatakami. Podsumowując: nie ma sensu mieć najlepszych procesów i technologii, jeśli połowa personelu zapisuje hasła na dokumentach lub przekazuje poufne informacje zwykłym tekstem. Jeśli osoby zarządzające Twoją organizacją nie zostaną przeszkolone w zakresie podstawowych praktyk higieny cybernetycznej, bezpieczeństwo Twojej organizacji będzie zagrożone.

DORA: obowiązkowe szkolenia dla pracowników i kadry zarządzającej

NIS 2 wprowadza obowiązkowe szkolenia z zakresu zarządzania cyber ryzykiem dla organów zarządzających, ale jedynie zachęca do tego pracowników. DORA natomiast idzie dalej i narzuca obowiązkowe szkolenia z zakresu operacyjnej odporności cyfrowej zarówno dla kadry kierowniczej, jak i pracowników. Ostateczny tekst jest bardzo jasny:

„Podmioty finansowe w ramach swoich programów szkoleniowych dla personelu przygotowują obowiązkowe moduły obejmujące programy zwiększania świadomości w zakresie bezpieczeństwa ICT oraz szkolenia w zakresie operacyjnej odporności cyfrowej. Skierowane są one do wszystkich pracowników oraz do kadry kierowniczej wyższego szczebla, a ich poziom złożoności jest współmierny do funkcji pełnionych przez te osoby. W stosownych przypadkach podmioty finansowe obejmują też zewnętrznych dostawców usług ICT swoimi odnośnymi systemami szkoleń.”

– DORA, Artykuł 13(6)

CISO jest prawdopodobnie jedną z najlepiej przygotowanych osób do kierowania wyborem szkoleń (lub dostawców) we współpracy z działem kadr i menedżerami każdego działu. Właściwe szkolenie pracowników to ogromne przedsięwzięcie, przekrojowe dla różnych zawodów, które należy podjąć jak najszybciej.

17. Oceń ryzyko stron trzecich ICT i zarządzaj ich ryzykiem

Bezpieczeństwo łańcucha dostaw jest sercem NIS 2 i DORA się do niego dostosowuje. Rozporządzenie kładzie szczególny nacisk na zarządzanie ryzykiem związanym z dostawcami usług ICT.

Należy zauważyć, że ten obszar należy do zadań CISO, ale także działów prawnych. Wiele wymagań DORA dotyczących dostawców ma bezpośredni wpływ na treść umów regulujących współpracę. Omówimy część, której większość zadań mieści się w sferze prawno-umownej, a nie operacyjnej. Zalecamy przeczytanie całego Rozdziału 5 DORA.

Należy także zaznaczyć, że DORA wymaga od podmiotów finansowych zarządzania ryzykiem związanym z usługodawcami „zgodnie z zasadą proporcjonalności, z uwzględnieniem charakteru, zakresu, złożoności i wagi stosunków zależności” oraz ryzykami wynikającymi z tych ustaleń.

Wdróż strategię zarządzania ryzykiem dostawców ICT

Artykuł 28(2) wymaga od podmiotów finansowych „przyjęcia strategii dotyczącej ryzyka stron trzecich w zakresie ICT” i regularnego jej przeglądu. Strategia ta sama musi obejmować politykę dotyczącą korzystania z usług wspierających funkcje krytyczne lub ważne. Organ zarządzający musi także „regularnie” dokonywać przeglądu ryzyka zidentyfikowanego w odniesieniu do tych samych usług i umów. Ponownie DORA jest zgodna z zarządzaniem NIS 2. Cyberbezpieczeństwo nie powinno być wyłączną odpowiedzialnością zespołów operacyjnych, a najwyższe kierownictwo musi również być świadome ryzyka i brać za nie odpowiedzialność.

W ramach ram zarządzania ryzykiem ICT podmioty finansowe muszą również prowadzić i aktualizować „rejestr informacji w odniesieniu do wszystkich ustaleń umownych dotyczących korzystania z usług ICT świadczonych przez zewnętrznych dostawców usług ICT”

Krótko mówiąc: musisz mieć pełną inwentaryzację całego ekosystemu dostawców ICT. Musisz wyraźnie rozróżniać dostawców obsługujących funkcje krytyczne od tych, którzy tego nie robią. Rejestr ten należy udostępnić właściwym organom, jeżeli o to poproszą.

Co powinieneś zrobić przed zawarciem umowy z dostawcą ICT?

Artykuł 28(4) bardzo jasno określa zasady, których należy przestrzegać. Przed zawarciem umowy o korzystanie z usług ICT podmioty finansowe mają obowiązek:

• ocenić, czy ustalenia umowne obejmują korzystanie z usług ICT wspierających funkcję krytyczną lub ważną;
• ocenić, czy spełnione są warunki nadzoru dotyczące zawierania kontraktów;
• zidentyfikować i ocenić wszystkie istotne ryzyka związane z ustaleniami umownymi, w tym możliwość, że takie ustalenia umowne mogą przyczynić się do wzmocnienia ryzyka koncentracji ICT;
• dołożyć należytej staranności wobec potencjalnych zewnętrznych dostawców usług ICT i podczas całego procesu selekcji i oceny zapewnić, że zewnętrzny dostawca usług ICT jest odpowiedni;
• identyfikować i oceniać konflikty interesów, jakie może powodować ustalenie umowne;
• w stosownych przypadkach określić z wyprzedzeniem obszary podlegające audytowi i częstotliwość inspekcji.

Jeśli chodzi o listę głównych postanowień umownych, których należy przestrzegać, odsyłamy Cię bezpośrednio do Artykułu 30.

Zaplanuj strategię wyjścia ze współpracy z kluczowymi dostawcami ICT

Artykuł 28(8) wzywa podmioty finansowe do posiadania „kompleksowych i udokumentowanych” strategii wyjścia w przypadku usług wspierających funkcje krytyczne lub ważne. Strategia wyjścia musi obejmować co najmniej:

• alternatywne rozwiązania;
• plany przejściowe dotyczące usuwania usług i danych przechowywanych przez dostawcę;
• oraz bezpieczne i pełne przekazanie ich alternatywnym dostawcom lub ponowne włączenie ich do wewnątrz.

Artykuł 28(7) określa warunki, na jakich należy rozwiązać te ustalenia umowne – większość powodów jest związana z brakiem bezpieczeństwa lub należytej staranności ze strony dostawcy.

Krytyczni dostawcy ICT według EUN

Należy zauważyć, że Europejskie Urzędy Nadzoru mają prawo uznawać niektórych dostawców usług za kluczowych dla podmiotów finansowych. Wspomniani dostawcy podlegają wówczas nadzorowi głównego organu nadzoru, czyli Europejskiego Urzędu Nadzoru wyznaczonego do tej roli, czyli w Polsce KNF. Ramy nadzoru są niezwykle obszerne i obejmują ponad 10 artykułów rozporządzenia. Jeśli więc interesuje Cię ten temat, zapraszamy do przeczytania artykułów od 31 do 44 DORA.

W skrócie

Europejski sektor finansowy ma czas do 17 stycznia 2025 r. na przygotowanie się do wdrożenia ustawy o operacyjnej odporności cyfrowej. Zadanie jest poważne i będzie wymagało dyscypliny, zasobów, a przede wszystkim czasu. Dlatego też doradzamy wszystkim CISO podmiotów objętych zakresem rozporządzenia, aby od razu rozpoczęli prace nad zapewnieniem zgodności.

Większość prac powinna skupiać się na trzech głównych obszarach:

• ramy zarządzania ryzykiem ICT;
• cyfrowe testy operacyjnej odporności cyfrowej;
• zarządzanie ryzykiem stron trzecich ICT.

Te kluczowe tematy regulacyjne podzieliliśmy na 17 etapów działań, które staraliśmy się przedstawić w jak najbardziej konkretny sposób. Prawdopodobnie najrozsądniej będzie zacząć od opracowania i wdrożenia obowiązkowych polityk wprowadzonych przez DORA.

Do ram zarządzania ryzykiem ICT należy dołączyć:

• strategię cyfrowej odporności operacyjnej;
• politykę ciągłości działania ICT;
• procedury tworzenia kopii zapasowych, przywracania i odtwarzania;
• zapisy działań na wypadek zakłóceń;
• proces zarządzania incydentami;
• plan reagowania na incydenty;
• plany komunikacji kryzysowej.

Po stronie testów bezpieczeństwa konieczne będzie przeprowadzenie:

• testów cyfrowej odporności operacyjnej przynajmniej raz w roku;
• w przypadku konkretnych podmiotów testy penetracyjne oparte na zagrożeniach przynajmniej co 3 lata, zgodnie z ramami TIBER-UE.

DORA kładzie tak duży nacisk na ryzyko ICT, że głównym celem zapewnienia zgodności stanie się zarządzanie ryzykiem związanym z zewnętrznymi dostawcami. Zarządzanie ryzykiem będzie  wymagało odpowiedniej strategii cyberodporności, a więc wsparcia działu prawnego Twojej organizacji, a może nawet wspólnego działania w uwzględnieniu obszaru ICT w strategii. Prawdopodobnie zespoły prawne będą odgrywały ważną rolę w zapewnieniu zgodności z rozporządzeniem DORA, a zespoły bezpieczeństwa  będą musiały zarządzać ryzykiem, w tym współpracą z dostawcami i dokumentować ją od początku do końca, od obowiązkowych postanowień umownych, po plany wyjścia dla najbardziej ryzykownych dostawców.