Crie análises com base no contexto

O Chronicle permite que você veja a telemetria, o contexto da entidade, as relações e as vulnerabilidades como uma única detecção na sua conta do Chronicle. Ela fornece contextualização de entidades para que você entenda os padrões comportamentais de telemetria e o contexto dessas entidades afetadas por esses padrões.

Exemplos:

  • Mostrar as permissões de uma conta em que um login de força bruta está sendo tentado
  • Importância dos dados hospedados por um recurso que também é a origem da atividade de saída da rede.

Os clientes podem usar essa contextualização para filtrar filtros, priorização de alertas heurísticos, triagem e investigação.

Os analistas e engenheiros de detecção normalmente trabalham para criar uma detecção em um padrão básico de telemetria de eventos (uma conexão de rede de saída), criando diversas detecções para os analistas fazerem a triagem. Os analistas tentam reunir uma compreensão do que aconteceu para acionar o alerta e a importância da ameaça.

A análise baseada no contexto incorpora recursos avançados de enriquecimento mais cedo no fluxo de trabalho de criação e execução de detecção, o que permite disponibilizar estes recursos adicionais:

  • Disponibilização de um contexto relevante para a pontuação de risco contextual baseada em heurística no momento da execução da detecção, e não no estágio de triagem humana
  • reduzir o tempo gasto na triagem e agrupar manualmente informações de diferentes sistemas de segurança de TI, como consoles de EDR, registros de firewall/proxy, contexto do CMDB e do IAM e resultados de verificação de vulnerabilidades;
  • Permitir que analistas e engenheiros de detecção filtrem todos os clusters de ameaças que podem ser esperadas ou representem pouco ou nenhum risco para a empresa (testes de malware em um ambiente sandbox, vulnerabilidades e atividades anômalas em uma rede de desenvolvimento sem acesso ou dados confidenciais etc.)

Como escrever regras para análise baseada no contexto

Você pode usar as regras do mecanismo de detecção para pesquisar dados de contexto de entidade na sua conta do Chronicle.

Para pesquisar dados de contexto de entidade, faça o seguinte:

  1. Especifique uma origem usando a udm ou a entidade.

    $eventname.[<source>].field1.field2 Para um contexto de entidade, <source> é 'graph'. Para um evento UDM, <source> é 'udm'. Se omitido, o padrão é <source> udm.

  2. Especifique os dados da entidade:

    $e1.graph.entity.hostname = "my-hostname"

    $e1.graph.entity.relations.relationship = "OWNS"

  3. Especifique os dados do evento UDM. As instruções a seguir são equivalentes.

    $e1.udm.principal.asset_id = "my_asset_id"

    $e1.principal.asset_id = "my_asset_id"

É possível criar muitos dos mesmos tipos de regras para contextos de entidades que você criaria para eventos UDM, incluindo o seguinte:

  • Várias regras de evento

  • Comparar contextos de entidade com outros contextos de entidade

  • Comparar contextos de entidade com eventos UDM

  • Campos repetidos em contextos de entidade

  • Janelas de correr

  • Como calcular uma pontuação de risco para detecções

Diferentemente de um evento de UDM, o contexto da entidade não tem um carimbo de data/hora específico. Cada contexto de entidade tem um intervalo de tempo em que a associação é válida. O período não precisa começar em um limite de dias e pode ter qualquer duração arbitrária.

  • Ao comparar eventos de UDM a um contexto de entidade com janelamento, um contexto de entidade representa um valor constante em uma janela especificada.
  • Se houver buckets de dia adjacentes em que o contexto da entidade altera o valor, o Chronicle tentará fazer a correspondência em todos os valores de contexto da entidade e retornar todas as correspondências encontradas.

Exemplo de regras

Pesquisando entidades com contexto de administrador

A regra a seguir procura entidades que também estejam vinculadas a privilégios de administrador. Ele procura horários em que alguém com privilégios de administrador tentou fazer login ou sair do sistema.

rule LoginLogout {
  meta:
  events:
    $log_in.metadata.event_type = "USER_LOGIN"
    $log_in.principal.user.user_display_name = $user
    $log_in.principal.user.userid = "alice"

    $log_out.metadata.event_type = "USER_LOGOUT"
    $log_out.principal.user.user_display_name = $user
    $log_out.principal.user.userid = "alice"

    $log_in.metadata.event_timestamp.seconds <=
     $log_out.metadata.event_timestamp.seconds

    $context.graph.entity.user.user_display_name = $user
    $context.graph.entity.resource.attribute.roles.type = "ADMINISTRATOR"

  match:
    $user over 2m

  condition:
    $log_in and $log_out and $context
}

Exemplo de janela deslizante

O exemplo de janela deslizante a seguir é válido.

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Using e2 (a UDM event) as a pivot.
    $host over 3h after $e2

  condition:
    $e1 and $e2
}

Exemplo de janela deslizante inválida

O exemplo de janela deslizante a seguir é inválido. O contexto de entidade não pode ser usado como tabela dinâmica para uma janela deslizante.

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Attempting to use $e1 (an entity context) as a pivot. Invalid.
    $host over 3h after $e1

  condition:
    $e1 and $e2
}

Exemplo de login usando a seção de resultados

No exemplo a seguir, a seção outcome é usada para calcular uma pontuação de risco para a detecção.

rule Detection {
  meta:
  events:
    $auth.metadata.event_type = "USER_LOGIN"
    $auth.metadata.vendor_name = "Acme"
    $auth.metadata.product_name = "Acme SSO"
    $auth.target.user.userid = $user
    $auth.target.user.termination_date.seconds > 0

    $auth.metadata.event_timestamp.seconds >
       $context.graph.entity.user.termination_date.seconds

    $context.graph.metadata.vendor_name = "Microsoft"
    $context.graph.metadata.product_name = "Azure Active Directory"
    $context.graph.metadata.entity_type = "USER"
    $context.graph.entity.user.userid = $user
    $context.graph.entity.user.termination_date.seconds > 0

  match:
    $user over 15m

  outcome:
    $risk_score = max(
        if ( $auth.metadata.event_type = "USER_LOGIN", 50) +
        if (
            $context.graph.entity.user.title = "Remote" nocase or
            $context.graph.entity.user.title = "Temp" nocase or
            $context.graph.entity.user.title = "Vendor" nocase, 40) +
        if ( $context.graph.entity.user.title = "Legal" nocase, 10)
    )

  condition:
    $auth and $context
}

Exemplo de inicialização de processo suspeito

O exemplo a seguir avalia os dados do processo de eventos do UDM em relação aos dados de contexto de IOC armazenados como um contexto de entidade.

rule ProcessLaunch {
  meta:
  events:
    $ioc.graph.metadata.vendor_name = "ACME"
    $ioc.graph.metadata.product_name = "IOCs"
    $ioc.graph.metadata.entity_type = "FILE"
    $ioc.graph.entity.file.sha256 = $hash

    $process.metadata.event_type = "PROCESS_LAUNCH"
    $process.principal.hostname = $hostname
    (
        not $process.target.process.file.sha256 = "" and
        $process.target.process.file.sha256 = $hash
    )

  match:
    $hash over 15m

  condition:
    $ioc and $process
}

Qualificadores adicionais para contexto de entidade

Para criar uma variável de evento que usa um contexto de entidade, é necessário fornecer um <source> após o nome do evento. O <source> precisa ser graph.

O padrão a seguir se refere a um contexto de entidade:

  • $e.graph.entity.hostname

Há dois métodos equivalentes de se referir a um evento de UDM:

  • $u.udm.principal.asset_id
  • $u.principal.asset_id

É possível combinar todos esses qualificadores no texto da regra. Também é possível usar diferentes qualificadores para o mesmo evento.

Seção de resultados

O mecanismo de detecção é compatível com uma seção outcome, que permite que você receba mais informações de uma regra. A lógica definida na seção outcome é avaliada em relação a cada detecção. Se uma regra gerar N detecções, cada uma delas poderá resultar em um resultado diferente.

Veja um exemplo de regra que usa a seção outcome aqui.

O uso detalhado e a sintaxe de uma seção outcome podem ser encontrados nesta seção.

Seção "Resultado" e eliminação de duplicação / agrupamento de detecção

Para regras com uma seção de correspondência, lembre-se de que as detecções são "agrupadas pelas" variáveis de correspondência. Isso causa a eliminação de duplicação das detecções, de modo que uma linha seja retornada para cada conjunto exclusivo de variáveis de correspondência e janela de tempo.

As variáveis de resultado são ignoradas ao fazer essa eliminação de duplicação. Assim, se houver duas detecções diferentes com os mesmos valores para as variáveis de correspondência e janela de tempo, mas com valores diferentes para variáveis de resultado, a duplicação será eliminada, e você verá apenas uma detecção. Isso pode acontecer quando uma detecção é criada devido a dados que chegam atrasados, por exemplo. Veja um exemplo que ilustra esse caso.

rule ExampleOutcomeRule {
  ...
  match:
    $hostname over <some window>
  outcome:
    $risk_score = <some logic here>
  ...
}

Esta regra resulta nas seguintes correspondências:

Detecção 1: nome do host: test-hostname janela de tempo: [t1, t2] ris_score: 10

Detecção 2: nome do host: test-hostname janela de tempo: [t1, t2] ris_score: 73

Como as variáveis de correspondência e a janela de tempo são as mesmas para Detecção 1 e Detecção 2, a duplicação é eliminada, e você verá apenas uma detecção, mesmo que a variável de resultado, riscos_pontuações seja diferente.