Napisz reguły wykrywania

Logika reguły detekcji to SQL, który definiuje, czego szuka. Ta strona wyjaśnia, jak działają reguły, jak wybrać podejście do typowych wzorców wykrywania oraz jak dostosować regułę do odpowiedniego okna danych. Aby poznać kroki UI do tworzenia reguły, zobacz Tworzenie i zarządzanie regułami wykrywania.

Jak działają reguły detekcji

Każda zasada wykrywania w Lakewatch działa według harmonogramu. Gdy reguła się uruchamia, wykonuje SQL detekcji w określonym oknie czasowym i generuje sygnał dla każdego dopasowania. Piszesz pełne zapytanie, włącznie z klauzulą FROM , więc reguła może łączyć tabele, skanować całą tabelę lub obliczać agregaty. Zaplanowana reguła wykrywania działa w udostępnionym przez Ciebie magazynie SQL. Zobacz Skonfiguruj magazyn detekcji.

Ustawiasz harmonogram reguły i określasz sposób przetwarzania podczas jej tworzenia. Zobacz Tworzenie i zarządzanie regułami wykrywania.

Wybór podejścia

Ta tabela mapuje typowe wzorce detekcji na sposób tworzenia każdego z nich:

Ogranicz reguły do zakresu czasu

Kiedy to możliwe, ogranicz regułę do odpowiedniego zakresu czasowego, zamiast skanować całą tabelę. Użyj funkcji IN_TIMERANGE, aby wyrazić to okno, a uruchomienie niech dostarczy granice:

SELECT *
FROM process_activity
WHERE IN_TIMERANGE(<event_time>)
  AND activity_id = 1
  AND endswith(lower(process.name), '\\hashcat.exe')

Zastąp <event_time> kolumną TIMESTAMP lub wyrażeniem służącym do filtrowania.

IN_TIMERANGE(<event_time>) Zwraca true, gdy zdarzenie mieści się w efektywnym przedziale czasowym bieżącego przebiegu. Zakres jest częściowo otwarty: uwzględnia się wydarzenie, którego znacznik czasu odpowiada rozpoczęciu okna, ale takie, które odpowiada końcowi, jest wykluczone. To zapobiega współdzieleniu punktu końcowego między oknami, które się nie pokrywają. Niezerowy extend_lookback celowo powoduje, że kolejne okna nakładają się na siebie. Deduplikacja sygnałów kontroluje powtarzające się sygnały z pasujących wierszy. Nie zapisujesz sam czasu początku i końca w SQL. Zamiast tego Lakewatch podaje zakres na podstawie sposobu działania zapytania:

• W przypadku zaplanowanego uruchomienia okno bazowe zaczyna się od poprzedniego zaplanowanego czasu uruchomienia i kończy się na bieżącym zaplanowanym czasie uruchomienia. To okno nie jest dotknięte opóźnieniami harmonogramu. Aby uwzględnić opóźnienie pobierania, zobacz Wydłuż okno o extend_lookback.
• Na stronie zapytania (którą możesz użyć do opracowania reguły) wybierasz okno za pomocą narzędzia do wyboru daty/godziny. Ponieważ SQL zapisany na stronie zapytania sam w sobie nie zawiera zakresu czasu, może być wdrożony jako reguła detekcji bez zmian.

Rozszerz okno za pomocą extend_lookback

IN_TIMERANGE(<event_time>) filtruje według czasu zdarzenia, ale logi często docierają do tabeli kilka minut po jego wystąpieniu. Wiersz może trafić po zakończeniu uruchomienia, którego okno obejmowało czas zdarzenia, a późniejsze uruchomienia skanują nowsze czasy zdarzeń, tworząc lukę w pokryciu. extend_lookback, opcjonalne ustawienie dla każdej reguły, przesuwa początek okna wcześniej, dzięki czemu każde uruchomienie ponownie skanuje fragment starszego czasu zdarzenia i wychwytuje wiersze, które pojawiły się po ostatnim uruchomieniu. Przesuwa tylko najwcześniejszą granicę. Najnowsze powiązanie pozostaje na bieżącym zaplanowanym czasie wyzwolenia. Ustaw czas trwania na 30s, 10m lub 2h. Okno skanowania zaplanowanej reguły to jej kadencja harmonogramu plus extend_lookback:

Nakładające się przebiegi mogą wybierać ten sam wiersz wielokrotnie. Zachowaj włączoną deduplikację sygnału i wybierz okno deduplikacji, które obejmuje okres, w którym można ponownie wybrać wiersz. Dłuższy okres wsteczny nie wydłuża automatycznie okna deduplikacji. Unikaj dodawania zmieniających się wartości, takich jak CURRENT_TIMESTAMP(), do wyniku SQL wyłącznie dla księgowości, ponieważ zmienione wiersze wyników nie są duplikatami. Zobacz Deduplikacja sygnału.

Jeśli nie ustawisz extend_lookback, Lakewatch stosuje domyślnie 15 minut. Większość źródeł korporacyjnych dociera w ciągu kilku minut, ale niewiele gwarantuje górny limit, więc ustawienie domyślne uwzględnia typowe opóźnione nadejścia bez żadnego strojenia.

Aby ustawić extend_lookback w interfejsie, wpisz czas trwania w Extend lookback, obok SQL detekcji. Użyj wartości dnia, godziny, minuty i sekundy w podanej kolejności, takich jak 15m lub 1h30m. Pozostaw puste, aby użyć domyślnego 15-minutowego terminu, lub wpisz 0s, aby wyłączyć rozszerzenie. To ustawienie nie ma wpływu, chyba że Twój SQL używa IN_TIMERANGE.

Wybierz odpowiednią kolumnę z czasem

Kolumna z czasem zdarzenia w połączeniu z tym extend_lookback to właściwe podejście dla niemal każdej reguły. Oszacuj opóźnienie pozyskiwania danych ze źródła i ustaw extend_lookback, aby je uwzględnić, lub polegaj na domyślnym 15-minutowym ustawieniu dla źródeł, które dostarczają dane szybko.

Jeśli opóźnienie pozyskiwania danych przez źródło jest tak zmienne, że żadne pojedyncze extend_lookback nie pokrywa go wiarygodnie, możesz zamiast tego ustawić regułę na czas pozyskiwania danych. W tabelach generowanych przez źródło danych Lakewatch kolumna lw_meta.ingestion_time rejestruje, kiedy Lakewatch zapisał każdy wiersz po ingestii danych, więc okno zdefiniowane na tej kolumnie nie jest objęte opóźnieniami w dostawie:

WHERE IN_TIMERANGE(lw_meta.ingestion_time)

Sięgnij po to tylko wtedy, gdy event time plus extend_lookback nie wystarczy. Każdy przebieg obejmuje wtedy stały fragment czasu pobierania, a nie czasu zdarzenia, więc znacznik czasu zdarzenia może wykraczać poza nominalne okno czasowe przebiegu, co może zniekształcić agregacje w przedziałach czasowych. Spróbuj najpierw rozwiązać to, używając czasu zdarzenia.

Unikaj kotwiczenia do NOW() lub CURRENT_TIMESTAMP()

Typowy wzorzec określa okno ręcznie względem aktualnego czasu rzeczywistego:

-- Avoid this
WHERE time BETWEEN CURRENT_TIMESTAMP() - INTERVAL 24 HOUR AND CURRENT_TIMESTAMP()

To działa przy rutynowym uruchomieniu, ale może powodować problemy:

• Pominięcie lub podwójne liczenie danych: Okno takie jak "ostatnia godzina" jest zakotwiczone w momencie uruchomienia, a nie do zakresu, który miało obejmować. Jeśli uruchomienie o 3:00 jest opóźnione do 3:12, skanuje 2:12–3:12, zostawia przerwę 2:00–2:12 i może nakładać się na kolejne uruchomienie. IN_TIMERANGE wyznacza okno na podstawie zaplanowanego przedziału, więc opóźniony przebieg nie zostawia luki. Nakładanie się zaplanowanych przebiegów wynika z extend_lookback. Zobacz „Rozszerz okno o extend_lookback”.
• Zmiany harmonogramu: Jeśli zmieniasz regułę z co 15 minut na co 30 minut, zakodowane na stałe INTERVAL 15 MINUTES jest błędne, dopóki nie przypomnisz sobie, żeby je edytować. Z IN_TIMERANGE okno jest zgodne z harmonogramem.
• Ponowne okienkowanie: Uzupełnienie pominiętego okresu, ponowne odtwarzanie po poprawie danych lub podgląd nowej reguły na starszych danych – wszystko to uruchamia tę samą regułę w innym oknie. Zapytanie zablokowane na NOW() nie może tego zrobić bez ręcznych edycji.
• Powtarzalność: Przy tych samych granicach skanuje IN_TIMERANGE te same wiersze przy każdym przebiegu, więc wyniki są powtarzalne. Zapytanie powiązane z NOW() przesuwa się przy każdym wykonaniu.

Zarezerwuj NOW() i CURRENT_TIMESTAMP() na przypadki, gdy musisz odnieść się do rzeczywistego czasu zegara ściennego, na przykład obliczając, jak stare jest dane zdarzenie względem chwili obecnej.

Odwołaj się do okna przebiegu za pomocą TIMERANGE_NOW()

Gdy potrzebujesz wartości „teraz”, która uwzględnia okno uruchomienia, a nie zegar systemowy, użyj TIMERANGE_NOW(). Zwraca zaplanowany czas uruchomienia i wraca do rzeczywistego aktualnego czasu, gdy nie jest ustawione okno (na przykład na stronie zapytania). Użyj go do ręcznego zbudowania okna, którego IN_TIMERANGE nie da się wyrazić, na przykład przesuwając okno lub skanując dwa niesąsiadujące przedziały czasu w jednym przebiegu:

Te predykaty wykorzystują stałe przesunięcia względem TIMERANGE_NOW(). Zmiana harmonogramu nie zmienia ich literałów interwałów. extend_lookback nie poszerza tych ręcznie określonych okien, ponieważ zmienia tylko zarządzaną początkową granicę używaną przez IN_TIMERANGE.

Ta tabela podsumowuje, kiedy używać każdej funkcji: