Logi incydentów bezpieczeństwa: jak tworzyć logi spełniające wymogi GDPR i organów regulacyjnych

Najtrudniejsza część incydentu bezpieczeństwa zwykle następuje po jego zakończeniu: gdy firma musi wyjaśnić, co się stało, kiedy go wykryto, jakie dane były objęte, kto został poszkodowany i dlaczego podjęto określone decyzje.

W wielu MŚP takie rejestry nie istnieją w kompletnej formie. Szczegóły mogą być rozproszone po wiadomościach czatowych, skrzynkach odbiorczych, zgłoszeniach do helpdesku, zrzutach ekranu i w pamięci członków zespołu. Firmy utrzymują się na powierzchni podczas incydentu dzięki tym niekompletnym zapisom, ale stają się one problemem, gdy organ nadzorczy, ubezpieczyciel, klient lub członek zarządu poprosi o jasny harmonogram.

Firmy każdej wielkości potrzebują dokładnego logu incydentów bezpieczeństwa. Powinien być jednym źródłem prawdy do rejestrowania, co się stało, jak obsłużono incydent i jakie dowody wspierają decyzje podjęte po drodze.

Rejestr jest cenny nawet wtedy, gdy nie musisz zgłaszać incydentu. Wyjaśnimy, dlaczego logi incydentów bezpieczeństwa są przydatne dla Twojej firmy i jak stworzyć własne.

Dlaczego logi incydentów bezpieczeństwa mają znaczenie

Logi incydentów a plany reagowania na incydenty

Co powinien zawierać log incydentów bezpieczeństwa

Prosty szablon logu incydentów dla MŚP

Jak rejestrować decyzje dotyczące powiadomień

Czego organy nadzorcze oczekują od logów incydentów bezpieczeństwa

Log dostępu do danych logowania

Dlaczego logi incydentów bezpieczeństwa mają znaczenie

Logi incydentów bezpieczeństwa tworzą rozliczalność w momencie, gdy firma najczęściej traci z oczu szczegóły. Podczas incydentu działania następują szybko: hasła są resetowane, konta są wyłączane, kontaktuje się z dostawcami IT, sprawdza się dane klientów i informuje kierownictwo. Te kroki mogą być dokładnie tym, czego firma potrzebuje w danym momencie, ale znacznie trudniej je później wyjaśnić, jeśli nikt nie rejestruje, kiedy miało miejsce każde działanie, kto je zatwierdził i jakie dowody je wspierały.

W przypadku firm z Europy to nie tylko dobra praktyka. Zgodnie z ogólnym rozporządzeniem o ochronie danych (GDPR), zarówno w Wielkiej Brytanii, jak i w UE, naruszenia danych osobowych trzeba oceniać, a niektóre należy zgłaszać do właściwego organu nadzorczego.

W Wielkiej Brytanii wytyczne ICO dotyczące zgłaszania naruszeń(nowe okno)⁠ wyjaśniają, że organizacje muszą ocenić prawdopodobne ryzyko dla praw i wolności osób oraz powiadomić ICO, gdy ryzyko jest prawdopodobne. Artykuł 33 wymaga również od administratorów dokumentowania naruszeń danych osobowych, w tym faktów naruszenia, jego skutków i podjętych działań naprawczych. Te same wymagania mają zastosowanie w ramach unijnego GDPR.

Na przykład ICO nie oczekuje, że każde MŚP będzie miało systemy klasy enterprise, ale oczekuje odpowiednich rejestrów. Jej ramy reagowania na naruszenia i monitorowania mówią, że organizacje powinny mieć procedury zapewniające wykrywanie, zarządzanie i odpowiednie rejestrowanie incydentów oraz naruszeń danych osobowych. Oznacza to, że log incydentów nie powinien być tworzony tylko wtedy, gdy doszło już do poważnego naruszenia. Powinien być częścią normalnego procesu reagowania.

Dobre rejestry wspierają również roszczenia ubezpieczeniowe. Ubezpieczyciele cyber mogą pytać o dowody na to, kiedy wykryto incydent, jakie kroki powstrzymujące podjęto, które konta zostały dotknięte i czy firma przestrzegała swojego procesu reagowania na incydenty. Dobrze prowadzony log może pokazać, że firma działała szybko i konsekwentnie.

Pomaga to również firmie się uczyć. Wspomnienia i zapisy ustne nie są wiarygodne, ale rejestr, który pokazuje, że incydent zaczął się od ponownie użytego hasła, braku uwierzytelniania wieloskładnikowego (MFA), dostępu dostawcy lub opóźnionego offboardingu, daje firmie konkretny obszar do naprawy i jaśniejszy kierunek wzmacniania bezpieczeństwa z czasem.

Logi incydentów a plany reagowania na incydenty

Log incydentów bezpieczeństwa i plan reagowania na incydenty są ze sobą powiązane, ale nie są tym samym dokumentem.

Plan reagowania na incydenty wyjaśnia, co firma powinna zrobić, gdy coś pójdzie nie tak. Przypisuje role, ścieżki eskalacji, kroki powstrzymujące, obowiązki komunikacyjne i procedury odzyskiwania. Log incydentów rejestruje to, co faktycznie się wydarzyło. To oś czasu, ślad dowodowy, rejestr decyzji i plik działań następczych dla konkretnego zdarzenia.

To rozróżnienie ma znaczenie, ponieważ nawet dobry plan może zawieść bez dokumentacji. Firma może wykonać właściwe kroki, ale później wciąż mieć trudność z ich udowodnieniem. Log powinien umożliwiać odpowiedź na praktyczne pytania: kiedy się dowiedzieliśmy, kto działał, co powstrzymaliśmy, jakie dane były zagrożone, co postanowiliśmy i co zmieniło się później?

Co powinien zawierać log incydentów bezpieczeństwa

Przydatny log incydentów musi być wystarczająco spójny, aby firma mogła później odtworzyć zdarzenie i wyjaśnić decyzje podjęte podczas reakcji.

Data i godzina wykrycia

Zarejestruj, kiedy firma po raz pierwszy dowiedziała się o incydencie, kto go zauważył i jak go wykryto. Jeśli czas jest przybliżony, oznacz go jako przybliżony. Czas wykrycia ma znaczenie, ponieważ terminy zgłaszania GDPR i wymogi ubezpieczeniowe często zależą od tego, kiedy firma dowiedziała się o problemie.

Charakter incydentu

Opisz, co się stało, prostym językiem. Unikaj niejasnych etykiet, takich jak „problem z bezpieczeństwem” lub „możliwe naruszenie”, bez kontekstu. Log powinien wyjaśniać, które systemy zostały dotknięte i czy incydent obejmował dane logowania, wiadomości e-mail, pliki, dane klientów, systemy płatności, punkty końcowe lub dostęp stron trzecich.

Dane objęte incydentem

Jeśli dane osobowe mogły zostać naruszone, zarejestruj, jaki rodzaj danych był objęty: imiona i nazwiska, adresy e-mail, numery telefonów, adresy, szczegóły konta, informacje finansowe, akta pracowników, komunikację z klientami, dane logowania lub inną istotną kategorię. Oszacuj, ile osób może być poszkodowanych, i jasno określ, czy liczba jest potwierdzona, czy wciąż badana.

Prawdopodobna przyczyna

Zarejestruj znaną lub podejrzewaną przyczynę, nawet jeśli śledztwo trwa. Gdy pojawią się nowe szczegóły, log można zaktualizować z „przyczyna nieznana” na „e-mail phishingowy doprowadził do naruszenia danych logowania” lub „konto byłego wykonawcy pozostało aktywne”. Log powinien pokazywać, jak zmieniało się zrozumienie sytuacji przez firmę w czasie.

Natychmiastowe działania powstrzymujące

Udokumentuj, co zrobiono, aby ograniczyć szkody. Może to obejmować resetowanie haseł, unieważnianie sesji, wymuszanie MFA, zawieszanie kont, usuwanie reguł skrzynki pocztowej, izolację urządzeń, usuwanie dostępu dostawców, zmiany w zaporze sieciowej lub tymczasowe wyłączanie usług. Tam, gdzie to możliwe, podaj właściciela i znacznik czasu dla każdego działania.

Decyzje dotyczące powiadomień

Zarejestruj, czy firma powiadomiła właściwy organ nadzorczy (ICO w Wielkiej Brytanii lub krajowy organ ochrony danych gdzie indziej w UE), poszkodowane osoby, klientów, dostawców, ubezpieczycieli, doradców prawnych lub organy ścigania. Jeśli zdecydowano nie powiadamiać, udokumentuj uzasadnienie. To wyjaśnienie jest często równie ważne jak samo powiadomienie.

