brak rejestrowania naruszeń ochrony danych

Brak rejestrowania naruszeń ochrony danych to zaniedbanie zgodności utrudniające wykazanie reakcji organizacji na incydent.

Na czym polega brak rejestrowania naruszeń ochrony danych

Brak rejestrowania naruszeń ochrony danych oznacza, że incydenty związane z nieuprawnionym dostępem, ujawnieniem, zmianą, utratą albo zniszczeniem danych nie są zapisywane w uporządkowanym rejestrze. Nie chodzi wyłącznie o sytuację, w której dane zostały skopiowane przez osobę nieuprawnioną. Naruszeniem może być także wysłanie pliku do niewłaściwego odbiorcy, pozostawienie niezabezpieczonego komputera, utrata nośnika, omyłkowe nadanie zbyt szerokich uprawnień albo awaria powodująca niedostępność danych.

Rejestr powinien pozwalać odtworzyć przebieg zdarzenia: kiedy zostało zauważone, jakiego systemu lub urządzenia dotyczyło, jakie dane mogły zostać objęte incydentem, kto wykrył problem, jakie działania wykonano oraz jaki był wynik analizy. Sam komunikat „wystąpił problem z bezpieczeństwem” nie jest wystarczającą dokumentacją techniczną. Bez identyfikatora zdarzenia, znaczników czasu i opisu podjętych czynności trudno później rozróżnić pojedynczy incydent od powtarzającej się awarii lub trwającego ataku.

Jakie informacje powinien zawierać techniczny zapis incydentu

Praktyczny wpis w rejestrze może zawierać unikalny numer sprawy, datę i czas wykrycia, źródło zgłoszenia, nazwę urządzenia lub systemu, konto użytkownika, adres sieciowy, rodzaj zdarzenia oraz ocenę jego zakresu. W przypadku komputera przydatne są również informacje o systemie operacyjnym, używanym programie, podłączonym nośniku i stanie zabezpieczeń. Należy odnotować fakty, a nie niepotwierdzone przypuszczenia. Jeżeli nie wiadomo, czy plik został odczytany, zapis powinien wskazywać „brak potwierdzenia odczytu”, a nie przedstawiać takiego odczytu jako pewnik.

Istotne są także dowody techniczne: wpisy z dziennika systemowego, logowania, historię zmian uprawnień, alerty programu ochronnego, nagłówki wiadomości, sumy kontrolne plików lub kopie konfiguracji. Dowody powinny być przechowywane w sposób ograniczający możliwość ich późniejszej zmiany. Dostęp do rejestru i załączników powinien być nadawany tylko osobom, które uczestniczą w analizie. Warto zapisywać, kto utworzył wpis, kto go zmienił oraz kiedy dokonano każdej zmiany. Taki ślad audytowy pomaga ustalić, czy dokumentacja odzwierciedla stan ustaleń z chwili obsługi incydentu.

Skutki pominięcia rejestru w przepływie obsługi

Jeżeli zgłoszenie nie trafia do rejestru, dalsze działania mogą zostać wykonane bez pełnego kontekstu. Osoba reagująca na problem może usunąć złośliwy plik, odłączyć komputer od sieci albo zmienić hasło, ale bez zapisu czasu i zakresu tych czynności nie będzie wiadomo, jakie dane diagnostyczne pozostały dostępne. Przedwczesne czyszczenie urządzenia może usunąć logi, historię procesów lub inne ślady potrzebne do ustalenia przyczyny. Z kolei brak informacji o wykonanej kopii może prowadzić do wielokrotnego odtwarzania tego samego materiału albo pominięcia ważnego dowodu.

Nieprowadzony rejestr utrudnia również wykrywanie wzorców. Kilka pozornie małych zdarzeń może mieć wspólną przyczynę: wadliwą regułę zapory, nieaktualny program, błędną konfigurację współdzielenia plików lub używanie tego samego hasła na wielu kontach. Bez wspólnej klasyfikacji, znaczników czasu i powiązania zgłoszeń incydenty pozostają rozproszonymi wiadomościami, notatkami i rozmowami. W rezultacie organizacja może nie zauważyć, że problem powraca, obejmuje więcej urządzeń albo wymaga zmiany procedury.

Porządkowanie dokumentacji po wykryciu zaniedbania

Naprawę procesu warto rozpocząć od ustalenia jednego miejsca rejestracji oraz minimalnego zestawu pól, których nie można pominąć. Następnie należy zebrać dostępne zgłoszenia, logi i notatki, nadać sprawom identyfikatory oraz wyraźnie oznaczyć informacje odtworzone po czasie. Nie należy dopisywać niepotwierdzonych szczegółów tylko po to, aby formularz wyglądał na kompletny. Lepszy jest zapis „brak danych w logu” wraz z informacją, dlaczego log nie był dostępny. Każdy incydent powinien mieć także status, osobę odpowiedzialną za analizę, listę działań oraz decyzję o zakończeniu albo dalszej obserwacji.

Podczas diagnostyki laptopa lub komputera PC przydatne jest zachowanie chronologii: objaw, moment zgłoszenia, wykonane czynności, wynik testu i stan urządzenia po zakończeniu pracy. Należy oddzielić opis techniczny od oceny skutków, ponieważ ustalenie awarii programu nie zawsze oznacza potwierdzenie dostępu do danych. W przypadku braku logów można sprawdzić kopie zapasowe, historię zdarzeń systemu, ustawienia kont i daty modyfikacji plików, o ile te informacje nadal istnieją. Tak uporządkowana dokumentacja nie usuwa samego zaniedbania, ale pozwala rzetelnie określić jego zakres i ograniczyć ryzyko powtórzenia podobnego problemu.