Materiał dowodowy DORA TLPT zmapowany na zabezpieczenia ISO 27001

Jest 07:40 w poniedziałek rano, a CISO średniej wielkości instytucji płatniczej patrzy na trzy wersje tego samego niewygodnego pytania.

Zarząd chce wiedzieć, czy organizacja przetrwa niedostępność portalu płatności dla klientów spowodowaną ransomware. Regulator oczekuje dowodu, że testowanie cyfrowej odporności operacyjnej nie jest ćwiczeniem w PowerPoincie. Audyt wewnętrzny chce zobaczyć czystą ścieżkę od obowiązków wynikających z DORA do ryzyk ICT, zabezpieczeń ISO 27001, wyników testów, planów działań korygujących, materiału dowodowego od dostawców oraz akceptacji kierownictwa.

CISO ma raport z ćwiczenia red team. SOC ma zrzuty ekranu alertów. Zespół infrastruktury ma log odtworzenia kopii zapasowej. Dział prawny ma rejestr gotowości do DORA. Zakupy mają atestacje dostawcy chmurowego.

Nic z tego nie jest ze sobą połączone.

W tym miejscu zawodzi wiele programów DORA TLPT i testowania odporności. Nie dlatego, że testy są słabe, lecz dlatego, że materiał dowodowy jest rozproszony. Gdy audytor pyta: „Pokażcie, w jaki sposób ten test potwierdza odporność funkcji krytycznej lub istotnej”, odpowiedzią nie może być folder pełen zrzutów ekranu. Musi to być możliwy do obrony łańcuch dowodowy.

Właśnie w tym łańcuchu SZBI zgodny z ISO/IEC 27001:2022 ISO/IEC 27001:2022 staje się szczególnie wartościowy. ISO 27001 nadaje strukturę zakresowi, ocenie ryzyka, doborowi zabezpieczeń, Deklaracji stosowania, nadzorowi operacyjnemu, audytowi wewnętrznemu, przeglądowi zarządzania i ciągłemu doskonaleniu. DORA wnosi presję sektorową. Metodyka Clarysec i narzędzia zgodności krzyżowej łączą oba elementy w jeden gotowy do audytu model dowodowy.

DORA TLPT to test ładu zarządczego, a nie tylko symulacja ataku

Testy penetracyjne oparte na analizie zagrożeń, czyli TLPT, łatwo błędnie zrozumieć. Technicznie mogą wyglądać jak zaawansowane ćwiczenie red team: informacje o zagrożeniach, realistyczne ścieżki ataku, działanie w ukryciu, próby wykorzystania podatności, scenariusze ruchu lateralnego oraz walidacja reakcji blue team.

W DORA głębszym zagadnieniem jest cyfrowa odporność operacyjna. Czy podmiot finansowy potrafi wytrzymać poważne zakłócenie ICT wpływające na procesy biznesowe, zareagować na nie i odtworzyć po nim zdolność działania? Czy potrafi wykazać, że funkcje krytyczne lub istotne pozostają w granicach tolerancji wpływu? Czy kierownictwo może wykazać, że ryzyko ICT jest objęte nadzorem, finansowane, testowane, poddawane działaniom korygującym i doskonalone?

DORA Article 1 ustanawia jednolite ramy UE dla bezpieczeństwa sieci i systemów informatycznych wspierających procesy biznesowe podmiotów finansowych. Obejmuje zarządzanie ryzykiem ICT, zgłaszanie poważnych incydentów związanych z ICT, testowanie cyfrowej odporności operacyjnej, zarządzanie ryzykiem ICT związanym ze stronami trzecimi, obowiązkowe wymagania umowne wobec dostawców ICT, nadzór nad krytycznymi zewnętrznymi dostawcami usług ICT oraz współpracę nadzorczą. DORA obowiązuje od 17 stycznia 2025 r.

Dla organizacji objętych również NIS2, DORA działa jako sektorowy akt prawny Unii dla pokrywających się wymagań cyberbezpieczeństwa. W praktyce podmioty finansowe powinny priorytetowo traktować DORA w zakresie zarządzania ryzykiem ICT, zgłaszania incydentów, testowania oraz ryzyka ICT związanego ze stronami trzecimi tam, gdzie reżimy regulacyjne się pokrywają, przy jednoczesnym rozumieniu oczekiwań NIS2 wobec struktur grupowych, dostawców i niefinansowych usług cyfrowych.

DORA umieszcza także rozliczalność na najwyższym poziomie. Article 5 wymaga, aby organ zarządzający definiował, zatwierdzał, nadzorował i wdrażał rozwiązania dotyczące ryzyka ICT. Obejmuje to strategię cyfrowej odporności operacyjnej, politykę ciągłości działania ICT, plany reagowania i odtwarzania, plany audytów, budżety, polityki dotyczące zewnętrznych dostawców ICT, kanały raportowania oraz wystarczającą wiedzę o ryzyku ICT uzyskiwaną przez regularne szkolenia.

Pytanie audytowe nie brzmi więc po prostu: „Czy przeprowadziliście TLPT?”

Brzmi ono:

• Czy TLPT powiązano z funkcjami krytycznymi lub istotnymi?
• Czy test był autoryzowany, objęty zakresem, bezpieczny i poprzedzony oceną ryzyka?
• Czy uwzględniono dostawców, zależności chmurowe i outsourcingowe usługi ICT tam, gdzie było to istotne?
• Czy test wygenerował materiał dowodowy dotyczący wykrywania, reagowania, odtwarzania i wniosków z ćwiczenia?
• Czy ustalenia przekształcono w postępowanie z ryzykiem, śledzone działania korygujące, ponowne testy i raportowanie zarządcze?
• Czy Deklaracja stosowania wyjaśnia, które zabezpieczenia z Załącznika A ISO 27001 wybrano do zarządzania ryzykiem?

Dlatego Clarysec traktuje materiał dowodowy DORA TLPT jako problem dowodowy SZBI, a nie wyłącznie jako produkt prac z testów penetracyjnych.

Zbuduj kręgosłup dowodowy ISO 27001 przed rozpoczęciem testu

ISO 27001 wymaga, aby organizacja ustanowiła, wdrożyła, utrzymywała i stale doskonaliła SZBI, który chroni poufność, integralność i dostępność poprzez proces zarządzania ryzykiem. Klauzule 4.1–4.4 wymagają, aby organizacja rozumiała kwestie wewnętrzne i zewnętrzne, strony zainteresowane, obowiązki prawne i regulacyjne, interfejsy, zależności, a następnie udokumentowała zakres SZBI.

W przypadku podmiotu regulowanego przez DORA ten etap określania zakresu powinien wprost obejmować funkcje krytyczne lub istotne, aktywa ICT, platformy chmurowe, operacje realizowane w outsourcingu, systemy płatnicze, portale klientów, usługi tożsamości, platformy rejestrowania zdarzeń, środowiska odtwarzania oraz zewnętrznych dostawców usług ICT. Jeżeli zakres TLPT nie mapuje się z powrotem na zakres SZBI, ścieżka audytowa jest słaba już na starcie.

ISO 27001, klauzule 6.1.1, 6.1.2 i 6.1.3, łącznie z klauzulami 8.2 i 8.3, wymagają procesu oceny ryzyka i postępowania z ryzykiem. Ryzyka muszą być identyfikowane względem poufności, integralności i dostępności. Należy przypisać właścicieli ryzyka. Należy ocenić prawdopodobieństwo i konsekwencje. Zabezpieczenia muszą zostać wybrane i porównane z Załącznikiem A. Ryzyko szczątkowe musi zostać zaakceptowane przez właścicieli ryzyka.

To jest pomost między DORA a testowaniem gotowym do audytu.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Clarysec Zenith Blueprint, w fazie zarządzania ryzykiem, krok 13, jasno opisuje tę rolę identyfikowalności:

SoA jest w praktyce dokumentem pomostowym: łączy ocenę ryzyka/postępowanie z ryzykiem z faktycznie posiadanymi środkami kontroli. Uzupełniając go, dodatkowo sprawdzasz, czy nie pominięto żadnych środków kontroli.

W przypadku DORA TLPT Deklaracja stosowania nie powinna być statycznym artefaktem certyfikacyjnym. Powinna wyjaśniać, dlaczego zabezpieczenia takie jak bezpieczeństwo dostawców, zarządzanie incydentami, gotowość ICT do ciągłości działania, rejestrowanie zdarzeń, monitorowanie, techniczne zarządzanie podatnościami, kopie zapasowe, bezpieczny rozwój oprogramowania i testy bezpieczeństwa mają zastosowanie do scenariusza odporności.

Praktyczny scenariusz ryzyka może brzmieć następująco:

„Przejęcie danych uwierzytelniających uprzywilejowanego dostawcy tożsamości pozwala atakującemu uzyskać dostęp do systemów administracyjnych przetwarzania płatności, zmienić konfiguracje routingu i zakłócić krytyczną funkcję płatniczą, powodując niedostępność usługi, obowiązki zgłoszeniowe wobec regulatora, szkodę dla klientów i szkodę reputacyjną”.

Ten pojedynczy scenariusz może wyznaczać zakres TLPT, przypadki użycia wykrywania, udział dostawców, ćwiczenie odtwarzania, raportowanie do zarządu i zestaw materiału dowodowego.

Zenith Blueprint zaleca również jednoznaczne wykazywanie identyfikowalności regulacyjnej:

Odwołuj się krzyżowo do regulacji: jeżeli określone środki kontroli wdrożono specjalnie w celu spełnienia wymagań GDPR, NIS2 lub DORA, można odnotować to w Rejestrze ryzyk jako część uzasadnienia wpływu ryzyka albo w notatkach SoA.

Ta rada jest prosta, ale zmienia rozmowę z audytorem. Zamiast deklarować, że DORA została uwzględniona, organizacja może pokazać, gdzie DORA występuje w rejestrze ryzyk, SoA, programie testów, zestawie polityk i przeglądzie zarządzania.

Mapuj testowanie DORA na zabezpieczenia ISO 27001 rozpoznawane przez audytorów

DORA Article 6 oczekuje udokumentowanych ram zarządzania ryzykiem ICT zintegrowanych z ogólnym zarządzaniem ryzykiem. Załącznik A ISO 27001 dostarcza katalog zabezpieczeń, który przekłada to na praktykę operacyjną.

Dla DORA TLPT i testowania odporności szczególnie ważne są następujące zabezpieczenia z Załącznika A ISO/IEC 27001:2022:

Zenith Controls: The Cross-Compliance Guide Clarysec Zenith Controls pomaga organizacjom uniknąć traktowania tych zabezpieczeń jako odizolowanych pozycji listy kontrolnej. Mapuje zabezpieczenia ISO/IEC 27002:2022 na atrybuty, domeny, zdolności operacyjne, oczekiwania audytowe oraz wzorce międzyramowe.

Na przykład Zenith Controls klasyfikuje zabezpieczenie ISO/IEC 27002:2022 5.30, gotowość ICT do ciągłości działania, jako „korygujące”, powiązane z „dostępnością”, skojarzone z koncepcją cyberbezpieczeństwa „reagowanie” i umieszczone w domenie „odporność”. Taka klasyfikacja jest użyteczna przy wyjaśnianiu audytorom, dlaczego ćwiczenie odtwarzania nie jest tylko operacją IT, lecz zabezpieczeniem odporności o zdefiniowanej roli w środowisku kontroli.

Zenith Controls klasyfikuje również zabezpieczenie 8.29, testy bezpieczeństwa w rozwoju i akceptacji, jako zabezpieczenie zapobiegawcze wspierające poufność, integralność i dostępność, ze zdolnościami operacyjnymi w zakresie bezpieczeństwa aplikacji, zapewnienia bezpieczeństwa informacji oraz bezpieczeństwa systemów i sieci. Dla ustaleń TLPT wynikających ze słabości projektu aplikacji, niebezpiecznego zachowania interfejsu API, słabego przepływu uwierzytelniania lub niewystarczającej walidacji jest to ścieżka kontrolna do ładu nad bezpiecznym rozwojem oprogramowania.

Istotne jest także zabezpieczenie 5.35, niezależny przegląd bezpieczeństwa informacji. Wspiera niezależne kwestionowanie, zapewnienie w zakresie ładu zarządczego i doskonalenie korygujące. Zespoły wewnętrzne mogą koordynować testy, ale materiał dowodowy gotowy do audytu wymaga przeglądu, eskalacji i nadzoru wykraczających poza osoby, które zbudowały lub obsługiwały testowane systemy.

Chroń system podczas jego testowania

Niebezpiecznym założeniem w testowaniu odporności jest przekonanie, że testowanie samo w sobie jest zawsze dobre. W rzeczywistości testy inwazyjne mogą powodować niedostępność usług, ujawniać dane wrażliwe, zanieczyszczać logi, uruchamiać zautomatyzowane mechanizmy obronne, przerywać sesje klientów albo skłaniać dostawców do uruchomienia procedur awaryjnych.

Security Testing and Red-Teaming Policy Clarysec Security Testing and Red-Teaming Policy dostarcza organizacjom wzorzec ładu zarządczego dla bezpiecznej realizacji. Klauzula 6.1 stanowi:

Rodzaje testów: program testów bezpieczeństwa musi obejmować co najmniej: (a) skanowanie podatności, polegające na zautomatyzowanych cotygodniowych lub comiesięcznych skanach sieci i aplikacji w celu identyfikacji znanych podatności; (b) testy penetracyjne, polegające na ręcznych, pogłębionych testach określonych systemów lub aplikacji wykonywanych przez wykwalifikowanych testerów w celu identyfikacji złożonych słabości; oraz (c) ćwiczenia red team, polegające na opartych na scenariuszach symulacjach rzeczywistych ataków, w tym inżynierii społecznej i innych taktyk, w celu sprawdzenia zdolności organizacji do wykrywania i reagowania jako całości.

W przypadku TLPT element red team jest oczywisty, ale wartość audytowa wynika z projektu programu. Skanowanie podatności, testy penetracyjne, ćwiczenia red team, ćwiczenia odpornościowe i ponowne testy powinny tworzyć cykl, a nie zbiór niepowiązanych testów.

Klauzula 6.2 tej samej polityki dotyczy bezpiecznej realizacji:

Zakres i zasady prowadzenia działań: dla każdego testu lub ćwiczenia STC musi zdefiniować zakres, w tym systemy i zakresy IP objęte testem, dozwolone metody testowania, cele, termin i czas trwania. Zasady prowadzenia działań muszą być udokumentowane. Na przykład systemy wrażliwe operacyjnie mogą zostać oznaczone jako „tylko monitorowanie”, aby uniknąć zakłóceń, a każde testowanie w środowisku produkcyjnym musi obejmować procedury wycofania zmian i zatrzymania testu. Należy ustanowić środki bezpieczeństwa, takie jak określone okna czasowe i kanały komunikacji, aby zapobiec niezamierzonej niedostępności usług.

Mapuje się to bezpośrednio na Zenith Blueprint, fazę Controls in Action, krok 21, który koncentruje się na zabezpieczeniu 8.34 z Załącznika A ISO 27001, ochronie systemów informatycznych podczas testów audytowych. Zenith Blueprint ostrzega, że audyty, testy penetracyjne, analizy kryminalistyczne i oceny operacyjne mogą obejmować uprawnienia podwyższone, narzędzia inwazyjne lub tymczasowe zmiany zachowania systemu. Podkreśla autoryzację, zakres, okna czasowe, zgodę właściciela systemu, wycofanie zmian, monitorowanie oraz bezpieczne postępowanie z danymi testowymi.

Pakiet materiału dowodowego gotowy do audytu powinien obejmować:

• kartę TLPT i cele;
• podsumowanie informacji o zagrożeniach i uzasadnienie scenariusza;
• funkcje krytyczne lub istotne objęte zakresem;
• systemy, zakresy IP, tożsamości, dostawców i środowiska objęte zakresem;
• wyłączenia i systemy objęte wyłącznie monitorowaniem;
• zasady prowadzenia działań;
• ocenę ryzyka testowania produkcyjnego;
• procedury wycofania zmian i zatrzymania testu;
• model powiadamiania SOC, w tym zakres ujawnianych i wstrzymywanych informacji;
• zgody prawne, prywatnościowe i dostawców;
• dowody utworzenia i cofnięcia kont testowych;
• bezpieczną lokalizację przechowywania artefaktów testowych i logów.

DORA TLPT, który nie potrafi wykazać bezpiecznej autoryzacji i kontroli aktywności testowej, może ujawniać luki odpornościowe, ale jednocześnie tworzy luki w ładzie zarządczym.

Przekształć wyniki TLPT w postępowanie z ryzykiem

Najczęstszą porażką po teście jest problem raportu red team odłożonego na półkę. Raport wysokiej jakości zostaje dostarczony, rozesłany, omówiony, a następnie stopniowo traci impet. Ustalenia pozostają otwarte. Zabezpieczenia kompensujące nie są dokumentowane. Zaakceptowane ryzyka mają charakter nieformalny. Ponowne testowanie nigdy się nie odbywa.

Security Testing and Red-Teaming Policy uznaje to za niedopuszczalne. Klauzula 6.6 stanowi:

Działania naprawcze dotyczące ustaleń: wszystkie zidentyfikowane podatności lub słabości muszą być udokumentowane w raporcie ustaleń wraz z oceną wagi. Po otrzymaniu raportu właściciele systemów odpowiadają za przygotowanie planu działań naprawczych z terminami realizacji; na przykład ustalenia krytyczne muszą zostać usunięte w ciągu 30 dni, a ustalenia o wysokiej wadze w ciągu 60 dni, zgodnie z Polityką zarządzania podatnościami i poprawkami organizacji. STC musi śledzić postęp działań naprawczych. Należy przeprowadzić ponowne testy, aby potwierdzić, że kwestie krytyczne zostały rozwiązane lub odpowiednio ograniczone.

Klauzula 6.7 dodaje warstwę ładu zarządczego:

Raportowanie: po zakończeniu każdego testu należy wydać formalny raport. W przypadku testów penetracyjnych raport musi zawierać podsumowanie dla kierownictwa, metodykę oraz szczegółowe ustalenia z dowodami wspierającymi i rekomendacjami. W przypadku ćwiczeń red team raport musi opisywać scenariusze, skuteczne ścieżki ataku, elementy wykryte przez Blue Team oraz wnioski dotyczące luk w wykrywaniu i reagowaniu. CISO musi przedstawić podsumowane wyniki i status działań naprawczych kierownictwu wyższego szczebla oraz, tam gdzie ma to zastosowanie, uwzględnić je w rocznym raporcie bezpieczeństwa dla Rady Dyrektorów.

Jest to zgodne z wytycznymi ISO/IEC 27005:2022 dotyczącymi postępowania z ryzykiem: wybór opcji postępowania, określenie zabezpieczeń z Załącznika A ISO 27001 oraz wymagań sektorowych, opracowanie planu postępowania z ryzykiem, przypisanie osób rozliczalnych, zdefiniowanie terminów, śledzenie statusu, uzyskanie akceptacji właściciela ryzyka i udokumentowanie akceptacji ryzyka szczątkowego.

Każde istotne ustalenie TLPT powinno stać się jedną z czterech rzeczy: działaniem korygującym, usprawnieniem zabezpieczenia, formalną akceptacją ryzyka albo wymaganiem ponownego testu.

Celem nie jest produkowanie większej liczby dokumentów. Celem jest to, aby każdy dokument wyjaśniał następną decyzję.

Testowanie odporności musi potwierdzać odtwarzanie, a nie tylko wykrywanie

Udany TLPT może pokazać, że SOC wykrył ruch command-and-control, zablokował ruch lateralny i prawidłowo przeprowadził eskalację. To wartościowe, ale testowanie odporności w DORA idzie dalej. Pyta, czy organizacja potrafi kontynuować lub odtworzyć usługi biznesowe.

Zenith Blueprint, faza Controls in Action, krok 23, wyjaśnia zabezpieczenie 5.30, gotowość ICT do ciągłości działania, językiem, którego każdy CISO powinien używać w rozmowie z zarządem:

Z perspektywy audytu ten środek kontroli jest często testowany jednym zdaniem: Pokażcie mi. Pokażcie mi ostatni wynik testu. Pokażcie mi dokumentację odzyskiwania. Pokażcie mi, ile trwało przełączenie awaryjne i powrót. Pokażcie mi dowód, że to, co obiecano, można dostarczyć.

Ten standard „Pokażcie mi” stanowi różnicę między dojrzałością polityk a odpornością operacyjną.

Business Continuity Policy and Disaster Recovery Policy-sme Clarysec Business Continuity Policy and Disaster Recovery Policy - SME, z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula 6.4.1, stanowi:

Organizacja musi testować zarówno swoje zdolności BCP, jak i DR co najmniej raz w roku. Testy muszą obejmować:

Sekcja dotycząca egzekwowania tej samej polityki, klauzula 8.5.1, jednoznacznie przypisuje odpowiedzialność za materiał dowodowy:

GM musi zapewnić utrzymywanie następujących elementów w stanie gotowości do audytu:

W przypadku podmiotu finansowego regulowanego przez DORA testowanie roczne może być poziomem minimalnym, a nie ambicją. Funkcje krytyczne lub istotne o wyższym ryzyku powinny być testowane częściej, zwłaszcza po zmianach architektury, migracji do chmury obliczeniowej, poważnych incydentach, nowych dostawcach ICT, istotnych wydaniach aplikacji lub zmianach ekspozycji na zagrożenia.

Silny pakiet materiału dowodowego z testu odporności powinien obejmować:

• analizę wpływu na biznes mapującą funkcję krytyczną lub istotną;
• RTO i RPO zatwierdzone przez właścicieli biznesowych;
• mapę zależności systemowych, w tym tożsamość, DNS, sieć, chmurę obliczeniową, bazę danych, monitorowanie, kopie zapasowe i usługi stron trzecich;
• wyniki testów tworzenia kopii zapasowych i odtwarzania;
• znaczniki czasu przełączenia awaryjnego i powrotu;
• dowody działania zabezpieczeń podczas zakłócenia;
• szablony komunikacji z klientami, regulatorem i wewnątrz organizacji;
• logi udziału dowódcy incydentu i zespołu kryzysowego;
• wnioski i działania doskonalące;
• dowody ponownego testowania wcześniejszych luk w odtwarzaniu.

W tym miejscu pojawia się również GDPR. GDPR Articles 2 i 3 obejmują zakresem większość przetwarzania danych osobowych UE w usługach SaaS i fintech. Article 4 definiuje dane osobowe, przetwarzanie, administratora, podmiot przetwarzający oraz naruszenie ochrony danych osobowych. Article 5 wymaga integralności, poufności i rozliczalności, co oznacza, że organizacja musi być w stanie wykazać zgodność. Jeżeli TLPT lub testy odtwarzania wykorzystują produkcyjne dane osobowe, kopiują logi zawierające identyfikatory albo walidują reakcję na naruszenie, zabezpieczenia prywatności muszą być udokumentowane.

Materiał dowodowy od dostawców to ślepy punkt DORA, którego audytorzy nie zignorują

Nowoczesne usługi finansowe są składane z platform chmurowych, aplikacji SaaS, dostawców zarządzanego bezpieczeństwa, procesorów płatności, platform danych, dostawców tożsamości, narzędzi obserwowalności, outsourcingowych zespołów rozwoju oprogramowania i dostawców kopii zapasowych.

