Crea regole di rilevamento

Importante

Lakewatch è in anteprima privata. Per richiedere l'accesso, contatta il team del tuo account Azure Databricks.

La logica di una regola di rilevamento è l'SQL che definisce ciò che cerca. Questa pagina spiega come funzionano le regole, come scegliere un approccio per i pattern di rilevamento comuni e come limitare una regola alla corretta finestra di dati. Per i passaggi dell'interfaccia utente per creare una regola, vedi Crea e gestisci regole di rilevamento.

Come funzionano le regole di rilevamento

Ogni regola di rilevamento in Lakewatch viene eseguita secondo una pianificazione. Quando una regola viene eseguita, esegue il tuo SQL di rilevamento in una finestra temporale e genera un segnale per ogni corrispondenza. Scrivi la query completa, inclusa la FROM clausola, così una regola può unire tabelle, scansionare un'intera tabella o calcolare aggregati. Una regola gira su un SQL warehouse che fornisci, oppure su calcolo serverless; vedi Configura un warehouse di rilevamento.

Impostate il programma di una regola e il calcolo quando la create. Vedi Crea e gestisci regole di rilevamento.

Scelta di un approccio

Questa tabella associa i modelli di rilevamento comuni al modo in cui crei ciascuno di essi:

Schema di rilevamento	Example	Come crearlo
Corrispondenza della firma o dell’IOC	Un hash di processo in una lista di hash malevoli noti; una connessione a un IP segnalato	Confronta gli eventi con una lista di valori noti come dannosi
Segnale atomico	Un nuovo account amministrativo; un registro di audit cancellato; una regola di inoltro della casella aggiunta	Abbina un singolo evento che sia di per sé degno di nota
Soglia finestra breve	Più di 5 accessi falliti per un utente in 1 minuto; un IP con 20 account con accesso non riuscito in 10 minuti	Aggrega e applica una soglia con una pianificazione breve
Baseline comportamentale o anomalia	Un utente che accede a molti più server rispetto alla sua norma di 30 giorni	Confronta con una tabella di riferimento
Rari o mai visti prima	Un hash di processo mai visto prima; una prima aggiunta a un gruppo privilegiato	Confronta con una tabella seen-list
Correlazione tra sorgenti	Login, poi accesso alla condivisione file, poi esfiltrazione, correlati tra più fonti	Esegui join tra diverse fonti con una pianificazione ogni ora o più frequente

Limitare le regole a un intervallo di tempo

Quando possibile, limita una regola a un intervallo temporale rilevante invece di scansionare un'intera tabella. Usa la funzione IN_TIMERANGE() per esprimere quella finestra e lascia che l’esecuzione fornisca i limiti:

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

IN_TIMERANGE(time) ritorna vero quando un evento rientra nell'intervallo temporale effettivo della run corrente. L'intervallo è mezzo aperto: un evento il cui timestamp è uguale all'inizio della finestra è incluso, ma uno che corrisponde alla fine è escluso, quindi le esecuzioni adiacenti non contano mai due volte il confine. Non scrivi tu stesso gli orari di inizio e fine nel codice SQL. Invece, Lakewatch fornisce l'intervallo basato su come viene eseguita la query:

• In una regola di rilevamento, la finestra deriva dalla pianificazione della regola e termina al momento di attivazione dell'esecuzione. Una regola che si ripete ogni 15 minuti copre una fetta di 15 minuti. Puoi allargare quella fetta con extend_lookback includendo i log in ritardo.
• Nella pagina delle query (che puoi usare per sviluppare una regola), selezioni la finestra usando il selezionatore data/ora. Poiché SQL scritto nella pagina di query non contiene esso stesso l'intervallo di tempo, può essere implementato come regola di rilevamento senza variazioni.

Estendi la finestra con extend_lookback

IN_TIMERANGE() filtrano in base all'orario dell'evento, ma i log spesso raggiungono la tabella pochi minuti dopo l'evento. Una fila può atterrare dopo che la run la cui finestra copriva il tempo dell'evento è già terminata, e le run successive scansionano tempi dell'evento più recenti, creando un gap di copertura. extend_lookback, un'impostazione opzionale per regola, anticipa l'inizio della finestra così che ogni run ri-scansioni una fetta dell'intervallo temporale di eventi meno recenti e catturi le righe arrivate dall'ultima esecuzione. Sposta solo il limite iniziale; il limite finale rimane all'orario di innesco della corsa. Impostalo a una durata come 30s, 10m, o 2h. La finestra che una regola programmata scansiona è la sua cadenza di programmazione più extend_lookback:

extend_lookback	Schedule	Intervallo di tempo scansionato (che termina al momento di innesco)
Non impostato (predefinito 15m)	Ogni 5 minuti	Negli ultimi 20 minuti
0s	Ogni 5 minuti	I 5 minuti precedenti
12m	Ogni 30 minuti	I 42 minuti precedenti
5h	Ogni 10 minuti	Le ultime 5 ore e 10 minuti

