Use tabelas de dados

Suportado em:

Google secops SIEM

As tabelas de dados são construções de dados com várias colunas que lhe permitem introduzir os seus próprios dados no Google Security Operations. As tabelas de dados podem funcionar como tabelas de consulta com colunas definidas e os dados armazenados em linhas. Pode criar ou importar uma tabela de dados para a sua conta do Google SecOps através da interface Web do Google SecOps, da API de tabelas de dados ou de uma consulta Vista geral do YARA-L 2.0.

Atribua âmbitos a tabelas de dados através do RBAC de dados

Para usar tabelas de dados, tem de atribuir âmbitos às tabelas de dados através do controlo de acesso baseado em funções (RBAC) de dados. Ao atribuir âmbitos a uma tabela de dados, pode controlar os utilizadores e os recursos que podem aceder à mesma e utilizá-la. Para mais informações, consulte o artigo Configure o RBAC de dados para tabelas de dados.

Faça a gestão de tabelas de dados através da interface Web do Google SecOps

As secções seguintes descrevem como gerir tabelas de dados através da interface Web, incluindo como aceder a tabelas de dados, adicionar uma nova tabela de dados, editar o respetivo conteúdo, adicionar linhas e remover uma tabela de dados da sua conta.

Aceda às suas tabelas de dados

Para aceder à página Tabelas de dados, faça o seguinte:

• Na barra lateral, selecione Investigação > Tabelas de dados.

Para encontrar uma tabela de dados específica, na parte superior da barra lateral Tabelas de dados, introduza o respetivo nome no campo Pesquisar.

Adicione uma nova tabela de dados

Quando adiciona uma nova tabela de dados, pode introduzir dados CSV manualmente, colar dados CSV ou importar um ficheiro CSV ou TSV para a tabela de dados.

Nota: as tabelas de dados não suportam valores separados por tabulações, exceto quando importa um ficheiro de valores separados por tabulações (TSV). Quando importa um ficheiro TSV, o Google SecOps converte os separadores de tabulação em separadores de vírgulas na tabela de dados. Os campos da tabela de dados não suportam carateres de vírgula (,).

As seguintes configurações são permanentes e não podem ser alteradas depois de guardar uma nova tabela de dados:

• Cabeçalhos das colunas
• Mapeamento de dados
• Chaves principais
• Campos repetidos
• Mapeamento de nomes de colunas para campos de entidades

Para adicionar uma nova tabela de dados ao Google SecOps, faça o seguinte:

1. Na barra lateral, selecione Investigação > Tabelas de dados.

2. Na parte superior da barra lateral Tabelas de dados, clique em add Criar.

3. Na caixa de diálogo Criar nova tabela de dados, atribua um nome à tabela e, opcionalmente, adicione uma descrição.

4. Efetue um dos seguintes passos:

   • Introduza os dados CSV manualmente ou cole-os na área Texto (modo de edição).
   • Faça o seguinte para importar dados de um ficheiro CSV ou TSV para a tabela de dados:
   1. Clique em Importar ficheiro.
   2. Aceda ao ficheiro e clique em Abrir. É apresentada a caixa de diálogo Importar ficheiro.
   3. Se selecionou um ficheiro TSV no passo anterior, faça o seguinte:
      1. Na lista Tipo de separador, selecione Detetar automaticamente ou Tabulação.
      2. Na lista Iniciar importação na linha, especifique a linha no ficheiro a partir da qual importar os dados.
   4. Clique em Importar dados.

5. Selecione o modo de edição Tabela e configure o seguinte conforme necessário:

   • Mapeie tipos de dados para colunas da tabela de dados
   • Designar colunas específicas como colunas principais
   • Designe colunas específicas para suportar campos repetidos
   • Mapeie os nomes das colunas para os campos das entidades (opcional)

6. Clique em Guardar. A nova tabela de dados é apresentada na barra lateral Tabelas de dados e está pronta para aceitar dados adicionais.

Mapeie tipos de dados para colunas da tabela de dados

Quando adiciona uma nova tabela de dados, pode mapear tipos de dados (string, expressão regular, CIDR ou número) para colunas da tabela de dados.

Pode mapear campos de dados únicos para uma coluna de dados e mapear campos de dados repetidos para uma coluna de dados através da interface Web ou da API, da seguinte forma:

• Tanto na interface Web como na API, separe os valores dos campos de dados com uma barra vertical (|). Na interface Web, se algum valor incluir uma barra vertical (|), é tratado como um valor repetido por predefinição.

• Para pedidos de API, defina repeated_values como true.

Para mais informações, consulte a secção Campos repetidos.

No exemplo seguinte, a coluna da tabela de dados Field_value contém valores para vários campos:

Field_value	Field_name
altostrat.com	FQDN
192.0.2.135	PI
charlie	userid
exemplo	hostname

A tabela anterior está dividida em quatro colunas, com cada coluna mapeada para apenas um tipo de campo antes de poder ser usada para qualquer um dos exemplos de utilização de tabelas de dados apresentados neste documento.

FQDN	IP	Userid	Nome do anfitrião
altostrat.com	192.0.2.135	charlie	exemplo
…	…	…	…

Designar colunas principais

Quando adiciona uma nova tabela de dados, pode designar colunas específicas como colunas de chaves.

Marcar uma coluna como coluna principal identifica exclusivamente os valores nessa coluna, impede a duplicação de dados e melhora a deteção de dados para regras e pesquisas.

Nota: por predefinição, todas as colunas são tratadas como colunas principais, salvo especificação em contrário durante a criação da tabela de dados.

Designe colunas para suportar campos repetidos

Quando adiciona uma nova tabela de dados, pode designar colunas específicas para suportar campos repetidos.

As colunas destinadas a armazenar campos com vários valores ou campos repetidos têm de ser explicitamente designadas como repetidas quando a tabela de dados é criada.

Mapeie os nomes das colunas para os campos das entidades (opcional)

Quando adiciona uma nova tabela de dados, pode mapear os nomes das colunas da tabela de dados para campos de entidade.

Nota: o mapeamento de campos de entidades para colunas é opcional e usado quando o enriquecimento de entidades é realizado. Para mais informações, consulte o artigo Enriqueça o gráfico de entidades com uma tabela de dados.

Na tabela de dados de exemplo seguinte, as colunas Userid e Role são mapeadas, respetivamente, para entity.user.userid e entity.user.attribute.role.name:

Userid (mapeamento para entity.user.userid)	Email	Função (mapear para entity.user.attribute.role.name)
Jack	[e-mail]	administrator
tony	[e-mail]	engenheiro

Pode mapear uma coluna da tabela de dados para um campo proto de entidade através do campo mapped_column_path do recurso DataTable.

Para colunas sem um caminho de entidade definido, como Email na tabela de exemplo, tem de especificar manualmente um tipo de dados. Tal como nas listas de referência, os tipos de dados suportados para tabelas de dados são number, string, regex e cidr.

Pode incluir colunas mapeadas e não mapeadas numa tabela de dados especificando uma condição join.

As colunas não mapeadas são armazenadas no campo additional da entidade à qual a tabela se junta. Estes são adicionados como pares de chave-valor, em que key é o nome da coluna e value é o valor da linha correspondente.

Adicione uma nova linha a uma tabela de dados

Para adicionar uma nova linha, faça o seguinte:

1. No separador Detalhes, selecione o modo de edição Tabela.
2. Clique com o botão direito do rato numa linha existente e selecione Adicionar linha acima.
3. Introduza dados para uma nova linha. A primeira linha é tratada como um cabeçalho da tabela. Certifique-se de que faz corresponder cada item de dados à coluna de dados e ao tipo de dados adequados.
4. Clique em Guardar.

Nota: as linhas são guardadas numa ordem aleatória na tabela de dados.

Edite uma linha numa tabela de dados

Para editar uma linha, faça o seguinte:

1. Clique no campo que quer alterar. O campo torna-se editável.
2. Faça as suas alterações.
3. Clique em Guardar.

Pesquise linhas da tabela de dados

Pode pesquisar informações específicas numa tabela de dados através da interface Web. No separador Detalhes, introduza uma string de pesquisa no campo de pesquisa e clique em Pesquisar. São apresentadas as linhas que contêm a string de pesquisa.

Faça a gestão do TTL da linha da tabela

Para gerir o valor de tempo de vida (TTL) das linhas da tabela, faça o seguinte:

1. Clique em Mostrar TTL por linha. É apresentada uma coluna TTL, que indica se cada linha expirou. Se não tiver expirado, mostra o tempo restante antes da expiração.

2. Clique na hora de validade predefinida da linha para apresentar a caixa de diálogo Atualizar validade predefinida da linha e ajustar o TTL da linha da tabela.

3. Introduza um novo valor de TTL em Horas ou Dias. O valor mínimo é de 24 horas. O valor máximo é de 365 dias.

4. Clique em Guardar.

Nota: o TTL aplicado ao nível da tabela é herdado pelas linhas. Qualquer atualização às linhas existentes repõe o TTL dessa linha. Quando adiciona uma nova linha à tabela, o TTL começa a partir do ponto em que a linha foi criada.

Elimine uma linha da tabela

Para eliminar uma linha, clique com o botão direito do rato na linha e selecione Eliminar linhas.

Para eliminar várias linhas, selecione cada linha que quer remover. Em seguida, clique com o botão direito do rato em qualquer linha selecionada e escolha Eliminar linhas.

Remova uma tabela de dados

Para remover uma tabela de dados, faça o seguinte:

1. Selecione uma tabela de dados na lista Tabelas de dados na barra lateral.

2. Clique em Eliminar.

Faça a gestão de tabelas de dados com a API Chronicle

Também pode usar os recursos REST disponíveis na API Chronicle para gerir tabelas de dados no Google SecOps. A API pode replicar todas as funcionalidades disponíveis na interface Web e inclui algumas funcionalidades adicionais que lhe permitem gerir tabelas de dados com mais desempenho e maior escala.

Seguem-se os recursos REST da tabela de dados:

• dataTables

• dataTableRows

• dataTableOperationErrors

Exemplo: sintaxe de filtro

O exemplo seguinte da API Chronicle mostra como usar a sintaxe filter para pesquisar google.com nas linhas da tabela de dados:

curl -X GET \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://staging-chronicle.sandbox.googleapis.com/v1alpha/projects/{$PROJECT}/locations/${REGION}/instances/${INSTANCE}/dataTables/${DATA_TABLE_NAME}/dataTableRows?filter=google.com"

Use tabelas de dados no Google SecOps

Depois de adicionar tabelas de dados à sua instância do Google SecOps, pode usá-las para filtrar, melhorar e enriquecer os seus dados através de consultas YARA-L. Este documento inclui vários exemplos na sintaxe YARA-L, que pode incorporar no Google SecOps.

Pode usar tabelas de dados em conjunto com consultas YARA-L na Pesquisa e nas regras.

Pode usar as tabelas de dados das seguintes formas:

• Filtre dados de eventos ou entidades do UDM através de uma tabela de dados

  Pode filtrar eventos e entidades de telemetria do UDM comparando-os com entradas numa tabela de dados.

• Use uma tabela de dados como uma lista de referência de várias colunas

  Pode usar uma tabela de dados como uma lista de referência de várias colunas. Embora uma lista de referência possa aceder a dados numa única dimensão, as tabelas de dados permitem-lhe aceder a dados em várias dimensões, o que permite a filtragem de dados.

• Junte uma tabela de dados a um evento ou a uma entidade

  Pode associar eventos da UDM a uma tabela de dados através do operador de igualdade (=) para comparações baseadas em linhas. Esta comparação permite-lhe filtrar os dados. Uma comparação baseada em linhas é avaliada como true apenas se todas as condições na declaração corresponderem a uma única linha na tabela de dados.

Filtre dados de eventos e entidades do UDM através de uma tabela de dados

Pode filtrar eventos e entidades do UDM comparando-os com entradas numa tabela de dados. Junte a tabela de dados a um evento ou uma entidade do UDM através de comparações baseadas em linhas ou baseadas em colunas.

Comparações baseadas em linhas e colunas em tabelas de dados

Tipo de comparação	Lógica principal	Operadores comuns	Sintaxe de exemplo	Quando usar
Com base em linhas	Todas as condições têm de corresponder na MESMA linha	=, !=, >, >=, <, <=	$e.field = %table.col_a	Quando a relação entre vários valores de colunas na mesma linha é importante.
Baseado em colunas	O valor tem de existir EM QUALQUER LUGAR na coluna	IN, IN regex, IN cidr	$e.field IN %table.col_b	Quando verifica a presença de um valor num conjunto de valores numa única coluna.

Associe eventos do UDM a tabelas de dados através de métodos de comparação baseados em linhas ou baseados em colunas:

Comparação baseada em linhas para associar eventos do UDM a tabelas de dados

• Para associar eventos UDM a tabelas de dados através da comparação baseada em linhas, use operadores de igualdade (=, !=, >, >=, <, <=).

  Por exemplo: $<udm_variable>.<field_path> = %<data_table_name>.<column_name>

  • Se estiver a usar várias declarações de comparação, todos os campos ou condições têm de corresponder na mesma linha da tabela de dados.

  • Para usar operadores (como not, !=, >, >=, <, <=) na sua consulta, tem de incluir, pelo menos, uma condição join entre os campos de DFU e as linhas da tabela de dados.

  • O Google SecOps trata qualquer regra com uma tabela de dados join como uma regra de vários eventos, que requer uma secção match na definição da regra.

• Para filtrar dados por valores correspondentes de eventos da UDM em relação às linhas na tabela de dados, considere a seguinte sintaxe de junção:

  • Sintaxe de junção correta:

    A "exclusão de combinação" baseada em linhas requer, por exemplo, uma junção left outer e uma cláusula where que verifique a existência de nulls.

  • Sintaxe de junção incorreta:

    Não envolva NOT em várias condições de igualdade baseadas em linhas. Esta sintaxe não produz um efeito de "excluir se esta combinação for encontrada".

    Por exemplo, não use esta sintaxe: NOT (field1 = %table.col1 AND field2 = %table.col2)

    Isto acontece porque a correspondência continua a ser aplicada linha a linha. Se qualquer linha falhar na condição combinada interna, o NOT faz com que a avaliação dessa linha seja true, o que pode incluir o evento em vez de o excluir.

• Para usar uma coluna da tabela de dados do tipo CIDR ou regex para uma comparação baseada em linhas, use a seguinte sintaxe:

  net.ip_in_range_cidr($e.principal.ip, %<data_table_name>.<column_name>)
  
    re.regex($e.principal.hostname, %<data_table_name>.<column_name>)
  

Comparação baseada em colunas para associar eventos da UDM a tabelas de dados

• Para associar eventos da UDM a tabelas de dados através da comparação baseada em colunas, use a palavra-chave in.

  Por exemplo: $<udm_variable>.<field_path> in %<data_table_name>.<column_name>

• Para filtrar eventos em que o valor do campo existe na coluna especificada (por exemplo, uma lista de bloqueio ou uma lista de autorizações), use esta sintaxe: NOT (... IN %table.column)

  Por exemplo: not ($evt_username in %my_data_table.username)

• Para usar uma coluna da tabela de dados do tipo CIDR ou regex para comparação baseada em colunas, use a seguinte sintaxe:

  $e.principal.ip in cidr %cidr_data_table.column_name
  
  $e.principal.hostname in regex %regex_data_table.column_name
  

• Quando compara colunas em tabelas de dados que são tipos de dados CIDR ou de expressões regulares, as palavras-chave cidr e regex são opcionais.

• Também pode usar o operador not com tabelas de dados.

  A seguinte consulta de exemplo filtra as entradas em que os endereços IP ($e.principal.ip) não correspondem a nenhum dos intervalos CIDR indicados na coluna benign_ip em cidr_data_table:

  not $e.principal.ip in %data_table.benign_ip
  

Use uma tabela de dados como uma lista de referência de várias colunas

Pode usar uma tabela de dados como uma lista de referência de várias colunas. Embora uma lista de referência possa aceder a dados numa única dimensão (uma coluna), as tabelas de dados suportam várias colunas, o que lhe permite filtrar e aceder a dados em várias dimensões.

Pode associar eventos de GDU a uma tabela de dados através da palavra-chave in para comparação baseada em colunas, o que lhe permite fazer corresponder valores num campo de GDU específico a valores numa única coluna da tabela de dados.

No exemplo seguinte, a tabela de dados badApps contém duas colunas: hostname e ip. A consulta corresponde aos dois valores (valor com base no campo UDM e valor com base na tabela de dados, ambos dos tipos de dados de string) de forma independente.

• Exemplo de regra:

  rule udm_in_data_table {
  meta:
    description = "Use data table as multicolumn reference list"
  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.security_result.action = "ALLOW"
    $e.target.asset.asset_id = $assetid
  
    // Event hostname matches at least one value in table column hostname.
    $e.target.hostname in %badApps.hostname
  
    // Event IP matches at least one value in table column ip.
    $e.target.ip in %badApps.ip
  
  match:
    $assetid over 1h
  
  condition:
    $e
  }
  

• Exemplo de pesquisa:

  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.security_result.action = "ALLOW"
    $e.target.asset.asset_id = $assetid
  
    // Event hostname matches at least one value in table column hostname.
    $e.target.hostname in %badApps.hostname
  
    // Event IP matches at least one value in table column ip.
    $e.target.ip in %badApps.ip
  

Junções baseadas em linhas entre uma tabela de dados e um evento ou uma entidade do UDM

Pode associar eventos UDM a uma tabela de dados através de operadores de igualdade e comparação (=, !=, >, >=, <, <=) para fazer comparações baseadas em linhas. Esta abordagem permite-lhe filtrar dados fazendo corresponder valores de eventos da UDM a linhas na tabela de dados. Se estiver a usar várias declarações de comparação, todos os campos ou condições têm de corresponder na mesma linha da tabela de dados.

Tem de incluir, pelo menos, uma condição join entre os campos da UDM e as linhas da tabela de dados para usar operadores (como not, !=, >, >=, <, <=) na sua consulta. O Google SecOps trata qualquer regra com uma tabela de dados join como uma regra de vários eventos, que requer uma secção match correspondente na definição da regra.

Quando ocorre uma junção, as linhas da tabela de dados associada ficam visíveis na Pesquisa. Para mais informações, consulte o artigo Veja linhas da tabela de dados na Pesquisa.

• Os marcadores de posição são suportados para tabelas de dados na secção event de uma consulta, mas têm de estar associados a um evento UDM ou a uma entidade UDM.

  O exemplo seguinte usa uma coluna de tabela de dados do tipo string.

  • Este exemplo de consulta YARA-L verifica se um evento de início de sessão de utilizador corresponde a uma linha na tabela example_table.

  • Uma condição é que o user ID exista no example_table.

  • Ambas as condições têm de corresponder à mesma linha no example_table para que a regra seja acionada.

// Check if a user exists in a data table and that the user is active for all user login events.

Exemplo de regra:

// Check if user exists in a data table and is active in all user login events.
rule udm_join_data_table {

meta:
  description = "Join data table with UDM event"

events:
  $e.metadata.event_type = "USER_LOGIN"
  $e.security_result.action = "ALLOW"
  $e.principal.user.userid = $userid

// Event must match at least 1 row in the data table 
// where the uid in the data table row is the userid on the event 
// and the active date in the same data table row is before the event timestamp.
%example_table.uid = $userid
$e.principal.hostname = %example_table.hostname

match:
  $userid over 1h

condition:
  $e
}

Exemplo de pesquisa:

events:
$e.metadata.event_type = "USER_LOGIN"
$e.security_result.action = "ALLOW"
$e.principal.user.userid = $userid

// Event must match at least 1 row in the data table 
// where the uid in the data table row is the userid on the event 
// and the active date in the same data table row is before the event timestamp

%example_table.uid = $userid
$e.principal.hostname = %example_table.hostname

• O exemplo seguinte ilustra como uma tabela de dados e os dados de eventos da UDM funcionam em conjunto.

  Com base na lógica na consulta YARA-L anterior, um utilizador com user ID 32452 aparece na deteção como o hostname do utilizador no sistema, e corresponde ao hostname na tabela de dados.

  Tabela de dados
  uid	título	hostname
  32452	RH	host1
  64452	Finanças	host2
  46364	IT	host3

  Tabela de eventos da UDM
  principal	metadata	security_result	principal
  32452	USER_LOGIN	PERMITIR	host1
  64589	USER_LOGIN	PERMITIR	host9
  87352	USER_LOGIN	PERMITIR	host4

Escreva resultados de consultas YARA-L em tabelas de dados

Pode escrever os resultados de consultas YARA-L numa tabela de dados. Com esta funcionalidade, pode criar tabelas de dados a partir dos seus dados do Google SecOps e usar essas tabelas para filtrar e melhorar outros dados.

Pode usar a sintaxe de escrita de consultas YARA-L para o seguinte:

• Defina a sintaxe YARA-L para escrever resultados de consultas em tabelas de dados.

• Use tabelas de dados para inteligência contra ameaças, resposta a incidentes e outros exemplos de utilização de segurança.

• Os dados devem estar em conformidade com a sintaxe e as convenções da YARA-L.

Escreva deteções e alertas em tabelas de dados com YARA-L

Pode usar uma consulta YARA-L para enviar deteções e alertas para tabelas de dados.

Com a função write_row, pode substituir uma linha de uma tabela de dados pela chave correspondente na tabela de dados usando os resultados de uma regra. Se a chave não for encontrada na tabela, adicione uma nova linha.

Especifique a função write_row na secção de exportação de uma consulta YARA-L. A escrita de dados na tabela de dados tem de ser a ação final da consulta. Isto resulta na gravação das variáveis de resultado na tabela de dados.

export:
  %<data_table_name>.write_row(
  data_table_column_x_name: <value>,
  data_table_column_y_name: <value>,
  ...,
  ...,
  data_table_column_z_name: <value>
)
// depending on the key column(s), the rows will be updated for existing keys 
and appended for new keys

Modifique uma tabela de dados com YARA-L

O exemplo seguinte mostra como modificar uma tabela de dados usando o YARA-L:

TableName: ip_user_domain_table (as colunas principais da chave primária são definidas na criação)

Endereço IP	employee_id*	domínio
192.0.2.10	Dana	altostrat.com
192.0.2.20	Quinn	altostrat.com
192.0.2.30	Lee	cymbalgroup.com

* indica a chave principal.

Nota: a chave principal pode ser uma combinação de várias colunas, embora seja uma única coluna neste exemplo.

A seguinte consulta capta combinações únicas de principal.ip, principal.user.employee_id e target.domain. Filtra os resultados com base na prevalência do target.domain:

events:
  $e.principal.ip = $principal_ip
  $e.principal.user.employee_id = $principal_user_employee_id
  $e.target.domain.name = $target_domain
  $e.target.domain.prevalence.day_count < 5

// To run this query as a rule, add Condition Section here 
// condition:$e

Resultados da consulta:

ip	empid	domínio
192.0.2.10	Dana	altostrat.com
192.0.2.30	Lee	examplepetstore.com
192.0.2.20	Quinn	altostrat.com

Exemplo: use write_row para escrever o resultado da consulta numa tabela de dados

Exemplo de regra:

  rule udm_write_data_table {
  meta:
      description = "Writeto data table"
  events:
    $e.principal.user.employee_id = $principal_user_employee_id
    $e.target.domain.name = $target_domain
    $e.target.domain.prevalence.day_count < 5

  outcome:
    $hostname = $target_domain
    $principal_emp_id = $principal_user_employee_id
  
  condition:
    $e

  export:
    %ips_with_hostnames.write_row(
        employeeid:$principal_emp_id,
        hostname:$hostname
    )
  }

• Exemplo de pesquisa:

  events:
    $e.principal.user.employee_id = $principal_user_employee_id
    $e.target.domain.name = $target_domain
    $e.target.domain.prevalence.day_count < 5
  
  outcome:
    $hostname = $target_domain
    $principal_emp_id = $principal_user_employee_id
  
  export:
    %ips_with_hostnames.write_row(
      employeeid:$principal_emp_id,
      hostname:$hostname
    )
  

Exemplo: compreender write_row

No exemplo seguinte, user e ip são usados como chaves principais. Cada deteção que persiste na tabela de deteções resulta numa avaliação da chamada de função na secção de exportação da consulta.

Exemplo de regra:

  rule udm_write_data_table {
  meta:
    description = "Write data table"
  events:
    $e.metadata.event_type = "USER_LOGIN"
    all $e.security_result.action != "BLOCK"
    all $e.security_result.action != "UNKNOWN_ACTION"

    $user = $e.principal.user.userid
    $ip = $e.target.ip
    $ts = $e.metadata.event_timestamp.seconds

  match:
    $user, $ip over 1h

  outcome:
    $first_seen = min($ts)

  condition:
    $e

  export:
    %successful_logins.write_row(user:$user, ip:$ip)
  }

• Exemplo de pesquisa:

  events:
    $e.metadata.event_type = "USER_LOGIN"
    all $e.security_result.action != "BLOCK"
    all $e.security_result.action != "UNKNOWN_ACTION"
  
    $ts = $e.metadata.event_timestamp.seconds
  
  outcome:
    $user = $e.principal.user.userid
    $ip = $e.target.ip[0]
  
  export:
    %successful_logins.write_row(user:$user, ip:$ip)
  

  Seguem-se os dados de eventos:

  metadata: {
    event_type: USER_LOGIN
    event_timestamp: { seconds: 1283299200 }
  }
  principal: {
    user: {
      userid: "charlie"
    }
  }
  target: {
    ip: ["192.0.2.135", "192.0.2.136"]
  }
  security_result: {
    action: ALLOW
  }
  

• As seguintes deteções são devolvidas quando esta consulta é executada como uma regra:

  ID de deteção	Match $user	Match $ip
  0	charlie	192.0.2.135
  1	charlie	192.0.2.136

  A tabela de dados contém o seguinte:

  user	ip
  charlie	192.0.2.135
  charlie	192.0.2.136

Nota: se clicar em Executar teste no editor de regras para verificar uma regra, os dados de exemplo não são mantidos na tabela de dados.

• A consulta de pesquisa seguinte ilustra o suporte oferecido na Pesquisa para escrever valores escalares em tabelas de dados.

  Nota: esta opção não é suportada em regras.

  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
  
  export:
    %summary_table.write_row(col_name: $e.metadata.product_name, Vendor_name: $e.metadata.vendor_name)
  

Enriqueça o gráfico de entidades com uma tabela de dados

Pode usar tabelas de dados para adicionar, remover ou substituir as entidades apresentadas num gráfico de entidades a partir de regras. Use funções na secção setup para indicar como a tabela de dados deve ser unida, anexada ou usada para remover entidades de eventos de entidades referenciados na secção events.

Nota: esta opção não é suportada com a Pesquisa.

Pode usar o seguinte modelo de regra para modificar um gráfico de entidades:

rule entity_graph_template {

  meta:
    ...

  setup:
    // import the data table into entity graph
    <enrichment_keyword> <join_condition>

  events:
    ...

  match:
    ...

  condition:
    ...
}

Pode usar as seguintes funções YARA-L 2.0 para melhorar o gráfico de entidades com uma tabela de dados:

• graph_override: substitui as linhas no gráfico de entidades que correspondem à condição de junção com dados da tabela de dados.

  Por exemplo: [graph_override](?tab=t.0#heading=h.v0fps7eke1if)

• graph_append: anexa as linhas da tabela de dados às linhas no gráfico de entidades. A operação graph_append requer uma matriz que inclua uma variável de tabela de dados e uma variável de evento de entidade, em vez de uma condição de junção.

  No exemplo seguinte, $g1 é a variável do gráfico de entidades e example_table é a tabela de dados: graph_append [$g1, %example_table]

  Para a função append, as tabelas de dados devem incluir as seguintes colunas para validar a entidade:

  • start_time (mapeado para metadata.interval.start_time.seconds)

  • end_time (mapeado para metadata.interval.end_time.seconds)

  Não é possível mapear colunas de tabelas de dados para campos de metadados através da interface Web. Para append exemplos de utilização, as tabelas de dados têm de ser criadas através da API Chronicle (https://cloud.google.com/chronicle/docs/reference/rest/v1alpha/projects.locations.instances.dataTables/create)

• graph_exclude: remove as linhas no gráfico de entidades que correspondem à condição join.

  Por exemplo: [graph_exclude](?tab=t.0#heading=h.o0qbb5paki6g)

A condição de junção tem de ser uma expressão de igualdade entre a coluna da tabela de dados e o campo do gráfico de entidades. Para as funções graph_override e graph_exclude, a sintaxe para aceder a uma tabela de dados é a seguinte:

<data_table_name>.<column_name>

Qualquer filtro especificado para o <entity_variable> na secção de eventos é aplicado após o respetivo melhoramento com a tabela de dados.

Depois de a entidade no gráfico de entidades ser enriquecida com a entidade na tabela de dados, a variável de entidade no gráfico de entidades tem de ser associada à entidade UDM.

Substitua o gráfico de entidades por dados da tabela de dados

Com a função graph_override, os campos presentes no gráfico de entidades e na tabela de dados são substituídos por campos da tabela de dados. Os campos presentes no gráfico de entidades e não na tabela de dados permanecem iguais. Os campos não presentes no gráfico de entidades, mas presentes na tabela de dados, estão incluídos.

Apenas as colunas da tabela de dados mapeadas substituem as colunas do gráfico de entidades. As colunas não mapeadas são adicionadas ao campo additional da entidade do gráfico ao qual a tabela de dados está associada.

Exemplo: correspondência numa única junção

No exemplo seguinte, as linhas no gráfico de entidades que correspondem à condição de junção entre a coluna da tabela de dados e o campo do gráfico de entidades ($g1.graph.entity.ip = %example_table.my_ip) são substituídas pela tabela de dados.

rule rule_override {
  meta:
    description = "Override entity context with data table before joining with UDM event"

  setup:
    //Rows in the entity graph that match the join condition are overridden by the data table
    graph_override ($g1.graph.entity.ip = %example_table.my_ip)

  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.security_result.action = "ALLOW"

    // Filter will be applied after graph is overridden by data table
    $g1.graph.entity.hostname = "ftp01"

    // Accessing unmapped columns
    $g1.graph.additional.fields["Owner"] = "alice"

    // Joining the UDM event with the enriched entity graph
    $e.target.ip = $iocip
    $g1.graph.entity.ip = $iocip

  match:
    $iocip over 1h

  condition:
    $e and $g1
}

Para usar uma coluna não mapeada (por exemplo, "Proprietário") da tabela de dados, use uma declaração equivalente para $g1.graph.entity.owner = "alice" is $g1.graph.additional.fields["Owner"] = "alice". Isto deve-se ao facto de todas as colunas não mapeadas da tabela de dados serem incluídas no campo additional do gráfico de entidades ($g1).

As tabelas seguintes ilustram uma operação de substituição em que as linhas no gráfico de entidades são enriquecidas quando o campo IP na tabela de dados corresponde ao campo IP no gráfico de entidades.

Gráfico de entidades existente
Nome do anfitrião	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

Tabela de dados
Nome do anfitrião	IP	MAC	Proprietário
ftp01	10.1.1.4	…:bb	alice
h1	10.1.1.6	…:cc	bob
h2	10.1.1.7	…:dd	chris
h3	10.1.1.4	…:ee	doug

Gráfico de entidades enriquecido
Nome do anfitrião	IP	MAC	Proprietário
ftp01	10.1.1.4	…:bb	alice
www01	10.1.1.5	…:02
h3	10.1.1.4	…:ee	doug

Exemplo: correspondência em várias junções

No exemplo seguinte, as linhas no gráfico de entidades que correspondem às várias condições de junção ($g1.graph.entity.ip = %example_table.my_ip e $g1.graph.entity.hostname = %example_table.my_hostname) são substituídas pela tabela de dados.

rule rule_override {
meta:
    description = "Override Entity context with Data Table before joining with UDM event"
setup:
  // example with more than one condition
  graph_override ($g1.graph.entity.ip = %example_table.my_ip and
  $g1.graph.entity.hostname = %example_table.my_hostname) 
events:
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.security_result.action = "ALLOW"

  // Filter will be applied after graph is overridden by data table
  $g1.graph.entity.hostname = "ftp01"

  // joining the UDM event with the enriched entity graph
  $e.target.ip = $iocip
  $g1.graph.entity.ip = $iocip

match:
  $iocip over 1h

condition:
  $e and $g1
}

As tabelas seguintes ilustram uma operação de substituição em que as linhas do gráfico de entidades são enriquecidas quando o campo IP e o campo de nome do anfitrião na tabela de dados correspondem ao campo IP e ao campo de nome do anfitrião no gráfico de entidades.

Gráfico de entidades existente
Nome do anfitrião	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

Tabela de dados
Nome do anfitrião	IP	MAC	Proprietário
ftp01	10.1.1.4	…:bb	alice
h1	10.1.1.5	…:cc	bob
h2	10.1.1.6	…:dd	chris
h3	10.1.1.4	…:ee	doug

Gráfico de entidades enriquecido
Nome do anfitrião	IP	MAC	Proprietário
ftp01	10.1.1.4	…:bb	alice
www01	10.1.1.5	…:02

Anexe dados da tabela de dados ao gráfico de entidades

Com a função graph_append, não é necessária nenhuma condição de junção.

No exemplo seguinte, todas as linhas na tabela de dados são anexadas às linhas no gráfico de entidades.

Nota: não existe eliminação de duplicados das linhas anexadas ao gráfico de entidades. Isto significa que, se uma linha estiver presente no gráfico de entidades e na tabela de dados, ambas as linhas estão presentes no gráfico de entidades enriquecido.

rule rule_append {
meta:
  description = "Data table append entity"
   
setup:
  graph_append [$g1, %example_table]

events:
    // filter UDM events
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.security_result.action = "ALLOW"

  // Join the filtered UDM events with the enriched graph
  $e.target.ip = $iocip
  $g1.graph.entity.ip = $iocip

match:
  $iocip over 1h

condition:
  $e and $g1
}

A tabela de exemplo seguinte ilustra uma operação de anexação em que as linhas da tabela de dados são anexadas às linhas no gráfico de entidades:

Gráfico de entidades existente
Nome do anfitrião	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

Tabela de dados
IP	MAC	Proprietário
10.1.1.4	…:01	alice
10.1.1.6	…:cc	bob
10.1.1.7	…:dd	chris
10.1.1.4	…:ee	doug

Gráfico de entidades enriquecido
Nome do anfitrião	IP	MAC	Proprietário
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02
	10.1.1.4	…:bb	alice
	10.1.1.6	…:cc	bob
	10.1.1.7	…:dd	chris
	10.1.1.4	…:ee	doug

Use graph_exclude para remover linhas do gráfico de entidades

Com a função graph_exclude, as linhas no gráfico de entidades que correspondem à condição de junção são removidas do gráfico de entidades.

No exemplo seguinte, todas as linhas no gráfico de entidades que correspondem à condição de junção especificada (entre a coluna da tabela de dados e o campo do gráfico de entidades) são removidas. Não são adicionadas linhas da tabela de dados ao gráfico de entidades.

rule rule_exclude {

    meta:
    setup:
      graph_exclude ($g1.graph.entity.ip = %example_table.ip)

    events:
        $e.metadata.event_type = "NETWORK_CONNECTION"
        $e.security_result.action = "ALLOW"
        $e.target.ip = $iocip
        $g1.graph.entity.ip = $iocip

    match:
        $iocip over 1h

    condition:
        $e and $g1
}

As tabelas seguintes ilustram uma operação de exclusão na qual as linhas do gráfico de entidades que correspondem ao campo IP da tabela de dados são removidas:

Gráfico de entidades existente
Nome do anfitrião	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

Tabela de dados
IP	MAC	Proprietário
10.1.1.4	…:bb	alice
10.1.1.6	…:cc	bob
10.1.1.7	…:dd	chris

Gráfico de entidades enriquecido
Nome do anfitrião	IP	MAC
www01	10.1.1.5	…:02

Limitações

• Número máximo de tabelas de dados para uma conta do Google SecOps: 1000.

• As tabelas de dados só suportam dados CSV. As tabelas de dados suportam valores separados por tabulações apenas quando adiciona uma nova tabela de dados e importa um ficheiro de valores separados por tabulações (TSV).

• Os campos da tabela de dados não suportam carateres de vírgula (,).

• Os limites no número de declarações in quando faz referência a uma lista de referências numa consulta também se aplicam a declarações in numa tabela de dados.

• Número máximo de declarações in numa consulta para colunas do tipo de dados String e Number: 7.

• Número máximo de declarações in com operadores de expressões regulares: 4.

• Número máximo de declarações in com operadores CIDR: 2.

• Máximo de colunas por tabela de dados: 1000.

• Máximo de linhas por tabela de dados: 10 milhões.

• Limite máximo agregado do volume de dados nas tabelas de dados numa conta: 1 TB.

• Limite máximo de apresentação na página Web para linhas de tabelas de dados na vista do editor de texto e de tabelas: 10 000 linhas.

• Limite máximo de tamanho de carregamento de ficheiros para a criação de tabelas de dados: 10 GB.

• Não são permitidos marcadores de posição na secção de configuração.

• As colunas não mapeadas de uma tabela de dados com o tipo de dados definido como string só podem ser associadas a campos de string de eventos ou entidades do UDM.

• Use apenas colunas não mapeadas numa tabela de dados com um tipo de dados definido como cidr ou regex para CIDR ou expressão regular.

• Pesquisas de tabelas de dados: os carateres universais de expressões regulares não são suportados e os termos de pesquisa estão limitados a 100 carateres.

Limitações para junções de tabelas de dados em regras

As seguintes limitações aplicam-se às junções de tabelas de dados em regras.

• A obtenção de todas as amostras de eventos para deteções não é suportada quando usa junções de tabelas de dados com eventos.

• Ao contrário das entidades e do UDM, as tabelas de dados não suportam marcadores de posição. Isto leva às seguintes limitações:

  • Não pode aplicar um conjunto de filtros a uma tabela de dados e juntá-lo a uma entidade do UDM.

  • Não pode aplicar um conjunto diferente de filtros à mesma tabela de dados enquanto a associa a outro marcador de posição do UDM.

  Por exemplo, uma tabela de dados denominada dt com três colunas: my_hostname, org e my_email e com a seguinte regra:

  events:
    $e1.principal.hostname =  %dt.my_hostname
    %dt.org ="hr"
  
    $e2.principal.email =  %dt.my_email
    %dt.org !="hr"
  

Todos os filtros numa tabela de dados são aplicados primeiro e, em seguida, as linhas filtradas da tabela de dados são unidas com o UDM. Neste caso, os filtros contraditórios (%dt.org ="hr" and %dt.org !="hr") na tabela dt resultam numa tabela de dados vazia, que é, em seguida, unida com e1 e e2.

Limitações na utilização de tabelas de dados com regras

As seguintes limitações aplicam-se às tabelas de dados quando usadas com regras.

Limitações da frequência de execução

A frequência de execução em tempo real não é suportada para regras com tabelas de dados.

Limitações para a saída para tabelas de dados

• Os modificadores any e all não são suportados para colunas de campos repetidos em tabelas de dados.

• A indexação de matrizes não é suportada para colunas de campos repetidos em tabelas de dados.

• Só pode exportar variáveis de resultados para uma tabela de dados. Não pode exportar diretamente caminhos de eventos nem colunas de tabelas de dados.

• As listas de colunas têm de incluir as colunas de chave primária para tabelas de dados.

• Pode ter um máximo de 20 resultados.

• Se não existir uma tabela de dados, é criada uma nova tabela com o tipo de dados string predefinido para todas as colunas, seguindo a ordem especificada.

• Apenas uma regra pode escrever numa tabela de dados de cada vez. Se uma regra tentar escrever numa tabela de dados na qual outra regra já está a escrever, a compilação da regra falha.

• Não existe garantia de que uma regra de produtor possa adicionar linhas a uma tabela de dados antes de uma regra de consumidor para essa tabela de dados começar.

• Uma única regra tem um limite no número de linhas de resultados. É aplicado um limite máximo de 10 000 linhas ao resultado e aos dados persistentes,bem como às tabelas de dados.

• Quando atualiza uma linha, os novos valores de todas as colunas não principais substituem os antigos. As atualizações, incluindo a adição de uma nova linha, demoram aproximadamente cinco minutos a ficar disponíveis para consulta.

Limitações do enriquecimento de entidades a partir de tabelas de dados

• Só pode aplicar uma operação de enriquecimento (override, append ou exclude) a uma única variável de gráfico de entidades.

• Cada operação de enriquecimento só pode usar uma tabela de dados.

• Pode definir um máximo de duas operações de enriquecimento de qualquer tipo na secção setup de uma regra YARA-L.

No exemplo seguinte, é aplicada uma operação override à variável $g1 do gráfico de entidades e uma operação append à variável $g2 do gráfico de entidades.

    setup:
    graph_override($g1.graph.entity.user.userid = %table1.myids)
    graph_append [$g2, %table1]

No exemplo anterior, a mesma tabela de dados (table1) é usada para melhorar diferentes gráficos de entidades. Também pode usar tabelas de dados diferentes para melhorar os diferentes gráficos de entidades, da seguinte forma:

    setup:
    graph_override($g1.graph.entity.user.userid = %table1.myids)
    graph_append [$g2, %table2]

Limitações da utilização de tabelas de dados com a Pesquisa

As seguintes limitações aplicam-se às tabelas de dados quando usadas com a Pesquisa:

• Não pode executar consultas de pesquisa em tabelas de dados através da API Chronicle. As consultas só são suportadas através da interface Web.

• Uma única execução de consulta pode gerar um máximo de 1 milhão de linhas para uma tabela de dados ou 1 GB, consoante o limite que for atingido primeiro.

• A saída da pesquisa para uma tabela de dados ignora as linhas de eventos se excederem 5 MB.

• O enriquecimento de entidades não é suportado com a Pesquisa.

• As tabelas de dados não são suportadas para utilizadores de chaves de encriptação geridas pelo cliente (CMEK).

• As gravações estão limitadas a 6 por minuto por cliente.

• O suporte da API não está disponível para operações de tabelas de dados relacionadas com a Pesquisa.

• As consultas de estatísticas não são suportadas com associações de tabelas de dados.

• A tabela de dados e as junções de tabelas de dados só são suportadas com eventos do UDM e não com entidades.

  Suportado: %datatable1.column1 = %datatable2.column1

  Não suportado: graph.entity.hostname = %sample.test

• Não pode incluir uma variável match na secção export de uma consulta de estatísticas.

  Por exemplo, o seguinte não é suportado:

    match:
        principal.hostname
    export:
        %sample.write_row(
        row: principal.hostname
      )
  

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais da Google SecOps.