Criar e gerenciar regras de detecção

info

Visualização

O Lakewatch está em visualização privada. Para solicitar acesso, entre em contato com a equipe da sua account Databricks.

As regras de detecção são filtros em execução em suas tabelas para identificar anomalias e possíveis ameaças à segurança. As regras geralmente consomem dados das tabelas analisadas escritas por suas fontes de dados, mas podem ser executadas em qualquer tabela que você possa query. As regras identificam sinais com base nos critérios especificados.

Esta página aborda como criar, view, atualizar e gerenciar regras de detecção na interface do usuário.

Crie e gerencie regras de detecção na IU

Esta página aborda a configuração e implantação de regras de detecção na IU. Você configurará os parâmetros de execução da regra, programar, os recursos de compute e as configurações de geração de sinal.

Antes de começar

Pré-requisitos : Você já deve ter projetado sua lógica de detecção. Esta página configura como essa lógica é executada em produção.

Fluxo de trabalho : Após concluir este formulário, o Lakewatch agenda e execução sua regra de detecção de acordo com suas configurações. As correspondências geram sinais, que o Lakewatch agrupa em alertas que aparecem no painel lateral de alertas para revisão do analista. Você também pode query sinais diretamente na signals tabela de sistema no Unity Catalog.

Como posso criar regras de detecção?

Vá para Regras de detecção e clique em Criar regra de detecção . O formulário inclui configuração de SQL e query, com configurações organizadas em tab:

• Execução : programar, estado ativo, supressão de alerta e principal de execução como.
• Sinais : Resumo da saída, campos de contexto e desduplicação.
• MITRE ATT&CK (opcional): Mapeie a detecção para o framework MITRE ATT&CK.
• Detalhes : Metadados da classificação (severidade, categoria, fidelidade, objetivo).

Esses controles de cabeçalho se aplicam em toda a extensão:

• Criar com Genie : Abre um painel lateral acoplado onde o Genie (um assistente de AI) ajuda você a escrever e refinar a lógica de detecção. Slogan do Genie: "Crie, revise e refine regras de detecção com um parceiro de AI."
• Editar como YAML : Alterne entre o formulário e a edição da regra como YAML; os dois permanecem sincronizados. Consulte Editar uma regra como YAML.
• Ativo (alternar): Se a regra está habilitada e é execução em seu programar.
• Editar supressão de alerta (botão): Quando a supressão está ativada, uma regra ativa ainda está em execução e produz sinais, mas esses sinais não abrem alertas. Defina uma data e hora até para quando a supressão termina (obrigatório). As horas usam o seu fuso horário local e são armazenadas como UTC.

Configuração da regra

Dê um nome à regra, defina sua lógica de detecção e selecione seu warehouse de compute:

• Nome da regra (obrigatório): insira um nome para a regra. Não pode ser alterado após a criação.
• SQL de detecção (obrigatório): escreva sua lógica de detecção como SQL inline. Veja Escrever regras de detecção para saber como funciona o SQL de detecção.
• SQL warehouse (obrigatório): Uma regra de detecção executa o SQL de detecção em um SQL warehouse selecionado por você, em seu próprio job isolado. As regras não usam agrupamento de clusters ou configurações de compute personalizadas. Se você não tiver um warehouse dimensionado para cargas de trabalho de detecção, consulte o guia de warehouse de detecção.
• Descrição (opcional): Uma breve descrição da função da sua regra, por exemplo "Detecta preenchimento de credenciais" ou "Identifica grandes anexos de email."
• Principal de execução (opcional): O usuário ou service principal que a regra usa como execução. default para o criador da regra.

Tab de execução

Configure quando a regra entra em execução, se está ativa e como os alertas são suprimidos:

• Ativo (alternar): Se a regra está habilitada e é execução em sua programar. default: ativado.

