PII w logach bezpieczeństwa: playbook dla GDPR, NIS2 i DORA

Analityk bezpieczeństwa otwiera SIEM o 02:17. Alert początkowo wygląda rutynowo: wiele nieudanych logowań, udana sesja z nietypowego adresu IP, a następnie seria wywołań API do punktu końcowego eksportu danych klienta. W ciągu kilku minut kanał incydentowy jest pełny. CISO chce wiedzieć, czy doszło do przejęcia konta. Dział prawny pyta, czy logi zawierają dane osobowe. DPO pyta, czy identyfikator użytkownika, adres IP, identyfikator urządzenia i adresy URL żądań w SIEM są objęte klauzulą informacyjną oraz rejestrem czynności przetwarzania. Menedżer ds. zgodności pyta, czy logi muszą zostać zachowane na potrzeby raportowania regulacyjnego. Zespół obsługi klienta pyta, czy klient może następnego dnia zażądać usunięcia tych samych wpisów logów.

W tym miejscu wiele organizacji odkrywa, że rejestrowanie zdarzeń bezpieczeństwa i ład w zakresie prywatności zbudowano jako dwa odrębne światy.

Zespoły bezpieczeństwa oczekują szczegółowych logów, długiej retencji, niemodyfikowalnego przechowywania i szybkiego dostępu. Zespoły ds. prywatności oczekują minimalizacji, ograniczenia celu, dostępu opartego na rolach, dyscypliny retencji i usunięcia danych, gdy nie są już potrzebne. Zespoły reagowania na incydenty oczekują zachowania dowodów dokładnie w takim stanie, w jakim zostały pozyskane. Rozliczalność zgodnie z GDPR wymaga, aby organizacja potrafiła wyjaśnić, dlaczego dane osobowe znajdują się w logach, kto uzyskał do nich dostęp i jak długo są przechowywane. NIS2 i DORA zwiększają presję czasową, ponieważ podmioty kluczowe, podmioty ważne i organizacje finansowe potrzebują wystarczających dowodów, aby klasyfikować incydenty, raportować je w terminie i wykazać skuteczne zarządzanie ryzykiem ICT.

Niewygodna prawda jest prosta: logi bezpieczeństwa często są repozytoriami danych osobowych. Logi uwierzytelniania mogą zawierać nazwy użytkowników, adresy e-mail, adresy IP, odciski urządzeń i geolokalizację. Logi aplikacyjne mogą ujawniać adresy URL, ciągi wyszukiwania, fragmenty ładunków, numery spraw i treść wiadomości. Logi EDR i logi chmurowe mogą obejmować nazwy hostów powiązane z pracownikami, ścieżki plików zawierające nazwiska, identyfikatory sesji i działania administratorów. Logi IAM mogą ujawniać zmiany uprawnień, członkostwo w grupach i nieudane próby dostępu do systemów wrażliwych.

Jeżeli logi zawierają PII, nie są już wyłącznie zagadnieniem rejestrowania w ISO 27001. Stają się kwestią prywatności, retencji, materiału dowodowego, zgłaszania incydentów i nadzoru nad dostawcami. Clarysec traktuje nadzór nad PII w logach bezpieczeństwa jako problem zgodności między ramami, a nie jako problem konfiguracji narzędzia.

Rzeczywisty dylemat CISO: dowody detekcyjne a minimalizacja danych

CISO w scenariuszu z 02:17 mierzy się z realnym konfliktem operacyjnym. Jeżeli logi są zbyt ubogie, SOC nie może wykryć naruszenia, odtworzyć osi czasu ani wesprzeć raportowania na potrzeby NIS2 i DORA. Jeżeli logi są zbyt szczegółowe, organizacja może gromadzić więcej danych osobowych niż jest to konieczne, przechowywać je zbyt długo, udostępniać je zbyt wielu administratorom lub nie być w stanie obsłużyć praw wynikających z GDPR i obowiązków przejrzystości.

GDPR szeroko definiuje dane osobowe jako informacje dotyczące zidentyfikowanej lub możliwej do zidentyfikowania osoby. Przetwarzanie obejmuje zbieranie, przechowywanie, użycie, ujawnianie, usunięcie i zniszczenie. W praktyce logi zawierające adresy IP, identyfikatory użytkowników, identyfikatory urządzeń lub zapisy aktywności mogą być danymi osobowymi zależnie od kontekstu. Zasady GDPR wymagają zgodnego z prawem, rzetelnego i przejrzystego przetwarzania, ograniczenia celu, minimalizacji danych, ograniczenia przechowywania, integralności i poufności oraz rozliczalności.

Pytanie z zakresu ładu nie brzmi: „Czy kiedykolwiek możemy logować dane osobowe?”. Właściwsze pytanie brzmi: „Jakie PII musimy logować dla bezpieczeństwa, reagowania na incydenty i zgodności, jaka podstawa prawna to uzasadnia, jakie środki ochrony mają zastosowanie i kiedy dane muszą zostać usunięte, zanonimizowane albo objęte zatwierdzonym wstrzymaniem usuwania?”.

Biblioteka korporacyjnych polityk prywatności Clarysec bezpośrednio adresuje to napięcie. Polityka ochrony danych i prywatności, Wymagania dotyczące wdrożenia polityki, klauzula 6.2.1 stanowi:

Zbierane i przetwarzane mogą być wyłącznie dane niezbędne do konkretnego, uzasadnionego celu biznesowego.

Dla MŚP ta sama zasada została wskazana w Polityce ochrony danych i prywatności dla MŚP, Wymagania dotyczące wdrożenia polityki, klauzula 6.2.1:

Należy zbierać i przechowywać wyłącznie minimalny zakres niezbędnych danych osobowych.

To zdanie powinno determinować każdą decyzję projektową dotyczącą rejestrowania. Czy każde pole w każdym źródle logów jest niezbędne do zdefiniowanego celu bezpieczeństwa, operacyjnego, prawnego lub umownego?

Dlaczego ISO 27701 zmienia rozmowę o rejestrowaniu

ISO/IEC 27001:2022 zapewnia system zarządzania: zakres, strony zainteresowane, ocenę ryzyka, postępowanie z ryzykiem, kontrolę operacyjną, monitorowanie, audyt wewnętrzny i ciągłe doskonalenie. ISO/IEC 27002:2022 dostarcza praktycznych wytycznych dotyczących środków kontrolnych w obszarze rejestrowania, monitorowania, ochrony prywatności PII, zabezpieczania materiału dowodowego, ochrony zapisów, usuwania, kontroli dostępu i zarządzania dostawcami. ISO/IEC 27701 rozszerza model ładu na system zarządzania informacjami o prywatności, koncentrując się na administratorach i podmiotach przetwarzających PII, rolach związanych z prywatnością, zapisach przetwarzania PII, ochronie prywatności w fazie projektowania, obsłudze praw oraz obowiązkach podmiotu przetwarzającego.

W odniesieniu do logów bezpieczeństwa ISO 27701 ma znaczenie, ponieważ wymusza pytania specyficzne dla prywatności, które zespoły bezpieczeństwa czasem pomijają:

• Czy źródło logów przetwarza PII jako administrator, podmiot przetwarzający, współadministrator lub podwykonawca przetwarzania?
• Czy dane logów są ujęte w inwentarzu czynności przetwarzania?
• Czy organizacja wie, które pola logów zawierają PII?
• Czy PII w logach jest powiązane z regułami retencji i usuwania?
• Czy klienci, dla których organizacja działa jako podmiot przetwarzający, są informowani o rejestrowaniu dostępu do PII, gdy wymagają tego umowy?
• Czy logi są uwzględniane przy obsłudze żądań dostępu, usunięcia lub ograniczenia przetwarzania?
• Czy incydenty PII są oceniane łącznie pod kątem prywatności, cyberbezpieczeństwa i przesłanek raportowania w sektorze finansowym?

Polityka bezpieczeństwa i kontroli dostępu do PII Clarysec przekłada to na wymagania operacyjne. Z sekcji Rejestrowanie i monitorowanie, klauzula 4.6.1:

[Obie role] Właściciel systemu / właściciel aplikacji MUSI zdefiniować zakres rejestrowania PII dla zdarzeń uwierzytelniania, zdarzeń dostępu, działań uprzywilejowanych, aktywności eksportu PII oraz istotnych zmian konfiguracji w REG12 przed użyciem produkcyjnym lub istotną zmianą.

Klauzula 4.6.2 zamyka pętlę między rejestrowaniem, kontrolą dostępu i retencją:

[Obie role] Kierownik ds. bezpieczeństwa informacji MUSI zapewnić, aby logi zawierające PII miały ograniczony dostęp i były powiązane z zatwierdzoną regułą retencji lub usuwania w REG02 albo REG12 przed rozpoczęciem monitorowania logów.

Dzięki temu ład PIMS staje się praktyczny. REG12 definiuje, jakie rejestrowanie PII jest dozwolone i wymagane. REG02 wskazuje, gdzie występuje PII, w tym w logach. Reguły retencji i usuwania nie są dokumentacją dodawaną później. Stają się warunkami wstępnymi rejestrowania produkcyjnego.

Logi bezpieczeństwa są zapisami, dowodami i czynnością przetwarzania PII

Dojrzała organizacja nie powinna traktować logów jako technicznych odpadów eksploatacyjnych. Logi są zapisami. Podczas incydentu mogą stać się dowodami prawnymi. Gdy zawierają PII, są również danymi przetwarzanymi podlegającymi ładowi w zakresie prywatności.

Polityka logowania i monitorowania Clarysec określa oczekiwania dotyczące normalizacji logów. Z sekcji Wymagania ładu zarządczego, klauzula 5.1.4:

Wymagania dotyczące formatu i normalizacji logów (np. znacznik czasu, identyfikator użytkownika, typ zdarzenia, źródłowy adres IP)

To dokładnie te pola, które czynią logi użytecznymi dla reagowania na incydenty. To również pola, które często sprawiają, że logi stają się danymi osobowymi. Ta sama polityka korporacyjna wskazuje, czego nigdy nie należy dopuszczać, w sekcji Wymagania ładu zarządczego, klauzula 5.3.3:

Przechowywanie danych wrażliwych w postaci jawnego tekstu (np. haseł, tajemnic kryptograficznych)

Nie chodzi o to, aby logi unikały wszystkich identyfikatorów. Chodzi o to, aby identyfikatory były celowe, chronione i uzasadnione. Hasła, sekrety, pełne tokeny i niepotrzebne ładunki nie powinny być logowane. Identyfikatory użytkowników, adresy IP i metadane zdarzeń mogą być niezbędne, ale wymagają środków kontrolnych.

Dla MŚP Polityka logowania i monitorowania dla MŚP Clarysec umieszcza przegląd prywatności w strukturze ról. W sekcji Role i odpowiedzialności, klauzula 4.3.1, wymaga od organizacji, aby:

Weryfikowała, że dane logów dotyczące informacji osobowych lub wrażliwych są przetwarzane zgodnie z GDPR oraz innymi przepisami o ochronie danych.

Wersja dla MŚP ustanawia również jasny bazowy wymóg retencji. Z sekcji Wymagania ładu zarządczego, klauzula 5.2.1:

Logi muszą być przechowywane przez co najmniej 12 miesięcy, chyba że dłuższy okres przechowywania jest wymagany przez prawo lub umowę albo uzasadniony w związku z aktywnym incydentem lub sporem prawnym.

Określa także oczekiwanie dotyczące ochrony, w sekcji Wymagania ładu zarządczego, klauzula 5.3.1:

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

W odniesieniu do korporacyjnego reagowania na incydenty Polityka zabezpieczania materiału dowodowego i informatyki śledczej, Wymagania dotyczące wdrożenia polityki, klauzula 6.3.1 wymaga:

Logi z zapór sieciowych, SIEM, agentów punktów końcowych, platform zarządzania tożsamością i dostępem (IAM) oraz platform chmurowych należy eksportować i przechowywać w formatach niemodyfikowalnych.

Wersja dla MŚP dodaje zabezpieczenie proporcjonalności. Polityka zabezpieczania materiału dowodowego i informatyki śledczej dla MŚP, Postępowanie z ryzykiem i wyjątki, klauzula 7.2.1 stanowi:

Minimalizuj zakres gromadzenia; pozyskuj wyłącznie to, co jest niezbędne.

To istota rejestrowania świadomego prywatności: zachować to, co jest niezbędne, wykazać, dlaczego jest to niezbędne, ograniczyć dostęp i usunąć po wygaśnięciu zatwierdzonego celu.

Model kontroli Clarysec dla dowodów bezpiecznych z perspektywy prywatności

W Zenith Blueprint: 30-etapowej mapie drogowej audytora Clarysec umieszcza rejestrowanie w fazie Działanie środków kontrolnych, krok 19: Zabezpieczenia techniczne I. Przewodnik wyjaśnia oczekiwanie kontrolne ISO/IEC 27002:2022:

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

Ten sam krok wskazuje organizacjom, aby generowały logi dla kluczowych zdarzeń, przechowywały je bezpiecznie tak, aby nie mogły zostać zmienione, utrzymywały je przez zdefiniowany okres i analizowały przez SIEM albo proces przeglądu. Łączy też rejestrowanie ze zgłoszeniem naruszenia w GDPR, zapisami incydentów DORA, zarządzaniem ryzykiem NIS2 oraz analizą logów bezpieczeństwa w COBIT.

Samo rejestrowanie jednak nie wystarcza. W tej samej fazie Działanie środków kontrolnych, w kroku 19, Zenith Blueprint omawia usuwanie. Ostrzega, że dane przechowywane dłużej niż wynika to z wartości operacyjnej zwiększają ekspozycję i ryzyko regulacyjne, oraz wprost wskazuje kopie zapasowe, migawki i archiwa. Ma to znaczenie, ponieważ reguła retencji w SIEM jest bezwartościowa, jeżeli zreplikowane archiwa logów lub zasobniki pamięci obiektowej w chmurze przechowują to samo PII bezterminowo.

W kroku 23: Zabezpieczenia organizacyjne, Zenith Blueprint omawia zabezpieczanie materiału dowodowego. Wskazuje, że dowody incydentu muszą zostać zidentyfikowane, zebrane i zachowane w sposób dopuszczalny prawnie, wiarygodny i zgodny z potrzebami dochodzenia. Podkreśla również realność operacyjną: dowody często są tracone w pierwszych minutach reakcji, gdy logi ulegają rotacji, systemy są restartowane albo administratorzy zmieniają naruszone konta przed wykonaniem migawek.

Krok 23 obejmuje także prywatność i ochronę PII. Przewodnik ujmuje PII jako zagadnienie cyklu życia, wymagające świadomości danych, klasyfikacji, kontroli dostępu, maskowania, usuwania, szyfrowania i obowiązków dostawców. W odniesieniu do logów oznacza to, że SIEM, EDR, platforma rejestrowania w chmurze obliczeniowej i system zgłoszeniowy muszą być częścią inwentarza PII.

Mapowanie zgodności między ramami dla PII w logach

Zenith Controls: przewodnik po zgodności między ramami mapuje środek kontrolny ISO/IEC 27002:2022 8.15, Rejestrowanie, do powiązanych środków kontrolnych niezbędnych dla ładu w zakresie PII. Te relacje pokazują, dlaczego rejestrowanie nie jest wyłącznie kwestią SOC.

Zenith Controls mapuje również Rejestrowanie do klauzuli ISO/IEC 27002:2022 8.15, ISO/IEC 27035-1 i ISO/IEC 27035-2 dla zarządzania incydentami, ISO/IEC 27701 dla rejestrowania czynności przetwarzania PII, ISO/IEC 27017 dla logów audytowych w chmurze, ISO/IEC 27018 dla rejestrowania dostępu do PII w chmurze, ISO/IEC 27005 dla ryzyk wynikających z niewystarczającego rejestrowania, ISO/IEC 27033 dla rejestrowania aktywności sieciowej oraz ISO/IEC 15408-2 dla funkcjonalności audytowej w ocenianych produktach.

W obszarze prywatności Zenith Controls mapuje środek kontrolny ISO/IEC 27002:2022 5.34, Prywatność i ochrona PII, do inwentarza aktywów, maskowania danych, usług chmurowych, klasyfikacji, przekazywania informacji, kontroli dostępu, zarządzania tożsamością oraz przeglądu bezpieczeństwa projektów i zmian. Dla programu nadzoru nad logami te powiązania stają się praktycznymi wymaganiami projektowymi:

• Inwentaryzuj repozytoria logów jako lokalizacje PII.
• Maskuj lub tokenizuj PII tam, gdzie pełne identyfikatory nie są niezbędne.
• Przeglądaj usługi rejestrowania w chmurze i dostawców SIEM w ramach kontroli chmury i dostawców.
• Klasyfikuj logi zawierające PII jako zapisy wrażliwe.
• Nadzoruj eksporty i przekazywanie logów jako transfery PII.
• Ograniczaj dostęp do logów za pomocą kontroli tożsamości i dostępu uprzywilejowanego.
• Przeglądaj zmiany w rejestrowaniu aplikacyjnym przed wydaniem produkcyjnym.

GDPR, NIS2 i DORA: jeden log, trzy perspektywy regulacyjne

Ten sam wpis logu może być oceniany inaczej w ramach GDPR, NIS2 i DORA.

W ramach GDPR organizacja pyta, czy wpis logu zawiera dane osobowe, jaka podstawa prawna uzasadnia przetwarzanie, czy dane są niezbędne, jak długo są przechowywane, kto może uzyskać do nich dostęp, czy są ujawniane podmiotom przetwarzającym lub klientom oraz czy muszą zostać uwzględnione w żądaniu realizacji praw albo w ocenie naruszenia.

W ramach NIS2 organizacja pyta, czy logi wspierają zarządzanie ryzykiem cyberbezpieczeństwa, obsługę incydentów, ciągłość działania, kontrolę dostępu, bezpieczeństwo łańcucha dostaw oraz ocenę skuteczności kontroli. NIS2 Article 20 czyni organy zarządzające odpowiedzialnymi za zatwierdzanie środków zarządzania ryzykiem cyberbezpieczeństwa i nadzór nad nimi. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego rozwoju oprogramowania, obsługi podatności, oceny skuteczności, cyberhigieny, kontroli dostępu i zarządzania aktywami. Article 23 ustanawia etapowe raportowanie znaczących incydentów, obejmujące wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin oraz raport końcowy w ciągu jednego miesiąca.

W ramach DORA podmioty finansowe muszą prowadzić udokumentowane ramy zarządzania ryzykiem ICT. DORA Article 5 przypisuje odpowiedzialność organowi zarządzającemu. Article 10 dotyczy wykrywania. Article 17 wymaga procesu zarządzania incydentami związanymi z ICT. Article 18 obejmuje klasyfikację incydentów związanych z ICT i cyberzagrożeń. Article 19 dotyczy zgłaszania poważnych incydentów związanych z ICT. Logi wspierają wykrywanie, klasyfikację, analizę przyczyny źródłowej, ocenę wpływu, reakcję, odzyskiwanie oraz dowody działań naprawczych.

Bardziej szczegółowa tabela korelacji środków kontrolnych pomaga CISO uzasadnić rejestrowanie bez odwoływania się do ogólnych stwierdzeń typu „potrzebujemy tego dla bezpieczeństwa”.

Zbuduj zakres rejestrowania PII w REG12

Klient Clarysec obsłużyłby incydent SIEM z 02:17, zanim w ogóle do niego dojdzie. Organizacja zaczyna od aplikacji dostępnej dla klientów, która przetwarza dane kont. Przed uruchomieniem produkcyjnym właściciel aplikacji używa REG12 do zdefiniowania zakresu rejestrowania PII. Celem jest uchwycenie wystarczających zdarzeń na potrzeby bezpieczeństwa i dowodów regulacyjnych bez logowania zbędnych danych osobowych lub treści ładunków.

Następnie osoba odpowiedzialna za prywatność potwierdza, czy organizacja działa jako administrator, podmiot przetwarzający albo w obu rolach dla każdego źródła logów. Jeżeli organizacja jest podmiotem przetwarzającym, polecenia umowne klienta i ujawnienia podwykonawców przetwarzania mogą ograniczać dostęp do logów i ich udostępnianie. Jeżeli jest administratorem, należy uwzględnić klauzule informacyjne, podstawę prawną i obsługę praw.

Właściciel danych aktualizuje następnie REG02, aby uwzględnić aktywne repozytoria logów, indeksy SIEM, archiwa, kopie zapasowe i tymczasowe eksporty śledcze. Jest to zgodne z Polityką retencji, usuwania i utylizacji PII, Kopie zapasowe, archiwa, repliki, logi i pliki tymczasowe, klauzula 4.4.1:

[Obie role] Właściciel systemu / właściciel aplikacji MUSI zidentyfikować w REG02 aktywne repozytoria, archiwa, kopie zapasowe, repliki, logi, obszary stagingowe i pliki tymczasowe zawierające PII przed uruchomieniem produkcyjnym oraz podczas każdego corocznego przeglądu retencji.

Polityka retencji i utylizacji danych powinna następnie dopasować biznesowe reguły retencji do wymagań prawnych, umownych i wymagań zachowania dowodów.

Na końcu zespół bezpieczeństwa konfiguruje SIEM tak, aby hasła, sekrety i treści ładunków były odrzucane lub redagowane przed pozyskaniem. Logi zawierające PII są przypisywane do indeksów o ograniczonym dostępie. Retencja jest egzekwowana automatycznie, chyba że zatwierdzono incydent albo blokadę prawną. Działania usunięcia są logowane. Eksporty śledcze wymagają zatwierdzenia i śledzenia łańcucha nadzoru. Pulpity pokazują identyfikatory spseudonimizowane tam, gdzie pełna tożsamość nie jest potrzebna. Pobieranie logów historycznych jest testowane podczas audytów wewnętrznych.

Na tym polega różnica między stwierdzeniem „logujemy dla bezpieczeństwa” a wykazaniem „logujemy tylko to, co jest niezbędne, chronimy to, przechowujemy według zatwierdzonych reguł i możemy wykorzystać jako dowód bez naruszania obowiązków prywatności”.

DSAR, usuwanie i logi: podejmij decyzje, zanim wpłynie żądanie

Jednym z najtrudniejszych pytań jest to, czy logi muszą być przeszukiwane, ujawniane albo usuwane w odpowiedzi na żądania dostępu osoby, której dane dotyczą, lub żądania usunięcia danych. Odpowiedź zależy od roli, celu, podstawy prawnej, wykonalności, wyłączeń i obowiązków retencji. Procesu ładu nie można jednak wymyślać osobno dla każdego żądania.

Polityka zarządzania prawami osób, których dane dotyczą, Weryfikacja tożsamości, zakres i ocena, klauzula 4.2.3 stanowi:

[Administrator] Właściciel procesu / właściciel biznesowy MUSI zidentyfikować właściwe systemy, zapisy, cele, kategorie PII, odbiorców i ograniczenia retencji z REG02 przed oceną realizacji żądania.

Oznacza to, że logi muszą znajdować się w REG02 z jasnymi metadanymi: jakie kategorie PII zawierają, jakiemu celowi służą, jakie ograniczenie retencji ma zastosowanie oraz czy żądanie może zostać zrealizowane przez bezpośrednie ujawnienie, dostęp w formie podsumowania, ograniczenie, usunięcie po upływie okresu przechowywania albo odmowę na podstawie udokumentowanej podstawy prawnej.

Clarysec rekomenduje podejście trójpoziomowe:

1. Logi operacyjne o niskim wpływie na prywatność, takie jak logi zdarzeń systemowych wykorzystujące pseudonimowe identyfikatory użytkowników, mogą być przeszukiwane i ujawniane, gdy jest to właściwe.
2. Logi bezpieczeństwa o wysokiej wrażliwości z perspektywy bezpieczeństwa, takie jak dane korelacyjne SIEM lub kontekst informacji o zagrożeniach, mogą wymagać filtrowania, ujawnienia w formie podsumowania albo ograniczenia, aby nie ujawniać logiki detekcji lub danych stron trzecich.
3. Dowody śledcze objęte aktywnym incydentem albo blokadą prawną nie powinny być swobodnie zmieniane. Usunięcie może zostać odroczone albo ograniczone, gdy jest to prawnie uzasadnione, a decyzja musi zostać udokumentowana przez interesariuszy ds. prywatności i prawnych.

Jeżeli DPO i SOC analizują każdy DSAR od podstaw, organizacja będzie działać niespójnie i wolno. Jeżeli REG02 i REG12 są utrzymywane, obsługa praw staje się oparta na dowodach.

Zgłaszanie naruszeń i incydentów: jedno zdarzenie, wiele zegarów

Alert z 02:17 może uruchomić kilka terminów. Ocena naruszenia ochrony danych osobowych na gruncie GDPR może wymagać zgłoszenia organowi nadzorczemu, jeżeli spełnione są progi ryzyka. Raportowanie znaczącego incydentu w ramach NIS2 może wymagać wczesnego ostrzeżenia w ciągu 24 godzin, zgłoszenia w ciągu 72 godzin i raportu końcowego. DORA może wymagać zgłoszenia poważnego incydentu związanego z ICT w etapach wstępnym, pośrednim i końcowym. Umowy z klientami mogą przewidywać jeszcze krótsze terminy powiadomień.

Polityka zarządzania incydentami PII i naruszeniami ochrony danych Clarysec bezpośrednio adresuje problem wielu przesłanek zgłoszeniowych. W sekcji Klasyfikacja i ocena naruszenia, klauzula 4.2.6:

[Warunkowo] Osoba odpowiedzialna za prywatność / Menedżer PIMS MUSI ocenić mające zastosowanie prawne, sektorowe, finansowo-sektorowe, cyberbezpieczeństwa, umowne, klientowskie oraz dotyczące odbiorców usług przesłanki raportowania dla każdego incydentu PII o istotnym wpływie i odnotować wynik oceny stosowalności w REG01, REG08 i REG10.

Podczas wstępnej kwalifikacji organizacja powinna zapytać:

• Czy atakujący uzyskał dostęp do danych osobowych, czy tylko do metadanych?
• Czy logi ujawniły dodatkowe PII nieuprawnionym użytkownikom?
• Czy logi są potrzebne do ustalenia osób, systemów i ram czasowych objętych zdarzeniem?
• Czy logi są przechowywane w sposób niemodyfikowalny i mają ograniczony dostęp?
• Czy wstrzymanie usuwania na potrzeby incydentu zatrzymało usuwanie właściwych logów?
• Czy dotknięci są klienci, dla których organizacja działa jako podmiot przetwarzający, klienci z sektora finansowego albo odbiorcy usług?
• Jakie terminy raportowania mają zastosowanie i kto odpowiada za każde zgłoszenie?

Dobrze nadzorowane logi przyspieszają raportowanie, ponieważ dostarczają decydentom wiarygodnych faktów. Słabe rejestrowanie powoduje opóźnienia. Nadmierne logowanie tworzy ryzyko prywatności. Właściwą odpowiedzią jest rejestrowanie ukierunkowane, chronione i zmapowane.

Rejestrowanie u dostawców i w chmurze: problem podmiotu przetwarzającego ukryty w SIEM

Większość organizacji nie przechowuje wszystkich logów na infrastrukturze, nad którą ma pełną kontrolę. Logi trafiają do platform SIEM, portali EDR, natywnych chmurowo usług rejestrowania, narzędzi obserwowalności, systemów zgłoszeniowych i dostawców Managed Detection and Response (MDR). Na gruncie GDPR ci dostawcy mogą być podmiotami przetwarzającymi albo podwykonawcami przetwarzania. W ramach NIS2 i DORA mogą być również bezpośrednimi dostawcami, zewnętrznymi dostawcami usług ICT, dostawcami usług zarządzanych albo dostawcami zarządzanych usług bezpieczeństwa.

NIS2 Article 21 wprost obejmuje bezpieczeństwo łańcucha dostaw, podatności dostawców i ogólne praktyki cyberbezpieczeństwa dostawców. DORA dodaje szczegółowe wymagania dotyczące ryzyka związanego z zewnętrznymi dostawcami ICT dla podmiotów finansowych, w tym due diligence przed zawarciem umowy, rejestry informacji, prawo do audytu i dostępu, wsparcie w incydentach, lokalizację danych, klauzule ochrony danych, strategie wyjścia oraz postanowienia umowne dla funkcji krytycznych lub ważnych.

W przypadku PII w logach bezpieczeństwa przeglądy dostawców powinny obejmować następujące pytania:

Umowa na SIEM nie jest wyłącznie subskrypcją oprogramowania. Jest zależnością dotyczącą przetwarzania PII i dowodów incydentowych.

Perspektywa audytu: jak asesorzy testują PII w logach bezpieczeństwa

Dobry audytor nie zaakceptuje stwierdzenia, że „logi są chronione”. Przetestuje łańcuch od polityki, przez konfigurację, dowody i przegląd.

Praktyczny test audytowy jest prosty, ale bardzo ujawniający: poproś SOC o odtworzenie wpisu logu sprzed dziesięciu miesięcy, który pokazuje zmianę dostępu uprzywilejowanego w platformie chmurowej; o wykazanie, kto uzyskał dostęp do tego logu; o potwierdzenie, że nie został zmieniony; o wskazanie reguły retencji, która pozwalała na jego istnienie; o pokazanie, jakie pola PII zawiera; oraz o wyjaśnienie, jak zostałby obsłużony w DSAR lub raporcie incydentowym. Jeżeli zespół nie potrafi odpowiedzieć łącznie z perspektywy bezpieczeństwa, prywatności i zgodności, ład jest niekompletny.

Typowe ustalenia w audytach PII w logach

Clarysec często obserwuje te same wzorce:

• Zespoły aplikacyjne logują pełne ładunki żądań na potrzeby debugowania, w tym imiona i nazwiska, adresy e-mail, numery kont lub treść wiadomości.
• Indeksy SIEM są otwarte dla szerokich grup administratorów IT zamiast ograniczonych ról SOC.
• Retencja logów jest ustawiona globalnie, bez uwzględnienia wrażliwości PII, umów z klientami lub reguł wstrzymania usuwania na potrzeby incydentu.
• Logi dostawcy usług chmurowych są włączone, ale dostęp administratorów dostawcy do danych logów klienta nie jest przeglądany.
• Procedury DSAR nie wspominają o logach, sprawach SIEM ani eksportach śledczych.
• Podręczniki reagowania na incydenty zabezpieczają dowody, ale zespoły ds. prywatności nie uczestniczą w klasyfikacji.
• Kopie zapasowe i archiwa przechowują PII z logów dłużej niż SIEM.
• Programiści mogą zmieniać poziomy rejestrowania w środowisku produkcyjnym bez przeglądu prywatności lub bezpieczeństwa.
• Środowiska testowe otrzymują logi produkcyjne z danymi osobowymi.
• Organizacja ma obowiązki raportowania wynikające z NIS2 lub DORA, ale nie może szybko pobrać wiarygodnych dowodów.

Te ustalenia rzadko wynikają ze złych intencji. Wynikają z silosowej odpowiedzialności. Logi bezpieczeństwa znajdują się na styku SOC, inżynierii platform, prywatności, działu prawnego, zgodności, audytu i dostawców. Jeżeli nikt nie odpowiada za cały cykl życia, pojawiają się luki.

Lista kontrolna Clarysec dla nadzoru nad logami gotowego do audytu

Użyj tej listy kontrolnej jako praktycznego punktu wyjścia do kolejnego przeglądu ładu:

1. Zdefiniuj, które źródła logów mogą zawierać PII: IAM, aplikacja, brama API, SIEM, EDR, chmura, baza danych, sieć, dostęp fizyczny i system zgłoszeniowy.
2. Zarejestruj każde repozytorium logów w REG02, w tym aktywne repozytoria, archiwa, kopie zapasowe, repliki i tymczasowe eksporty śledcze.
3. Zdefiniuj zakres rejestrowania PII w REG12 przed użyciem produkcyjnym lub istotnymi zmianami.
4. Zidentyfikuj cel i podstawę prawną przetwarzania logów bezpieczeństwa.
5. Zakazuj haseł, sekretów, pełnych tokenów i zbędnych ładunków w logach.
6. Stosuj maskowanie, haszowanie albo pseudonimizację tam, gdzie pełne identyfikatory nie są wymagane.
7. Ogranicz dostęp do logów zawierających PII według roli, z przeglądem dostępu uprzywilejowanego.
8. Przechowuj logi o wysokiej wartości w formatach niemodyfikowalnych albo zabezpieczonych przed zapisem.
9. Definiuj retencję według typu logu, obowiązku prawnego, umowy, potrzeby incydentowej i ryzyka dla prywatności.
10. Wdrażaj wstrzymania usuwania na potrzeby incydentu z zatwierdzeniem, zakresem i terminem wygaśnięcia.
11. Uwzględniaj logi w logice oceny DSAR i usunięcia danych.
12. Przeglądaj dostawców SIEM, EDR, chmury i MDR jako podmioty przetwarzające lub zewnętrzne podmioty ICT.
13. Testuj pobieranie danych historycznych i integralność dowodów.
14. Mapuj rejestrowanie do potrzeb raportowania w GDPR, ISO 27701, NIS2, DORA, NIST CSF i COBIT.
15. Szkol SOC, zespoły ds. prywatności i zespoły aplikacyjne z tego, co może, a co nie może być logowane.

Ta lista kontrolna przekształca rejestrowanie świadome prywatności w powtarzalny proces kontrolny.

Od dylematu do zaufania na poziomie zarządu

NIS2 czyni cyberbezpieczeństwo odpowiedzialnością kierownictwa. DORA czyni organ zarządzający odpowiedzialnym za zarządzanie ryzykiem ICT, strategię cyfrowej odporności operacyjnej, poufność danych, komunikację incydentową i polityki dotyczące usług ICT stron trzecich. ISO/IEC 27001:2022 wymaga, aby najwyższe kierownictwo dostosowało SZBI do celów biznesowych, przypisało odpowiedzialności, zapewniło zasoby i napędzało ciągłe doskonalenie.

PII w logach bezpieczeństwa nie jest zatem wąskim szczegółem technicznym. Jest kwestią zaufania na poziomie zarządu. Zdolność organizacji do wykrywania incydentów, ochrony danych osobowych, zachowywania dowodów, odpowiadania klientom, spełniania oczekiwań regulatorów i odzyskiwania operacji zależy od decyzji dotyczących rejestrowania podjętych na długo przed incydentem.

Najlepsze programy ładu nie wybierają między prywatnością a bezpieczeństwem. Definiują minimalny zakres rejestrowania potrzebny dla solidnego bezpieczeństwa, chronią to rejestrowanie jako wrażliwe PII tam, gdzie jest to wymagane, i łączą je z retencją, dowodami, obsługą praw i obowiązkami dostawców.

Kolejne kroki z Clarysec

Jeżeli Twój SIEM, IAM, EDR lub logi chmurowe zawierają dane osobowe, teraz jest czas, aby objąć je świadomym nadzorem.

Clarysec może pomóc Ci:

• Zbudować zakres rejestrowania PII z użyciem REG12 i powiązać go z Polityką bezpieczeństwa i kontroli dostępu do PII.
• Zinwentaryzować repozytoria logów, archiwa, kopie zapasowe i eksporty śledcze z użyciem REG02 oraz Polityki retencji, usuwania i utylizacji PII.
• Dostosować rejestrowanie, monitorowanie, dowody i zabezpieczenia w zakresie prywatności do Zenith Blueprint.
• Zmapować środki kontrolne pomiędzy GDPR, ISO 27701, NIS2, DORA, NIST CSF i COBIT z użyciem Zenith Controls.
• Przygotować dowody gotowe do audytu na potrzeby przeglądów zapewnienia ISO, prywatności, NIST, COBIT, NIS2 i DORA.

Zacznij od jednego systemu wysokiego ryzyka: platformy IAM, SIEM albo aplikacji dostępnej dla klientów. Ustal, jakie PII trafia do logów, dlaczego jest potrzebne, kto może uzyskać do niego dostęp, jak długo jest przechowywane i jak zostałoby wykorzystane podczas incydentu albo żądania realizacji praw. To jedno ćwiczenie pokaże, czy obecny program rejestrowania jest wyłącznie operacyjny, czy rzeczywiście gotowy do audytu.