Zauważanie, zanim zrobi to ktoś inny.
CC7.2 to kryterium SOC 2 dotyczące monitorowania: wykrywania anomalii i zdarzeń bezpieczeństwa, aby można było na nie zareagować. Opiera się na logowaniu - logi rejestrują, co się stało, a monitorowanie to mechanizm, który to zauważa i sygnalizuje. Kontrola, której działania nie widać, to kontrola, na którą nie można zareagować, dlatego wykrywanie ma własne kryterium.
The shapes the same control failure takes.
CC7.2 słabnie, gdy zmiana cicho zmniejsza to, co system może zauważyć. Powtarzające się wzorce:
Reguła alertu została usunięta
Reguła, która uruchamiała się przy warunku bezpieczeństwa (np. gwałtowny wzrost nieudanych logowań, nieoczekiwane nadanie uprawnień), została usunięta, ponieważ była zbyt głośna, zabierając przy tym możliwość wykrywania.
Próg został poluzowany
Próg alertu został podniesiony na tyle, że anomalię, którą miał wykrywać, przestaje uruchamiać, pozostawiając regułę obecną, ale praktycznie niewidomą.
Metryka przestaje być emitowana
Instrumentacja, która zasilała pulpit nawigacyjny lub alert, została usunięta, więc obserwowany element staje się niewidoczny, mimo że alert nadal istnieje.
Zakres nie nadąża za nową powierzchnią
Nowa usługa, punkt końcowy lub ścieżka jest wdrażana bez monitorowania, więc cała część systemu pozostaje domyślnie nieobserwowana.
Wykrywanie zostało wyłączone
Wykrywanie anomalii lub monitor bezpieczeństwa został wyłączony (np. flaga funkcji, zakomentowana sprawdzanie), aby zredukować szum, i nigdy nie został ponownie włączony.
Alert o wzroście nieudanych logowań, usunięty.
Alert, który uruchamiał się przy wzroście nieudanych logowań, wywoływał powiadomienia podczas testów obciążeniowych, więc zmiana usuwa go z konfiguracji monitorowania. Szum ustaje, a wraz z nim jedyna zautomatyzowana metoda, dzięki której zespół zauważyłby atak brute-force w produkcji.
groups:- - alert: FailedLoginSpike- expr: rate(auth_failures_total[5m]) > 20- for: 2m- labels: { severity: security }Ta zmiana usuwa wykrywanie wzrostu nieudanych logowań, sygnał, którego potrzebowałbyś, gdyby ktoś przeprowadzał atak brute-force na konto. CC7.2 oczekuje, że system monitoruje i wykrywa anomalie tego typu. Jeśli alert jest zbyt głośny, dostrój próg lub zmień jego trasowanie, ale zachowaj wykrywanie zamiast je usuwać.
Monitorowanie jest sprawdzane jako zdolność, a nie obietnica.
Auditor szuka dowodów na to, że faktycznie wykrywasz i reagujesz na anomalie: istnienie alertów, ich uruchamianie oraz to, że ktoś podejmuje działanie, gdy się pojawią. Zmiana, która usuwa alert bezpieczeństwa lub cicho wyłącza metrykę, to luka za twierdzeniem, że prowadzisz monitorowanie. Ujawnia się w diffie konfiguracji monitorowania, co jest najtańszym miejscem, aby ją złapać.
Przegląd, a nie Twój stack monitorujący.
heygrc sygnalizuje zmiany, które dotyczą CC7.2, i cytuje kryterium, aby naprawa nastąpiła w pull request. Nie uruchamia Twojego systemu alertów ani reagowania na incydenty. Wychwytuje moment, w którym wykrywanie zostaje usunięte lub wyłączone, na etapie diffu.