Dowody z logów w ISO 27001 dla NIS2, DORA i GDPR

Alert pojawił się w kanale SOC we wtorek o 2:17 nad ranem: wiele nieudanych prób uwierzytelnienia uprzywilejowanego użytkownika admin z nowego adresu IP. Próby ustały po kilku minutach. Młodszy analityk odnotował alert, uznał go za błędnie skonfigurowany skrypt albo późną pracę administratora systemu i przeszedł do kolejnych zadań.

Dwa dni później Maria, dyrektor ds. bezpieczeństwa informacji w szybko rosnącej spółce FinTech, była na spotkaniu kierownictwa, gdy zawibrował jej telefon. Zespół inżynierski wykrył nietypowo wysokie wykorzystanie CPU w produkcyjnej instancji bazy danych. Utworzono nowe, nieautoryzowane konto użytkownika. Alert z 2:17 nie był fałszywym alarmem. Był pierwszym widocznym sygnałem próby włamania.

Incydent został powstrzymany, ale dochodzenie ujawniło poważniejszy problem. Logi zapory sieciowej znajdowały się w jednym systemie. Logi Kubernetes w innym. Logi audytowe bazy danych przechowywano osobno. Kilka znaczników czasu różniło się o minuty. Zespół miał dane, ale nie był w stanie szybko przedstawić możliwej do obrony historii wykrycia, przeglądu, eskalacji, powstrzymania i oceny naruszenia.

Audyt nadzoru ISO/IEC 27001:2022 Marii zakończył się pomyślnie, ale audytor pozostawił jedno ostrzeżenie: organizacja posiadała zabezpieczenia w zakresie logowania zdarzeń i monitorowania, jednak miałaby trudność z terminowym przygotowaniem skorelowanych dowodów na potrzeby decyzji raportowych w ramach NIS2, DORA i GDPR.

To rzeczywistość, z którą w 2026 roku mierzy się wiele organizacji. Nie mają problemu z logowaniem zdarzeń. Mają problem z dowodami.

SIEM, platforma EDR, ścieżka audytowa w środowisku chmurowym lub log zapory sieciowej same w sobie nie są dowodem gotowym do audytu. Dowód staje się możliwy do obrony dopiero wtedy, gdy jest objęty polityką, chroniony przed manipulacją, przeglądany zgodnie z określoną częstotliwością, powiązany z decyzjami dotyczącymi incydentów i przechowywany wystarczająco długo, aby odtworzyć przebieg zdarzeń.

W przypadku ISO/IEC 27001:2022, NIS2, DORA i GDPR kluczowe pytanie nie brzmi już: „Czy zbieramy logi?”. Pytanie brzmi: „Czy możemy wykazać, co się wydarzyło, kto to przejrzał, jak to sklasyfikowano, czy wymagane było raportowanie i czy kierownictwo sprawowało nadzór?”.

Dlaczego logowanie zdarzeń i monitorowanie stały się kwestią dowodów zgodności

NIS2, DORA i GDPR zmieniły biznesowe znaczenie logów bezpieczeństwa.

Zgodnie z NIS2 podmioty kluczowe i ważne muszą wdrożyć odpowiednie i proporcjonalne środki zarządzania ryzykiem cyberbezpieczeństwa. Article 21 obejmuje obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczny rozwój oprogramowania, ocenę skuteczności, cyberhigienę, kryptografię, bezpieczeństwo zasobów ludzkich, kontrolę dostępu, zarządzanie aktywami, MFA oraz bezpieczną komunikację. Article 23 tworzy etapowy model raportowania, obejmujący wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie incydentu w ciągu 72 godzin, aktualizacje pośrednie tam, gdzie są istotne, oraz raport końcowy nie później niż miesiąc po zgłoszeniu incydentu.

Ten model zależy od logowania zdarzeń i monitorowania. Nie można wysłać wiarygodnego wczesnego ostrzeżenia, jeżeli nie da się wykazać, kiedy zdarzenie zostało wykryte. Nie można sklasyfikować istotnego incydentu, jeżeli nie da się odtworzyć dotkniętych systemów, aktywności użytkowników, wpływu na usługę i działań powstrzymujących.

DORA wywiera podobną presję na podmioty finansowe. Articles 5 to 14 ustanawiają oczekiwania dotyczące ładu zarządczego i zarządzania ryzykiem ICT, w tym odpowiedzialności organu zarządzającego, identyfikacji aktywów ICT, ochrony i zapobiegania, wykrywania, reagowania i odzyskiwania, tworzenia kopii zapasowych, odtwarzania, uczenia się i komunikacji. Articles 17 to 23 wymagają procesu zarządzania incydentami związanymi z ICT obejmującego wykrywanie, rejestrowanie, klasyfikację, eskalację, powiadamianie i działania następcze. Articles 24 to 27 dotyczą testowania cyfrowej odporności operacyjnej. Articles 28 to 31 tworzą obowiązki zarządzania ryzykiem ICT stron trzecich.

GDPR dodaje warstwę rozliczalności w obszarze prywatności. Article 32 wymaga odpowiedniego bezpieczeństwa przetwarzania. Article 33 wymaga zgłoszenia naruszenia ochrony danych osobowych organowi nadzorczemu bez zbędnej zwłoki oraz, jeżeli jest to wykonalne, nie później niż 72 godziny po stwierdzeniu naruszenia, chyba że jest mało prawdopodobne, aby naruszenie skutkowało ryzykiem dla osób fizycznych. Article 34 może wymagać zawiadomienia osób, których dane dotyczą, gdy ryzyko jest wysokie. Logi pomagają ustalić, czy dane osobowe zostały odczytane, zmienione, wyeksfiltrowane lub ujawnione, ale same logi również mogą zawierać dane osobowe i muszą być odpowiednio zarządzane.

ISO/IEC 27001:2022 zapewnia podstawę systemu zarządzania. Klauzule 4.1 to 4.4 wymagają, aby organizacja rozumiała kontekst, strony zainteresowane, wymagania i zakres SZBI. Klauzule 5.1 to 5.3 wymagają przywództwa, zgodności polityk, ról, odpowiedzialności i uprawnień. Klauzule 6.1.1 to 6.1.3 wymagają powtarzalnego procesu oceny ryzyka i postępowania z ryzykiem, obejmującego kryteria ryzyka, właścicieli ryzyka, opcje postępowania z ryzykiem, porównanie z zabezpieczeniami Annex A, Deklarację stosowania oraz akceptację ryzyka rezydualnego. Klauzula 6.2 wymaga mierzalnych celów bezpieczeństwa informacji.

Dlatego dowody logowania zdarzeń i monitorowania nie mogą istnieć wyłącznie w SOC. Należą do SZBI, rejestru ryzyk, Deklaracji stosowania, procesu reagowania na incydenty, procesu oceny naruszeń prywatności, nadzoru nad dostawcami i raportowania zarządczego.

Zabezpieczenia ISO 27001 dotyczące logowania zdarzeń, które audytorzy łączą w pierwszej kolejności

W Zenith Blueprint: 30-etapowa mapa drogowa audytora Zenith Blueprint, w fazie Kontrole w działaniu, krok 19: Techniczne środki kontroli I, logowanie zdarzeń, monitorowanie i synchronizacja czasu są traktowane jako jeden łańcuch dowodowy.

A.8.15 – Rejestrowanie: „Logi rejestrujące działania, wyjątki, awarie oraz inne istotne zdarzenia
powinny być tworzone, przechowywane, chronione i analizowane.”

A.8.16 – Działania monitorujące: „Sieci, systemy i aplikacje powinny być monitorowane pod kątem
anomalnego zachowania, a odpowiednie działania powinny być podejmowane w celu oceny potencjalnych
incydentów bezpieczeństwa informacji”.

A.8.17 – Synchronizacja czasu: „Zegary systemów przetwarzania informacji używanych przez
organizację powinny być synchronizowane z zatwierdzonymi źródłami czasu.”

Te zabezpieczenia odpowiadają na trzy pytania audytowe:

Zenith Controls: Przewodnik mapowania zgodności Zenith Controls wyraźnie pokazuje tę zależność:

„Rejestrowanie stanowi podstawową warstwę danych dla monitorowania. Zabezpieczenie 8.16 zależy od logów generowanych w ramach 8.15, aby analizować zdarzenia bezpieczeństwa, wykrywać anomalie i identyfikować potencjalne naruszenia. Bez kompleksowego rejestrowania systemy monitorowania są nieskuteczne.”

