Rejestrowanie, kontrola, która cicho zanika.
ISO 27001:2022 A.8.15 (rejestrowanie) wymaga, aby istotne dla bezpieczeństwa zdarzenia (logowania, błędy, awarie, dostęp do wrażliwych danych) były rejestrowane, przechowywane przez określony czas i chronione przed modyfikacją. Jest to kluczowe dla A.8.16 (monitorowanie) oraz dla późniejszych dochodzeń: nie można wykryć ani zrekonstruować tego, czego nigdy nie zarejestrowano. Łatwo ją osłabić, nie zauważając, ponieważ log to rodzaj wiersza, który często jest usuwany podczas porządkowania kodu.
The shapes the same control failure takes.
A.8.15 rzadko ulega awarii na skutek dramatycznej zmiany. Zazwyczaj przestaje działać, gdy istotne dla bezpieczeństwa zdarzenie przestaje być rejestrowane. Typowe przypadki:
Log bezpieczeństwa został usunięty
Wywołanie logu dla zdarzenia autentykacji, zmiany uprawnień lub dostępu do wrażliwych danych zostało usunięte podczas czyszczenia kodu, ponieważ wydawało się zbyt hałaśliwe.
Poziom logowania spada poniżej poziomu produkcji
Zdarzenie bezpieczeństwa zostało przeniesione na poziom (debug), który nie jest emitowany w środowisku produkcyjnym, więc przestaje być rejestrowane tam, gdzie jest to istotne.
Aktor zostaje usunięty z rekordu
Log nadal jest generowany, ale przestaje zawierać informację o tym, kto wykonał działanie, więc zdarzenie nie może być przypisane podczas dochodzenia.
Nowa uprawniona akcja jest wdrażana bez logowania
Nowa operacja administracyjna lub niszcząca została dodana bez żadnego rekordu audytu, więc nie ma nic do pobrania później.
Okres retencji został skrócony
Okres przechowywania lub rotacja logów została skrócona poniżej oczekiwań kontroli, więc rekord znika, zanim ktokolwiek go potrzebuje.
Błędy autentykacji obniżone poniżej poziomu logowania produkcji.
Logi nieudanych autentykacji są hałaśliwe w środowisku deweloperskim, więc zmiana przenosi je z poziomu ostrzeżenia na poziom debug. W produkcji poziom logowania jest ustawiony na info, więc te błędy teraz znikają z rekordu całkowicie, a to właśnie zdarzenia, których najbardziej potrzebujesz podczas badania naruszenia bezpieczeństwa.
if (!valid) {- logger.warn("auth.failed", { userId, ip })+ logger.debug("auth.failed", { userId, ip }) return unauthorized()}Przy poziomie produkcji ustawionym na info, obniżenie błędów autentykacji do poziomu debug oznacza, że nie są one już rejestrowane w produkcji. A.8.15 wymaga, aby istotne dla bezpieczeństwa zdarzenia, w tym nieudane autentykacje, były rejestrowane i przechowywane, a A.8.16 (monitorowanie) zależy od nich. Zachowaj je na poziomie ostrzeżenia lub skieruj do logów bezpieczeństwa, zamiast wyciszać je w produkcji.
Rejestrowanie jest sprawdzane na podstawie rzeczywistych zdarzeń.
Auditor sprawdza, czy istotne dla bezpieczeństwa zdarzenia są faktycznie rejestrowane, przechowywane przez okres określony w polityce oraz chronione przed modyfikacją, i pobiera próbki konkretnych typów zdarzeń (logowania, zmiany uprawnień, dostęp do wrażliwych danych). Zmiana, która niepostrzeżenie przestała rejestrować jedno z nich, usuwając je lub obniżając poniżej poziomu produkcji, to luka, którą wykryje. Zmiana, która ją wprowadziła, była zwykle zwykłym pull requestem, który wyglądał na redukcję hałasu.
Przegląd, a nie Twoje SIEM.
heygrc sygnalizuje zmiany, które dotyczą A.8.15, i cytuje kontrolę, aby naprawa nastąpiła w pull request. Nie uruchamia Twojego potoku logowania ani monitorowania. Wychwytuje moment, w którym zdarzenie bezpieczeństwa przestaje być rejestrowane, na poziomie diff.