Kroki naprawcze i harmonogram

Powstrzymanie dotyczy bezpośredniego incydentu. Naprawa zmniejsza ryzyko ponownego wystąpienia tego samego problemu. Zarejestruj działania następcze, takie jak wymuszanie MFA, usuwanie współdzielonych danych logowania, aktualizowanie zasad dostępu, ulepszanie offboardingu, naprawianie błędnej konfiguracji lub zmiana sposobu ochrony kopii zapasowych.

Wyciągnięte wnioski

Zakończ tym, czego firma się nauczyła i co się zmieni. Nie należy tego pisać jako oskarżenia. Powinno wskazywać słabość, potrzebną poprawę i osobę odpowiedzialną za działania następcze.

Prosty szablon logu incydentów dla MŚP

Specjalistyczne oprogramowanie nie jest konieczne do dokumentowania incydentów. Arkusz kalkulacyjny, bezpieczny formularz wewnętrzny, system zgłoszeń lub współdzielony rejestr mogą się sprawdzić, jeśli dostęp jest kontrolowany, a wpisy są spójne.

Skuteczny log incydentów powinien zawierać następujące pola:

• Identyfikator incydentu: Unikalny numer referencyjny.
• Data i godzina wykrycia: Kiedy firma dowiedziała się o incydencie.
• Zgłoszone przez: pracownika, usługodawcę, klienta, dostawcę, alert monitorujący lub podmiot zewnętrzny.
• Typ incydentu: próba wyłudzenia informacji, złośliwe oprogramowanie, naruszenie danych logowania, utrata danych, nieautoryzowany dostęp, oprogramowanie ransomware, incydent u dostawcy, utrata urządzenia, błędnie wysłana wiadomość lub inny.
• Podsumowanie: co się stało, opisane prostym językiem.
• Systemy, których dotyczy: aplikacje, konta, urządzenia, bazy danych, skrzynki odbiorcze lub usługi stron trzecich.
• Dane, których dotyczy: czy doszło do naruszenia danych osobowych, jakiego rodzaju i ile osób może być poszkodowanych.
• Prawdopodobna przyczyna: znana, podejrzewana lub w trakcie badania.
• Działania ograniczające: co zrobiono natychmiast.
• Decyzja o powiadomieniu: organ nadzorczy, osoby, klienci, ubezpieczyciel lub brak powiadomienia wraz z uzasadnieniem.
• Linki do dowodów: zrzuty ekranu, zgłoszenia, logi, wiadomości e-mail, rejestry dostępu, pliki eksportu lub raporty dostawcy.
• Działania naprawcze: kroki podjęte po ograniczeniu incydentu.
• Właściciel: osoba odpowiedzialna za dalsze działania.
• Status: otwarty, monitorowany, opanowany, rozwiązany, zamknięty.
• Wnioski: co należy zmienić.

Jak rejestrować decyzje o powiadomieniu

Decyzje o powiadomieniu zasługują na własne miejsce w logu incydentów bezpieczeństwa, ponieważ często są analizowane po incydencie.

Zarówno w przypadku brytyjskiego, jak i unijnego GDPR organizacje muszą ocenić prawdopodobne ryzyko dla praw i wolności osób w przypadku naruszenia ochrony danych osobowych. Jeśli ryzyko jest prawdopodobne, należy jak najszybciej powiadomić organ nadzorczy, a jeśli to możliwe, w ciągu 72 godzin; w Wielkiej Brytanii jest to ICO(nowe okno), a w każdym państwie członkowskim UE – krajowy organ ochrony danych. Jeśli ryzyko jest wysokie, należy również bez zbędnej zwłoki powiadomić osoby, których to dotyczy. Progi i terminy są takie same w obu systemach; zmienia się tylko organ.

Dobry log incydentów powinien pokazywać, że firma przeprowadziła taką ocenę. Powinien rejestrować, czy wiązało się to z danymi osobowymi, jakiego rodzaju szkody mogą wystąpić, jakie zabezpieczenia zastosowano i dlaczego firma zdecydowała się zgłosić incydent lub nie.