Zenith Controls klasyfikuje zabezpieczenie ISO/IEC 27002:2022 8.15, Rejestrowanie, jako kontrolę detekcyjną wspierającą poufność, integralność i dostępność. Mapuje je na funkcję cyberbezpieczeństwa Detect oraz zarządzanie zdarzeniami bezpieczeństwa informacji. Łączy również Rejestrowanie z Działaniami monitorującymi, Oceną i decyzją dotyczącą zdarzeń bezpieczeństwa informacji oraz Synchronizacją czasu.

W przypadku zabezpieczenia 8.16, Działania monitorujące, Zenith Controls klasyfikuje je jako detekcyjne i korygujące, zmapowane na Detect i Respond. Łączy monitorowanie z monitorowaniem usług dostawców oraz oceną zdarzeń, co jest kluczowe w środowiskach chmurowych, SaaS, usług zarządzanych i outsourcingu.

Praktyczny przekaz jest prosty. Logi dostarczają faktów. Monitorowanie identyfikuje anomalie. Synchronizacja czasu sprawia, że fakty są wiarygodne między systemami. Ocena zdarzeń zamienia alerty w decyzje.

Jak naprawdę wygląda gotowy do audytu dowód dotyczący logów

Dowód gotowy do audytu nie jest folderem ze zrzutami ekranu. To spójna ścieżka, która potwierdza projekt kontroli, działanie kontroli i proces decyzyjny.

Dojrzały plik dowodowy dotyczący logowania zdarzeń i monitorowania zwykle zawiera następujące elementy:

Korporacyjna Polityka logowania zdarzeń i monitorowania Clarysec Polityka logowania i monitorowania ujmuje to wprost:

„Niniejsza polityka ma kluczowe znaczenie dla wsparcia ISO/IEC 27001 Clause 8.1 oraz Annex A Controls 8.15 (Logging), 8.16 (Monitoring) i 8.17 (Clock Synchronization), a także jest bezpośrednio mapowana na obowiązki regulacyjne wynikające z GDPR, NIS2, DORA i COBIT 2019.”

Z sekcji „Cel”, klauzula polityki 1.3.

Ta sama polityka określa oczekiwanie operacyjne:

„Ustanowić scentralizowane systemy logowania zdarzeń i alertowania (np. SIEM) w celu agregowania, korelowania i eskalowania podejrzanej aktywności niemal w czasie rzeczywistym.”

Z sekcji „Cele”, klauzula polityki 3.4.

Dla mniejszych organizacji Polityka logowania zdarzeń i monitorowania — MŚP Clarysec Polityka logowania i monitorowania - MŚP przekłada tę samą zasadę na proporcjonalne wymagania:

„Dostawca wsparcia IT musi zdefiniować i stosować regularny harmonogram przeglądu logów:”

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.1.1.

Określa również retencję i ochronę:

„Logi muszą być przechowywane przez co najmniej 12 miesięcy, chyba że dłuższy okres przechowywania jest wymagany przez prawo lub umowę albo jest uzasadniony w ramach aktywnego incydentu lub sporu prawnego.”

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.2.1.

„Logi muszą być przechowywane w lokalizacjach zabezpieczonych przed zapisem, a dostęp musi być ograniczony wyłącznie do upoważnionego personelu”.

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.3.1.

W przypadku NIS2 i DORA 12-miesięczna baza dowodowa może stanowić różnicę między wiarygodnym odtworzeniem zdarzeń a nieskutecznym dochodzeniem. W przypadku GDPR wspiera rozliczalność, jednocześnie wymagając minimalizacji, kontroli dostępu i dyscypliny okresu przechowywania.

Brakujące ogniwo: ocena zdarzeń i progi raportowania

Wiele organizacji zbiera logi i alertuje o anomaliach, ale zawodzi w punkcie decyzyjnym.

Czy alert był tylko zdarzeniem bezpieczeństwa, czy stał się incydentem bezpieczeństwa informacji? Czy był istotny w rozumieniu NIS2? Czy był poważnym incydentem związanym z ICT w rozumieniu DORA? Czy dotyczył danych osobowych? Czy wymagana jest analiza zgłoszenia naruszenia zgodnie z GDPR?

Ten punkt decyzyjny mapuje się na zabezpieczenie ISO/IEC 27002:2022 5.25, Ocenę i decyzję dotyczącą zdarzeń bezpieczeństwa informacji. Zenith Controls opisuje 5.25 jako funkcję triage między surowymi alertami z monitorowania a formalną obsługą incydentów. Łączy 5.25 z planowaniem zarządzania incydentami, działaniami monitorującymi, reagowaniem na incydenty bezpieczeństwa informacji i rejestrowaniem. Mapuje również 5.25 na GDPR Articles 33 i 34 w zakresie zgłaszania naruszeń i oceny ryzyka, zgłaszania incydentów i kryteriów klasyfikacji w NIS2 oraz klasyfikacji poważnych incydentów związanych z ICT w DORA.

Polityka reagowania na incydenty Clarysec Polityka reagowania na incydenty wspiera ten punkt eskalacji:

„Jeżeli incydent skutkuje potwierdzonym lub prawdopodobnym ujawnieniem danych osobowych albo innych danych regulowanych, Dział Prawny i DPO muszą ocenić zastosowanie:”

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.4.1.

Dla MŚP Polityka reagowania na incydenty — MŚP Polityka reagowania na incydenty - MŚP ustanawia wymaganie dotyczące dowodu technicznego:

„Systemy logowania zdarzeń muszą być skonfigurowane tak, aby przechwytywać wystarczający poziom szczegółowości wspierający dochodzenie.”

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.4.1.

W tym miejscu GDPR Article 33 staje się operacyjny. Pytanie nie dotyczy wyłącznie tego, czy uzyskano dostęp do danych osobowych. Pytanie brzmi, czy logi, alerty monitorowania i zapisy incydentu pozwalają DPO przeprowadzić terminową i możliwą do obrony ocenę naruszenia.

NIS2 Article 23 oraz DORA Articles 17 to 23 tworzą podobną presję. Terminy raportowania zależą od świadomości, klasyfikacji i oceny istotności. Organizacja musi być w stanie wykazać, kiedy alert został wygenerowany, kiedy został przejrzany, kto go ocenił, jaka decyzja została podjęta i kiedy nastąpiła eskalacja.

60-minutowe ćwiczenie dowodowe dla dochodzenia dotyczącego uprzywilejowanego uwierzytelnienia

Praktycznym sposobem testowania gotowości dowodowej jest przećwiczenie realnego scenariusza przed audytem lub incydentem.

Scenariusz: uprzywilejowane konto administratora loguje się z nietypowego kraju o 02:13 UTC. Pięć minut później konto próbuje uzyskać dostęp do funkcji eksportu danych klientów. Dostęp warunkowy blokuje sesję i generowany jest alert.

Cel: w ciągu 60 minut przygotować pakiet dowodowy potwierdzający wykrycie, przegląd, eskalację, ocenę i zamknięcie.

Krok 1: Potwierdź, że zdarzenie istnieje w logach

Użyj Polityki logowania zdarzeń i monitorowania, aby zidentyfikować wymagane źródła logów: logi dostawcy tożsamości, logi administratorów środowiska chmurowego, logi aplikacyjne, logi baz danych, logi punktów końcowych oraz logi zapory sieciowej lub bezpiecznego dostępu.

Wyeksportuj zapis zdarzenia ze znacznikiem czasu, identyfikatorem użytkownika, źródłowym adresem IP, urządzeniem, działaniem, wynikiem i identyfikatorem korelacji. Jeżeli zdarzenie istnieje tylko w jednej konsoli, a nie w SIEM lub kolektorze logów, odnotuj to jako lukę kontrolną.

Zenith Blueprint krok 19 zaleca zapewnienie, że systemy krytyczne przekazują logi do SIEM lub centralnego kolektora logów, oraz walidację zgodności retencji z polityką.

Krok 2: Wykaż, że monitorowanie wykryło zdarzenie

Pokaż alert SIEM, alert EDR lub alert ochrony tożsamości. Uwzględnij nazwę reguły, wagę, znacznik czasu, warunek wyzwolenia i ścieżkę powiadomienia. Jeżeli organizacja stosuje ręczny przegląd, pokaż dzienny raport i zatwierdzenie przeglądu.

