Escreva regras de deteção

A lógica de uma regra de deteção é o SQL que define o que procura. Esta página explica como as regras funcionam, como escolher uma abordagem para padrões comuns de deteção e como definir uma regra para a janela de dados adequada. Para os passos da interface para criar uma regra, veja Criar e gerir regras de deteção.

Como funcionam as regras de deteção

Todas as regras de deteção no Lakewatch são executadas segundo um agendamento. Quando uma regra é executada, executa o seu SQL de deteção numa janela temporal e gera um sinal para cada correspondência. Escreves a consulta completa, incluindo a FROM cláusula, para que uma regra possa juntar tabelas, analisar uma tabela inteira ou calcular agregados. Uma regra é executada num SQL warehouse que fornece, ou em computação serverless; veja Configurar um warehouse de deteção.

Define o calendário e o cálculo de uma regra ao criá-la. Veja Criar e gerir regras de deteção.

Escolha de uma abordagem

Esta tabela mapeia padrões comuns de deteção para a forma como cria cada um:

Limitar as regras a um intervalo temporal

Sempre que possível, define uma regra para um intervalo de tempo relevante em vez de analisar uma tabela inteira. Utilize a função IN_TIMERANGE() para expressar essa janela e deixe a execução fornecer os limites:

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

IN_TIMERANGE(time) retorna verdadeiro quando um evento ocorre dentro do intervalo de tempo efetivo da execução atual. O intervalo é meio aberto: um evento cujo carimbo temporal é igual ao início da janela é incluído, mas um que seja igual ao fim é excluído, pelo que execuções adjacentes nunca contam duas vezes a fronteira. Não escreves os horários de início e fim no SQL tu próprio. Em vez disso, o Lakewatch fornece o intervalo com base em como a consulta é executada:

• Numa regra de deteção, a janela é derivada do agendamento da regra e termina no momento de ativação da execução. Uma regra que se aplica a cada 15 minutos cobre uma fatia de 15 minutos. Pode alargar essa fatia para extend_lookback incluir registos que chegam tarde.
• Na página de consulta (que pode usar para desenvolver uma regra), seleciona o intervalo usando o seletor de data/hora. Como o SQL escrito na página de consulta não contém o intervalo temporal, pode ser implementado como regra de deteção sem alterações.

Estenda a janela com extend_lookback

IN_TIMERANGE() filtra com base no tempo do evento, mas os registos frequentemente chegam à tabela minutos após o evento ocorrer. Uma linha pode chegar depois de a execução cuja janela cobriu o tempo do seu evento já ter terminado, e as execuções posteriores analisam tempos do evento mais recentes, criando uma lacuna de cobertura. extend_lookback, uma definição opcional por regra, antecipa o início da janela para que cada execução volte a escanear uma fatia do tempo anterior do evento e apanhe os registos que chegaram desde a última execução. Só desloca o limite mais cedo; o limite mais recente mantém-se no momento de ativação da execução. Defina-o para uma duração como 30s, 10m, ou 2h. A janela que uma regra agendada analisa é a sua cadência do agendamento mais extend_lookback:

Se não definires extend_lookback, o Lakewatch aplica o valor predefinido de 15 minutos. A maioria das fontes empresariais entrega em poucos minutos, mas poucas garantem um limite superior, por isso o padrão absorve as chegadas tardias típicas sem qualquer ajuste.

extend_lookback não tem campo de formulário dedicado. Defina-a editando a regra como YAML (ver Criar e gerir regras de deteção) e adicionando um bloco de topo timerange :

timerange:
  extend_lookback: 30m

Escolha a coluna temporal certa

Tempo de evento (time) combinado com extend_lookback é a abordagem correta para quase todas as regras. Estima o atraso de ingestão da tua fonte e define extend_lookback para cobri-lo, ou confia no padrão de 15 minutos para fontes que entregam prontamente.

Se a latência de ingestão de uma fonte for tão variável que nenhuma única extend_lookback a cobre de forma fiável, pode, em vez disso, delimitar a regra com base no tempo de ingestão. Em tabelas produzidas por uma fonte de dados do Lakewatch, a lw_meta.ingestion_time coluna regista quando o Lakewatch escreveu cada linha após a ingestão, pelo que uma janela sobre ela não é afetada por atrasos na entrega:

WHERE IN_TIMERANGE(lw_meta.ingestion_time)

Recorra a isto apenas quando o tempo do evento mais extend_lookback não conseguir fazer o trabalho. Cada execução cobre então uma fatia fixa do tempo de ingestão em vez do tempo do evento, pelo que o carimbo temporal próprio do evento pode ficar fora da janela nominal da execução, o que pode distorcer as agregações agrupadas por intervalos temporais. Tenta primeiro resolvê-lo com event time.

Evite ancorar em NOW() ou CURRENT_TIMESTAMP()

Um padrão comum define manualmente a janela em função da hora atual do relógio de parede:

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

Isto funciona para uma execução rotineira, mas pode criar problemas:

• Pode omitir dados ou contá-los em dobro. Uma janela como "a última hora" está ancorada ao momento em que a execução é executada, não à fatia que deveria cobrir. Se uma execução de 3:00 for atrasada para 3:12, faz varreduras de 2:12–3:12, deixa um intervalo de 2:00–2:12 e pode sobrepor-se à execução seguinte. IN_TIMERANGE() deriva a janela a partir da fatia agendada, eliminando esse risco de lacunas e sobreposição.
• Não se adapta às mudanças de horários. Se mudares uma regra de cada 15 minutos para cada 30 minutos, um INTERVAL 15 MINUTES hardcoded está errado até te lembrares de o editar. Com IN_TIMERANGE(), a janela segue a programação.
• Não pode ser apresentada novamente numa janela. Preencher um período perdido, repetir após uma correção de dados ou pré-visualizar uma nova regra sobre dados mais antigos executam a mesma regra numa janela diferente. Uma consulta bloqueada a NOW() não consegue fazer isso sem edições manuais.
• É mais difícil de reproduzir. Dados os mesmos limites, IN_TIMERANGE() analisa as mesmas linhas em cada execução, por isso os resultados são repetíveis. Uma consulta ligada a NOW() muda em cada execução.

Reserve NOW() e CURRENT_TIMESTAMP() para os casos em que precise de consultar o tempo de relógio real, como calcular a idade de um evento em relação ao momento presente.

Referenciar a janela da execução com TIMERANGE_NOW()

Quando precisar de um valor "agora" que respeite a janela de execução em vez do relógio de parede, use TIMERANGE_NOW(). Retorna o tempo de disparo da execução e volta ao tempo atual real quando não há janela definida (por exemplo, na página de consulta). Use-o para construir manualmente uma janela que IN_TIMERANGE() não consiga expressar, como deslocar a janela ou analisar dois períodos não adjacentes numa única execução:

Esta tabela resume quando usar cada função: