Escreva regras de detecção

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

Como funcionam as regras de detecção

Toda regra de detecção no Lakewatch é executada de acordo com um agendamento. Quando uma regra é executada, ela executa seu SQL de detecção em uma janela de tempo e gera um sinal para cada correspondência. Você escreve a consulta completa, incluindo a FROM cláusula, para que uma regra possa juntar tabelas, escanear uma tabela inteira ou calcular agregados. Uma regra roda em um SQL warehouse que você fornece, ou em computação serverless; veja Configurar um warehouse de detecção.

Você define o cronograma e o cálculo de uma regra ao criá-la. Veja Criar e gerenciar regras de detecção.

Escolhendo uma abordagem

Esta tabela mapeia padrões comuns de detecção para como você cria cada um:

Limitar o escopo a um intervalo de tempo

Sempre que possível, restrinja uma regra a um intervalo de tempo relevante em vez de varrer uma tabela inteira. Use a função IN_TIMERANGE() para expressar essa janela e deixe a sequência informar 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 de tempo é igual ao início da janela é incluído, mas um que seja igual ao fim é excluído, então sequências adjacentes nunca contam duas vezes a fronteira. Você mesmo não escreve os horários de início e fim na instrução SQL. Em vez disso, o Lakewatch fornece o intervalo com base em como a consulta é executada:

• Em uma regra de detecção, a janela é derivada do cronograma da regra e termina no momento de disparo da execução. Uma regra que é executada a cada 15 minutos cobre uma fatia de 15 minutos. Você pode ampliar essa fatia com extend_lookback para incluir logs que chegam tarde.
• Na página de consulta (que você pode usar para desenvolver uma regra), você seleciona o intervalo usando o seletor de data/hora. Como o SQL escrito na página de consulta não contém o intervalo de tempo, ele pode ser implantado como uma regra de detecção sem alterações.

Estenda a janela com extend_lookback

IN_TIMERANGE() filtra por tempo do evento, mas os logs frequentemente chegam à tabela minutos depois que ele ocorrer. Uma linha pode chegar depois que a execução cuja janela cobria o tempo do seu evento já tiver terminado, e execuções posteriores examinam tempos de evento mais recentes, criando uma lacuna de cobertura. extend_lookback, uma configuração opcional por regra, antecipa o início da janela para que cada execução faça uma nova varredura de um intervalo de tempo de eventos anteriores e capture as linhas que chegaram desde a última execução. Ele desloca apenas o limite mais antigo; o limite mais recente permanece no horário de acionamento da execução. Defina para uma duração como 30s, 10m, ou 2h. A janela que uma regra agendada analisa é sua frequência de agendamento mais extend_lookback:

Se você não definir extend_lookback, o Lakewatch usa o valor padrão de 15 minutos. A maioria das fontes empresariais entrega em poucos minutos, mas poucas garantem um limite superior, então o padrão absorve as chegadas atrasadas típicas sem qualquer ajuste.

extend_lookback não possui campo de formulário dedicado. Configure isso editando a regra como YAML (veja Criar e gerenciar regras de detecção) e adicionando um bloco timerange de nível superior:

timerange:
  extend_lookback: 30m

Escolha a coluna de tempo certa

Tempo de evento (time) combinado com extend_lookback é a abordagem correta para quase todas as regras. Estime o atraso de ingestão da sua fonte e defina extend_lookback para cobri-lo, ou confie 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 nenhum extend_lookback único a cobre de maneira confiável, você pode aplicar 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 registra quando o Lakewatch escreveu cada linha após a ingestão, então uma janela sobre ela não é afetada por atrasos na entrega:

WHERE IN_TIMERANGE(lw_meta.ingestion_time)

Procure isso apenas quando o tempo do evento mais extend_lookback não for suficiente. Cada execução então cobre uma fatia fixa do tempo de ingestão em vez do tempo do evento , então o carimbo de tempo próprio de um evento pode ficar fora da janela nominal da execução, o que pode desequilibrar agregações por intervalos de tempo. Tente resolver isso primeiro com o tempo do evento.

Evite ancorar em NOW() ou CURRENT_TIMESTAMP()

Um padrão comum define manualmente a janela em relação à hora atual do sistema:

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

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

• Pode perder ou contar dados duas vezes. Uma janela como "a última hora" está ancorada ao momento em que a execução dispara, não ao intervalo que ela deveria cobrir. Se uma execução de 3:00 for atrasada para 3:12, ela escaneia 2:12–3:12, deixa um intervalo de 2:00–2:12 e pode se sobrepor à próxima execução. IN_TIMERANGE() deriva a janela a partir da fatia programada, eliminando esse risco de lacunas e sobreposições.
• Ela não se adapta às mudanças de horário. Se você mudar uma regra de cada 15 minutos para a cada 30 minutos, um INTERVAL 15 MINUTES codificado ficará errado até você lembrar de editar. Com IN_TIMERANGE(), a janela segue o cronograma.
• Não pode voltar ao modo em janela. Preencher um período perdido, reproduzir após uma correção de dados ou visualizar uma nova regra com base em dados antigos executam a mesma regra em uma janela diferente. Uma consulta bloqueada em NOW() não pode fazer isso sem edições manuais.
• É mais difícil de reproduzir. Com os mesmos limites, IN_TIMERANGE() escaneia as mesmas linhas em cada execução, então os resultados são repetíveis. Uma consulta vinculada a NOW() muda a cada execução.

Reserve NOW() e CURRENT_TIMESTAMP() para casos em que você precise fazer referência ao tempo de relógio, como calcular a idade de um evento em relação ao momento presente.

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

Quando você precisar de um valor "agora" que respeite a janela da execução em vez do relógio de parede, use TIMERANGE_NOW(). Ele retorna o tempo de disparo da execução e recorre ao horário atual real quando nenhuma janela está definida (por exemplo, na página de consulta). Use isso para criar manualmente uma janela que IN_TIMERANGE() não consegue representar, como deslocar a janela ou fazer a varredura de dois períodos não adjacentes em uma única execução:

Esta tabela resume quando usar cada função: