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

Este artigo descreve como identificar, comparar e migrar suas regras de detecção do QRadar para as regras internas do Microsoft Sentinel. Ele guia você no inventário das detecções existentes, comparando a terminologia das regras entre QRadar e Microsoft Sentinel, e escolhendo o caminho de migração correto — seja adotando templates de análise embutidos do Content Hub, convertendo consultas com uma ferramenta online ou escrevendo consultas personalizadas para a Linguagem de Consulta Kusto (KQL). Ao final, você terá uma abordagem estruturada para migrar suas regras de detecção enquanto aproveita as análises de aprendizado de máquina 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. Revise estas considerações ao identificar suas regras de detecçã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 você 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.
• Use a funcionalidade existente e verifique se as regras de análise internas do Microsoft Sentinel podem atender aos seus casos de uso 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 SOC Prime Threat Detection Marketplace, para verificar se 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 detecçã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, acesse Gerenciamento de conteúdo > Hub de conteúdo.
     2. Procure e instale a regra de análise relevante.

     Para obter mais informações, consulte Descobrir e gerenciar o conteúdo pronto para uso 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 gatilho e a ação de regra e, em seguida, construa e revise 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. Neste estágio, talvez você queira usar modelos de regra como exemplos de como construir suas consultas KQL como exemplos de como construir 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 a fim de entender como mapear melhor a sintaxe da sua consulta.

     4. Identifique a condição de disparo e a ação da regra e, em seguida, crie e revise sua consulta KQL. Ao revisar sua consulta, considere os recursos de orientação sobre otimização de KQL.

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

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

Para obter mais informações sobre Microsoft Sentinel regras de análise e 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 evidências a serem rastreadas 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 da UEBA: Como exemplo de como usar evidências para destacar eventos, alertas e quaisquer favoritos associados a um incidente específico no painel de pré-visualização do incidente.
• Linguagem de Consulta Kusto (KQL): Que você pode usar para enviar requisições somente leitura para seu banco de dados Log Analytics para processar dados e devolver resultados. O KQL também é utilizado em outros serviços da Microsoft, como Microsoft Defender para Ponto de Extremidade e Application Insights.

Compare a terminologia de 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), Segurança da Microsoft 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 usada pelo Microsoft Sentinel.

Sintaxe de testes de propriedades comuns

Esta é a sintaxe do QRadar para uma regra de testes de propriedades comuns.

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 propriedade comum com uma expressão regular no 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 usa 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 de testes de propriedades com uma consulta de filtro AQL no KQL:

CommonSecurityLog
| where SourceIP == '10.1.1.10'

Testes de propriedades comuns: exemplo de equals/not equals (QRadar)

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

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

Aqui está a regra de exemplo no QRadar:

Testes de propriedades comuns: exemplo de equals/not equals (KQL)

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

CommonSecurityLog
| where SourceIP == DestinationIP

Sintaxe de testes de data/hora

Aqui está a sintaxe do QRadar para uma regra de testes de 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 usa 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 de data/hora dos testes 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 o afteroperador , before, 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: exemplo de após/antes/em (KQL)

Aqui está a regra de 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 de testes de propriedade de evento

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 testes de propriedades de evento QRadar que usa 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 de testes de propriedades de evento com um filtro de protocolo IP no KQL:

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

Testes de propriedade de evento: exemplo de cadeia de caracteres de carga do evento (QRadar)

Aqui está a sintaxe de uma regra de exemplo de testes de propriedades de evento 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 propriedade de evento: exemplo de cadeia de caracteres de carga do evento (KQL)

Aqui está a regra de teste da propriedade de evento com uma cadeia de caracteres 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 de contadores

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

Contadores: exemplo de propriedade e hora 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 em um 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 de propriedade e hora do evento (KQL)

Aqui está a regra dos contadores com propriedades de evento e condições de tempo 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 de 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 simples das condições 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 de IP/porta:

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

Aqui está a sintaxe de uma regra de exemplo do QRadar especificando 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 de 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 especificando 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 de testes de IP/porta com um filtro de IP de origem no KQL:

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

Sintaxe de testes de origem de log

Aqui está a sintaxe QRadar para uma regra de teste de código de log:

Exemplo de origem de log (QRadar)

Aqui está a sintaxe de uma regra de exemplo do QRadar especificando as 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 origem do log (KQL)

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

OfficeActivity
| where OfficeWorkload == "Exchange"

Próximas etapas