Korporacyjna Polityka logowania zdarzeń i monitorowania czyni z tego odpowiedzialność roli:

„Przegląda dzienne raporty i zapewnia, że anomalie są analizowane, dokumentowane i eskalowane zgodnie z potrzebą.”

Z sekcji „Role i odpowiedzialności”, klauzula polityki 4.2.3.

Krok 3: Wykaż, że eskalacja nastąpiła zgodnie z polityką

Dla MŚP wymaganie eskalacji jest jednoznaczne:

„Alerty wysokiego priorytetu muszą zostać eskalowane do dyrektora generalnego (GM) i koordynatora ds. prywatności w ciągu 24 godzin”.

Z sekcji „Egzekwowanie i zgodność”, klauzula polityki 8.1.2.

W zespołach korporacyjnych dowody mogą obejmować zgłoszenie incydentu, zapis eskalacji w Teams lub Slack, log powiadamiania, powiadomienie e-mail, notatkę przekazania SOC albo wpis w systemie zarządzania sprawami.

Krok 4: Sklasyfikuj zdarzenie

Użyj logiki oceny zdarzeń 5.25 z Zenith Controls. Uchwyć, czy alert jest zdarzeniem bezpieczeństwa, incydentem bezpieczeństwa informacji, naruszeniem ochrony danych osobowych, istotnym incydentem NIS2 czy poważnym incydentem związanym z ICT w DORA.

Notatka klasyfikacyjna powinna odpowiadać na pytania:

• Czy uwierzytelnianie zakończyło się powodzeniem, czy zostało zablokowane?
• Czy użyto dostępu uprzywilejowanego?
• Czy uzyskano dostęp do danych klientów, zmieniono je lub wyeksfiltrowano?
• Czy usługi regulowane zostały zakłócone?
• Czy dotknięte zostały krytyczne aktywa ICT?
• Czy zaangażowani są dostawcy lub podmioty przetwarzające?
• Czy zdarzenie spełnia wewnętrzne progi raportowania?
• Czy wymagane jest powiadomienie DPO, Działu Prawnego, organu regulacyjnego lub klienta?

Krok 5: Zbuduj zaufaną oś czasu

Synchronizacja czasu jest często ignorowana do momentu, gdy dochodzenie się załamuje. Zenith Blueprint krok 19 wskazuje, że zsynchronizowany czas ma kluczowe znaczenie dla korelacji zdarzeń, ponieważ logi z różnych systemów muszą układać się w spójną sekwencję podczas analizy incydentu.

Uwzględnij dowody konfiguracji NTP dla platform tożsamości, usług chmurowych, serwerów, punktów końcowych, baz danych, zapór sieciowych i SIEM. Tam, gdzie to możliwe, normalizuj znaczniki czasu do UTC.

Krok 6: Zamknij lub eskaluj

Jeżeli zdarzenie zostało powstrzymane i nie uzyskano dostępu do danych, udokumentuj zamknięcie, wnioski i działania zapobiegawcze. Jeżeli staje się incydentem, powiąż je z reagowaniem na incydenty, przeglądem prawnym oraz dowolnym procesem raportowania NIS2, DORA lub GDPR.

Na koniec zabezpiecz dowody. Polityka audytu i monitorowania zgodności Clarysec Polityka audytu i monitorowania zgodności stanowi:

„Wszystkie logi audytowe, ustalenia i raporty działań naprawczych muszą być przechowywane, szyfrowane i chronione przed manipulacją.”

Z sekcji „Egzekwowanie i zgodność”, klauzula polityki 8.5.1.

To pojedyncze ćwiczenie dostarcza dowodów dla Annex A.8.15, A.8.16, A.8.17, zabezpieczenia ISO/IEC 27002:2022 5.25, rozliczalności naruszeń w GDPR, obsługi incydentów NIS2 i klasyfikacji incydentów ICT w DORA.

Mapa dowodów zgodności krzyżowej dla ISO 27001, NIS2, DORA i GDPR

Najsilniejsze programy zgodności nie budują osobnych zestawów dowodów dla każdego frameworku. Budują jeden system dowodowy, który można analizować z wielu perspektyw audytowych.

NIST Cybersecurity Framework 2.0 może pomóc zoperacjonalizować tę mapę jako warstwę komunikacyjną. Jego sześć funkcji: GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER, pokazuje, że logowanie zdarzeń i monitorowanie znajdują się głównie w DETECT i RESPOND, ale zależą od zarządzania, zrozumienia aktywów i priorytetów ryzyka.

Profile NIST CSF 2.0 mogą również wspierać mapę drogową na 2026 rok. Current Profile może pokazać dzisiejsze pokrycie logowaniem zdarzeń i dojrzałość alertowania. Target Profile może zdefiniować wymagane pokrycie dla systemów regulowanych, aktywności uprzywilejowanej, platform dostawców i środowisk danych osobowych. Luka między nimi staje się planem działań naprawczych.

Logi dostawców i usług chmurowych: luka dowodowa, którą audytorzy testują coraz częściej

We współczesnych audytach najtrudniejsze pytania dotyczące logowania zdarzeń często obejmują platformy outsourcingowe.

Czy masz dostęp do logów uwierzytelniania od swojego dostawcy usług chmurowych? Czy działania administratorów SaaS są logowane? Czy logi audytowe baz danych są włączone w usługach zarządzanych? Czy Twój MSSP przechowuje alerty wystarczająco długo? Czy umowy wymagają współpracy przy incydentach? Czy dostawcy mogą dostarczyć logi wystarczająco szybko dla terminów raportowania NIS2 lub DORA? Czy logi podmiotów przetwarzających są dostępne na potrzeby oceny naruszenia zgodnie z GDPR?

Zenith Controls łączy Działania monitorujące, zabezpieczenie 8.16, z Monitorowaniem usług dostawców, zabezpieczeniem 5.22. Mapuje również monitorowanie na klauzulę ISO/IEC 27005:2024 10.5, która podkreśla monitorowanie i przegląd planów postępowania z ryzykiem oraz zabezpieczeń, a także na klauzulę ISO/IEC 27035-2:2023 7.3, gdzie mechanizmy ciągłego monitorowania wykrywają zdarzenia bezpieczeństwa informacji i uruchamiają zarządzanie incydentami.

DORA sprawia, że logi dostawców są szczególnie istotne dla podmiotów finansowych, ponieważ zarządzanie ryzykiem ICT stron trzecich obejmuje rejestry dostawców, ustalenia umowne, ryzyko podwykonawstwa, ryzyko koncentracji i strategie wyjścia. NIS2 Article 21 umieszcza bezpieczeństwo łańcucha dostaw w ramach środków zarządzania ryzykiem cyberbezpieczeństwa. GDPR może uczynić logi dostawców decydującymi, gdy incydent u podmiotu przetwarzającego może stać się naruszeniem ochrony danych osobowych zgłaszanym przez administratora.

Praktyczna klauzula dotycząca logów dostawców powinna wymagać:

• Logów audytowych istotnych dla bezpieczeństwa w zakresie uwierzytelniania, zmian uprawnień, działań administracyjnych, dostępu API, eksportu danych i zmian konfiguracji.
• Retencji logów zgodnej z polityką, obowiązkami regulacyjnymi i ryzykiem umownym.
• Synchronizacji czasu i normalizacji stref czasowych.
• Ochrony przed manipulacją i ograniczonego dostępu do logów.
• Współpracy przy incydentach w określonych ramach czasowych.
• Dostarczania dowodów na potrzeby audytów, dochodzeń i zapytań organów regulacyjnych.
• Wyzwalaczy powiadomień dotyczących podejrzanego dostępu, naruszenia bezpieczeństwa usługi lub ujawnienia danych.
• Obowiązków logowania zdarzeń i eskalacji dla podwykonawców przetwarzania, tam gdzie ma to zastosowanie.

Logi dostawców powinny być uzgodnione przed incydentem, a nie negocjowane w jego trakcie.

Jak różni audytorzy testują to samo zabezpieczenie dotyczące logów

Dobry pakiet dowodowy musi wytrzymać różne perspektywy zawodowe. Audytor ISO, osoba oceniająca gotowość NIS2, nadzorca DORA, recenzent GDPR oraz audytor zorientowany na COBIT 2019 lub ISACA mogą patrzeć na ten sam panel SIEM, ale będą zadawać różne pytania.

Zenith Blueprint krok 19 przygotowuje organizacje na te pytania. W przypadku Rejestrowania audytorzy koncentrują się na tym, czy kluczowe zdarzenia bezpieczeństwa są logowane oraz czy logi są przechowywane, chronione i użyteczne. W przypadku Działań monitorujących pytają, w jaki sposób nietypowa lub nieautoryzowana aktywność jest wykrywana, oceniana i eskalowana. W przypadku Synchronizacji czasu mogą porównywać znaczniki czasu między systemami i wskazywać niespójności.

Krok 16: Kontrole dotyczące ludzi II, zabezpieczenie 6.8, również ma znaczenie, ponieważ mechanizmy zgłaszania incydentów łączą raportowanie przez ludzi z detekcją techniczną. GDPR Article 33, NIS2 Article 23 oraz obowiązki raportowania incydentów DORA zależą od terminowej eskalacji wewnętrznej.

Typowe ustalenia audytowe i praktyczne działania naprawcze

Większość ustaleń dotyczących logowania zdarzeń i monitorowania jest przewidywalna. Problem polega na tym, że organizacje często odkrywają je podczas audytu, a nie w trakcie testów wewnętrznych.

Dla organizacji o ograniczonych zasobach podejście polityki dla MŚP jest realistyczne. Nie wymaga pełnego SOC pierwszego dnia. Wymaga określonych harmonogramów przeglądu, 12-miesięcznej retencji, chyba że potrzebny jest dłuższy okres, pamięci zabezpieczonej przed zapisem, ograniczonego dostępu oraz eskalacji alertów wysokiego priorytetu. Tworzy to możliwą do obrony bazę, podczas gdy organizacja dojrzewa w kierunku scentralizowanego SIEM, zautomatyzowanej korelacji i zarządzanego wykrywania.

Metryki, które czynią logowanie zdarzeń wiarygodnym dla kierownictwa

Zarządy i najwyższe kierownictwo nie potrzebują surowych zdarzeń SIEM. Potrzebują zapewnienia istotnego z punktu widzenia ryzyka. Ponieważ NIS2 Article 20 oraz wymagania ładu zarządczego DORA nakładają odpowiedzialność na organy zarządzające, metryki logowania zdarzeń i monitorowania powinny pojawiać się w raportowaniu ładu bezpieczeństwa.

Przydatne metryki obejmują:

• Odsetek krytycznych aktywów przekazujących logi do SIEM lub kolektora logów.
• Odsetek zdarzeń dostępu uprzywilejowanego objętych alertowaniem.
• Liczbę alertów wysokiego priorytetu przejrzanych w ramach SLA.
• Średni czas od wygenerowania alertu do przeglądu przez analityka.
• Średni czas od wykrycia do eskalacji.
• Liczbę zdarzeń sklasyfikowanych w ramach procesu reagowania na incydenty.
• Liczbę zdarzeń wymagających przeglądu przez DPO lub Dział Prawny.
• Zgodność retencji logów według kategorii systemów.
• Liczbę platform dostawców z umownym dostępem do logów.
• Liczbę systemów niespełniających kontroli synchronizacji czasu.
• Otwarte działania naprawcze dotyczące logowania zdarzeń i monitorowania według poziomu ryzyka.

Te metryki wspierają klauzulę ISO/IEC 27001:2022 6.2 dotyczącą mierzalnych celów bezpieczeństwa informacji. Wzmacniają również nadzór kierownictwa w NIS2 i DORA oraz rozliczalność GDPR.

Budowanie pakietu dowodów logowania zdarzeń i monitorowania na 2026 rok

Silny pakiet dowodowy na 2026 rok powinien zostać złożony przed audytem lub incydentem. Clarysec zwykle rekomenduje ustrukturyzowany folder lub obiekt dowodowy GRC z następującymi sekcjami:

1. Zarządzanie i zakres: zakres SZBI, strony zainteresowane, stosowalność regulacyjna, zatwierdzenie przez kierownictwo i przypisania ról.
2. Polityka: Polityka logowania zdarzeń i monitorowania, Polityka reagowania na incydenty, Polityka audytu i monitorowania zgodności, wymagania dotyczące retencji i wymagania eskalacji.
3. Ryzyko i SoA: ocena ryzyka, plan postępowania z ryzykiem, uzasadnienie Deklaracji stosowania dla A.8.15, A.8.16, A.8.17 i powiązanych zabezpieczeń.
4. Architektura: diagram SIEM lub kolektora logów, inwentarz źródeł logów, ustawienia logowania zdarzeń w usługach chmurowych i zależności dotyczące logów dostawców.
5. Działanie kontroli: zapisy z przeglądów, alerty, zgłoszenia, logi eskalacji, dowody zamknięcia i wyjątki.
6. Powiązanie z incydentami: arkusz klasyfikacji zdarzeń, rejestr incydentów, zapis oceny DPO i dziennik decyzji raportowych.
7. Integralność i retencja: kontrole dostępu, szyfrowanie, ochrona przed zapisem, ustawienia archiwum, kontrole usuwania i dowód retencji.
8. Synchronizacja czasu: konfiguracja NTP, bezpieczna konfiguracja bazowa, monitorowanie dryfu zegara i podejście do normalizacji UTC.
9. Dowody od dostawców: klauzule umowne, raporty zapewnienia dostawców, dostępność logów audytowych usług chmurowych i procedury współpracy przy incydentach.
10. Doskonalenie: ustalenia audytu wewnętrznego, rejestr działań naprawczych, wyniki ćwiczeń typu tabletop, zapisy dostrajania alertów i raporty zarządcze.

Celem nie jest zasypanie audytorów ilością materiału. Celem jest wykazanie, że logowanie zdarzeń i monitorowanie działają jako kontrolowany proces od zarządzania po wykrywanie, ocenę, eskalację, raportowanie i doskonalenie.

Przekształć logi w możliwe do obrony dowody zgodności

Zespół Marii nie rozwiązał problemu, kupując kolejny panel. Rozwiązał go, przekształcając logowanie zdarzeń i monitorowanie w mechanizm dowodowy. Polityki zdefiniowały wymagania. Reguły SIEM i logi usług chmurowych dostarczyły sygnałów. Procesy reagowania na incydenty uchwyciły decyzje. Synchronizacja czasu uczyniła oś czasu wiarygodną. Raportowanie zarządcze uwidoczniło ryzyko.

To standard, którego organizacje potrzebują dla ISO/IEC 27001:2022, NIS2, DORA i GDPR w 2026 roku.

Zacznij od jednego praktycznego testu: weź rzeczywisty alert z ostatnich 30 dni i wykaż, od początku do końca, jak został zarejestrowany, wykryty, przejrzany, eskalowany, sklasyfikowany, zachowany i zaraportowany.

Jeżeli odpowiedź nie jest pewna, Clarysec może pomóc zamknąć lukę.

Użyj Zenith Blueprint: 30-etapowa mapa drogowa audytora Zenith Blueprint, aby wdrożyć krok 19 dotyczący logowania zdarzeń, monitorowania i synchronizacji czasu oraz krok 16 dotyczący mechanizmów zgłaszania incydentów. Użyj Zenith Controls: Przewodnik mapowania zgodności Zenith Controls, aby zmapować Annex A.8.15, A.8.16, A.8.17 oraz zabezpieczenie ISO/IEC 27002:2022 5.25 na perspektywy NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019.

Następnie przełóż wymagania na działanie za pomocą Polityki logowania zdarzeń i monitorowania Clarysec Polityka logowania i monitorowania, Polityki logowania zdarzeń i monitorowania — MŚP Polityka logowania i monitorowania - MŚP, Polityki reagowania na incydenty Polityka reagowania na incydenty, Polityki reagowania na incydenty — MŚP Polityka reagowania na incydenty - MŚP oraz Polityki audytu i monitorowania zgodności Polityka audytu i monitorowania zgodności.

Logi nie są dowodem, dopóki nie są zarządzane, chronione, przeglądane i powiązane z decyzjami. Organizacje, które potrafią wykazać ten łańcuch, szybciej przejdą audyty, lepiej zareagują na incydenty i dadzą kierownictwu pewność, gdy nadejdzie kolejny alert o 2:17 nad ranem.