Migrar regras de deteção do QRadar para Microsoft Sentinel

Este artigo descreve como identificar, comparar e migrar as suas regras de deteção do QRadar para as regras incorporadas do Microsoft Sentinel. Guia-o através do inventário das suas deteções existentes, comparando a terminologia das regras entre o QRadar e o Microsoft Sentinel, e escolhendo o caminho de migração correto — seja adotando modelos de análise integrados do Content Hub, convertendo consultas com uma ferramenta online ou escrevendo consultas personalizadas para a Linguagem de Consultas Kusto (KQL). No final, terá uma abordagem estruturada para migrar as suas regras de deteção, aproveitando as análises de machine learning do Microsoft Sentinel.

Identificar e migrar regras

Microsoft Sentinel utiliza a análise de machine learning para criar incidentes de alta fidelidade e acionáveis e algumas das suas deteções existentes podem ser redundantes no Microsoft Sentinel. Por conseguinte, não migre todas as regras de deteção e análise de forma cega. Reveja estas considerações ao identificar as regras de deteção existentes.

• Certifique-se de que seleciona casos de utilização que justificam a migração de regras, considerando a prioridade comercial e a eficiência.
• Verifique se compreende os tipos de regras do Microsoft Sentinel.
• Verifique se compreende a terminologia da regra.
• Reveja as regras que não acionaram quaisquer alertas nos últimos 6 a 12 meses e determine se ainda são relevantes.
• Elimine alertas ou ameaças de baixo nível que ignora regularmente.
• Utilize a funcionalidade existente e verifique se as regras de análise incorporadas do Microsoft Sentinel podem resolver os seus casos de utilização atuais. Uma vez que Microsoft Sentinel utiliza a análise de machine learning para produzir incidentes acionáveis e de alta fidelidade, é provável que algumas das suas deteções existentes já não sejam necessárias.
• Confirme as origens de dados ligadas e reveja os métodos de ligação de dados. Revisite as conversações de recolha de dados para garantir a profundidade e a amplitude dos dados em todos os casos de utilização que planeia detetar.
• Explore os recursos da comunidade, como o Marketplace de Deteção de Ameaças Principais do SOC , para verificar se as suas regras estão disponíveis.
• Considere se um conversor de consulta online, como Uncoder.io, pode funcionar para as suas regras.
• Se as regras não estiverem disponíveis ou não puderem ser convertidas, têm de ser criadas manualmente através de uma consulta KQL. Reveja o mapeamento de regras para criar novas consultas.

Saiba mais sobre as melhores práticas para migrar regras de deteção.

Para migrar as regras de análise para Microsoft Sentinel:

1. Verifique se tem um sistema de teste implementado para cada regra que pretende migrar.

   1. Prepare um processo de validação para as regras migradas, incluindo scripts e cenários de teste completos.

   2. Certifique-se de que a sua equipa tem recursos úteis para testar as regras migradas.

   3. Confirme que tem as origens de dados necessárias ligadas e reveja os métodos de ligação de dados.

2. Verifique se as deteções estão disponíveis como modelos incorporados no Hub de Conteúdos:

   • Se as regras incorporadas forem suficientes, instale as soluções relevantes e utilize os modelos para criar regras para a área de trabalho.

     1. No Microsoft Sentinel, aceda a Gestão de conteúdos > Hub de conteúdos.
     2. Procure e instale a regra de análise relevante.

     Para obter mais informações, consulte Descobrir e gerir conteúdo pronto a utilizar do Microsoft Sentinel e Criar regras de análise agendadas a partir de modelos.

   • Se tiver deteções que não estão abrangidas pelas regras incorporadas disponíveis no HubContent, experimente um conversor de consultas online, como Uncoder.io para converter as suas consultas em KQL.

     Identifique a condição de acionamento e a ação da regra e, em seguida, crie e revise a sua consulta KQL.

   • Se nem as soluções do Hub de Conteúdos nem um conversor de regras online forem suficientes, terá de criar a regra manualmente. Nestes casos, utilize os seguintes passos para começar a criar a regra:

     1. Identifique as origens de dados que pretende utilizar na regra. Vai querer criar uma tabela de mapeamento entre origens de dados e tabelas de dados no Microsoft Sentinel para identificar as tabelas que pretende consultar.

     2. Identifique quaisquer atributos, campos ou entidades nos seus dados que pretenda utilizar nas suas regras.

     3. Identifique os critérios e a lógica da regra. Nesta fase, poderá querer utilizar modelos de regras como exemplos de como construir as suas consultas KQL como exemplos de como construir as suas consultas KQL.

        Considere filtros, regras de correlação, listas ativas, conjuntos de referência, listas de observação, anomalias de deteção, agregações, etc. Você pode usar referências fornecidas pelo SIEM herdado para entender a melhor forma de mapear a sintaxe da consulta.

     4. Identifique a condição de acionamento e a ação da regra e, em seguida, crie e reveja a consulta KQL. Ao analisar a sua consulta, considere os recursos com orientações para otimização do KQL.

3. Teste a regra com cada um dos seus casos de utilização relevantes. Se não fornecer os resultados esperados, talvez seja melhor rever o KQL e testá-lo novamente.

4. Quando estiver satisfeito, pode considerar que a regra foi migrada. Crie um guia de procedimentos para a ação da sua regra, se necessário. Para obter mais informações, veja Automatizar a resposta a ameaças com manuais de procedimentos no Microsoft Sentinel.

Para mais informações sobre as regras de análise do Microsoft Sentinel e o KQL, consulte os seguintes recursos:

• Regras de análise agendada no Microsoft Sentinel: Use o agrupamento de alertas para reduzir a fadiga dos alertas, agrupando alertas que ocorrem dentro de um determinado período de tempo.
• Mapear campos de dados para entidades no Microsoft Sentinel: Para permitir que engenheiros SOC definam entidades como parte das provas a acompanhar durante uma investigação. O mapeamento de entidades também permite que os analistas do SOC tirem partido de um gráfico de investigação intuitivo que pode ajudar a reduzir o tempo e o esforço.
• Investigue incidentes com dados UEBA: Como exemplo de como usar provas para destacar eventos, alertas e quaisquer favoritos associados a um incidente específico no painel de pré-visualização do incidente.
• Kusto Query Language (KQL): Que pode usar para enviar pedidos de apenas leitura para a sua base de dados Log Analytics para processar dados e devolver resultados. O KQL também é utilizado noutros serviços Microsoft, como o Microsoft Defender para Endpoint e o Application Insights.

Comparar a terminologia das regras

Esta tabela ajuda-o a clarificar o conceito de uma regra no Microsoft Sentinel em comparação com o QRadar. Os tipos de regras do Microsoft Sentinel incluem consultas agendadas, Fusion (que correlaciona automaticamente alertas de múltiplas fontes de dados em incidentes usando machine learning), Microsoft Security e Machine Learning (ML) Behavior Analytics.

Mapear e comparar exemplos de regras

Utilize estes exemplos para comparar e mapear regras do QRadar para Microsoft Sentinel em vários cenários. As consultas de exemplo são escritas na Linguagem de Consulta Kusto (KQL), a linguagem de consulta utilizada pelo Microsoft Sentinel.

Sintaxe comum dos testes de propriedades

Eis a sintaxe do QRadar para uma regra comum de testes de propriedades.

Testes de propriedade comuns: Exemplo de expressão regular (QRadar)

Eis a sintaxe de uma regra de testes de propriedade comum do QRadar de exemplo que utiliza uma expressão regular:

when any of <these properties> match <this regular expression>

Aqui está a regra de exemplo no QRadar:

Testes de propriedade comuns: Exemplo de expressão regular (KQL)

Eis a regra de testes de propriedades comuns com uma expressão regular em KQL.

CommonSecurityLog
| where tostring(SourcePort) matches regex @"\d{1,5}" or tostring(DestinationPort) matches regex @"\d{1,5}"

Testes de propriedade comuns: exemplo de consulta de filtro AQL (QRadar)

Aqui está a sintaxe de uma regra de exemplo de testes de propriedades comuns do QRadar que utiliza uma consulta de filtro AQL:

when the event matches <this> AQL filter query

Aqui está a regra de exemplo no QRadar:

Testes de propriedade comuns: exemplo de consulta de filtro AQL (KQL)

Aqui está a regra comum dos testes de propriedades com uma consulta de filtro AQL no KQL:

CommonSecurityLog
| where SourceIP == '10.1.1.10'

Testes comuns de atributos: exemplo de igual a/não igual a (QRadar)

Aqui está a sintaxe de uma regra de exemplo dos testes de propriedades comuns do QRadar que utiliza o equals operador ou not equals :

and when <this property> <equals/not equals> <this property>

Aqui está a regra de exemplo no QRadar:

Testes comuns de propriedades: exemplo de igual/não igual (KQL)

Aqui está a regra dos testes de propriedades comuns com o equals operador ou not equals no KQL:

CommonSecurityLog
| where SourceIP == DestinationIP

Sintaxe dos testes de data e hora

Aqui está a sintaxe do QRadar para uma regra de testes data/hora:

Testes de data/hora: Dia selecionado do exemplo do mês (QRadar)

Aqui está a sintaxe de uma regra de exemplo de testes de data/hora do QRadar que utiliza um dia selecionado do mês:

and when the event(s) occur <on/after/before> the <selected> day of the month

Aqui está a regra de exemplo no QRadar:

Testes de data/hora: exemplo de dia selecionado do mês (KQL)

Aqui está a regra dos testes de data/hora com um dia selecionado do mês no KQL:

SecurityEvent
 | where dayofmonth(TimeGenerated) < 4

Testes de data/hora: Exemplo de dia da semana selecionado (QRadar)

Eis a sintaxe de uma regra de teste de data/hora do QRadar de exemplo que utiliza um dia da semana selecionado:

and when the event(s) occur on any of <these days of the week{Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday}>

Aqui está a regra de exemplo no QRadar:

Testes de data/hora: exemplo de dia da semana selecionado (KQL)

Aqui está a regra dos testes de data/hora com um dia selecionado da semana no KQL:

SecurityEvent
 | where dayofweek(TimeGenerated) between (3d .. 5d)

Testes de data/hora: depois/antes/no exemplo (QRadar)

Aqui está a sintaxe de uma regra de exemplo de testes de data/hora do QRadar que usa , afterbefore, ou at operador:

and when the event(s) occur <after/before/at> <this time{12.00AM, 12.05AM, ...11.50PM, 11.55PM}>

Aqui está a regra de exemplo no QRadar:

Testes de data/hora: depois/antes/no exemplo (KQL)

Aqui está a regra dos testes de data/hora que usa o after, before, ou at operador no KQL:

SecurityEvent
| where format_datetime(TimeGenerated,'HH:mm')=="23:55"

TimeGenerated está em UTC/GMT.

Sintaxe dos testes de propriedades de eventos

Aqui está a sintaxe QRadar para uma regra de testes de propriedades de evento:

Testes de propriedades de eventos: exemplo de protocolo IP (QRadar)

Aqui está a sintaxe de uma regra de exemplo de propriedade de eventos QRadar que utiliza um protocolo IP:

and when the IP protocol is one of the following <protocols>

Aqui está a regra de exemplo no QRadar:

Testes de propriedades de eventos: exemplo de protocolo IP (KQL)

Aqui está a regra dos testes de propriedades do evento com um filtro de protocolo IP no KQL:

CommonSecurityLog
| where Protocol in ("UDP","ICMP")

Testes às propriedades de eventos: exemplo de cadeia da carga útil do evento (QRadar)

Aqui está a sintaxe de uma regra de exemplo de testes de propriedades de eventos QRadar que usa um Event Payload valor de string:

and when the Event Payload contains <this string>

Aqui está a regra de exemplo no QRadar:

Testes de propriedades do evento: Exemplo de cadeia de caracteres do payload do evento (KQL)

Aqui está a regra de testes da propriedade do evento com uma cadeia Event Payload em KQL. Para otimizar o desempenho, evite utilizar o search comando se já souber o nome da tabela.

CommonSecurityLog
| where DeviceVendor has "Palo Alto"

search "Palo Alto"

Funções: sintaxe dos contadores

Aqui está a sintaxe QRadar para uma regra de funções que usa contadores:

Contadores: exemplo de tempo e propriedade do evento (QRadar)

Aqui está a sintaxe de uma regra de exemplo de funções QRadar que usa um número definido de propriedades de eventos num número definido de minutos"

and when at least <this many> events are seen with the same <event properties> in <this many> <minutes>

Aqui está a regra de exemplo no QRadar:

Contadores: Exemplo temporal e de propriedade de evento (KQL)

Aqui está a regra dos contadores com propriedades de evento e condições temporais no KQL:

CommonSecurityLog
| summarize Count = count() by SourceIP, DestinationIP
| where Count >= 5

Funções: sintaxe de condições negativas

Aqui está a sintaxe QRadar para uma regra de funções que usa condições negativas:

Exemplo de condições negativas (QRadar)

Aqui está a sintaxe de uma regra de exemplo de funções QRadar que usa condições negativas:

and when none of <these rules> match in <this many> <minutes> after <these rules> match with the same <event properties>

Eis duas regras definidas no QRadar. As condições negativas baseiam-se nestas regras:

Aqui está um exemplo da regra das condições negativas baseada nas duas regras QRadar previamente definidas (Test2 e Test6):

Exemplo de condições negativas (KQL)

Aqui está a regra das condições negativas com uma rightanti junção no KQL:

let spanoftime = 10m;
let Test2 = (
CommonSecurityLog
| where Protocol !in ("UDP","ICMP")
| where TimeGenerated > ago(spanoftime)
);
let Test6 = (
CommonSecurityLog
| where SourceIP == DestinationIP
);
Test2
| join kind=rightanti Test6 on $left. SourceIP == $right. SourceIP and $left. Protocol ==$right. Protocol

Funções: sintaxe de condições simples

Aqui está a sintaxe QRadar para uma regra de funções que usa condições simples:

Exemplo de condições simples (QRadar)

Aqui está a sintaxe de uma regra de exemplo de funções QRadar que usa condições simples.:

and when an event matches <any|all> of the following <rules>

Aqui está a regra de exemplo no QRadar:

Exemplo de condições simples (KQL)

Aqui está a regra das condições simples no KQL:

CommonSecurityLog
| where Protocol !in ("UDP","ICMP") or SourceIP == DestinationIP

Sintaxe dos testes de IP/porta

Aqui está a sintaxe QRadar para uma regra de testes IP/porta:

Testes de IP/porta: exemplo de porta de origem (QRadar)

Aqui está a sintaxe de uma regra de exemplo do QRadar que especifica uma porta de origem:

and when the source port is one of the following <ports>

Aqui está a regra de exemplo no QRadar:

Testes de IP/porta: exemplo de porta de origem (KQL)

Aqui está a regra dos testes IP/porta com um filtro de porta de origem no KQL:

CommonSecurityLog
| where SourcePort == 20

Testes de IP/porta: exemplo de IP de origem (QRadar)

Aqui está a sintaxe de uma regra de exemplo do QRadar que especifica um IP de origem:

and when the source IP is one of the following <IP addresses>

Aqui está a regra de exemplo no QRadar:

Testes de IP/porta: exemplo de IP de origem (KQL)

Aqui está a regra dos testes IP/portas com um filtro IP de origem no KQL:

CommonSecurityLog
| where SourceIP in ("10.1.1.1","10.2.2.2")

Sintaxe dos testes da origem do registo

Aqui está a sintaxe QRadar para uma regra de testes de fonte de registo:

Exemplo de origem de logs (QRadar)

Aqui está a sintaxe de uma regra de exemplo do QRadar que especifica fontes de log:

and when the event(s) were detected by one or more of these <log source types>

Aqui está a regra de exemplo no QRadar:

Exemplo de fonte de registo (KQL)

Aqui está a regra dos testes de origem do log no KQL.

OfficeActivity
| where OfficeWorkload == "Exchange"

Passo seguinte