Zyski:
- Dowiedz się, jak polowanie na zagrożenia rozpoczyna się od testowalnej hipotezy, a nie od alarmu, oraz w jaki sposób sztuczna inteligencja pomaga w generowaniu hipotez i opracowywaniu zapytań.
- Umiejętność zastosowania, że przeciwny/rzadki sygnał podkreślony przez sztuczną inteligencję nie oznacza automatycznie złośliwych zamiarów i że hipotezę należy potwierdzić surowymi dowodami.
- Możliwość weryfikacji numerów technicznych i identyfikatorów zdarzeń MITER ATT&CK nadawanych przez sztuczną inteligencję z oficjalnym źródłem i wyeliminowania sfabrykowanych szczegółów technicznych
Klasyczny monitoring bezpieczeństwa działa zgodnie z logiką „czekaj na alarm, patrz, kiedy nadejdzie”. Jednak najniebezpieczniejsi napastnicy starają się nie wzbudzać alarmu: korzystają z legalnych narzędzi (nazywa się to „exploitowaniem” — czyli nadużywaniem narzędzi już istniejących w systemie, takich jak PowerShell czy WMI), działają powoli i zakłócają normalny ruch. Dlatego właśnie narodziło się polowanie na zagrożenia: bez czekania na alarm, „gdyby w mojej organizacji znajdował się aktualnie niewykryty napastnik, gdzie by on był?” Proaktywne poszukiwanie śladów za pomocą pytania: Polowanie na zagrożenia zaczyna się od hipotezy, a nie od alarmu.
Sztuczna inteligencja jest bardzo przydatna w dwóch miejscach podczas polowania na zagrożenia. Pierwsza to generowanie hipotez: podaj technikę ataku i zadaj pytanie: „Gdyby ta technika została zastosowana w mojej instytucji, na jakich logach i według jakiego wzoru pozostawiłaby ślad?” możesz zapytać. Drugi to ekstrakcja sygnału: może uwydatnić rzadkie, odstające, „inne od normalnych” dane w dużych zbiorach danych. Jednak sztuczna inteligencja nie wie, co jest normalne w Twojej organizacji, i może wpaść w pułapkę myślenia, że hipoteza jest „udowodniona”. W polowaniu na zagrożenia sztuczna inteligencja jest partnerem umysłowym i skanerem; Myśliwy (analityk) decyduje, czy ofiara znajdzie realne zagrożenie i czy zostanie to zgłoszone.
Etapy polowania na zagrożenia
- Hipoteza. Konkretne, możliwe do przetestowania zdanie: „Napastnik może skanować sieć wewnętrzną poza godzinami pracy, korzystając z przejętego konta”. Tutaj możesz wykorzystać sztuczną inteligencję do burzy mózgów.
- Zidentyfikuj źródło danych. Który log potwierdza/obala hipotezę? (Na przykład dzienniki zapory sieciowej i DNS dotyczące skanowania sieci, dzienniki tożsamości dotyczące eskalacji uprawnień).
- Zaprojektuj zapytanie. Zapytanie, które będzie szukać docelowego wzorca (język zapytań SIEM, KQL, podobny do SQL). AI pomaga w tworzeniu zapytań; ale przeglądasz zapytanie i uruchamiasz je.
- Wyodrębnij wynik. Filtruj rzeczywisty sygnał z setek linii wyjściowych. Tutaj sztuczna inteligencja dokonuje grupowania i podsumowywania.
- Potwierdź lub zaprzecz. Potwierdź na podstawie surowych dowodów i kontekstu, czy znaleziony ślad jest naprawdę złośliwy, czy nie.
- Udokumentuj wynik i przekształć go w ustalenie. Konwertuj znaleziony wzorzec na trwałą regułę wykrywania; Jeśli hipoteza nie powiodła się, zapisz to również (wynik negatywny jest również informacją).
Terminy: TTP (Taktyka, Technika, Procedury — wzorzec zachowania atakującego). MITER ATT&CK to wyliczona i udokumentowana biblioteka technik atakujących (np. T1078 „Valid Accounts”); Zapewnia wspólny język w polowaniu na zagrożenia. IOC (wskaźnik naruszenia — zły adres IP, skrót, domena). Biały szum (biała lista/znane dobro) to normalne zachowanie, o którym wiadomo, że składa ofiarę.
Tabela podejść do polowania na zagrożenia
Podejście
punkt wyjścia
Wkład sztucznej inteligencji
Uwaga
Polowanie oparte na hipotezach
„Gdyby był taki napastnik…”
Generacja hipotez, opis wzorca
Hipoteza nie jest dowodem
Polowanie w oparciu o MKOl
Znany zły wskaźnik
Dopasowywanie IOC do logów
Stare/nieprawidłowe MKOl wprowadza w błąd
Polowanie w oparciu o TTP/ATT&CK
Technika (liczba T)
Konwersja techniki na wzór dziennika
Technika ≠ pojedynczy wzór
Polowanie na podstawie anomalii
Odchylenie statystyczne
Podkreśl wartość odstającą
Sprzeczny ≠ zła wiara
Analiza częstotliwości stosu
„Co jest najrzadsze?”
Znalezienie rzadkiego zdarzenia
Rzadko ≠ niebezpieczne
trzy mini etui
Przypadek 1 — Znajdowanie rzadkości. Łowca może zapytać: „Który proces w sieci wewnętrznej działa na najmniejszej liczbie komputerów, ale ustanawia najwięcej połączeń sieciowych?” stawia swoją hipotezę. Sztuczna inteligencja podkreśla wzór na podstawie zanonimizowanych danych połączenia procesowego: proces o nazwie svchost32.exe, widoczny tylko na 2 komputerach, łączy się z 340 różnymi adresami zewnętrznymi. Myśliwy to bada; Znajduje złośliwe oprogramowanie imitujące legalny plik svchost.exe. AI odfiltrowała rzadkie; Myśliwy postawił diagnozę i podjął interwencję.
Przypadek 2 — Nieudane (ale wartościowe) polowanie. Jeden z myśliwych zapytał „czy może mieć miejsce masowe pobieranie danych poza godzinami pracy?” ustala swoją hipotezę; AI pisze odpowiedni projekt zapytania. Wynik: 3 użytkowników pobrało w nocy, ale wszyscy trzej to pracownicy biurowi za granicą i pracują w godzinach pracy ze względu na różnicę stref czasowych. Hipoteza zostaje odrzucona. Myśliwy dokumentuje to jako „wynik negatywny” i odnotowuje tych 3 użytkowników jako wyjątki dla przyszłych polowań. Nawet nieudane polowanie pozwoliło nam lepiej poznać instytucję.
Przypadek 3 — Wymyślona pułapka techniczna. Myśliwy pyta AI: „Jak szukać techniki T1055 w mojej organizacji?” mówi. AI pisze przekonujące zapytanie i stwierdzenie, że „T1055 generuje następujący identyfikator zdarzenia”; ale podany przez niego identyfikator zdarzenia jest błędny, a model stanowi podtechnikę ATT&CK. Avcı otwiera rekord MITER ATT&CK, potwierdza opis techniczny i rzeczywiste źródła dziennika oraz poprawia nieprawidłowy identyfikator zdarzenia. Lekcja: Sprawdź każdy szczegół techniczny podany przez sztuczną inteligencję (identyfikator zdarzenia, numer T, pole dziennika) w oficjalnym źródle.
Słaba zachęta/silna zachęta
Słaba zachęta:
Dowiedz się, czy w mojej sieci znajduje się osoba atakująca.
To twierdzenie jest wolne od hipotez, wolne od danych, nieograniczone i nieweryfikowalne. AI tworzy listę ogólną lub wymyśloną; to jest bezużyteczne.
Potężny monit:
Twoja rola: asystent, który przekazuje pomysły i zarysy łowcy zagrożeń. Nie decyduj, nie mów „istnieje zagrożenie”. Moja hipoteza: „Zaatakowane konto może skanować porty wewnętrzne poza godzinami pracy”. Wygeneruj następujące elementy: (1) wypisz źródła logów, które potwierdzą i rozwieją tę hipotezę, (2) opisz konkretny wzorzec do przeszukania (które pola, jakie progi), (3) napisz wersję roboczą przykładowego zapytania i skomentuj każdą linię, (4) zapisz, które niewinne wyjaśnienia zostaną wyeliminowane w wynikowym wyniku. Zaproponuj odpowiednią technikę MITER ATT&CK, ale zaznacz numer T i identyfikator zdarzenia jako „[należy zweryfikować z MITER]”, nie wymyślaj tego.
Silne twierdzenie zaczyna się od konkretnej hipotezy, ustala równowagę dowodów/obaleń, wyjaśnia pytanie i pozostawia szczegóły techniczne do weryfikacji.
Kopiowalne szablony podpowiedzi
SZABLON GENEROWANIA HIPOTEZ Dla mojej instytucji [podmiot: m.in. Generuj testowalne hipotezy dotyczące polowania na zagrożenia w kontekście [Active Directory / chmura / punkt końcowy]5. Dla każdej hipotezy: (1) jakie zachowanie atakującego jest celem, (2) które źródło dziennika dostarczy dowodów/obalenia, (3) oczekiwany wzorzec. Twórz zdania sprawdzalne, a nie ogólne.
WZÓR TECHNIKI WZÓR Poszukam następującej techniki ataku w mojej instytucji [nazwa techniki]. Wygeneruj: (1) obszary dziennika, w których technika zazwyczaj pozostawia swój ślad, (2) konkretne wzorce i progi, których należy szukać, (3) niewinne (fałszywie pozytywne) sytuacje, które mogą wyzwolić ten wzorzec. Zaoferuj odpowiedni numer T MITRE ATT&CK, ale z flagą „[Musi zostać zweryfikowany przez MITRE]”; nie podawaj sfabrykowanego identyfikatora/numeru wydarzenia.
SZABLON PROJEKTU ZAPYTANIA Napisz wersję roboczą zapytania [SIEM/KQL/SQL], która będzie szukać następującego wzorca: [opis wzorca]. Skomentuj każdą linię, wyjaśnij, które pole filtrujesz i dlaczego oraz oznacz ryzyko związane z wydajnością. Przejrzę zapytanie i uruchomię je; nie zakładaj, że to uruchomisz. Pozostaw nazwy pól oznaczone „[poprawne do schematu]” zgodnie ze znanym mi schematem.
SZABLON ELIMINOWANIA WYNIKÓW Wynik mojego polowania dał następujące linie (anonimowe): [wklej]. Pogrupuj je i dla każdej grupy napisz (1) złośliwy scenariusz, (2) co najmniej 2 niewinne wyjaśnienia oraz (3) dodatkowe dowody, których należy szukać w celu rozróżnienia. Podejmowanie decyzji; Nie pozwól mi was rozdzielić. Zaznacz „[brak podstawy]” w przypadku twierdzenia, które nie ma dowodów.
Typowe błędy
- Polowanie bez hipotez. Powiedzenie „znajdź coś” zmusza sztuczną inteligencję do odgadnięcia i zmyślenia; Polowanie zaczyna się od konkretnego, sprawdzalnego wyroku.
- Mylenie hipotezy z dowodem. Polowanie testuje możliwość; Znaleziony ślad nie stanowi „zagrożenia”, dopóki nie zostanie potwierdzony surowymi dowodami.
- Automatyczne uznanie czegoś przeciwnego za złe. Rzecz rzadka/odstająca często jest niewinna (konserwacja, nowe oprogramowanie, jednorazowe zlecenie); Przesiać z kontekstem.
- Nie sprawdzam szczegółów technicznych. AI może dopasować identyfikator zdarzenia, numer T i pole dziennika; Potwierdź za pomocą MITER ATT&CK i dokumentacji produktu.
- Wyrzucanie zmarnowanego połowu. Negatywny wynik to także wiedza: lepiej poznaje organizację, ograniczając przyszłe fałszywe alarmy; dokument.
Wskazówka: dobra hipoteza dotycząca polowania na zagrożenia powinna być „testowalna”: konkretne twierdzenie, które może okazać się prawdziwe lub fałszywe. „Czy w mojej sieci dzieje się coś złego?” nie można przetestować; „Czy konto X łączyło się z ponad 50 wewnętrznymi adresami IP poza godzinami pracy?” można przetestować.
Uwaga: Wyszukiwanie zagrożeń odbywa się wyłącznie w systemach, do których masz uprawnienia. Proszenie sztucznej inteligencji o „sondowanie” innej organizacji, osoby lub sieci, do której nie masz uprawnień, jest próbą uzyskania nieautoryzowanego dostępu i wykracza poza ten moduł.
Podsumowując
Polowanie na zagrożenia polega na proaktywnym poszukiwaniu śladów ukrytego napastnika bez czekania na alarm i zaczyna się od hipotezy, a nie od alarmu. Sztuczna inteligencja oferuje dwa potężne wkłady w ten proces: generowanie testowalnych hipotez i wersji roboczych zapytań oraz filtrowanie rzadkich/odstających sygnałów z dużych zbiorów danych. Ale sztuczna inteligencja nie wie, co jest normalne w Twojej organizacji, może domyślać się szczegółów technicznych i wpaść w pułapkę pomylenia hipotezy z dowodem. Zatem polowanie składa się z sześciu etapów (hipoteza, dane, zapytanie, wyodrębnienie, weryfikacja, udokumentowanie) i na każdym etapie decyzja należy do myśliwego. Sprzeczny ≠ zły, hipoteza ≠ dowód, szczegóły techniczne podane przez sztuczną inteligencję ≠ poprawne; wszystko potwierdzone surowymi dowodami i MITRE ATT&CK.
Zadanie aplikacji
Uzyskaj 5 hipotez dotyczących polowań na zagrożenia od sztucznej inteligencji za pomocą szablonu „Generowanie hipotez” dla własnej organizacji (lub przykładowego środowiska). Wybierz najbardziej testowalne, przygotuj zapytanie za pomocą szablonów „Technika wzorca” i „Draft zapytania”, zweryfikuj każdy wiersz zapytania i każdy sugerowany numer T w MITER ATT&CK. Zapisz wynik (czy hipoteza została potwierdzona, obalona, czego się dowiedziałeś) w krótkiej notatce z polowania.
lista kontrolna
- [ ] Zacząłem polowanie od konkretnej, sprawdzalnej hipotezy.
- [ ] Zidentyfikowałem źródła dzienników, które zarówno potwierdzają, jak i obalają tę hipotezę.
- [ ] Sprawdziłem każdą linię wersji roboczej zapytania i dostosowałem ją do własnego schematu.
- [ ] Sprawdziłem proponowaną technikę MITRE ATT&CK i identyfikatory zdarzeń w oficjalnym źródle.
- [ ] Potwierdziłem każdy sygnał surowymi dowodami i kontekstem; Nie uważałem automatycznie czegoś przeciwnego za złe.
- [ ] Udokumentowałem także hipotezę, która się nie powiodła (wynik negatywny jest informacją).
- [ ] Polowałem wyłącznie na systemach, do których polowania miałem uprawnienia.