• Programar (botão "Editar programar"): Defina com que frequência a regra é colocada em execução, utilizando um de dois tipos de programar:

  • Pelo menos a cada : a regra tem execução pelo menos com essa frequência (mínimo de 5 minutos), mas pode ter execução com mais frequência em determinadas circunstâncias. Defina uma quantidade e uma unidade: minutos, horas ou dias.
  • Exatamente em : A regra é execução em um programar cron. Crie-o com o controle Cada N e uma unidade (minuto, hora, dia, semana ou mês) mais o controle em , ou selecione Mostrar sintaxe cron para inserir uma expressão cron do Quartz diretamente.
  • De qualquer forma, a regra é um trabalho em lote que entra em execução no SQL Warehouse selecionado no passo Regra e entrada , em seu próprio Job isolado. O agrupamento de clusters e as configurações de compute não se aplicam.

• Supressão de alertas (botão “Editar supressão de alertas”): Quando ativado, a regra ainda está em execução e produz sinais, mas esses sinais não abrem alertas. Defina uma data e hora até que a supressão termine (obrigatório). Os horários usam seu fuso horário local e são armazenados como UTC.

Tab de sinais

Configure os sinais produzidos pela regra e controle a desduplicação:

Resumo

O resumo do sinal aparece na lista de resultados de detecção e fornece aos analistas um título rápido e descritivo do que foi detectado. Este campo permite criar mensagens de alerta dinâmicas incorporando dados do evento original usando expressões SQL entre chaves {sql-expression}. Sinais que compartilham um resumo, ID de regra e versão são agrupados em um único alerta; se todas as suas linhas de saída também corresponderem dentro da janela de desduplicação, a duplicata será descartada. Para evitar a criação de um número excessivo de alertas, mantenha o resumo geral e evite expansões de campo que produzam um valor exclusivo em cada correspondência, como um timestamp ou ID de evento.

Exemplo :

Brute force attempt detected for `{user.name}`

Contexto

O campo context anexa metadados estruturados ao evento de sinal como pares key-value. Cada key é um rótulo e cada valor pode incluir expressões SQL entre chaves {sql-expression} para inserir detalhes do evento. Por exemplo, uma key de source_ip com um valor de {src_endpoint.ip}.

Como alternativa, alterne Incluir todos os dados para gravar automaticamente todas as colunas da linha de entrada que dispararam o sinal.

Deduplicação

Controle se o Lakewatch ignora sinais duplicados produzidos por esta regra. Consulte Desduplicação de sinal para ver como as duplicatas são identificadas e como a janela de tempo funciona.

• Desduplicação : Ative para descartar sinais cujas linhas de saída inteiras são idênticas dentro da janela de tempo; desative para registrar todos os sinais.
• Janela de tempo de deduplicação : Automático (recomendado) deriva a janela do programar da regra. Uma janela personalizada não pode exceder 7 dias.

Tab MITRE ATT&CK

Mapeie a detecção para o framework MITRE ATT&CK para uma categorização de ameaças padronizada:

O MITRE ATT&CK® é uma base de conhecimento globalmente acessível de táticas e técnicas de adversários com base em observações do mundo real. A base de conhecimento ATT&CK é usada como base para o desenvolvimento de modelos e metodologias de ameaças específicas no setor privado, no governo e na comunidade de produtos e serviços de cibersegurança.

Se a detecção mapear para o framework MITRE ATT&CK, preencha os campos a seguir para ajudar os analistas a entender o contexto da ameaça e permitir uma melhor caça a ameaças:

Clique em Adicionar para criar um mapeamento e, em seguida, preencha essas listas suspensas. Adicione quantos mapeamentos forem aplicáveis:

• Taxonomia : A matriz MITRE ATT&CK, como Enterprise.
• Tática : O objetivo tático do adversário.
• Técnica : o método usado para atingir a tática.
• Subtécnica : uma variação específica da técnica.

Tab de detalhes

Defina os metadados de classificação da regra:

Campos obrigatórios:

• Gravidade : Uma avaliação da gravidade da ameaça, usada para atribuir pontuações de risco aos sinais. Valores: Informational, Low, Medium, High, Critical.

• Categoria : uma classificação que descreve a metodologia de detecção. Todos os Workspace do Lakewatch incluem estas categorias default:

  • Assinatura estática - Para regras que correspondem a padrões exatos (ex.: hashes de malware conhecidos)
  • Assinatura Difusa - Para correspondência de padrões com tolerância de variação (por exemplo, assuntos de phishing semelhantes)
  • Comportamental - para detecção baseada em ação (por exemplo, sequências de escalonamento de privilégios)
  • Estatística - para detecção baseada em limite (por exemplo, volume de login incomum)
  • Aprendizado (AI/ML) - Para detecção baseada em ML (por exemplo, modelos de detecção de anomalia)

  Categorias personalizadas podem ser adicionadas na configuração do workspace. As categorias ajudam a organizar regras, filtrar detecções por metodologia e entender a cobertura de detecção.

Obrigatório condicionalmente:

• Fidelidade : O nível de maturidade da regra. Regras recém-criadas e não testadas devem ser marcadas como Development ou Investigative. Regras mais antigas e bem testadas devem ser marcadas como High. Isso ajuda os analistas a determinar a probabilidade de um sinal ser um falso positivo. Valores: Development, Investigative, Medium, High. (Obrigatório apenas para criação de regras; pode ficar em branco para rascunhos.)

Campos opcionais:

• Objetivo : uma descrição mais longa para a documentação detalhada da regra; você pode incluir seu raciocínio para a criação da regra, metodologia de teste e/ou notas de implementação.
• Anotações (Pares key-value) : Um método de categorização adicional que usa um sistema de tagging flexível para organização personalizada.

Criar ou cancelar a regra

Depois de preencher todos os campos obrigatórios, clique em Criar regra para salvar e implantar a regra. Clique em Cancelar para descartar as alterações.

Edite uma regra como YAML

O formulário de regra inclui um botão Editar como YAML que abre um editor YAML. O formulário e o editor YAML permanecem sincronizados: as alterações que você faz no YAML preenchem o formulário, e o YAML sempre reflete os valores atuais do formulário. Use o editor YAML para revisar uma regra completa de uma só vez ou para copiar uma regra e ajustar alguns campos.

O YAML de uma regra usa nomes de campo simples e snake_case, e cada campo mapeia para um controle no assistente. O exemplo a seguir define uma regra agendada que lê eventos de autenticação analisados e gera um sinal para cada login correspondente:

YAML

catalog_name: security
schema_name: detections
rule_name: suspicious_login_activity

description: Detects login attempts from unusual locations.
severity: High
category: Behavioral
fidelity: FIDELITY_INVESTIGATIVE

schedule:
  enabled: true
  at_least_every: 1h

batch:
  sql:
    query: |
      SELECT
        time,
        actor.user.name AS user_name,
        src_endpoint.ip AS source_ip
      FROM security.parsed.authentication_events
      WHERE IN_TIMERANGE(time)
        AND activity_name = 'Logon'

output:
  event_time_column: time
  summary: 'Suspicious login from {source_ip} by {user_name}'
  context:
    user_name: '{user_name}'
    source_ip: '{source_ip}'
  default_context: false

Campos de regra

Cada campo mapeia para um controle de assistente descrito acima. Para saber o que um campo faz, consulte o passo do assistente.

Campo YAML	Controle de assistente	Obrigatório	Notas
catalog_name	Catálogo	Sim	Não pode ser alterado após a criação da regra.
schema_name	Esquema	Sim	Não pode ser alterado após a criação da regra.
rule_name	Nome	Sim	Não pode ser alterado após a criação da regra.
description	Descrição	Não
run_as_principal	Identidade de Run-as	Não	Um email de usuário ou ID de aplicativo de service principal. O default é o criador da regra.
batch.sql.query	SQL de detecção	Sim	A query de detecção. Use IN_TIMERANGE() para limitá-lo à janela de cada execução. Consulte Escrever regras de detecção.
batch.warehouse_id	Compute	Não	O ID do SQL warehouse em que a regra é executada.
severity	Gravidade	Sim	Um de Informational, Low, Medium, High ou Critical.
category	Categoria	Não	Um rótulo de categoria, como Behavioral.
fidelity	Fidelidade	Sim	Um de FIDELITY_DEVELOPMENT, FIDELITY_INVESTIGATIVE, FIDELITY_MEDIUM ou FIDELITY_HIGH (mostrado no assistente como Desenvolvimento, Investigativo, Médio e Alto).
objective	Objetivo	Não
mitre	MITRE ATT&CK	Não	Uma lista de mapeamentos, cada um com taxonomy, tactic, technique_id, technique, sub_technique_id e sub_technique.
output.summary	Resumo	Não	Suporta {sql-expression} substituições.
output.context	Contexto	Não	Um mapa de key/valor. Os valores oferecem suporte a substituições de {sql-expression}.
output.default_context	Incluir todos os dados	Não	Quando true, registra cada coluna da linha de gatilho.
output.event_time_column	—	Não	A coluna de saída que contém o timestamp do evento.
deduplication	Deduplicação	Não	Um de DEDUPLICATION_DEFAULT, DEDUPLICATION_ENABLEDou DEDUPLICATION_DISABLED.
deduplication_time_window	Janela de tempo de desduplicação	Não	Uma duração como 1h, 24h, ou 7d, ou automatic.
schedule.enabled	Ativas	Não	Se a regra está em execução conforme seu programar. O padrão é default true.
schedule.at_least_every	Pelo menos a cada	Um de	Um intervalo como 5m, 15m ou 1h (mínimo de 5 minutos), para um programar Pelo menos a cada .
schedule.cron_expression	Exatamente em	Um de	Uma expressão cron do Quartz, para programar Exatamente em .
suppress_until_time	Suprimir até	Não	Um timestamp até o qual os sinais da regra não abrem alertas.
annotations	anotação	Não	Um mapa de key/valor.

Campo YAML	Controle de assistente	Obrigatório	Notas
catalog_name	Catálogo	Sim	Não pode ser alterado após a criação da regra.
schema_name	Esquema	Sim	Não pode ser alterado após a criação da regra.
rule_name	Nome	Sim	Não pode ser alterado após a criação da regra.
description	Descrição	Não
run_as_principal	Identidade de Run-as	Não	Um email de usuário ou ID de aplicativo de service principal. O default é o criador da regra.
batch.sql.query	SQL de detecção	Sim	A query de detecção. Use IN_TIMERANGE() para limitá-lo à janela de cada execução. Consulte Escrever regras de detecção.
batch.warehouse_id	Compute	Não	O ID do SQL warehouse em que a regra é executada.
severity	Gravidade	Sim	Um de Informational, Low, Medium, High ou Critical.
category	Categoria	Não	Um rótulo de categoria, como Behavioral.
fidelity	Fidelidade	Sim	Um de FIDELITY_DEVELOPMENT, FIDELITY_INVESTIGATIVE, FIDELITY_MEDIUM ou FIDELITY_HIGH (mostrado no assistente como Desenvolvimento, Investigativo, Médio e Alto).
objective	Objetivo	Não
mitre	MITRE ATT&CK	Não	Uma lista de mapeamentos, cada um com taxonomy, tactic, technique_id, technique, sub_technique_id e sub_technique.
output.summary	Resumo	Não	Suporta {sql-expression} substituições.
output.context	Contexto	Não	Um mapa de key/valor. Os valores oferecem suporte a substituições de {sql-expression}.
output.default_context	Incluir todos os dados	Não	Quando true, registra cada coluna da linha de gatilho.
output.event_time_column	—	Não	A coluna de saída que contém o timestamp do evento.
deduplication	Deduplicação	Não	Um de DEDUPLICATION_DEFAULT, DEDUPLICATION_ENABLEDou DEDUPLICATION_DISABLED.
deduplication_time_window	Janela de tempo de desduplicação	Não	Uma duração como 1h, 24h, ou 7d, ou automatic.
schedule.enabled	Ativas	Não	Se a regra está em execução conforme seu programar. O padrão é default true.
schedule.at_least_every	Pelo menos a cada	Um de	Um intervalo como 5m, 15m ou 1h (mínimo de 5 minutos), para um programar Pelo menos a cada .
schedule.cron_expression	Exatamente em	Um de	Uma expressão cron do Quartz, para programar Exatamente em .
suppress_until_time	Suprimir até	Não	Um timestamp até o qual os sinais da regra não abrem alertas.
annotations	anotação	Não	Um mapa de key/valor.