Wdrożenie wymagań wynikających z rozporządzenia DORA dla podmiotów finansowych

Celem, wspomnianych wyżej, konsultacji publicznych było zebranie opinii uczestników rynku na temat proponowanych projektów rozporządzeń wykonawczych do Rozporządzenia DORA. Jednym z nich jest rozporządzenie dotyczące standardów technicznych określających elementy związane z testami penetracyjnymi pod kątem wyszukiwania zagrożeń (dalej: „RTS dla TLPT”) wydane na podstawie delegacji wynikającej z art. 26 ust 11 Rozporządzenia DORA. W ramach Rozporządzenia DORA, podmioty finansowe są zobowiązane do przeprowadzania zaawansowanych testów penetracyjnych, bazujących na zagrożeniach (dalej: „TLPT”; skrót od Threat-Led Penetration Testing).

Z uzasadnienia do projektu RTS dla TLPT oraz z motywu nr 1 do rozporządzenia RTS dla TLPT wynika, że rozporządzenie zostało sporządzone zgodnie z ramami TIBER-EU³ i odzwierciedla metodykę, proces i strukturę TLPT opisane w TIBER-EU. Podmioty finansowe podlegające TLPT mogą powoływać się na ramy TIBER-EU i je stosować, o ile ramy te są spójne z wymogami określonymi w art. 26 i 27 Rozporządzenia DORA oraz rozporządzenia RTS dla TLPT.⁴

***

Czym są testy penetracyjne prowadzone pod kątem wyszukiwania zagrożeń (TLPT), o których mowa w art. 26 Rozporządzenia DORA? Zgodnie z art. 3 pkt 7 Rozporządzenia 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żenia, 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.

Zatem TLPT to prowadzone przez zespół Red-Teamu⁵ (projekt RTS dla TLPT nie zawiera legalnej definicji „Red Team”; vide: wyjaśniania w przypisie), w oparciu o analizę zagrożeń zawansowane testy bezpieczeństwa. Będą prowadzone pod nadzorem krajowego organu właściwego dla TLPT⁶. Mają na celu weryfikację rzeczywistej odporności podmiotu finansowego. Należy wyjaśnić, że dzięki podejściu „pod kątem wyszukiwania zagrożeń” lub „na analizie zagrożeń” (threat intelligence; por. art. 3 pkt 15) Rozporządzenia DORA)⁷, testy penetracyjne typu TLPT są bardziej ukierunkowane i realistyczne, ponieważ skupiają się na najbardziej prawdopodobnych scenariuszach ataku, co pozwala podmiotowi zobowiązanemu lepiej zrozumieć istniejące ryzyko oraz podjąć odpowiednie kroki w celu poprawy bezpieczeństwa systemów informatycznych czy też zaplanować strategie bezpieczeństwa na kolejne lata. Testy penetracyjne prowadzone pod kątem wyszukiwania zagrożeń wymagają zaangażowania zespołu zajmującego się analizą zagrożeń tj. zespołu Threat Intelligence (por. art. 1 pkt 8 projektu RTS dla TLPT)⁸. Zespół typu Threat Intelligence to zespół, w skład którego wchodzi ekspert bądź eksperci spoza podmiotu zobowiązanego do przeprowadzenia testu, którzy zbierają i analizują informacje dotyczącą zagrożeń dla jednostki, która ma stanowić podstawę do przeprowadzenia testów TLPT oraz opracowują na potrzeby testów TLPT istotne i realistyczne scenariusze zagrożeń.

Musi być zrozumiałe, że TLPT obejmują testy na dużą skalę, które muszą symulować wszystkie elementy rzeczywistego ataku i testować powierzchnię ataku regulowanych podmiotów.

***

Należy wyjaśnić, że już samo Rozporządzenie DORA w art. 26 reguluje wymagania, kryteria dla przeprowadzenia testów penetracyjnych pod kątem analizy zagrożeń. Zgodnie z art. 26 Rozporządzenia DORA testy:

• Przeprowadzane są przez podmioty finansowe nie rzadziej niż co trzy lata (art. 26 ust 1 zd. 1 Rozporządzenia DORA)
• Każdy test penetracyjny pod kątem wyszukiwania zagrożeń obejmuje:
  a) kilka krytycznych lub istotnych funkcji podmiotu finansowego lub wszystkie te funkcje i
  b) jest przeprowadzany na działających systemach produkcyjnych wspierających takie funkcje (Art. 26 ust 2 zd. 1 Rozporządzenia DORA).
• Podmioty finansowe oceniają, które krytyczne lub istotne funkcje należy objąć TLPT. Wynik tej oceny określa dokładny zakres TLPT i podlega zatwierdzeniu przez właściwe organy. (Art. 26 ust 2 zd.2 i 3 Rozporządzenia DORA).
• W przypadku gdy zakres TLPT obejmuje zewnętrznych dostawców usług ICT, podmiot finansowy stosuje niezbędne środki i zabezpieczenia w celu zapewnienia udziału takich zewnętrznych dostawców usług ICT w TLPT i przez cały czas ponosi pełną odpowiedzialność za zapewnianie zgodności z niniejszym rozporządzeniem (art. 26 ust 3 Rozporządzenia DORA)
• Podmioty finansowe – we współpracy z zewnętrznymi dostawcami usług ICT i innymi zaangażowanymi stronami, w tym testerami, ale z wyłączeniem właściwych organów – stosują skuteczne środki kontroli zarządzania ryzykiem w celu złagodzenia ryzyka potencjalnego wpływu na dane, szkód dla zasobów i zakłócenia krytycznych lub istotnych funkcji, usług lub operacji samego podmiotu finansowego, jego kontrahentów lub sektora finansowego (art. 26 ust 5 Rozporządzenia DORA).
• Na koniec testowania, po uzgodnieniu sprawozdań i planów naprawczych, podmiot finansowy i, w stosownych przypadkach, testerzy zewnętrzni przedstawiają organowi podsumowanie najbardziej istotnych ustaleń, plany naprawcze i dokumentację wykazującą, że TLPT przeprowadzono zgodnie z wymogami (art. 26 ust 6 Rozporządzenia DORA)
• Organy przekazują podmiotom finansowym poświadczenie, że test został przeprowadzony zgodnie z wymogami potwierdzonymi w dokumentacji, aby umożliwić właściwym organom wzajemne uznawanie testów penetracyjnych pod kątem wyszukiwania zagrożeń. Podmiot finansowy powiadamia odpowiedni właściwy organ o poświadczeniu, podsumowaniu najbardziej istotnych ustaleń i planach naprawczych. Bez uszczerbku dla takiego poświadczenia podmioty finansowe przez cały czas ponoszą pełną odpowiedzialność za skutki testów (art. 26 ust 7 Rozporządzenia DORA).

Natomiast w części zawartej w art. 26 ust 11 Rozporządzenie DORA odsyła do RTS dla TLPT. Zgodnie z art. 26 ust 11 Rozporządzenia Dora Europejskie Urzędu Nadzoru (EUN), w porozumieniu z Europejskim Banku Centralnym, opracowują wspólne projekty regulacyjnych standardów technicznych zgodnie z ramami TIBER–EU, aby doprecyzować w szczególności kwestie związane z wymogami lub standardami związanymi z wykorzystaniem testerów, zakresu TLPT, metodyk testowania i podejść, które należy stosować na każdym konkretnym etapie procesu testowania, wymogów dotyczących etapów testów odnoszące się do wyników, zamykania i środków naprawczych, kwestie związane z nadzorem organu i współpracą w ramach prowadzenia testów. EUN przedkładają Komisji te projekty regulacyjnych standardów technicznych do dnia 17 lipca 2024 r.⁹

***

O ile samą koncepcję przeprowadzenia testów typu TLPT - ze wskazanych wyżej względów, z których wynika, że TLPT są kluczowym elementem strategii bezpieczeństwa informacji w organizacji - można ocenić pozytywnie, to rodzi on jednak wiele wątpliwości interpretacyjnych i co może wpłynąć na niejednolitą praktykę na rynku usług finansowych.

Obowiązkowe prowadzenie testów TLPT wymaga - od podmiotu objętego wymaganiami wynikającymi z Rozporządzenia DORA - wdrożenia odpowiedniego planu przeprowadzenia testów oraz przeznaczenia odpowiednich zasobów (zarówno finansowych, jak i kadrowych). Natomiast brzmienie proponowanych przepisów (w szczególności artykułu 2 RTS dla TLPT) często nie daje podmiotom finansowym jednoznacznej odpowiedzi, na pytanie które z nich zostaną ostateczne zobligowane przez organ właściwy do TLPT do przeprowadzenia testów TLPT. Co sprawia, że przygotowanie lub zaplanowanie takich działań może stanowić dla podmiotu zobowiązanego wyzwanie organizacyjne. W związku z tym, istotne wydaje się szczegółowe określenie w regulacji grup podmiotów, które są zobowiązane do wykonania testów, na przykład poprzez ustalenie konkretnych kryteriów, które pozwoliłyby na rozpoznanie podmiotu finansowego jako takiego, od którego wymaga się przeprowadzenia TLPT. Jednocześnie RTS dla TLPT nie reguluje żadnego trybu odwoławczego związanego ze zobowiązaniem danego podmiotu do przeprowadzenia testów, dlatego Europejskie Organu Nadzoru powinny rozważyć wdrożenie zmian w projekcie RTS dla TLPT dotyczących ewentualnej drogi odwoławczej dla zobowiązanej organizacji w sytuacji, w której organ właściwy dla TLPT wyda decyzję o przeprowadzeniu testów TLPT.

Kolejnym elementem, który może wzbudzać niepewność jest fakt, że treść projektowanych zmian przewiduje wysoki poziom zaangażowania organu nadzorczego właściwego dla testów TLPT (dalej: „organ TLPT”). Z projektu RTS dla TPLT wynika m.in., że:

• organ TLPT ocenia i zatwierdza dokumenty inicjujące postępowanie dotyczące TLPT przygotowane przez zobowiązany podmiot,
• zatwierdza dokument specyfikacji testów TLPT,
• zatwierdza korzystanie z testerów wewnętrznych
• zatwierdza sprawozdanie wywiadowcze w ramach fazy przygotowawczej obejmującej analizę zagrożeń (przygotowane przez zespół Threat Intelligence),
• zatwierdza plan testów Red Team,
• ma możliwość wniesienia zastrzeżeń co do dostawców informacji o zagrożeniach (threat intelligence providers) oraz testerów zewnętrznych,
• może zgłosić zastrzeżenia do oceny ryzyka oraz do związanych z nią środków zarządzania ryzykiem, jeżeli nie będą one w odpowiedni sposób adresować ryzyka TLPT,
• zatwierdza wszelkie zmiany w planie testów Red Teamu po jego zatwierdzeniu, w tym w harmonogramie, zakresie, systemach,
• bierze udział w uzgodnieniu zakończenia fazy testowania przez Red Team,
• zatwierdza procedurę „legs-up”¹⁰,
• waliduje środki umożliwiające kontynuowanie testu w przypadku wykrycia testu przez któregokolwiek członka personelu podmiotu zobowiązanego
• zatwierdza zawieszenie testu,
• zatwierdza sprawozdanie podsumowujące test etc.¹¹.

Z jednej strony RTS dla TLPT przewiduje szereg uregulowanych działań dla testów penetracyjnych dla TLPT a z drugiej brakuje pewnych uregulowań np. brak uregulowania kwestii związanej z przypadkiem zarejestrowania incydentu wykrytego w ramach testów przez blue team¹² oraz działaniem samego organu właściwego dla TLPT w tym zakresie.

Dodatkowo RTS dla TLPT nie określa jednoznacznie terminów, w których organ właściwy dla TLPT zobowiązany jest do określonych w rozporządzeniu działań. Dla większości obowiązków brakuje informacji na temat ram czasowych, w których organ TLPT powinien zatwierdzić (podjąć decyzję), wnieść zastrzeżenia, etc. Przykłady braku terminów zawarte są w obowiązkach organu TLPT określonych w artykułach 6, 7 i 8 projektu RTS dla TLPT. Kolejnym elementem związanym z zaangażowaniem organu TLPT jest brak uregulowania kwestii związanej z wydłużeniem czasu trwania testów w przypadku, w którym podmiot finansowy oczekuje na odpowiedź ze strony organu TLPT.

Podsumowując, wydaje, że tak dalekie zaangażowanie organu właściwego dla TLPT może nie spełnić swojej funkcji, wydłużać test oraz generować znaczne koszty po stronie zobligowanego podmiotu finansowego. Jednocześnie mamy brak określonych ram czasowych na podejmowanie działań przez organ właściwy dla TLPT.

***

Kończąc: rozporządzenie wykonawcze dotyczące testów penetracyjnych typu TLPT do Rozporządzenia DORA stanowi ważny krok w kierunku poprawy bezpieczeństwa infrastruktury rynków finansowych w UE poprzez standaryzację i zwiększenie świadomości w zakresie cyberbezpieczeństwa. Natomiast niezbędne jest doprecyzowanie wskazanych wyżej zapisów (definicji, określenia podmiotów zobowiązanych oraz zaangażowania organu TLPT w testy), które w praktyce będą sprawiać problemy interpretacyjne. Ważne jest, aby podmioty finansowe przeprowadzały regularne testy penetracyjne typu TLPT jako część kompleksowego programu zarządzania ryzykiem cyberbezpieczeństwa.

¹ EBA, EIOPA i ESMA to trzy europejskie agencje nadzoru finansowego, które mają za zadanie zapewnienie stabilności, przejrzystości, efektywności i prawidłowego funkcjonowania rynków finansowych w Unii Europejskiej. Każda z tych instytucji skupia się na określonym segmencie rynku finansowego: EBA (Europejski Urząd Nadzoru Bankowego) Homepage | European Banking Authority (europa.eu) zajmuje się regulacją i nadzorem nad sektorem bankowym w Unii Europejskiej. EBA pracuje nad utrzymaniem efektywnego i jednolitego ramy prawnej dla europejskiego sektora bankowego, promując harmonizację regulacji bankowych w UE. Celem EBA jest zapewnienie stabilności finansowej, ochrona deponentów, inwestorów i konsumentów finansowych. EIOPA (Europejski Urząd Ubezpieczeń i Pracowniczych Programów Emerytalnych) Homepage - European Union (europa.eu) odpowiada za nadzór nad sektorem ubezpieczeń i pracowniczych programów emerytalnych. EIOPA dąży do zapewnienia skutecznego i spójnego poziomu regulacji i nadzoru w całej UE, promując przejrzystość, uproszczenie i uczciwość rynków ubezpieczeń i emerytalnych dla obywateli Unii. ESMA (Europejski Urząd Nadzoru i Giełd Papierów Wartościowych) European Securities and Markets Authority (europa.eu) koncentruje się na nadzorze rynków papierów wartościowych oraz inwestycji, w tym rynków pochodnych i infrastruktury rynku finansowego. ESMA ma za zadanie zwiększenie ochrony inwestorów i promowanie stabilnych oraz dobrze funkcjonujących rynków finansowych w UE.

² Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego i zmieniające rozporządzenia (WE) nr 1060/2009, (UE) nr 648/2012, (UE) nr 600/2014, (UE) nr 909/2014 oraz (UE) 2016/1011 (Tekst mający znaczenie dla EOG). Publications Office (europa.eu) https://eur-lex.europa.eu/legal-content/PL/TXT/PDF/?uri=CELEX:32022R2554

³ TIBER-EU ( Framework on Threat Intelligence-based Ethical Red Teaming) to europejskie ramy etycznego red-teamingu opartego na analizie zagrożeń. Zawiera kompleksowe wytyczne dotyczące tego, w jaki sposób organy, podmioty, osoby zajmujące się threat intelligence (analizą zagrożeń) i dostawcy usług red-team powinny współpracować w celu przeprowadzenia testów, aby doszło poprawy odporności cybernetycznej podmiotów poprzez przeprowadzanie kontrolowanych cyberataków. Został on opracowany wspólnie przez Europejski Bank Centralny i krajowe banki centralne UE oraz z uwzględnieniem wniosków wyciągniętych z podobnych inicjatyw w Wielkiej Brytanii (CBEST) i Holandii (TIBER-NL), a następnie opublikowany w maju 2018 (por. str. 6 , punkt 3.2.1 RAMY TIBER-EU – projektu dla TLPT). Informacje na temat TIBER-EU można znaleźć możesz znaleźć na stronie Europejskiego Urzędu Nadzoru Bankowego (EBA). Homepage | European Banking Authority (europa.eu)

⁴ Por motyw nr 1 do projektu RTS dla TLPT

⁵ W projekcie RTS dla TLPT brak definicji dla „Red Teamu”. Natomiast zgodnie z definicją podaną przez NIST (National Institute of Standards and Technology U.S. Department of Commerce). Link: Red Team - Glossary | CSRC (nist.gov) Red Team należy zdefiniować jako “A group of people authorized and organized to emulate a potential adversary’s attack or exploitation capabilities against an enterprise’s security posture. The Red Team’s objective is to improve enterprise cybersecurity by demonstrating the impacts of successful attacks and by demonstrating what works for the defenders (i.e., the Blue Team) in an operational environment. Also known as Cyber Red Team." „Red team” w testach penetracyjnych typu TLPT dotyczy zespołu, który jest upoważniony przez organizacją do przeprowadzenia symulowanego ataku na organizację. Celem zadania Red Teamu jest poprawa cyberbezpieczeństwa organizacji poprzez demonstrację potencjalnego skutku udanego ataku hakerskiego oraz pokazanie i uświadomienie organizacji w jaki sposób działa zespół dedykowany do ochrony organizacji w środowisku operacyjnym (Blue Team). Red Team działa w sposób niezależny od Blue Team, co pozwala na obiektywną ocenę poziomi odporności organizacji na atak. Rezultatem prac Red Teamu jest raport zawierający zidentyfikowane luki lub słabości w systemie bezpieczeństwa oraz zalecenie dotyczące naprawy lub wzmocnienia systemu obrony organizacji.

⁶ Zgodnie z art. 1 pkt 5) projektu RTS dla TLPT „TLPT authority” means: a. the single public authority that is designated to be responsible for carrying out TLPT in a Member State in accordance with Article 26(9) of Regulation (EU) 2022/2554, or
b. the authority to which the exercise of some or all of the tasks in relation to TLPT is delegated in accordance with Article 26(10) of Regulation (EU) 2022/2554, or c. the competent authority in accordance with Article 46 of Regulation (EU) 2022/2554.”

⁷ Art. 3 pkt 15) DORA - „analiza zagrożeń” oznacza informacje, które zostały zagregowane, przekształcone, przeanalizowane, zinterpretowane lub wzbogacone w celu zapewnienia niezbędnego kontekstu na potrzeby podejmowania decyzji i umożliwienia odpowiedniego i wystarczającego zrozumienia w celu złagodzenia skutków incydentu związanego z ICT lub cyberzagrożenia, w tym informacje dotyczące technicznych szczegółów cyberataku, osób odpowiedzialnych za atak oraz ich sposobu działania i motywacji.”

⁸ Art 1 pkt 8) projektu RTS dla TLPT: „threat intelligence provider” means the expert(s), external to the financial entity, who collect and analyze targeted threat intelligence relevant for the financial entities in scope of a specific TLPT exercise and develop matching relevant and realistic threat scenarios.”

⁹ Por. z art. 26 ust 11 Rozporządzenia DORA

¹⁰ W przypadku prowadzenia testów penetracyjnych może zdarzyć się przypadek, że testerzy (Red Team) nie są w stanie przejść w ramach testu z jednego zaprojektowanego etapu do kolejnego. Wówczas zespół odpowiadający za kontrolę testu może od czasu do czasu udzielić pomocy lub wsparcia co jest nazywane jako „leg-ups”. W takim przypadku podmiot finansowy udziela dostępu w stosownych przypadkach, do systemu teleinformatycznego lub sieci wewnętrznej w celu kontynuowania testu i skupienia się na kolejnych etapach symulacji ataku (por. z motywem nr 18 Rozporządzenia DORA).

¹¹ Por art. 6, 7 i 8 projektu RTS dla TLPT

¹² Blue team oznacza członków zespołu podmiotu finansowego i zewnętrznych dostawców usług podmiotu finansowego, którzy bronią korzystania przez podmiot finansowy z sieci i systemów informatycznych poprzez utrzymywanie jego stanu bezpieczeństwa przed symulowanymi lub rzeczywistymi atakami i którzy nie są świadomi TLPT (por art. 1 pkt 3 projektu RTS dla TLPT).