Escrever regras de detecção
Visualização
O Lakewatch está em Prévia privada. Para solicitar acesso, entre em contato com a equipe da sua conta da Databricks.
A lógica de uma regra de detecção é o SQL que define o que ela procura. Esta página explica como as regras estão em execução, como escolher uma abordagem para padrões de detecção comuns e como limitar uma regra à janela de dados correta. Para os passos da IU para criar uma regra, consulte Criar e gerenciar regras de detecção.
Como as regras de detecção são executadas
Todas as regras de detecção no Lakewatch têm execução em programar. Quando uma execução de regra ocorre, ela executa seu SQL de detecção em uma janela de tempo e gera um sinal para cada correspondência. Você escreve a query completa, incluindo a cláusula FROM, para que uma regra possa join tabelas, digitalizar uma tabela inteira ou compute agregados. Uma regra entra em execução em um SQL Warehouse fornecido por você ou em compute Serverless; consulte Configurar um warehouse de detecção.
Você define programar e o compute de uma regra quando a cria. Consulte 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:
Padrão de detecção | Exemplo | Como criá-la |
|---|---|---|
Correspondência de assinatura ou IOC | Um hash de processo em uma lista de conhecidos como maliciosos; uma conexão com um IP sinalizado | Combina eventos com uma lista de valores conhecidos como inválidos |
Sinal atômico | Uma nova account de administrador; um log de auditoria limpo; uma regra de encaminhamento de caixa de correio adicionada | Corresponder a um único evento que é digno de nota |
Limite de janela curta | Mais de 5 logins malsucedidos de um usuário em 1 minuto; um IP com falhas em 20 contas em 10 minutos | Agregar e definir um limite em programar curto |
Linha de base comportamental ou anomalia | Um usuário acessando muito mais servidores do que o normal nos últimos 30 dias | Comparar com uma tabela de base |
Raro ou visto pela primeira vez | Um hash de processo nunca antes visto; uma adição inédita a um grupo privilegiado | Comparar com uma tabela de lista de vistos |
Correlação entre fontes | Login, depois acesso a compartilhamento de arquivos, depois exfiltração, unidos através de origens | Join fontes em uma programar por hora ou menor |
Regras de escopo para um intervalo de tempo
Sempre que possível, limite 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 que a execução forneça 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 true quando um evento está dentro do intervalo de tempo efetivo da execução atual. O intervalo é semiaberto: um evento cujo Timestamp é igual ao começar da janela é incluído, mas um que é igual ao fim é excluído, para que execuções adjacentes nunca façam contagem dupla do limite. Você não grava os horários de começar e término no SQL você mesmo. Em vez disso, o Lakewatch fornece o intervalo com base na execução da query:
- Em uma regra de detecção, a janela é derivada do programar da regra e termina no momento do Trigger da execução. Uma regra que é execução a cada 15 minutos cobre um intervalo de 15 minutos. Você pode ampliar esse intervalo com
extend_lookbackpara incluir logs que chegam com atraso. - Na página de query (que você pode usar para criar uma regra), você seleciona a janela usando o seletor de data/hora. Como o SQL escrito na página da query não contém o intervalo de tempo em si, ele pode ser implantado como uma regra de detecção sem alterações.
Prolongar a janela com extend_lookback
IN_TIMERANGE() filtra por hora do evento, mas os logs geralmente chegam à tabela minutos após a ocorrência do evento. Uma linha pode chegar depois que a execução cuja janela cobria seu horário de evento já tiver terminado, e as execuções posteriores verificam horários de evento mais recentes, criando uma lacuna de cobertura. extend_lookback, uma configuração opcional por regra, move o começar da janela para mais cedo, para que cada execução verifique novamente uma fatia do horário de evento anterior e capture linhas que chegaram desde a última execução. Ele desloca apenas o limite mais antigo; o limite mais recente permanece no horário de execução do job. Defina-o com uma duração como 30s, 10m ou 2h. A janela que uma regra agendada verifica é sua cadência de programar mais extend_lookback:
| Agendamento | Intervalo de tempo verificado (terminando na hora do trigger) |
|---|---|---|
Não definido (default 15 m) | A cada 5 minutos | Os últimos 20 minutos |
| A cada 5 minutos | Os 5 minutos anteriores |
| A cada 30 minutos | Os últimos 42 minutos |
| A cada 10 minutos | As 5 horas e 10 minutos anteriores |
Se você não definir extend_lookback, o Lakewatch aplicará um default de 15 minutos. A maioria das fontes corporativas faz a entrega em poucos minutos, mas poucas garantem um limite superior, por isso o default absorve os atrasos típicos sem qualquer ajuste.
extend_lookback não tem um campo de formulário dedicado. Defina-o editando a regra como YAML (consulte 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 correta
O tempo do evento (time) emparelhado com extend_lookback é a abordagem correta para quase todas as regras. Estime o atraso de ingestão de sua fonte e defina extend_lookback para cobri-lo ou conte com o default 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 cubra de forma confiável, você pode definir o escopo da regra no tempo de ingestão. Nas tabelas produzidas por uma fonte de dados do Lakewatch, a coluna lw_meta.ingestion_time registra quando o Lakewatch escreveu cada linha após a ingestão, de modo que uma janela sobre ela não seja afetada por atrasos na entrega:
WHERE IN_TIMERANGE(lw_meta.ingestion_time)
Use isso apenas quando o tempo do evento mais extend_lookback não puder fazer o Job. Cada execução cobre uma fatia fixa do tempo de ingestão em vez do tempo do evento , de modo que o timestamp de um evento pode cair fora da janela nominal da execução, o que pode distorcer as agregações em intervalos de tempo. Tente resolvê-lo com o tempo do evento primeiro.
Evite ancorar em NOW() ou CURRENT_TIMESTAMP()
Um padrão comum escreve manualmente a janela em relação ao tempo real atual:
-- 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 duplicadamente os dados. Uma janela como "a última hora" é ancorada ao momento em que a execução é disparada, não ao setor que deveria cobrir. Se uma execução das 3:00 for atrasada para as 3:12, ela digitalizará as 2:12–3:12, deixará uma lacuna entre 2:00–2:12 e poderá se sobrepor à próxima execução.
IN_TIMERANGE()deriva a janela do setor agendado, eliminando esse risco de lacuna e sobreposição. - Não se adapta a mudanças no programar. Se você alterar uma regra de cada 15 minutos para cada 30 minutos, um
INTERVAL 15 MINUTEScodificado estará incorreto até que você se lembre de editá-lo. ComIN_TIMERANGE(), a janela segue programar. - Ela não pode ser rejanelada. O preenchimento retroativo de um período perdido, a reprodução após uma correção de dados ou a visualização de uma nova regra em relação a dados mais antigos fazem a execução da mesma regra em uma janela diferente. Uma query bloqueada em
NOW()não pode fazer isso sem edições manuais. - É mais difícil de reproduzir. Dados os mesmos limites, o
IN_TIMERANGE()verifica as mesmas linhas em cada execução, portanto os resultados são repetíveis. Uma query vinculada aNOW()muda a cada execução.
Reserve NOW() e CURRENT_TIMESTAMP() para casos em que você precisa fazer referência ao tempo real do relógio de parede, como calcular a idade de um evento em relação ao momento presente.
Referencie a janela da execução com TIMERANGE_NOW()
Quando precisar de um valor de “agora” que respeite a janela da execução em vez do relógio, use TIMERANGE_NOW(). Ele retorna o momento do Trigger da execução e retorna ao momento atual real quando nenhuma janela é definida (por exemplo, na página de query). Use-o para criar manualmente uma janela que IN_TIMERANGE() não consegue expressar, como compensar a janela ou verificar dois períodos não adjacentes em uma única execução:
Agendamento | Predicado | Resultado |
|---|---|---|
A cada 10 minutos |
| Desloca a janela de 10 minutos em 7 minutos para o passado |
Todos os dias |
| Corresponde a eventos de hoje e do mesmo dia da semana passada |
Esta tabela resume quando usar cada função:
Objetivo | Uso |
|---|---|
Defina o escopo de uma regra para seu intervalo de tempo |
|
Referência "agora" que respeita a janela de execução |
|