Jak przebiega TLPT krok po kroku? Test penetracyjny pod kątem wyszukiwania zagrożeń (TLPT) to sekwencja działań, w której instytucja finansowa powołuje control team, ocenia ryzyko testu na produkcji, zleca zewnętrzną analizę zagrożeń, przechodzi co najmniej 12 tygodni aktywnego red teamingu, a następnie odtwarza atak z zespołem obrony, składa sprawozdanie organowi ds. TLPT (w Polsce KNF) i wdraża plan naprawczy. Ten artykuł opisuje, co robić na każdym etapie od strony organizacji – kto podlega testowi i jakie są terminy, wyjaśniliśmy w Testach TLPT pod DORA – jak zacząć, a wybór dostawców w artykule Jak wybrać dostawcę TLPT.
Definicja kanoniczna: Plan naprawczy TLPT to dokument wymagany przez art. 26 ust. 6 DORA i art. 13 RTS 2025/1190, w którym podmiot finansowy opisuje dla każdego ustalenia z testu niedociągnięcia, środki naprawcze z priorytetami, przyczyny źródłowe, odpowiedzialnych oraz ryzyko braku wdrożenia.
TLPT krok po kroku – w skrócie:
- Control team powinien być jak najmniejszy (motyw 10 RTS), a informacje o teście dostępne wyłącznie na zasadzie wiedzy koniecznej; test ma kryptonim (art. 4 RTS).
- Ocena ryzyka testu obejmuje sześć kategorii z art. 5 ust. 2 RTS, w tym ryzyko dla stabilności finansowej i ryzyko niepełnego przywrócenia systemów.
- Sprawozdanie z analizy zagrożeń musi zawierać co najmniej 3 scenariusze – jeden dotyczący dostępności, jeden integralności i jeden poufności (załącznik III RTS).
- Po zakończeniu fazy aktywnej testerzy mają 4 tygodnie na raport red team, blue team 10 tygodni na swój raport i odtworzenie ataku, a instytucja 8 tygodni na sprawozdanie podsumowujące i plan naprawczy.
- Wykrycie testerów przez blue team nie kończy testu – art. 11 ust. 9 RTS wymaga środków kontynuacji z zachowaniem poufności.
- Patronusec prowadzi klienta przez cały cykl: od przeglądu dokumentu określającego zakres, przez fazę TI i red team, po odtworzenie ataku, purple teaming i przygotowanie planu naprawczego pod ocenę KNF.
Spis treści
Jak zorganizować control team i zachować poufność testu TLPT?
Control team organizujesz wokół lidera z mandatem zarządu, w składzie 3-6 osób z bezpieczeństwa, IT, ryzyka i prawa, bez nikogo z zadań blue team. Art. 4 RTS 2025/1190 wymaga ograniczenia wiedzy o teście do control teamu, zarządu, dostawców TLPT i organu, procedury powstrzymania eskalacji incydentu po wykryciu testerów oraz posługiwania się kryptonimem.
Zadania control teamu wylicza art. 9 ust. 4 RTS 2025/1190: kanały komunikacji, informowanie zarządu o postępach i ryzyku, decyzje merytoryczne w trakcie testu, wybór dostawców i przygotowanie dokumentu określającego zakres. Lider odpowiada za bieżące zarządzanie i decyzje (art. 4 ust. 1), w tym o zawieszeniu testu (art. 11 ust. 10).
Cztery zasady, które w praktyce decydują o poufności:
- Skład – motyw 10 RTS: zespół możliwie mały, z dogłębną znajomością instytucji i dostępem do zarządu. Typowo: CISO lub jego zastępca jako lider, architekt IT, przedstawiciel ryzyka operacyjnego, prawnik, osoba od komunikacji z dostawcami ICT.
- Wykluczenia – nikt z SOC, incident response, administracji infrastruktury ani helpdesku. Art. 4 ust. 2 lit. b RTS wymaga konsultacji z kierownikami testów przed zaangażowaniem jakiegokolwiek członka blue teamu.
- Kanały – szyfrowana poczta, data room i komunikator poza infrastrukturą monitorowaną przez SOC (załącznik I RTS wymaga ich wskazania w karcie projektu).
- Kryptonim – skonstruowany tak, by osoba trzecia nie rozpoznała, że chodzi o TLPT (motyw 9 RTS); używany w kalendarzach, fakturach i dokumentach zakupowych.
Control team w TLPT to zespół pracowników podmiotu finansowego zarządzający testem, który zgodnie z art. 4 ust. 2 lit. c RTS 2025/1190 musi być informowany o każdym wykryciu testu i w razie potrzeby powstrzymać eskalację reagowania na incydent.
Najtrudniejszy punkt to procedura powstrzymania eskalacji. Jeśli SOC zgłosi incydent zgodnie z procedurą DORA (art. 17-19), a ten incydent to działania testerów, control team musi go zatrzymać, zanim trafi do KNF jako poważny incydent ICT, i zrobić to bez ujawnienia testu. Wymaga to wcześniej uzgodnionego mechanizmu – np. klauzuli w procedurze incydentowej, że lider control teamu może wstrzymać zgłoszenie zewnętrzne w określonym oknie czasowym z ogólnie sformułowanego powodu.
Patronusec Insight: Z naszego doświadczenia projektowego wynika, że instytucje najczęściej „przeciekają” nie przez SOC, lecz przez procesy wspierające: zakupy pytają dział bezpieczeństwa o dostawcę red teamu, HR widzi umowę o poufności dla zewnętrznej firmy, a księgowość – fakturę z opisem „testy bezpieczeństwa”. Rozwiązaniem jest kryptonim stosowany konsekwentnie od zapytania ofertowego, ogólny opis przedmiotu umowy i ograniczenie obiegu dokumentów do lidera control teamu. Patronusec przygotowuje dla control teamu pakiet dokumentów zakupowych i umownych pod kryptonimem, tak aby test nie był rozpoznawalny w systemach obiegu dokumentów.
Jak przeprowadzić ocenę ryzyka testu TLPT na systemach produkcyjnych?
Ocenę ryzyka testu przeprowadza control team na etapie przygotowawczym, obejmując sześć kategorii z art. 5 ust. 2 RTS: dostęp dostawców do informacji chronionych, brak zgodności skutkujący brakiem poświadczenia, eskalację incydentów, działania red teamu, działania blue teamu oraz niepełne przywrócenie systemów. Ocena jest konsultowana z kierownikami testów przed startem i przeglądana przez cały czas trwania testu.
| Kategoria ryzyka (art. 5 ust. 2 RTS) | Przykład | Typowy środek ograniczający |
|---|---|---|
| a) dostęp dostawców do informacji szczególnie chronionych | dostawca TI pozyskuje wyciekłe poświadczenia pracowników | NDA, szyfrowany data room, zasada minimalnego dostępu, procedury usunięcia po teście (art. 7 ust. 1 lit. g) |
| b) brak zgodności z DORA/RTS i brak poświadczenia | naruszenie poufności, nieetyczne działanie testerów | klauzule umowne, granice etyczne w planie testów, nadzór kierowników testów |
| c) eskalacja sytuacji kryzysowych i incydentów | SOC zgłasza działania red teamu jako poważny incydent | procedura powstrzymania eskalacji, dyżur lidera control teamu |
| d) działania red teamu | exploit destabilizuje system produkcyjny | testy exploitów w labie, okna czasowe, wyłączniki awaryjne, zakaz DoS |
| e) działania blue teamu | blue team odcina segment sieci w reakcji na „atak” | monitorowanie reakcji, prawo control teamu do interwencji za zgodą kierowników testów |
| f) niepełne przywrócenie sprawności systemów | pozostawione backdoory, zmienione konfiguracje | procedury przywracania z art. 7 ust. 1 lit. h, lista zmian, weryfikacja po teście |
Art. 5 ust. 1 dodaje wymiar sektorowy: control team ocenia potencjalny wpływ testu na sektor finansowy i stabilność finansową na poziomie krajowym i unijnym – np. gdy w zakresie jest system rozliczeń, z którego korzystają inne instytucje. Motyw 11 RTS dopuszcza, by środki zarządzania ryzykiem zatwierdzał sam organ zarządzający.
Ocena ryzyka TLPT musi zgodnie z art. 5 ust. 1 RTS 2025/1190 uwzględniać potencjalny wpływ testowania systemów produkcyjnych na sektor finansowy i na stabilność finansową na poziomie unijnym lub krajowym.
W praktyce oznacza to, że ocena ryzyka testu to osobny dokument, nie fragment rejestru ryzyka ICT. Dobrą podstawą metodyczną jest analiza ryzyka według ISO 27001 – z tą różnicą, że zagrożeniem jest tu sam test, a nie atakujący.
Co musi zawierać sprawozdanie z analizy zagrożeń i jak wybrać scenariusze TLPT?
Sprawozdanie z ukierunkowanej analizy zagrożeń (TTI) musi zgodnie z załącznikiem III RTS zawierać zakres badań, ocenę dostępnych danych o instytucji (poświadczenia, podobne domeny, dark web), analizę otoczenia geopolitycznego i gospodarczego, profile agresorów oraz co najmniej trzy scenariusze – po jednym dla dostępności, integralności i poufności. Lider control teamu wybiera scenariusze według art. 10 ust. 3, a zatwierdza je KNF.
Sześć obowiązkowych elementów sprawozdania TTI:
- Zakres badań wywiadowczych – funkcje w zakresie, lokalizacje, język, dostawcy ICT, okres gromadzenia danych.
- Ocena dostępnych danych operacyjnych – identyfikatory i hasła pracowników z wycieków, domeny podobne do oficjalnych, podatne technologie, informacje publikowane przez pracowników, oferty w dark webie, informacje o dostępie fizycznym.
- Analiza zagrożeń – otoczenie geopolityczne, gospodarcze, trendy technologiczne w sektorze.
- Profile zagrożeń – konkretne grupy lub klasy agresorów, ich motywacja, cele i sposób działania wobec instytucji.
- Scenariusze – co najmniej trzy pełne ścieżki ataku dla profili o najwyższej krytyczności.
- Scenariusz prospektywny (opcjonalnie) – zgodnie z art. 10 ust. 4 co najwyżej jeden scenariusz może dotyczyć przyszłego, jeszcze nieobserwowanego zagrożenia.
Kryteria wyboru scenariuszy przez lidera control teamu (art. 10 ust. 3): rekomendacja dostawcy TI, informacje od kierowników testów, wykonalność w ocenie testerów oraz wielkość, złożoność i profil ryzyka instytucji. Scenariusze muszą różnić się agresorami i TTP oraz obejmować każdą funkcję w zakresie (art. 10 ust. 2). Przy testowaniu zbiorczym lub wspólnym co najmniej jeden scenariusz musi dotyczyć systemów dostawcy ICT.
Zgodnie z załącznikiem III RTS 2025/1190 sprawozdanie z ukierunkowanej analizy zagrożeń zawiera co najmniej trzy scenariusze: jeden obejmujący ograniczenie dostępności usług, jeden naruszenie integralności danych i jeden naruszenie poufności informacji.
Faza TI trwa zwykle około 4 tygodni (motyw 18 RTS). Control team, testerzy i kierownicy testów udzielają dostawcy TI informacji zwrotnej na temat projektu sprawozdania – to moment, w którym control team może zgłosić, że scenariusz jest nierealny dla architektury instytucji, ale nie może go „złagodzić” ze względu na wygodę.
Masz gotowy dokument określający zakres lub projekt sprawozdania TTI i chcesz wiedzieć, czy przejdzie ocenę kierownika testu?
Patronusec wykonuje przegląd dokumentacji przygotowawczej TLPT względem załączników II i III RTS 2025/1190: w ciągu 5 dni roboczych otrzymujesz pisemną ocenę kompletności, listę elementów do uzupełnienia oraz rekomendację doboru scenariuszy do funkcji w zakresie.
Zamów przegląd dokumentacji TLPT
Jak przebiega faza red team w TLPT – flagi, ułatwienia i raporty tygodniowe?
Faza red team zaczyna się od planu testów zgodnego z załącznikiem IV RTS, zatwierdzanego przez control team i KNF, a następnie trwa co najmniej 12 tygodni aktywnego testowania podzielonego na etapy wejścia, przejścia i wyjścia. Testerzy dążą do zdobycia flag, raportują postęp co tydzień, a control team dostarcza zaplanowane ułatwienia, gdy ścieżka ataku się zatrzyma.
Plan testów red team (załącznik IV) zawiera: kanały komunikacji, dozwolone i niedozwolone TTP z granicami etycznymi inżynierii społecznej, środki zarządzania ryzykiem, opis każdego scenariusza (agresor, motywacja, funkcje, atrybuty bezpieczeństwa, flagi), spodziewane ścieżki ataku z warunkami wstępnymi i ułatwieniami, harmonogram z podziałem na trzy etapy oraz szczególne cechy infrastruktury.
Trzy etapy fazy aktywnej według załącznika IV lit. f:
| Etap | Cel testerów | Typowe TTP (motyw 21 RTS) | Co obserwuje control team |
|---|---|---|---|
| Wejście | uzyskanie pierwszego przyczółka | rozpoznanie, zbrojenie, phishing, wykorzystanie podatności zewnętrznych, dostęp fizyczny | czy blue team wykrył próby; czy potrzebne ułatwienie informacyjne |
| Przejście | ruch boczny do systemów wspierających funkcje w zakresie | eskalacja uprawnień, kontrola i przemieszczanie się, nadużycie dostępu uprzywilejowanego | czas do wykrycia, reakcje blue teamu, ryzyko dla produkcji |
| Wyjście | działania na celach – zdobycie flag i kontrolowane opuszczenie systemów | dostęp do danych celowych, symulowana eksfiltracja, usunięcie narzędzi | które flagi zdobyto, czy przywrócono stan wyjściowy |
Flagi to kluczowe cele w systemach wspierających funkcje w zakresie (art. 1 pkt 14 RTS) – np. odczyt danych z systemu księgi głównej, zmiana parametru w systemie płatności w środowisku kontrolowanym, dostęp do konsoli administracyjnej. Każda flaga ma przypisany atrybut: poufność, integralność, dostępność lub autentyczność.
Ułatwienia (art. 1 pkt 12, art. 11 ust. 8) – informacje lub dostęp, które control team przekazuje testerom, gdy nie są w stanie samodzielnie przejść dalej i nie ma innej rozsądnej alternatywy. Muszą być zaprojektowane w planie testów i udokumentowane w raporcie; ich nadużycie obniża wartość testu, a brak – może zmarnować 12 tygodni na jednym zablokowanym etapie.
Zgodnie z art. 11 ust. 7 RTS 2025/1190 testerzy składają control teamowi i kierownikom testów sprawozdanie z postępów TLPT co najmniej raz w tygodniu przez cały etap aktywnego testowania.
Patronusec Insight: Cotygodniowy raport postępu to nie formalność, lecz narzędzie decyzyjne lidera control teamu. Z naszego doświadczenia projektowego wynika, że warto uzgodnić stały format: status każdego scenariusza względem harmonogramu, wykorzystane i planowane TTP, próby wykryte przez blue team (z perspektywy testerów), ryzyka zgłoszone w tygodniu, decyzje wymagane od control teamu. Patronusec prowadzi raportowanie tygodniowe w formacie mapowanym na MITRE ATT&CK, dzięki czemu po teście te same raporty stają się szkieletem raportu red team wg załącznika V – bez odtwarzania historii z notatek.
Co zrobić, gdy blue team wykryje testerów lub test zagraża systemom produkcyjnym?
Wykrycie testerów uruchamia art. 11 ust. 9 RTS: control team w porozumieniu z testerami proponuje kierownikom testów środki pozwalające kontynuować test z zachowaniem poufności. Zagrożenie dla produkcji uruchamia art. 11 ust. 10: lider control teamu może zawiesić test lub – w ostateczności, za zgodą KNF – przejść do ograniczonych działań purple team. Żadna z tych sytuacji nie unieważnia testu.
Scenariusz wykrycia – kolejność działań:
- Testerzy zgłaszają podejrzenie wykrycia (obowiązek z art. 7 ust. 1 lit. h pkt vi RTS – monitorowanie blue teamu).
- Control team ustala, co widzi blue team i czy uruchomił procedurę incydentową.
- Lider control teamu powstrzymuje eskalację zewnętrzną (art. 4 ust. 2 lit. c), jeśli incydent zmierza do zgłoszenia do KNF.
- Control team proponuje kierownikom testów środki kontynuacji: zmiana infrastruktury C2, zmiana scenariusza, ułatwienie dostępu z pominięciem wykrytego wektora, ograniczone poinformowanie jednej osoby z blue teamu (za zgodą kierowników testów, art. 4 ust. 2 lit. b).
- Wykrycie i reakcja trafiają do raportu red team i blue team jako jeden z najcenniejszych wyników testu.
Scenariusz zagrożenia dla produkcji – opcje z art. 11 ust. 10:
- Zawieszenie – lider control teamu wstrzymuje działania testerów do czasu usunięcia ryzyka; czas zawieszenia nie wlicza się automatycznie do 12 tygodni, więc harmonogram wymaga aktualizacji zatwierdzanej przez kierowników testów (art. 11 ust. 6).
- Ograniczone działania purple team – za uprzednią zgodą KNF: „złap i wypuść” (testerzy dają się wykryć i wznawiają), gry wojenne lub wspólny dowód słuszności koncepcji (motyw 23 RTS). Ich czas wlicza się do minimum 12 tygodni.
Zgodnie z art. 11 ust. 9 RTS 2025/1190 wykrycie testowania przez personel podmiotu finansowego nie kończy TLPT – control team przedkłada kierownikom testów do zatwierdzenia środki umożliwiające kontynuowanie testu przy zachowaniu jego poufności.
W praktyce oznacza to, że procedury na oba scenariusze powinny być gotowe przed startem fazy aktywnej i opisane w planie testów (załącznik IV lit. c). Najgorszy wariant to improwizacja w piątek wieczorem, gdy SOC eskaluje incydent, a lider control teamu nie ma uprawnień, by go zatrzymać.
Jak wygląda etap zamykania TLPT – raporty, odtworzenie ataku i purple teaming?
Etap zamykania rozpoczyna się od poinformowania blue teamu o teście (art. 12 ust. 1 RTS) i obejmuje w ciągu 10 tygodni: raport red team (4 tygodnie), raport blue team, wspólne odtworzenie ataku oraz działania purple team dotyczące podatności i kwestii nieprzetestowanych. Kończy go wymiana informacji zwrotnych między wszystkimi stronami.
Zawartość obu raportów według załączników V i VI:
| Raport red team (zał. V, 4 tygodnie) | Raport blue team (zał. VI, 10 tygodni) |
|---|---|
| funkcje i systemy będące celem | dla każdego etapu ataku: wykryte próby i odpowiadające wpisy w logach |
| podsumowanie każdego scenariusza | ocena ustaleń i zaleceń testerów |
| flagi zdobyte i niezdobyte | dowody ataku zebrane przez blue team |
| ścieżki ataku udane i nieudane, TTP skuteczne i nieskuteczne | analiza przyczyn źródłowych powodzenia ataków (z perspektywy obrony) |
| odstępstwa od planu, przyznane ułatwienia | wnioski i możliwości poprawy |
| działania blue teamu znane testerom | tematy do działań purple team |
| podatności z krytycznością, przyczyny źródłowe, zalecenia z priorytetami |
Odtworzenie ataku (replay, art. 12 ust. 5) to wspólna sesja, w której testerzy krok po kroku pokazują ścieżkę ataku, a blue team porównuje ją z tym, co widział w logach i alertach. To tutaj wychodzą luki w detekcji: atak trwał 12 tygodni, a SOC widział dwa alerty niskiego priorytetu.
Purple teaming na etapie zamykania (motyw 24) może obejmować dyskusję alternatywnych scenariuszy, zastosowanie ich na systemach produkcyjnych lub ponowne przeprowadzenie scenariuszy, których testerzy nie zdążyli ukończyć. Celem jest maksymalizacja uczenia się – każdy niezrealizowany scenariusz to niezweryfikowana hipoteza o odporności.
Etap zamykania TLPT wymaga zgodnie z art. 12 ust. 5 RTS 2025/1190, aby nie później niż 10 tygodni po zakończeniu aktywnego testowania zespół blue team i testerzy odtworzyli działania ofensywne i obronne oraz przeprowadzili działania purple team.
Na wniosek kierowników testów raporty nie zawierają informacji szczególnie chronionych (art. 12 ust. 3-4) – control team powinien przygotować wersję pełną dla siebie i wersję oczyszczoną dla organu.
Co musi zawierać plan naprawczy TLPT i sprawozdanie podsumowujące dla KNF?
Po potwierdzeniu przez KNF, że raporty red i blue team są kompletne, instytucja ma 8 tygodni na dwa dokumenty: sprawozdanie podsumowujące istotne ustalenia (załącznik VII, art. 12 ust. 7) oraz plan naprawczy (art. 13). Plan musi dla każdego ustalenia zawierać opis niedociągnięcia, środki naprawcze z priorytetami i terminami, analizę przyczyn źródłowych, odpowiedzialnych oraz ryzyko braku wdrożenia. Dopiero po nich organ wydaje poświadczenie.
Sprawozdanie podsumowujące (załącznik VII) to 15 elementów: strony, plan projektu, zatwierdzony zakres z uzasadnieniem, scenariusze i odstępstwa od TTI, ścieżki ataku i TTP, flagi, odstępstwa od planu, wykrycia, działania purple team, ułatwienia, środki zarządzania ryzykiem, podatności z krytycznością, przyczyny źródłowe, wysokopoziomowy plan środków zaradczych oraz wnioski.
Plan naprawczy (art. 13 ust. 2) – pięć obowiązkowych elementów dla każdego ustalenia:
- Opis niedociągnięcia – co konkretnie umożliwiło atak (nie „słaba segmentacja”, lecz „brak filtrowania ruchu między VLAN stacji roboczych a segmentem serwerów aplikacyjnych”).
- Środki naprawcze z hierarchią ważności i terminem – w tym środki poprawiające identyfikację, ochronę, wykrywanie i reagowanie.
- Analiza przyczyn źródłowych – dlaczego luka istniała: proces, technologia, kompetencje, budżet.
- Odpowiedzialni – konkretne funkcje lub osoby, nie „dział IT”.
- Ryzyko braku wdrożenia – i, gdy zasadne, ryzyko samego wdrożenia.
Plan naprawczy TLPT musi zgodnie z art. 13 ust. 2 RTS 2025/1190 zawierać dla każdego ustalenia analizę przyczyn źródłowych oraz wskazanie ryzyka związanego z niewdrożeniem proponowanych środków.
Poświadczenie (załącznik VIII) dokumentuje daty testu, funkcje w zakresie, udział innych podmiotów i dostawców ICT, rodzaj testerów, czas trwania fazy aktywnej w dniach oraz wykaz dokumentów przeanalizowanych przez organ. Jest podstawą wzajemnego uznawania testu przez organy innych państw UE (art. 26 ust. 7 DORA).
Masz raporty red i blue team i 8 tygodni na plan naprawczy, który zaakceptuje KNF?
Patronusec wspiera control team w przygotowaniu sprawozdania podsumowującego i planu naprawczego: w ciągu 15 dni roboczych otrzymujesz projekt obu dokumentów w strukturze załącznika VII i art. 13 RTS, z analizą przyczyn źródłowych i priorytetyzacją środków, gotowy do zatwierdzenia przez zarząd.
Zamów wsparcie w planie naprawczym TLPT
Jak wykorzystać wyniki TLPT poza obowiązkiem regulacyjnym?
Wyniki TLPT wykorzystujesz w czterech obszarach poza samym poświadczeniem: jako wsad do ram zarządzania ryzykiem ICT z art. 6 DORA, jako korektę programu testów z art. 24-25 (pentesty, skany, scenariusze), jako materiał szkoleniowy dla SOC i zarządu oraz jako punkt odniesienia dla kolejnego cyklu za 3 lata. Motyw 24 RTS określa TLPT jako doświadczenie umożliwiające wyciąganie wniosków, nie tylko obowiązek.
Cztery praktyczne zastosowania:
- Rejestr ryzyka ICT – każda przyczyna źródłowa z planu naprawczego staje się ryzykiem z właścicielem i terminem; TLPT dostarcza dowodu, że ryzyko jest realne, a nie teoretyczne.
- Program testów z art. 24 DORA – ścieżki ataku pokazują, które systemy wymagają częstszych testów penetracyjnych, a które luki wykryłyby regularne skany podatności z uwierzytelnieniem.
- Detekcja i reagowanie – raport blue team wskazuje, ile alertów wygenerowało 12 tygodni ataku; każda niewykryta technika to reguła detekcji do napisania i scenariusz do przećwiczenia w SOC.
- Zarząd – sprawozdanie podsumowujące w wersji dla organu zarządzającego pokazuje odporność w kategoriach biznesowych: które funkcje krytyczne były osiągalne, w jakim czasie i jakim kosztem dla atakującego.
Zgodnie z motywem 24 RTS 2025/1190 TLPT powinny być wykorzystywane jako doświadczenie umożliwiające wyciągnięcie wniosków z myślą o zwiększeniu operacyjnej odporności cyfrowej podmiotów finansowych.
Wyniki TLPT warto też skonfrontować z planem cyberbezpieczeństwa na 12 miesięcy – jeśli test pokazał, że atakujący dotarł do funkcji krytycznej w 3 tygodnie, priorytety planu prawdopodobnie wymagają zmiany.
Patronusec Insight: Największa wartość TLPT ujawnia się w drugim cyklu, po 3 latach – ale tylko wtedy, gdy instytucja zachowała porównywalność: te same funkcje w zakresie, podobne profile agresorów, te same metryki (czas do pierwszego przyczółka, czas do wykrycia, liczba zdobytych flag). Z naszego doświadczenia projektowego wynika, że warto już w pierwszym cyklu zdefiniować 5-6 wskaźników odporności i zapisać je w sprawozdaniu podsumowującym. Patronusec proponuje taki zestaw wskaźników w raporcie red team, aby zarząd za 3 lata dostał odpowiedź na pytanie „czy jesteśmy bardziej odporni”, a nie tylko kolejną listę podatności.
Jakie błędy popełniają organizacje w trakcie TLPT?
Najczęstsze błędy organizacji w trakcie TLPT dotyczą poufności, ułatwień, reakcji na wykrycie, jakości planu naprawczego i braku porównywalności między cyklami. Każdy z nich ma odbicie w konkretnym wymogu RTS 2025/1190.
❌ Zbyt duży control team, w którym zasiada kierownik SOC – narusza logikę art. 1 pkt 3 RTS (blue team nieświadomy); wyniki detekcji stają się niewiarygodne.
❌ Ułatwienia przyznawane „żeby test szedł do przodu”, bez dokumentacji – art. 11 ust. 8 wymaga zaplanowania i zatwierdzenia; nieudokumentowane ułatwienia podważają wynik przed kierownikiem testu.
❌ Traktowanie wykrycia przez blue team jako porażki i ciche zakończenie scenariusza – art. 11 ust. 9 wymaga procedury kontynuacji; wykrycie to jeden z najcenniejszych wyników.
❌ Plan naprawczy jako lista podatności z raportu red team – art. 13 ust. 2 wymaga analizy przyczyn źródłowych, odpowiedzialnych i ryzyka braku wdrożenia; lista CVE nie spełnia tego wymogu.
❌ Brak wersji raportów bez informacji szczególnie chronionych – art. 12 ust. 3-4 przewiduje, że organ może o nią poprosić; jej przygotowanie po fakcie opóźnia zamknięcie.
❌ Zerwanie porównywalności między cyklami – zmiana zakresu i metryk w drugim teście uniemożliwia ocenę, czy remediacja z pierwszego cyklu zadziałała.
FAQ – TLPT krok po kroku
Ile osób powinien liczyć control team?
Zwykle 3-6 osób. Motyw 10 RTS 2025/1190 wymaga, aby zespół był jak najmniejszy, z dogłębną znajomością instytucji i dostępem do zarządu. Typowy skład: lider (CISO lub zastępca), architekt IT, ryzyko operacyjne, prawnik, osoba odpowiedzialna za relacje z dostawcami ICT objętymi zakresem.
Czy zarząd musi wiedzieć o teście?
Tak. Art. 4 ust. 2 lit. a RTS wymienia organ zarządzający wśród osób z dostępem do informacji o teście, art. 9 ust. 6 wymaga zatwierdzenia przez zarząd dokumentu określającego zakres, a art. 9 ust. 4 lit. b nakłada na control team obowiązek informowania zarządu o postępach i ryzyku.
Co się dzieje, gdy testerzy nie zdobędą żadnej flagi?
Test pozostaje ważny. Raport red team dokumentuje nieudane ścieżki i nieskuteczne TTP (załącznik V), a etap zamykania obejmuje purple teaming dla kwestii nieprzetestowanych (art. 12 ust. 5). Control team powinien jednak przeanalizować, czy nie zabrakło ułatwień lub czy scenariusze nie były nierealne.
Czy blue team może być poinformowany w trakcie testu?
Wyłącznie w uzasadnionych przypadkach i za uprzednią zgodą kierowników testów (art. 4 ust. 2 lit. b RTS, motyw 9). Najczęstszy przypadek to ograniczone poinformowanie jednej osoby po wykryciu, aby powstrzymać eskalację bez ujawnienia testu reszcie zespołu.
Kiedy testerzy muszą usunąć swoje narzędzia z systemów?
Po zakończeniu testu, zgodnie z art. 7 ust. 1 lit. g-h RTS: dezaktywacja C2, usunięcie backdoorów i złośliwego oprogramowania, bezpieczne usunięcie poświadczeń i danych, powiadomienie o potencjalnych naruszeniach oraz procedury umożliwiające przyszłe przywrócenie kopii zapasowych. Control team weryfikuje wykonanie przed zamknięciem.
Jak długo trwa wsparcie Patronusec w etapie zamykania TLPT?
Odtworzenie ataku i purple teaming realizujemy w oknie 10 tygodni wymaganym przez art. 12 ust. 5 RTS, a projekt sprawozdania podsumowującego i planu naprawczego dostarczamy w 15 dni roboczych od potwierdzenia raportów przez organ – z zapasem względem 8-tygodniowego terminu z art. 13.
Jak rozpocząć współpracę z Patronusec przy TLPT?
Od bezpłatnej 30-minutowej konsultacji, na której ustalamy etap, na którym jest Twoja instytucja – przed powiadomieniem, w trakcie przygotowań czy po fazie aktywnej – i dobieramy zakres wsparcia: readiness assessment, przegląd dokumentacji, realizacja obu ról TLPT lub plan naprawczy.
Warto przeczytać
- Testy TLPT pod DORA – jak zacząć – kto podlega, role i pełny harmonogram terminów RTS (hub definicji TLPT).
- Jak wybrać dostawcę TLPT – wymogi art. 27 DORA i art. 7 RTS, sygnały ostrzegawcze, koszty i klauzule umowne.
- Analiza ryzyka według ISO 27001 – metodyka, którą można zastosować do oceny ryzyka testu z art. 5 RTS.
- Ransomware – pierwsze 72 godziny – jak procedura incydentowa powinna współgrać z powstrzymaniem eskalacji w trakcie TLPT.
- 12-miesięczny plan cyberbezpieczeństwa – jak przełożyć plan naprawczy TLPT na priorytety programu bezpieczeństwa.
TLPT krok po kroku – bezpłatna konsultacja
Patronusec prowadzi instytucje finansowe przez cały cykl TLPT – od przeglądu dokumentu określającego zakres, przez realizację obu ról (analiza zagrożeń i red team w rozdzielonych zespołach), po odtworzenie ataku, purple teaming i plan naprawczy przygotowany pod ocenę KNF. Zespół pentesterów z certyfikatami OSCP, CREST i OSWE łączymy z doświadczeniem audytorskim (status QSA, audyty ISO 27001).
W bezpłatnej 30-minutowej konsultacji pomożemy Ci:
- ustalić skład control teamu i procedurę powstrzymania eskalacji zgodną z art. 4 RTS,
- zaplanować ocenę ryzyka testu w sześciu kategoriach z art. 5 ust. 2 RTS,
- przygotować scenariusze wykrycia i zawieszenia testu przed startem fazy aktywnej,
- ułożyć strukturę planu naprawczego i wskaźników odporności do porównania w kolejnym cyklu.
Umów bezpłatną konsultację | Testy TLPT | Testy penetracyjne | Skany podatności | Wdrożenie DORA
