Przekształcanie wskaźników zagrożeń Cloudflare w reguły WAF działające w czasie rzeczywistym

Gdy tylko wskaźnik zagrożenia dostanie się do systemu, reguły zaczynają blokować ruch. Ta akcja wygląda bardzo schludnie. Tempo jest szybkie, informacje zwrotne szybkie, a raporty są piękne. Ale kiedy to urządzenie zostanie wprowadzone do produkcji, prawdziwą trudnością nie jest już przekształcenie wskaźnika w regułę, ale sprawienie, aby ta reguła była odporna na ruch, fałszywe alarmy i wycofywanie zmian.

Kiedy czytałem Przekształcanie wskaźników zagrożeń Cloudflare w reguły WAF działające w czasie rzeczywistym, do głowy nie przyszły mi wymyślne słowa „automatyzacja dostępu do danych wywiadowczych”, ale kilka bardzo praktycznych obrazków: adres IP został oznaczony na czerwono i przechwycony dziesięć minut później; ASN oznaczono jako wysokie ryzyko, w wyniku czego zaangażowane było całe wspólne wyjście; krótkotrwała próbka ataku właśnie znalazła się w bazie reguł, a ruch związany z atakami został odcięty, pozostawiając starą regułę, która nadal obowiązuje. W czasie rzeczywistym nie chodzi tylko o szybkość, ale o kompresję cyklu życia reguł, wiarygodności danych i obowiązków w tym samym oknie.

Reguły mogą być szybkie, pod warunkiem, że można je wycofać

Kiedy wskaźnik zagrożenia wchodzi do WAF, pierwszą osobą, która traci cierpliwość, zwykle nie jest atakujący, ale osoba pełniąca służbę. Ponieważ gdy zasada zacznie obowiązywać, nie będzie to abstrakcyjna „poprawa bezpieczeństwa”, ale konkretne przypadkowe obrażenia, odwołania, wycofania i audyty. Wskaźniki na poziomie IP są najłatwiejsze do delegowania. Mają jednopunktowe trafienia, krótki czas przeżycia i niskie koszty regeneracji. Wskaźniki takie jak ASN, segment sieci, odcisk palca TLS i kombinacja żądań są znacznie ostrożniejsze. Zajmują większy obszar i mają trudniejsze efekty uboczne przy trafieniu.

Naprawdę cenną częścią tego jest to, że reguły nie są zapisywane raz i gotowe, ale pojawiają się z TTL, źródłem, zasięgiem trafienia i warunkami cofania. Bez tych pól reguły czasu rzeczywistego szybko przekształcą się w zbiór rekordów wygasłych banów. Jeśli dzisiaj zablokujesz atak, jutro zaczniesz blokować zwykłych użytkowników. Najczęstszym nieprzyjemnym zapachem podczas produkcji jest to, że baza reguł staje się coraz grubsza i zostaje zachowany nie skuteczny osąd, ale historyczne emocje.

Pomiędzy warstwą wskaźnikową a warstwą akcji należy pozostawić bufor.

Przełożenie wskaźników zagrożeń bezpośrednio na reguły blokowe jest oczywiście najszybsze, ale ten krok jest również najłatwiejszym do wzmocnienia błędów wywiadowczych i przekształcenia ich w wypadki online. Bardziej stabilne podejście polega zwykle na pozostawieniu warstwy bufora między wskaźnikiem a akcją, pozwalając temu samemu sygnałowi przejść najpierw przez obserwację, wyzwanie i ograniczenie prędkości, a następnie zdecydować, czy naprawdę go zablokować. Gdy brakuje tej warstwy buforowej, im szybciej wskaźniki są aktualizowane, tym szybciej reguły ulegną przypadkowemu uszkodzeniu.

Po faktycznym wdrożeniu najlepiej jest, aby zasada nie była płaskim włącznikiem/wyłącznikiem, ale zestawem stanów, które mogą wyrazić intensywność akcji: najpierw nagrywaj, potem rzucaj wyzwanie, potem ograniczaj prąd, a na końcu przechwytuj. Korzyści z tego są proste: zasady można stopniowo zwiększać w miarę wzmacniania się dowodów i szybko je obniżać, gdy dowody stają się słabsze. Dla zespołu ds. bezpieczeństwa może to lepiej zachować wiarygodność niż wypełnianie wszystkich zasad na raz; ze strony biznesowej przynajmniej mogą dostrzec nietypowe wahania, gdy się pojawią, zamiast czekać, aż uzbierają się stosy zgłoszeń do obsługi klienta, aby dowiedzieć się, co się stało.

{
  "action": "challenge",
  "scope": "path:/login",
  "ttl": "15m",
  "confidence": 0.82
}

Ta struktura wygląda na prostą, ale w rzeczywistości jest bardzo ważna. Gdy confidence jest niski, wyzwanie w pierwszej kolejności bardziej przypomina ocenę inżynierską niż bezpośrednie przechwytywanie; ttl automatycznie wygasa po wygaśnięciu, aby uniknąć zawieszania się starych informacji na boku; scope jest zredukowany do ścieżki lub segmentu ruchu, dzięki czemu obszar przypadkowych uszkodzeń nie będzie powiększany w nieskończoność.

Bez przeglądu reguły będą się tylko wydłużać i wyglądać jak kupa śmieci.

Największą obawą związaną z WAF w czasie rzeczywistym nie jest niski współczynnik trafień, ale to, że nikt nie wie, co stało się po trafieniu. Po opublikowaniu reguł musisz być w stanie spojrzeć wstecz na trzy rzeczy: ile rzeczywistych ataków zostało zablokowanych, ile normalnych żądań zostało przypadkowo zabitych i czy po trafieniach pojawiły się nowe metody obejścia. Tylko łącząc te trzy rzeczy, regułę można uznać za wykonalną i łatwą do utrzymania; bez żadnego z nich ostatecznie stanie się to działaniem bezwładnym polegającym na „i tak najpierw to zablokowaniu”.

Jest to również najbardziej niedoceniana część automatyzacji wskaźników zagrożeń. Źródeł wskaźników może być wiele, a aktualizacje danych wywiadowczych mogą być częste, ale bez stabilnej pętli informacji zwrotnej zasady zawsze będą po prostu pchać się do przodu. Prawdziwie dojrzały system będzie rejestrował współczynnik trafień, liczbę wycofań, liczbę ręcznych zwolnień, powiązane alarmy i straty biznesowe każdej reguły. W tym momencie zasadami nie są już po prostu konfiguracje zabezpieczeń, ale zapisy dotyczące usuwania wraz z łańcuchem dowodowym.

Ten zestaw narzędzi jest odpowiedni tylko dla zespołów, które mają już możliwości usuwania

Przekształcanie wskaźników zagrożeń w reguły WAF w czasie rzeczywistym nie jest odpowiednie dla wszystkich scenariuszy. W przypadku systemów o małym ruchu, wąskiej powierzchni ataku i wystarczająco szybkiej pracy ręcznej często bardziej kłopotliwe jest dalsze poleganie na regułach statycznych i ręcznych aktualizacjach. Ci, którzy naprawdę potrzebują tej możliwości, to zazwyczaj zespoły o dużym natężeniu ruchu, dużej gęstości ataków, częstych zmianach reguł i które mają już logi, przeglądy i procesy robocze.

Po wdrożeniu tego typu systemu wartością nie będzie tylko „szybsze zatrzymanie”. Ważniejsze jest przekształcenie usuwania skutków bezpieczeństwa z jednorazowej, ręcznej oceny w łańcuch wykonań, który można odwołać, przeglądać i stopniować. Zaletą platformy takiej jak Cloudflare jest nie tylko to, że może ona uzyskać więcej sygnałów o zagrożeniach, ale także możliwość przekazania sygnałów do warstwy reguł, a następnie ponownego połączenia warstwy reguł z monitorowaniem, wycofywaniem zmian i audytem. Bez tego łańcucha działanie w czasie rzeczywistym spowoduje jedynie szybsze występowanie błędów; dzięki temu łańcuchowi reguły mogą naprawdę wejść do produkcji.