Se non imposti extend_lookback, Lakewatch applica un default di 15 minuti. La maggior parte delle fonti aziendali consegna in pochi minuti, ma pochi garantiscono un limite superiore, quindi l'impostazione predefinita assorbe i tipici ritardi senza alcuna regolazione.

extend_lookback non dispone di un campo del modulo dedicato. Impostalo modificando la regola come YAML ( vedi Crea e gestisci regole di rilevamento) e aggiungendo un blocco timerange di primo livello:

timerange:
  extend_lookback: 30m

Scegli la colonna temporale giusta

Il tempo dell'evento (time) abbinato a extend_lookback è l'approccio giusto per quasi tutte le regole. Stima il ritardo di ingestione della tua fonte e imposta extend_lookback per coprirlo, oppure affidati al predefinito di 15 minuti per le fonti che consegnano puntualmente.

Se la latenza di ingestione di una sorgente è così variabile che nessun singolo extend_lookback lo copre in modo affidabile, puoi invece applicare la regola sul tempo di ingestione. Su tabelle prodotte da una sorgente dati di Lakewatch, la lw_meta.ingestion_time colonna registra quando Lakewatch ha scritto ogni riga dopo l'ingestione, quindi una finestra sopra di essa non è influenzata dai ritardi di consegna:

WHERE IN_TIMERANGE(lw_meta.ingestion_time)

Ricorri a questo solo quando il tempo dell'evento più extend_lookback non basta. Ogni run copre quindi una fetta fissa del tempo di ingestione piuttosto che del tempo dell'evento, quindi il timestamp di un evento può trovarsi al di fuori della finestra nominale della run, il che può sbilanciare le aggregazioni time-bucket. Prova prima a risolverlo con l'ora evento.

Evitare di ancorare a NOW() o CURRENT_TIMESTAMP()

Uno schema comune imposta manualmente la finestra rispetto all'ora corrente:

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

Questo funziona per un'esecuzione di routine, ma può creare problemi:

• Può non rilevare o contare due volte i dati. Una finestra come "l'ultima ora" è ancorata al momento in cui l'esecuzione viene avviata, non all'intervallo che doveva coprire. Se una corsa delle 3:00 viene ritardata a 3:12, scansiona 2:12–3:12, lascia un intervallo di 2:00–2:12 e può sovrapporsi alla corsa successiva. IN_TIMERANGE() deriva la finestra dalla slice programmata, eliminando quel rischio di gap e sovrapposizione.
• Non si adatta ai cambiamenti di programma. Se cambi una regola da ogni 15 minuti a ogni 30 minuti, un valore hardcoded INTERVAL 15 MINUTES è sbagliato finché non ti ricordi di modificarlo. Con IN_TIMERANGE(), la finestra segue la pianificazione.
• Non può essere riaperto in una finestra. Ricostruire un periodo mancante, rieseguire dopo una correzione dei dati o visualizzare un nuova regola su dati precedenti eseguono la stessa regola su una finestra diversa. Una query bloccata su NOW() non può farlo senza modifiche manuali.
• È più difficile da riprodurre. Dati gli stessi limiti, IN_TIMERANGE() scansiona le stesse righe ad ogni esecuzione, quindi i risultati sono ripetibili. Una query legata a NOW() cambia con ogni esecuzione.

Riserva NOW() e CURRENT_TIMESTAMP() per i casi in cui devi fare riferimento al tempo di clock reale, ad esempio per calcolare da quanto tempo si è verificato un evento rispetto al momento presente.

Fai riferimento alla finestra dell'esecuzione con TIMERANGE_NOW()

Quando ti serve un valore "ora" che rispetti la finestra dell'esecuzione invece dell'orologio a muro, usa TIMERANGE_NOW(). Restituisce l'ora di attivazione dell'esecuzione e torna all'ora attuale effettiva quando non è impostata alcuna finestra (ad esempio, nella pagina della query). Usalo per costruire a mano una finestra che IN_TIMERANGE() non può esprimere, ad esempio spostando la finestra o scansionando due periodi non adiacenti in una singola esecuzione:

Schedule	Predicato	Result
Ogni 10 minuti	time > TIMERANGE_NOW() - INTERVAL 17 MINUTE AND time < TIMERANGE_NOW() - INTERVAL 7 MINUTE	Sposta la finestra di 10 minuti di 7 minuti nel passato
Ogni giorno.	(time > TIMERANGE_NOW() - INTERVAL 1 DAY AND time < TIMERANGE_NOW()) OR (time > TIMERANGE_NOW() - INTERVAL 8 DAY AND time < TIMERANGE_NOW() - INTERVAL 7 DAY)	Corrisponde agli eventi di oggi e dello stesso giorno della scorsa settimana

Questa tabella riassume quando utilizzare ciascuna funzione:

Obiettivo	Utilizza
Applica una regola alla finestra temporale	IN_TIMERANGE(time)
Fai riferimento a "ora" che rispetti la finestra dell'esecuzione	TIMERANGE_NOW()