Strategia ITDR dla ISO 27001, NIS2, DORA i GDPR

O 3:00 nad ranem we wtorek Sarah, CISO FinScale, obudziła się po alercie, którego współcześni liderzy bezpieczeństwa obawiają się coraz częściej. Aktywna sesja starszego programisty, uwierzytelniona za pomocą MFA zaledwie kilka godzin wcześniej, była używana z nietypowego źródła do enumeracji schematów produkcyjnej bazy danych.

Nie było sygnału złośliwego oprogramowania. Nie było żądania okupu ransomware. Nie było exploita zapory sieciowej. Była tylko tożsamość.

SOC wykrył aktywność, ale reakcja była niespójna. Czy było to obejście MFA, skradziony token sesji, czy naruszenie bezpieczeństwa samego dostawcy tożsamości? Kto miał uprawnienia do zakończenia aktywnej sesji? Czy reset hasła wystarczał, czy zespół musiał unieważnić tokeny odświeżania, zrotować dane uwierzytelniające API i przejrzeć uprawnienia OAuth? Zanim aktywność została powstrzymana, atakujący działał przez 47 minut.

Następnego ranka incydent bezpieczeństwa stał się problemem ładu organizacyjnego. Zarząd oczekiwał prostego wyjaśnienia, czy cyberhigiena FinScale zawiodła w świetle NIS2. Zespół ds. zgodności chciał wiedzieć, czy zdarzenie można zaklasyfikować jako poważny incydent związany z ICT w rozumieniu DORA. Dział prawny potrzebował możliwej do obrony odpowiedzi, czy doszło do dostępu do danych osobowych w świetle GDPR Article 32 i czy wymagana jest ocena naruszenia ochrony danych osobowych. Audytor zewnętrzny zapytał, czy zabezpieczenia ISO/IEC 27001:2022 działają skutecznie, a nie tylko są opisane w politykach.

Problem Sarah nie wynikał z braku narzędzi. FinScale miał dostawcę tożsamości, MFA, SIEM, zabezpieczenia punktów końcowych, logi chmurowe i proces reagowania na incydenty. Problem polegał na tym, że zarządzanie tożsamością, rejestrowanie, monitorowanie, reagowanie na incydenty, ocena prywatności i postępowanie z materiałem dowodowym działały w silosach.

To jest problem Identity Threat Detection and Response w 2026 roku. ITDR nie jest już wyłącznie zdolnością operacji bezpieczeństwa. To mechanizm tworzenia materiału dowodowego wspierający zgodność z ISO/IEC 27001:2022, NIS2, DORA i GDPR Article 32.

Zenith Blueprint: 30-etapowa mapa drogowa dla audytora Clarysec Zenith Blueprint, pakiet polityk oraz Zenith Controls: przewodnik po zgodności międzyramowej Zenith Controls pomagają organizacjom przekształcić ataki na tożsamość z chaotycznych dochodzeń w powtarzalne, możliwe do audytu procesy kontrolne.

Dlaczego Identity Threat Detection and Response jest dziś tematem dla zarządu

Ataki na tożsamość są skuteczne, ponieważ nadużywają legalnych ścieżek dostępu. Atakujący, który kradnie token sesji, rejestruje złośliwą aplikację OAuth, przejmuje konto serwisowe albo nakłania użytkownika przez zmęczenie powiadomieniami MFA, może wyglądać jak prawidłowy użytkownik dla systemów, które sprawdzają wyłącznie, czy uwierzytelnianie zakończyło się sukcesem.

To odróżnia ITDR od tradycyjnej ochrony perymetru. Dojrzały program musi umieć odpowiedzieć na następujące pytania:

• Jakie istnieją tożsamości ludzkie, serwisowe, dostawców i aplikacyjne?
• Które tożsamości są uprzywilejowane, uśpione, współdzielone albo sfederowane zewnętrznie?
• Które zdarzenia uwierzytelniania są normalne, ryzykowne albo niemożliwe?
• Które uprawnienia OAuth, tokeny SaaS i dane uwierzytelniające API mogą uzyskać dostęp do danych wrażliwych?
• Które alerty uruchamiają klasyfikację incydentu, zabezpieczenie materiału dowodowego i decyzje regulacyjne?
• Które zabezpieczenia dowodzą, że dostęp do danych osobowych jest chroniony odpowiednimi środkami technicznymi i organizacyjnymi?

NIS2 czyni z tego zagadnienie ładu organizacyjnego. Article 20 wymaga, aby organy zarządzające podmiotów kluczowych i ważnych zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie i odbywały szkolenia. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, oceny skuteczności zabezpieczeń, cyberhigieny, szkoleń, kontroli dostępu, zarządzania aktywami oraz uwierzytelniania wieloskładnikowego lub ciągłego tam, gdzie jest to właściwe.

DORA wywiera podobną presję na podmioty finansowe. Wymaga udokumentowanych ram zarządzania ryzykiem ICT, odpowiedzialności organu zarządzającego, mechanizmów wykrywania, zarządzania incydentami, klasyfikacji, raportowania, testowania odporności oraz zarządzania ryzykiem ICT stron trzecich. DORA ma zastosowanie od 17 stycznia 2025 r. W przypadku podmiotów finansowych objętych również NIS2 DORA pełni funkcję sektorowego zbioru zasad dla nakładających się obowiązków dotyczących ryzyka ICT i incydentów.

GDPR dodaje warstwę rozliczalności w zakresie prywatności. Article 5 wymaga integralności, poufności i rozliczalności. Article 4 szeroko definiuje naruszenie ochrony danych osobowych, obejmując nim również nieuprawniony dostęp do danych osobowych. Article 32 wymaga odpowiednich środków technicznych i organizacyjnych zapewniających poziom bezpieczeństwa odpowiadający ryzyku. W incydentach tożsamości logi, mechanizmy kontroli dostępu, zapisy uwierzytelniania i materiał dowodowy z incydentu stają się kluczowe dla wykazania, czy dane osobowe były chronione.

ISO/IEC 27001:2022 jest systemem zarządzania, który może spiąć te obowiązki w całość. Klauzula 4 wymaga, aby organizacja rozumiała swój kontekst, strony zainteresowane oraz wymagania prawne, regulacyjne i umowne. Klauzula 6 wymaga oceny ryzyka, postępowania z ryzykiem, zatwierdzenia przez właściciela ryzyka i zachowania dowodów. Załącznik A obejmuje zabezpieczenia dotyczące zarządzania tożsamością, bezpiecznego uwierzytelniania, rejestrowania, monitorowania, zarządzania incydentami, zabezpieczania materiału dowodowego, relacji z dostawcami, usług w chmurze obliczeniowej i ochrony prywatności.

ITDR powinien być częścią SZBI, ponieważ ryzyko związane z tożsamością staje się możliwe do audytu dopiero wtedy, gdy jest objęte zakresem, ma właściciela, jest oceniane, poddawane postępowaniu z ryzykiem, monitorowane i doskonalone.

Scenariusz ataku na tożsamość, który interesuje regulatorów

Rozważmy dostawcę chmurowej platformy procesów finansowych obsługującego klientów z UE. Korzysta on z Microsoft 365, platformy SaaS do obsługi klienta, infrastruktury chmurowej, procesora płatności i kilku integracji opartych na API. Starszy inżynier wsparcia otrzymuje przekonujący monit o ponowne połączenie aplikacji produktywnościowej. Ekran zgody OAuth żąda dostępu do odczytu skrzynki pocztowej oraz dostępu offline. Inżynier zatwierdza żądanie.

W ciągu kilku minut atakujący używa tokenu do wyszukiwania identyfikatorów klientów i załączników zgłoszeń wsparcia. Enumeruje członkostwo w grupach i próbuje uzyskać dostęp do portalu administracyjnego. MFA było włączone, ale atakujący nie potrzebuje ponownie hasła, ponieważ token zapewnia trwały dostęp. SOC widzi nietypowy dostęp do skrzynki pocztowej, nową aplikację OAuth, nieudane próby dostępu do portalu administracyjnego oraz aktywność z nietypowej lokalizacji geograficznej.

Ten pojedynczy scenariusz przecina wiele obszarów kontroli:

• Cykl życia tożsamości, ponieważ rola i uprawnienia użytkownika determinują zasięg skutków.
• Bezpieczne uwierzytelnianie, ponieważ samo MFA nie zapobiegło nadużyciu tokenu.
• Rejestrowanie i monitorowanie, ponieważ wykrywanie zależy od logów dostawcy tożsamości, SaaS i aplikacji.
• Reagowanie na incydenty, ponieważ dane uwierzytelniające, sesje, tokeny i uprawnienia OAuth muszą zostać szybko unieważnione.
• Zabezpieczanie materiału dowodowego, ponieważ może dojść do ekspozycji danych osobowych i obowiązku raportowania regulacyjnego.
• Nadzór nad dostawcami i chmurą obliczeniową, ponieważ logi SaaS i audytowe interfejsy API są częścią łańcucha dowodowego.
• Ochrona prywatności, ponieważ dostęp do danych osobowych musi zostać oceniony zgodnie z GDPR.

Lepsze pytanie nie brzmi: „Które narzędzie zawiodło?”. Lepsze pytanie brzmi, czy organizacja miała zaprojektowany, przetestowany i możliwy do audytu łańcuch zabezpieczeń ITDR.

Łańcuch zabezpieczeń ISO 27001:2022 stojący za skutecznym ITDR

Najskuteczniejsze programy ITDR łączą zabezpieczenia prewencyjne, detekcyjne, korygujące i dowodowe.

W Zenith Controls zabezpieczenie ISO/IEC 27001:2022 5.16 Identity management jest traktowane jako zabezpieczenie prewencyjne wspierające poufność, integralność i dostępność. Łączy się bezpośrednio z 5.15 Access control, 5.17 Authentication information, 5.18 Access rights, 5.19 Information security in supplier relationships, 5.36 Compliance with policies, rules and standards for information security oraz 8.2 Privileged access rights.

Ma to znaczenie, ponieważ wykrywanie zagrożeń tożsamościowych zawodzi, gdy nadzór nad tożsamością jest słaby. Jeżeli konto serwisowe nie jest udokumentowane, tożsamość dostawcy nie jest zarządzana albo rola uprzywilejowana nie ma właściciela, monitorowanie może wykryć zdarzenie, ale osoby reagujące nie będą w stanie szybko go zinterpretować.

Zabezpieczenie 8.5 Secure authentication jest kolejną kotwicą ITDR. W Zenith Controls łączy się z zarządzaniem tożsamością, informacjami uwierzytelniającymi, prawami dostępu uprzywilejowanego, ograniczeniem dostępu do informacji, działaniami monitorowania, zarządzaniem incydentami i ochroną prywatności PII. Uwierzytelnianie nie kończy się na logowaniu. Zarządzanie sesją, obsługa tokenów, ochrona danych uwierzytelniających i identyfikowalność są częścią tej samej historii dowodowej.

Zabezpieczenie 8.16 Monitoring activities jest punktem przejścia między zbieraniem logów a podejmowaniem decyzji. Zależy od 8.15 Logging i wspiera 5.25 Assessment and decision on information security events, 5.26 Response to information security incidents oraz szersze zarządzanie incydentami. W ITDR 8.16 jest miejscem, w którym podejrzane zachowanie tożsamości staje się zdarzeniem po triage, zadeklarowanym incydentem albo udokumentowanym fałszywym alarmem.

Tabela nie jest teoretycznym mapowaniem. To praktyczny łańcuch dowodowy, którego po incydencie tożsamości będzie oczekiwać audytor, członek zarządu albo regulator.

Co wnoszą polityki Clarysec: własność, wyzwalacze i reguły dowodowe

Narzędzia tożsamościowe nie tworzą automatycznie rozliczalności. W czasie kryzysu osoby reagujące potrzebują uprawnień do unieważniania sesji, wyłączania kont, eksportowania logów, zabezpieczania materiału dowodowego i podejmowania decyzji eskalacyjnych. Audytorzy muszą widzieć, że działania te nie były improwizowane.

Pakiet polityk Clarysec dostarcza taki model operacyjny.

Z korporacyjnej Polityki zarządzania kontami użytkowników i uprawnieniami Polityka zarządzania kontami użytkowników i uprawnieniami, klauzula 5.9 wymagań ładu organizacyjnego stanowi:

Organizacja musi utrzymywać szczegółowy inwentarz wszystkich aktywnych i uśpionych danych uwierzytelniających, kont uprzywilejowanych oraz kont serwisowych na poziomie systemowym. Inwentarz ten musi być aktualizowany w sposób ciągły i przeglądany kwartalnie.

To przekształca inwentarz tożsamości w wyraźny obowiązek kontrolny. Jest to szczególnie istotne, ponieważ konta serwisowe, klucze API i uśpione dane uwierzytelniające są częstymi martwymi punktami ITDR.

Ta sama polityka w klauzuli 5.8 wymagań ładu organizacyjnego stanowi:

Wszystkie działania administracyjne i działania na kontach uprzywilejowanych muszą być rejestrowane w sposób umożliwiający wykrycie manipulacji oraz monitorowane pod kątem anomalii lub naruszeń polityki.

Ta klauzula łączy zarządzanie dostępem uprzywilejowanym z detekcją. Działanie uprzywilejowane nie jest jedynie dozwolone albo zabronione. Musi być monitorowane pod kątem zachowania, które nie pasuje do użytkownika, roli, źródła, czasu albo procesu biznesowego.

Dla mniejszych organizacji Polityka zarządzania kontami użytkowników i uprawnieniami - MŚP Polityka zarządzania kontami użytkowników i uprawnieniami - MŚP określa zwięzłe oczekiwanie w klauzuli 8.1.1 dotyczącej egzekwowania i zgodności:

Osoba odpowiedzialna za IT musi regularnie przeglądać logi systemowe pod kątem prób nieuprawnionego dostępu, anomalii logowania lub niezatwierdzonych zmian uprawnień.

W tym miejscu zaczyna się wiele programów ITDR w MŚP. Nie wymaga to dużego SOC. Wymaga wskazanej odpowiedzialności i regularnego przeglądu właściwych sygnałów tożsamościowych.

Polityka rejestrowania zapewnia podstawę dowodową. Polityka logowania i monitorowania - MŚP Polityka logowania i monitorowania - MŚP określa w klauzuli 5.4.2 wymagań ładu organizacyjnego:

Logi uwierzytelniania: udane i nieudane próby logowania, czas trwania sesji, użycie MFA

Te pola nie są opcjonalne. Pomagają wykazać, czy podejrzane zdarzenie obejmowało skuteczne uwierzytelnianie, powtarzające się niepowodzenia, użycie MFA, trwałość sesji albo nietypowy czas trwania.

Korporacyjna Polityka logowania i monitorowania Polityka logowania i monitorowania rozszerza wymagany zakres logowania w klauzuli 6.1.1 wymagań wdrożenia polityki:

Wszystkie objęte systemy muszą generować logi obejmujące: 6.1.1.1 Uwierzytelnianie użytkowników i próby dostępu 6.1.1.2 Działania użytkowników uprzywilejowanych 6.1.1.3 Zmiany konfiguracji 6.1.1.4 Nieudane próby dostępu lub zdarzenia systemowe 6.1.1.5 Wykrycia złośliwego oprogramowania i alerty bezpieczeństwa 6.1.1.6 Komunikację zewnętrzną i wyzwolenia reguł zapory sieciowej

Zmiany konfiguracji są szczególnie ważne w atakach na tożsamość. Atakujący często dodają uprawnienia OAuth, tworzą reguły przekazywania poczty, rejestrują urządzenia, modyfikują metody MFA albo tworzą awaryjne ścieżki dostępu.

Polityka reagowania na incydenty nadaje następnie osobom reagującym odpowiednie uprawnienia. Korporacyjna Polityka reagowania na incydenty Polityka reagowania na incydenty stanowi w klauzuli 6.2.1 wymagań wdrożenia polityki:

SOC musi niezwłocznie izolować dotknięte systemy, cofać naruszone dane uwierzytelniające albo blokować złośliwy ruch przy użyciu zapory sieciowej lub narzędzi ochrony punktów końcowych.

Polityka reagowania na incydenty - MŚP Polityka reagowania na incydenty - MŚP stanowi w klauzuli 4.2.2 dotyczącej ról i odpowiedzialności:

Wdraża działania powstrzymania i odzyskiwania, na przykład przez wyłączenie dostępu lub odtworzenie kopii zapasowych.

W ITDR reset hasła nie wystarcza. Podręczniki operacyjne muszą obejmować wyłączanie kont, unieważnianie sesji, unieważnianie uprawnień OAuth, rotację sekretów, resetowanie metod MFA i przegląd delegowanych uprawnień.

Postępowanie z materiałem dowodowym jest różnicą między reakcją a możliwością jej udowodnienia. Korporacyjna Polityka zabezpieczania materiału dowodowego i informatyki śledczej Polityka zabezpieczania materiału dowodowego i informatyki śledczej stanowi w klauzuli 5.5 wymagań ładu organizacyjnego:

Cały zebrany materiał dowodowy musi być jednoznacznie zidentyfikowany, oznaczony i przechowywany w bezpiecznym repozytorium obejmującym: 5.5.1 Weryfikację integralności, na przykład wartości skrótu SHA-256 5.5.2 Logi dostępu opatrzone znacznikiem czasu 5.5.3 Wpisy łańcucha nadzoru podpisane przez każdego depozytariusza

Polityka zabezpieczania materiału dowodowego i informatyki śledczej - MŚP Polityka zabezpieczania materiału dowodowego i informatyki śledczej - MŚP stanowi w klauzuli 6.1.1 wymagań wdrożenia polityki:

Zawsze należy utworzyć kopię kryminalistyczną lub eksport; oryginalny materiał dowodowy nigdy nie może być edytowany bezpośrednio.

W scenariuszu FinScale oznacza to, że SOC eksportuje logi dostawcy tożsamości, logi audytowe SaaS, zapisy dostępu do skrzynek pocztowych, zapisy zgód OAuth, zapisy unieważnienia sesji i alerty SIEM do repozytorium materiału dowodowego z ochroną integralności i łańcuchem nadzoru.

Budowanie mapy drogowej ITDR z Zenith Blueprint

Zenith Blueprint przekłada łańcuch zabezpieczeń na kroki wdrożeniowe.

W fazie Controls in Action, w kroku 19, Technological Controls I, Blueprint mówi wprost o uwierzytelnianiu:

Tam, gdzie to możliwe, należy unikać uwierzytelniania wyłącznie hasłem, szczególnie dla kont administracyjnych, konsol chmurowych, narzędzi dostępu zdalnego oraz każdego systemu wystawionego do Internetu. MFA, wykorzystujące drugi składnik, taki jak klucz sprzętowy, aplikacja mobilna albo biometria, jest dziś stanem bazowym, a nie luksusem. Ogranicza ryzyka kradzieży danych uwierzytelniających, phishingu i ataków brute force.

Ten sam krok wykracza poza hasła. Wymaga bezpiecznego przechowywania i transmisji danych uwierzytelniających, bezpiecznej obsługi tokenów API, identyfikatorów sesji i danych uwierzytelniających OAuth, zarządzania sekretami dla uwierzytelniania machine-to-machine, rotacji tokenów, kontroli czasu życia sesji, bezpiecznych flag cookies oraz przeglądu logów uwierzytelniania.

Krok 22, Organizational Controls, formalizuje cykl życia dostępu. Prowadzi zespoły przez integrację nadawania i odbierania dostępu z procesami HR, przeprowadzanie udokumentowanych kwartalnych przeglądów dostępu, definiowanie typów tożsamości, takich jak konta indywidualne, współdzielone i serwisowe, egzekwowanie MFA dla kont uprzywilejowanych, eliminowanie kont uśpionych i rotację danych uwierzytelniających usług.

Krok 19 wskazuje również ścieżkę doskonalenia rejestrowania: przekazywanie krytycznych logów do SIEM lub kolektora logów, walidację okresu retencji, prześledzenie niedawnego zdarzenia z użyciem logów, udokumentowanie funkcji integralności logów oraz potwierdzenie alertowania dla nieudanych logowań albo eskalacji uprawnień. Synchronizacja czasu ma znaczenie, ponieważ rekonstrukcja incydentu zawodzi, gdy logi dostawcy tożsamości, SaaS, punktów końcowych i chmury mają rozbieżne znaczniki czasu.

Krok 23, Organizational Controls dla 5.19 do 5.37, waliduje zdolności zarządzania incydentami. Wymaga aktualnego planu reagowania na incydenty, zdefiniowanych zdarzeń podlegających zgłoszeniu, ćwiczeń typu tabletop, udokumentowanych decyzji, zapisów komunikacji, wniosków wyciągniętych z incydentów oraz zabezpieczenia materiału dowodowego do analizy kryminalistycznej, takiego jak migawki logów, kopie zapasowe i bezpieczna izolacja.

Pragmatyczna sekwencja ITDR według Clarysec wygląda następująco:

1. Zdefiniuj typy i właścicieli tożsamości.
2. Zabezpiecz uwierzytelnianie, tokeny i sesje.
3. Zbieraj logi uwierzytelniania, uprawnień i SaaS.
4. Monitoruj zachowania ryzykowne.
5. Zdefiniuj reguły przejścia od zdarzenia do incydentu.
6. Zabezpieczaj materiał dowodowy.
7. Raportuj, odzyskuj i doskonal.

Tygodniowy pakiet dowodowy ITDR

Skoncentrowany „pakiet dowodowy incydentu tożsamości” jest jednym z najszybszych sposobów ujawnienia luk. Wybierz jeden scenariusz wysokiego ryzyka, na przykład: „Uprzywilejowany użytkownik SaaS wyraża zgodę na nieautoryzowaną aplikację OAuth, a token zostaje użyty do dostępu do danych klientów”.

Następnie zbuduj pakiet dowodowy w tydzień.

Uwzględnij co najmniej jedną rzeczywistą ścieżkę. Weź łagodną, niedawną anomalię logowania i pokaż, jak zespół przechodzi od alertu do tożsamości użytkownika, urządzenia, źródłowego adresu IP, metody MFA, czasu trwania sesji, zasobów SaaS, do których uzyskano dostęp, danych objętych dostępem i decyzji o powstrzymaniu. Jeśli organizacja nie potrafi odtworzyć tego łańcucha podczas ćwiczenia tabletop, będzie miała trudności w rzeczywistym incydencie.

Wynik staje się materiałem dowodowym wielokrotnego użytku dla audytów wewnętrznych ISO/IEC 27001:2022, testowania procesu incydentów ICT w DORA, nadzoru cyberhigieny w NIS2 i rozliczalności GDPR.

Mapowanie ITDR na NIS2, DORA i GDPR Article 32

Siłą jednolitego modelu ITDR jest to, że ten sam materiał dowodowy spełnia wiele obowiązków, przy jednoczesnym poszanowaniu języka każdych ram.

NIS2 Article 21 oczekuje opartych na ryzyku, proporcjonalnych środków technicznych, operacyjnych i organizacyjnych. Dla ITDR oznacza to kontrolę dostępu, zarządzanie aktywami, cyberhigienę, szkolenia, obsługę incydentów, ocenę skuteczności zabezpieczeń oraz MFA lub ciągłe uwierzytelnianie tam, gdzie jest to właściwe. Article 23 ustanawia etapowe raportowanie istotnych incydentów, w tym wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie incydentu w ciągu 72 godzin oraz raport końcowy w ciągu miesiąca.

DORA Articles 8 to 14 wymagają identyfikacji aktywów ICT i zależności, ochrony i zapobiegania, mechanizmów wykrywania, ciągłości i odzyskiwania, uczenia się oraz komunikacji. Articles 17 to 19 wymagają zarządzania incydentami, identyfikacji przyczyn źródłowych, wskaźników wczesnego ostrzegania, klasyfikacji według wagi i krytyczności usługi, eskalacji, powiadomienia organu zarządzającego, raportowania do właściwego organu oraz powiadamiania klientów, gdy dotknięte są ich interesy finansowe.

GDPR wymaga odpowiednich środków technicznych i organizacyjnych oraz możliwej do wykazania rozliczalności. W atakach na tożsamość pytania GDPR obejmują to, czy doszło do nieuprawnionego dostępu, jakie dane osobowe były objęte zdarzeniem, czy środki ochrony działały oraz czy zostały uruchomione progi zgłoszenia naruszenia.

Dla firm fintech relacja między NIS2 a DORA ma znaczenie. DORA jest traktowana jako sektorowe ramy dla objętych zakresem podmiotów finansowych, gdy nakładają się obowiązki dotyczące ryzyka ICT i raportowania incydentów. W praktyce organizacje powinny zbudować jeden model dowodowy ITDR i mapować decyzje raportowe na właściwą ścieżkę prawną.

W przypadku organizacji SaaS, chmurowych, usług zarządzanych, zarządzanego bezpieczeństwa i platform cyfrowych zakres NIS2 musi zostać starannie sprawdzony. NIS2 obejmuje wiele sektorów z załącznika I i II, w tym infrastrukturę cyfrową, dostawców usług chmurowych, centra danych, usługi zaufania, DNS, rejestry TLD, dostawców usług zarządzanych, dostawców usług zarządzanego bezpieczeństwa, internetowe platformy handlowe, wyszukiwarki i platformy sieci społecznościowych. Ustalanie zakresu według klauzuli 4 ISO/IEC 27001:2022 oraz analiza stron zainteresowanych nie są więc formalnością. Definiują, które obowiązki musi uwzględniać SZBI.

Ryzyko tożsamości związane z dostawcami i SaaS

Incydenty tożsamości często zależą od materiału dowodowego dostawcy. Czy dostawca SaaS może wyeksportować logi audytowe? Czy pokazuje zdarzenia zgody OAuth? Czy wspiera bezpieczne mechanizmy kontroli dostępu, rejestrowanie i ochronę danych? Czy wsparcie incydentowe, lokalizacja danych, podwykonawstwo, prawa dostępu i postanowienia dotyczące wyjścia są ujęte w umowie?

Polityka korzystania z chmury obliczeniowej - MŚP Clarysec Polityka korzystania z chmury obliczeniowej - MŚP zawiera bezpośredni wymóg z klauzuli 5.2.4 wymagań ładu organizacyjnego:

Usługa zapewnia bezpieczne mechanizmy kontroli dostępu, rejestrowanie oraz możliwości ochrony danych

To proste zdanie jest kontrolą zakupową. Jeśli platforma SaaS nie potrafi dostarczyć logów tożsamości potrzebnych do reagowania na incydenty, tworzy ryzyko zgodności.

DORA wyraża to wprost poprzez obowiązki dotyczące ryzyka ICT stron trzecich. Podmioty finansowe pozostają odpowiedzialne za zgodność, muszą utrzymywać rejestry umów dotyczących usług ICT, rozróżniać funkcje krytyczne lub ważne, prowadzić due diligence, oceniać ryzyko koncentracji, uwzględniać prawa audytu i dostępu, definiować wsparcie incydentowe i zapewniać strategie wyjścia.

W Zenith Controls zabezpieczenie ISO/IEC 27001:2022 8.16 Monitoring activities łączy się z 5.22 Monitoring, review and change management of supplier services. Odzwierciedla to rzeczywistość operacyjną. Alerty dostawcy tożsamości, logi audytowe SaaS, aktywność administratorów chmury i konta dostawców usług zarządzanych są częścią powierzchni ITDR.

Jak audytorzy będą oceniać ITDR

Silny program ITDR powinien wytrzymać ocenę z wielu perspektyw audytowych. Każda grupa odbiorców zadaje inne pytania, ale materiał dowodowy powinien pochodzić z tego samego systemu kontroli.

Audytor ISO/IEC 27001:2022 zapyta, czy zagrożenia tożsamościowe są ujęte w ocenie ryzyka, czy właściciele ryzyka zatwierdzili postępowanie z ryzykiem, czy Deklaracja stosowania obejmuje odpowiednie zabezpieczenia z załącznika A, czy polityki są wdrożone oraz czy materiał dowodowy pokazuje działanie zabezpieczeń. Może wybrać próbkę konta uprzywilejowanego i prześledzić zatwierdzenie, ustawienie MFA, aktywność w logach, przegląd dostępu i odebranie dostępu.

Asesor NIST CSF 2.0 zbada wyniki GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER. ITDR naturalnie wpisuje się w profil ograniczony do naruszenia tożsamości, nadużycia tokenu SaaS albo niewłaściwego użycia dostępu uprzywilejowanego.

Kontroler DORA będzie szukał rozliczalności organu zarządzającego, funkcji biznesowych wspieranych przez ICT, mechanizmów wykrywania, kryteriów klasyfikacji incydentów, eskalacji, zasad komunikacji z klientami, analizy przyczyn źródłowych i zależności od stron trzecich ICT.

Osoba prowadząca przegląd GDPR zapyta, czy organizacja może wykazać odpowiednie bezpieczeństwo danych osobowych. Zbada ograniczenie dostępu, wykrywanie nieuprawnionego dostępu, logi pokazujące, do jakich danych mogło dojść uzyskanie dostępu, ocenę naruszenia i dowody rozliczalności.

Audytor stosujący COBIT 2019 lub podejście ISACA zbada ład organizacyjny, cele kontroli, własność, monitorowanie wyników i zapewnienie.

Zenith Controls jest tu użyteczny, ponieważ działa jako przewodnik po zgodności międzyramowej. Nie tworzy odrębnych „zabezpieczeń Zenith”. Mapuje obszary zabezpieczeń ISO/IEC 27001:2022 na powiązane kontrole ISO, inne normy, oczekiwania audytowe i zależności wdrożeniowe.

Metryki dowodzące, że ITDR działa

Zarządy i audytorzy nie potrzebują surowego szumu z SIEM. Potrzebują dowodów, że zabezpieczenia tożsamości działają i są doskonalone. Przydatne metryki ITDR obejmują:

• Odsetek kont uprzywilejowanych z MFA odpornym na phishing.
• Liczbę kont uśpionych starszych niż próg określony w polityce.
• Liczbę kont serwisowych bez właściciela lub daty rotacji.
• Odsetek krytycznych platform SaaS przekazujących logi uwierzytelniania do SIEM.
• Średni czas wykrycia podejrzanej aktywności tożsamościowej.
• Średni czas unieważnienia naruszonych sesji i tokenów.
• Liczbę aplikacji OAuth zatwierdzonych, odrzuconych lub usuniętych.
• Odsetek incydentów tożsamości z kompletnymi pakietami dowodowymi.
• Liczbę przeterminowanych ustaleń z przeglądów dostępu.
• Liczbę platform dostawców pozbawionych wymaganych logów tożsamości.

Metryki te powinny zasilać przegląd zarządzania ISO/IEC 27001:2022, nadzór ładu organizacyjnego NIS2, raportowanie ryzyka ICT w DORA oraz dyskusje o rozliczalności GDPR.

Typowe ustalenia audytowe ITDR i działania naprawcze

Clarysec często obserwuje pięć powtarzających się ustaleń.

Po pierwsze, organizacje włączają MFA, ale nie monitorują zachowania MFA. Należy to skorygować przez rejestrowanie zmian metod MFA, nieudanych wyzwań, niemożliwej podróży, rejestracji nowych urządzeń i powtarzających się prób push.

Po drugie, konta serwisowe są wyłączone z nadzoru nad tożsamością. Należy to skorygować przez zinwentaryzowanie kont na poziomie systemowym, przypisanie właścicieli, rotację sekretów, usunięcie osadzonych danych uwierzytelniających i monitorowanie anomalnego zachowania API.

Po trzecie, zgody SaaS nie są zarządzane. Należy to skorygować przez ograniczenie zgód użytkowników, przegląd aplikacji OAuth, monitorowanie nowych uprawnień, dokumentowanie zatwierdzonych integracji i usuwanie nieużywanych aplikacji.

Po czwarte, materiał dowodowy jest zmieniany podczas dochodzenia. Należy to skorygować przez stosowanie reguły z Polityki zabezpieczania materiału dowodowego i informatyki śledczej: tworzyć kopie kryminalistyczne albo eksporty, nigdy nie edytować bezpośrednio oryginałów oraz przechowywać materiał dowodowy ze skrótami i zapisami łańcucha nadzoru.

Po piąte, klasyfikacja incydentu trwa zbyt długo. Należy to skorygować przez wcześniejsze zdefiniowanie progów zdarzeń tożsamościowych, obejmujących naruszenie konta uprzywilejowanego, dostęp do danych osobowych, nadużycie tokenu SaaS wpływające na klientów, zakłócenie usługi krytycznej oraz naruszenie tożsamości dostawcy.

Każde ustalenie ma odpowiedź w obszarze kontroli, polityki i materiału dowodowego. To jest praktyczna wartość jednolitego programu ITDR: określa, co musi mieć właściciela, być monitorowane, testowane, udowodnione i doskonalone.

Przekształć ryzyko tożsamości w materiał dowodowy gotowy do audytu

Gdyby kolejny incydent tożsamości wydarzył się jutro, czy potrafiłbyś udowodnić, kto uzyskał dostęp do czego, jak się uwierzytelnił, który token lub która sesja została użyta, jakich danych dotknięto, kto zdecydował o klasyfikacji regulacyjnej i które działania korygujące zostały zakończone?

Jeśli odpowiedź nie jest pewna, rozpocznij od skoncentrowanego sprintu gotowości ITDR.

Użyj Zenith Blueprint, aby uporządkować ścieżkę wdrożenia obejmującą uwierzytelnianie, cykl życia dostępu, rejestrowanie, monitorowanie, reagowanie na incydenty i postępowanie z materiałem dowodowym. Użyj polityk Clarysec dotyczących kontroli dostępu, rejestrowania, chmury obliczeniowej, reagowania na incydenty i informatyki śledczej, aby przypisać własność i uprawnienia do reagowania. Użyj Zenith Controls, aby zmapować zarządzanie tożsamością, bezpieczne uwierzytelnianie i działania monitorowania na ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 oraz oczekiwania audytowe.

Cel jest prosty: sprawić, aby ataki na tożsamość były wykrywalne, możliwe do powstrzymania, raportowalne i możliwe do obrony.

Clarysec może pomóc zbudować pakiet dowodowy ITDR, przetestować go w scenariuszu tabletop i przekształcić ustalenia w plan postępowania z ryzykiem zrozumiały dla zarządu, regulatora i audytora. Zacznij od przeglądu Polityki logowania i monitorowania, Polityki zarządzania kontami użytkowników i uprawnieniami - MŚP, Zenith Blueprint i Zenith Controls, a następnie zaplanuj ocenę gotowości ITDR, aby przekształcić ryzyko tożsamości w materiał dowodowy gotowy do audytu.