Na przykład incydent związany z ujawnionym hasłem administratora może nie od razu ujawniać, czy uzyskano dostęp do danych osobowych. Log powinien odzwierciedlać tę niepewność. Może rejestrować wstępne obawy, kroki dochodzenia, przegląd aktywności na koncie i ostateczny wniosek, gdy dostępne będą dowody.

Na tym etapie procesu wiele firm skupia się na zorganizowaniu naprawy technicznej i zapomina o udokumentowaniu uzasadnienia zgodności. Hasła są resetowane, konta zabezpieczane, a działania są kontynuowane. Tygodnie później firma nie potrafi wyjaśnić, dlaczego uznała, że incydent nie podlegał zgłoszeniu.

Czego organy nadzorcze oczekują od dokumentacji

Organy nadzorcze nie patrzą wyłącznie na to, czy naruszenie zostało zgłoszone. Mogą również zapytać, w jaki sposób firma:

• zidentyfikowała incydent
• oceniła ryzyko
• zdecydowała, czy powiadomienie było wymagane
• udokumentowała podjęte działania

Dobry rejestr powinien jasno przedstawiać przebieg incydentu od początku do końca. Powinien pokazywać, co się stało, jakie dane osobowe były objęte incydentem, jakie szkody mogą wystąpić, co firma zrobiła, aby ograniczyć problem, oraz dlaczego zgłosiła lub nie zgłosiła naruszenia.

Poziom szczegółowości powinien odpowiadać powadze incydentu. Błędnie wysłana wiadomość nie wymaga takiego samego rejestru jak atak ransomware, ale nadal musi zostać udokumentowana, aby pokazać, że firma należycie ją oceniła.

Takie rejestry powinny być również bezpiecznie przechowywane. Logi incydentów mogą zawierać wrażliwe szczegóły dotyczące osób, których to dotyczy, narażonych systemów, działań pracowników, zrzutów ekranu, logów dostępu lub kroków naprawczych. Dostęp powinien być ograniczony do osób, które go potrzebują, a okres przechowywania powinien być zgodny z ogólną zasadą przechowywania danych w firmie.

Log dostępu do danych logowania

Wiele incydentów wiąże się z danymi logowania: mogą być wywołane przez ponowne użycie hasła, współdzielone konto, zagrożoną skrzynkę odbiorczą, ujawniony login administratora, podejrzane żądanie MFA lub pracownika, który nie został prawidłowo odcięty od systemów.

Z tego powodu rejestry dostępu do danych logowania mogą stać się bezpośrednim źródłem danych wejściowych do dokumentacji incydentów cyberbezpieczeństwa. Gdy incydent dotyczy współdzielonego loginu lub wrażliwego konta, firma musi wiedzieć, kto miał dostęp, w jaki sposób dostęp był udostępniany, czy uprawnienia uległy zmianie i czy dane logowania zostały zmienione po incydencie.

Firmowy menadżer haseł⁠, taki jak Proton Pass for Business, pomaga zespołom zarządzać danymi logowania w zaszyfrowanych sejfach, generować unikalne hasła, korzystać z autouzupełniania, bezpiecznie udostępniać dane logowania, zarządzać kluczami dostępu i korzystać z wbudowanego uwierzytelniania dwustopniowego. W dokumentacji incydentów największą wartość ma ścieżka dostępu do danych logowania: kto miał dostęp do współdzielonych sejfów/kont, w jaki sposób zarządzano dostępem i kto z niego korzystał oraz co zmieniło się po incydencie.

Menadżer haseł dla zespołów IT dodaje funkcje administracyjne, takie jak zasady, raportowanie, logi, kontrola dostępu oparta na rolach, aprowizacja SCIM i integracja z SSO. Funkcje te mogą pomóc firmom pokazać, w jaki sposób kontrolowany jest dostęp do danych logowania, oraz dostarczyć dowodów, gdy badany jest incydent związany z danymi logowania.

Menadżer haseł nie zastąpi logu incydentów, oceny prawnej, procesu powiadamiania organów regulacyjnych ani planu reagowania na incydenty. Zapewnia jednak dowody dotyczące danych logowania, które mogą zasilać te procesy.

Prowadź pełny ślad audytowy dostępu do danych logowania dzięki firmowemu menadżerowi haseł⁠.