DORA Article 28 wymaga, aby podmioty finansowe zarządzały ryzykiem ICT związanym ze stronami trzecimi jako częścią ram zarządzania ryzykiem ICT i pozostawały w pełni odpowiedzialne także wtedy, gdy usługi ICT są outsourcingowane. Article 30 wymaga pisemnych umów dotyczących usług ICT, obejmujących opisy usług, warunki podwykonawstwa, lokalizacje przetwarzania, ochronę danych, dostęp i odtwarzanie, poziomy usług, wsparcie w incydentach, współpracę z organami, prawa wypowiedzenia, silniejsze postanowienia dla funkcji krytycznych lub istotnych, prawa audytu, środki bezpieczeństwa, udział w TLPT tam, gdzie ma to zastosowanie, oraz uzgodnienia wyjścia.

Oznacza to, że scenariusz TLPT nie może kończyć się na zaporze sieciowej organizacji, jeżeli funkcja krytyczna zależy od dostawcy.

Third-Party and Supplier Security Policy-sme Clarysec Third-Party and Supplier Security Policy - SME, z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula 6.3.1, stanowi:

Dostawcy krytyczni lub wysokiego ryzyka muszą być przeglądani co najmniej raz w roku. Przegląd musi weryfikować:

Security Testing and Red-Teaming Policy dodaje wymaganie dotyczące dostawców specyficzne dla testowania w klauzuli 6.9:

Koordynacja testów ze stronami trzecimi: jeżeli jakikolwiek krytyczny dostawca lub dostawca usług mieści się w zakresie ogólnego bezpieczeństwa organizacji, zgodnie z Polityką bezpieczeństwa dostawców i stron trzecich, organizacja powinna, tam gdzie jest to wykonalne, uzyskać zapewnienie dotyczące jego praktyk testowania bezpieczeństwa albo koordynować wspólne testy. Na przykład, gdy wykorzystywany jest dostawca usług chmurowych (CSP), organizacja może polegać na jego raportach z testów penetracyjnych albo uwzględnić go we współdzielonych scenariuszach red team, z zastrzeżeniem postanowień umownych.

Dla materiału dowodowego DORA gotowego do audytu zapewnienie dostawców powinno być powiązane z tym samym scenariuszem ryzyka co TLPT. Jeżeli dostawca tożsamości jest niezbędny do odtworzenia płatności, pakiet dowodowy powinien obejmować due diligence dostawcy, umowne wymagania bezpieczeństwa, warunki wsparcia w incydentach, koordynację testów, raporty zapewnienia, dowody poziomu usług, strategię wyjścia oraz ograniczenia dotyczące testowania.

NIS2 Article 21 ma również znaczenie dla dostawców SaaS, chmury obliczeniowej, usług zarządzanych, zarządzanego bezpieczeństwa, centrów danych, CDN, usług zaufania, DNS, TLD, platform handlu internetowego, wyszukiwarek i serwisów społecznościowych. Wymaga podejścia uwzględniającego wszystkie zagrożenia, obejmującego analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczny rozwój oprogramowania, ocenę skuteczności, szkolenia, kryptografię, kontrolę dostępu, zarządzanie aktywami, MFA i bezpieczną komunikację.

Praktyczny wniosek jest prosty: podmioty finansowe powinny zbudować jeden model dowodowy, który w pierwszej kolejności spełnia DORA, a następnie odwołuje się krzyżowo do oczekiwań NIS2 tam, gdzie zaangażowani są dostawcy, podmioty grupy lub niefinansowe usługi cyfrowe.

Praktyczny rejestr materiału dowodowego Clarysec TLPT

Załóżmy następujący scenariusz:

„Sprawca zagrożenia przejmuje konto administratora na platformie wsparcia SaaS, przenosi się do środowiska operacji płatniczych, modyfikuje konfigurację i zakłóca przetwarzanie transakcji”.

Utwórz rejestr materiału dowodowego z jednym wierszem dla każdego obiektu dowodowego. Nie czekaj do zakończenia testu. Uzupełniaj go podczas planowania, realizacji, działań korygujących i zamknięcia.

Następnie użyj Zenith Blueprint, krok 13, aby dodać identyfikowalność do rejestru ryzyk i Deklaracji stosowania. Każdy element dowodowy powinien łączyć się ze scenariuszem ryzyka, właścicielem ryzyka, wybranym zabezpieczeniem, planem postępowania z ryzykiem oraz decyzją dotyczącą ryzyka szczątkowego.

Jeżeli ustalenie dotyczy słabości oprogramowania, należy przywołać zabezpieczenia bezpiecznego rozwoju oprogramowania i testowania. Secure Development Policy-sme Clarysec Secure Development Policy - SME, z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula 6.5.2, wymaga:

Testowanie musi być udokumentowane wraz z:

Jeżeli ustalenie generuje materiał kryminalistyczny, zachowaj łańcuch nadzoru. Evidence Collection and Forensics Policy-sme Clarysec Evidence Collection and Forensics Policy - SME, z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula 5.2.1, stanowi:

Każdy element dowodu cyfrowego musi zostać zarejestrowany wraz z:

To punkt, który wiele zespołów pomija. Materiał dowodowy to nie tylko raporty końcowe. To kontrolowany zapis tego, kto zatwierdził, kto wykonał, co się wydarzyło, co wykryto, co odtworzono, co zmieniono, co pozostaje narażone oraz kto zaakceptował tę ekspozycję.

Jak audytorzy analizują ten sam materiał dowodowy TLPT

Materiał dowodowy DORA TLPT będzie odczytywany różnie w zależności od doświadczenia audytora. Clarysec projektuje pakiety dowodowe tak, aby każda perspektywa znalazła to, czego potrzebuje, bez zmuszania zespołów do dublowania pracy.

COBIT 2019 pojawia się w odwołaniach zgodności krzyżowej Zenith Blueprint dotyczących bezpiecznej realizacji audytu i testowania, w tym DSS05.03 i MEA03.04. Istotą nie jest to, że COBIT zastępuje DORA lub ISO 27001, lecz to, że specjaliści zapewnienia w stylu ISACA będą szukać dowodów kontrolowanej realizacji, monitorowania, oceny i zgodności.

Narracja dla zarządu: co kierownictwo musi zatwierdzić

Raportowanie do zarządu powinno unikać teatru technicznego. Zarząd nie potrzebuje ładunków exploitów. Potrzebuje materiału dowodowego umożliwiającego podejmowanie decyzji:

• Którą funkcję krytyczną lub istotną testowano?
• Jaki scenariusz zagrożenia zasymulowano i dlaczego?
• Czy wykrywanie zadziałało?
• Czy eskalacja reakcji zadziałała?
• Czy odtwarzanie spełniło RTO i RPO?
• Którzy dostawcy byli zaangażowani lub stanowili ograniczenie?
• Jakie istotne słabości pozostają?
• Jaki jest koszt działań korygujących, właściciel i harmonogram?
• Które ryzyka szczątkowe wymagają formalnej akceptacji?
• Co zostanie ponownie przetestowane?

W tym miejscu ważna staje się ISO 27001, klauzula 5. Najwyższe kierownictwo musi zapewnić ustanowienie polityki i celów bezpieczeństwa informacji, ich dostosowanie do kierunku strategicznego, zintegrowanie z procesami biznesowymi, zapewnienie zasobów, komunikację i ciągłe doskonalenie. Role i odpowiedzialności muszą zostać przypisane. Cele muszą być mierzalne tam, gdzie jest to praktyczne, oraz uwzględniać mające zastosowanie wymagania i wyniki postępowania z ryzykiem.

Jeżeli TLPT wykaże, że czas odtwarzania wynosi sześć godzin wobec czterogodzinnej tolerancji biznesowej, nie jest to jedynie pozycja backlogu infrastrukturalnego. To decyzja zarządcza obejmująca apetyt na ryzyko, budżet, zobowiązania wobec klientów, ekspozycję regulacyjną, umowy, architekturę i zdolności operacyjne.

Typowe braki w materiale dowodowym przy testowaniu odporności DORA

Przeglądy Clarysec często ujawniają te same luki dowodowe u podmiotów finansowych i dostawców usług ICT przygotowujących się do DORA.

Po pierwsze, zakres TLPT nie mapuje się na funkcje krytyczne lub istotne. Test może być technicznie imponujący, ale nie potwierdza odporności procesu biznesowego, który interesuje regulatorów.

Po drugie, zależności od dostawców są deklarowane, ale nieudowodnione. Zespoły mówią, że dostawca chmury, zarządzany SOC lub platforma SaaS są w zakresie, a jednak brakuje umów, praw audytu, zgód na testowanie, warunków wsparcia w incydentach i planów wyjścia.

Po trzecie, testowanie tworzy materiał dowodowy, ale nie prowadzi do postępowania z ryzykiem. Ustalenia pozostają w raporcie red team zamiast zostać przekształcone w aktualizacje rejestru ryzyk, zmiany zabezpieczeń, właścicieli, terminy, ponowne testy i decyzje dotyczące ryzyka szczątkowego.

Po czwarte, odtwarzanie jest zakładane, a nie wykazane. Polityki kopii zapasowych istnieją, ale nikt nie potrafi pokazać znaczników czasu przełączenia awaryjnego, kontroli integralności odtworzenia, walidacji dostępu ani potwierdzenia właściciela biznesowego.

Po piąte, dowody prywatnościowe i kryminalistyczne są niekontrolowane. Logi i zrzuty ekranu zawierają dane osobowe, artefakty testowe są przechowywane na dyskach współdzielonych, konta tymczasowe pozostają aktywne, a łańcuch nadzoru nad materiałem dowodowym jest niekompletny.

Po szóste, raportowanie zarządcze jest zbyt techniczne. Kierownictwo wyższego szczebla nie widzi, czy odporność się poprawiła, czy ryzyko mieści się w apetycie na ryzyko ani jakie decyzje inwestycyjne są potrzebne.

Każdą z tych luk można usunąć, traktując DORA TLPT jako uporządkowany przepływ pracy dowodowej ISO 27001.

Zintegrowane podejście Clarysec do odporności gotowej do audytu

Podejście Clarysec łączy trzy warstwy.

Pierwszą warstwą jest 30-etapowa mapa drogowa wdrożenia Zenith Blueprint. W tym temacie krok 13 buduje identyfikowalność postępowania z ryzykiem i SoA, krok 21 chroni systemy podczas testów audytowych, a krok 23 waliduje gotowość ICT do ciągłości działania. Te kroki przekształcają TLPT z wydarzenia technicznego w udokumentowany cykl ładu zarządczego.

Drugą warstwą jest biblioteka polityk Clarysec. Security Testing and Red-Teaming Policy definiuje rodzaje testów, zakres, zasady prowadzenia działań, działania korygujące, raportowanie i koordynację z dostawcami. Business Continuity Policy and Disaster Recovery Policy-sme określa oczekiwania wobec corocznego testowania BCP i DR oraz gotowego do audytu materiału dowodowego ciągłości działania. Third-Party and Supplier Security Policy-sme wspiera zapewnienie dostawców. Secure Development Policy-sme zapewnia dokumentowanie testów bezpieczeństwa. Evidence Collection and Forensics Policy-sme wspiera rejestrowanie materiału dowodowego i dyscyplinę łańcucha nadzoru.

Trzecią warstwą jest Zenith Controls, przewodnik zgodności krzyżowej Clarysec. Pomaga mapować zabezpieczenia ISO/IEC 27002:2022 na atrybuty, domeny, zdolności operacyjne i oczekiwania międzyramowe. W przypadku DORA TLPT najważniejszym wzorcem nie jest pojedyncze zabezpieczenie. Jest nim relacja między testowaniem, ciągłością działania, zarządzaniem incydentami, zarządzaniem dostawcami, rejestrowaniem zdarzeń, monitorowaniem, bezpiecznym rozwojem oprogramowania, niezależnym przeglądem i ładem zarządczym.

Gdy te warstwy działają razem, poniedziałkowy problem CISO zmienia się. Zamiast trzech niepowiązanych pytań od zarządu, regulatora i audytu wewnętrznego organizacja ma jedną historię dowodową:

„Zidentyfikowaliśmy funkcję krytyczną. Oceniliśmy ryzyko ICT. Wybraliśmy i uzasadniliśmy zabezpieczenia. Autoryzowaliśmy i bezpiecznie przeprowadziliśmy TLPT. Wykrywaliśmy, reagowaliśmy i odtwarzaliśmy. Zaangażowaliśmy dostawców tam, gdzie było to wymagane. Udokumentowaliśmy materiał dowodowy. Usunęliśmy ustalenia. Przeprowadziliśmy ponowne testy. Kierownictwo dokonało przeglądu i zaakceptowało pozostałe ryzyko”.

To jest odporność gotowa do audytu.

Następne kroki

Jeżeli Twój program DORA TLPT nadal jest zorganizowany wokół raportów, a nie łańcuchów dowodowych, zacznij od przeglądu materiału dowodowego z Clarysec.

Użyj Zenith Blueprint Zenith Blueprint, kroku 13, aby połączyć scenariusze TLPT z ryzykami, zabezpieczeniami i Deklaracją stosowania. Użyj kroku 21, aby zweryfikować bezpieczną autoryzację, zasady prowadzenia działań, wycofanie zmian, monitorowanie i uporządkowanie środowiska po testach. Użyj kroku 23, aby potwierdzić gotowość ICT do ciągłości działania przy użyciu materiału dowodowego odtwarzania.

Następnie dostosuj dokumenty operacyjne do Security Testing and Red-Teaming Policy Clarysec Security Testing and Red-Teaming Policy, Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME, Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, Secure Development Policy-sme Secure Development Policy - SME oraz Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME.

Na koniec użyj Zenith Controls Zenith Controls, aby krzyżowo zmapować materiał dowodowy DORA TLPT na zabezpieczenia ISO 27001, NIS2, GDPR, COBIT 2019 i oczekiwania audytorów.

Jeżeli chcesz, aby Twój kolejny test odporności wygenerował coś więcej niż ustalenia, użyj Clarysec, aby przekształcić go w możliwy do obrony łańcuch dowodowy. Pobierz pakiety narzędzi, zaplanuj ocenę gotowości materiału dowodowego albo poproś o omówienie, w jaki sposób Clarysec mapuje DORA TLPT na zabezpieczenia ISO 27001:2022 od planowania aż po zatwierdzenie przez zarząd.