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

Este artigo descreve como identificar, comparar e migrar as suas regras de deteção do ArcSight para regras de análise 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 as seguintes considerações enquanto identifica as suas 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 você entende a terminologia da regra.
• Revise quaisquer regras que não tenham ativado alertas nos últimos seis a doze 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 abordar 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 Microsoft Sentinel:

   • Se as regras incorporadas forem suficientes, utilize modelos de regras incorporadas para criar regras para a sua própria área de trabalho.

     No Microsoft Sentinel, aceda ao separador Modelos > de Regras de Análise de Configuração > e crie e atualize cada regra de análise relevante.

     Para aprender a criar regras a partir de templates incorporados, veja Criar regras de análise agendada a partir de templates.

   • Se tiver deteções que não estão abrangidas pelas regras incorporadas do Microsoft Sentinel, 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 regras incorporadas 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.

        Considere filtros, regras de correlação, listas ativas, conjuntos de referência, listas de observação, anomalias de deteção, agregações, etc. Pode usar referências fornecidas pelo seu SIEM antigo para mapear a sintaxe das consultas do ArcSight para o KQL.

     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 criar e usar playbooks para ações de regras, consulte Automatizar a resposta a ameaças com playbooks no Microsoft Sentinel.

Saiba mais sobre as regras de análise:

• 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.
• Linguagem de Consulta Kusto (KQL): Pode usar o KQL para enviar pedidos apenas de 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 ArcSight.

Mapear e comparar exemplos de regras

Use os seguintes exemplos para comparar as regras de deteção do ArcSight com consultas equivalentes do Microsoft Sentinel escritas na Linguagem de Consulta Kusto (KQL).

Exemplo de filtro (AND): ArcSight

Eis um exemplo de regra de filtro com as condições AND no ArcSight.

Exemplo de filtro (AND): KQL

Aqui está a regra de filtragem com AND condições em KQL.

SecurityEvent
| where EventID == 4728
| where SubjectUserName =~ "AutoMatedService"
| where isnotempty(SubjectDomainName)

Esta regra pressupõe que o Agente de Monitorização do Azure (AMA) recolhe os Eventos Segurança do Windows. Por conseguinte, a regra utiliza a tabela Microsoft Sentinel SecurityEvent.

Considere estas melhores práticas:

• Para otimizar as consultas, evite operadores não sensíveis a maiúsculas e minúsculas sempre que possível: =~.
• Utilize == se o valor não for sensível a maiúsculas e minúsculas.
• Ordene os filtros começando pela declaração where, que filtra mais dados.

Exemplo de filtro (OR): ArcSight

Eis um exemplo de regra de filtro com as condições OR no ArcSight.

Exemplo de filtro (OR): KQL

Eis algumas maneiras de escrever a regra de filtro com condições OR em KQL.

Como primeira opção, utilize a in instrução :

SecurityEvent
| where SubjectUserName in
 ("Adm1","ServiceAccount1","AutomationServices")

Como segunda opção, utilize a or instrução :

SecurityEvent
| where SubjectUserName == "Adm1" or 
SubjectUserName == "ServiceAccount1" or 
SubjectUserName == "AutomationServices"

Embora ambas as opções sejam idênticas no desempenho, recomendamos a primeira opção, que é mais fácil de ler.

Exemplo de filtro aninhado: ArcSight

Eis um exemplo de uma regra de filtro aninhada no ArcSight.

Eis uma regra para o /All Filters/Soc Filters/Exclude Valid Users filtro.

Exemplo de filtro aninhado: KQL

Eis algumas maneiras de escrever a regra de filtro com condições OR em KQL.

Como primeira opção, utilize um filtro direto com uma where instrução:

SecurityEvent
| where EventID == 4728 
| where isnotempty(SubjectDomainName) or 
isnotempty(TargetDomainName) 
| where SubjectUserName !~ "AutoMatedService"

Como segunda opção, utilize uma função KQL:

1. Guarde a seguinte consulta como uma função KQL com o alias ExcludeValidUsers .

       SecurityEvent
       | where EventID == 4728
       | where isnotempty(SubjectDomainName)
       | where SubjectUserName =~ "AutoMatedService"
       | project SubjectUserName
   

2. Utilize a seguinte consulta para filtrar o alias ExcludeValidUsers .

       SecurityEvent    
       | where EventID == 4728
       | where isnotempty(SubjectDomainName) or 
       isnotempty(TargetDomainName)
       | where SubjectUserName !in (ExcludeValidUsers)
   

Como terceira opção, utilize uma função de parâmetro:

1. Crie uma função de parâmetro com ExcludeValidUsers como nome e alias.

2. Defina os parâmetros da função. Por exemplo:

       Tbl: (TimeGenerated:datetime, Computer:string, 
       EventID:string, SubjectDomainName:string, 
       TargetDomainName:string, SubjectUserName:string)
   

3. A parameter função tem a seguinte consulta:

       Tbl
       | where SubjectUserName !~ "AutoMatedService"
   

4. Execute a seguinte consulta para invocar a função de parâmetro:

       let Events = (
       SecurityEvent 
       | where EventID == 4728
       );
       ExcludeValidUsers(Events)
   

Como quarta opção, utilize a join função :

let events = (
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName) 
or isnotempty(TargetDomainName)
);
let ExcludeValidUsers = (
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName)
| where SubjectUserName =~ "AutoMatedService"
);
events
| join kind=leftanti ExcludeValidUsers on 
$left.SubjectUserName == $right.SubjectUserName

Considerations

• Recomendamos que utilize um filtro direto com uma where instrução (primeira opção) devido à sua simplicidade. Para um desempenho otimizado, evite utilizar join (quarta opção).
• Para otimizar as consultas, evite os operadores =~ e !~ que não distinguem maiúsculas de minúsculas sempre que possível. Utilize os == operadores e != se o valor não for sensível a maiúsculas e minúsculas.

Exemplo de lista ativa (pesquisa): ArcSight

Eis uma regra de lista ativa (consulta) no ArcSight.

Exemplo de lista ativa (pesquisa): KQL

A seguinte consulta KQL utiliza a lista de observação Cyber-Ark Contas de Exceção para filtrar os resultados da pesquisa.

let Activelist=(
_GetWatchlist('Cyber-Ark Exception Accounts')
| project Account );
CommonSecurityLog
| where DestinationUserName in (Activelist)
| where DeviceVendor == "Cyber-Ark"
| where DeviceAction == "Get File Request"
| where DeviceCustomNumber1 != ""
| project DeviceAction, DestinationUserName, 
TimeGenerated,SourceHostName, 
SourceUserName, DeviceEventClassID

Ordene os filtros começando pela instrução where que filtra mais dados.

Exemplo de correlação (correspondente): ArcSight

Eis uma regra ArcSight de exemplo que define uma condição aplicada a um conjunto de eventos base, utilizando a instrução Matching Event.

Exemplo de correlação (correspondente): KQL

O seguinte exemplo do KQL mostra como implementar a regra de correlação de correspondência do ArcSight no Microsoft Sentinel.

let event1 =(
SecurityEvent
| where EventID == 4728
);
let event2 =(
SecurityEvent
| where EventID == 4729
);
event1
| join kind=inner event2 
on $left.TargetUserName==$right.TargetUserName

Melhores práticas

• Para otimizar a consulta, certifique-se de que a tabela mais pequena está no lado esquerdo da join função.
• Se o lado esquerdo da tabela for relativamente pequeno (até 100 K registos), adicione hint.strategy=broadcast para um melhor desempenho.

Exemplo de correlação (janela de tempo): ArcSight

Eis um exemplo de regra do ArcSight que define uma condição para um conjunto de eventos base, utilizando a instrução Matching Event e a condição de filtro Wait time.

Exemplo de correlação (janela de tempo): KQL

O exemplo seguinte do KQL implementa uma regra de correlação com uma janela temporal equivalente ao exemplo do ArcSight.

let waittime = 10m;
let lookback = 1d;
let event1 = (
SecurityEvent
| where TimeGenerated > ago(waittime+lookback)
| where EventID == 4728
| project event1_time = TimeGenerated, 
event1_ID = EventID, event1_Activity= Activity, 
event1_Host = Computer, TargetUserName, 
event1_UPN=UserPrincipalName, 
AccountUsedToAdd = SubjectUserName 
);
let event2 = (
SecurityEvent
| where TimeGenerated > ago(waittime)
| where EventID == 4729
| project event2_time = TimeGenerated, 
event2_ID = EventID, event2_Activity= Activity, 
event2_Host= Computer, TargetUserName, 
event2_UPN=UserPrincipalName,
 AccountUsedToRemove = SubjectUserName 
);
 event1
| join kind=inner event2 on TargetUserName
| where event2_time - event1_time < lookback
| where tolong(event2_time - event1_time ) >=0
| project delta_time = event2_time - event1_time,
 event1_time, event2_time,
 event1_ID,event2_ID,event1_Activity,
 event2_Activity, TargetUserName, AccountUsedToAdd,
 AccountUsedToRemove,event1_Host,event2_Host, 
 event1_UPN,event2_UPN

Exemplo de agregação: ArcSight

Segue-se um exemplo de regra do ArcSight com definições de agregação: três ocorrências em 10 minutos.

Exemplo de agregação: KQL

A seguinte consulta KQL mostra como detetar três ou mais correspondências usando agregação.

SecurityEvent
| summarize Count = count() by SubjectUserName, 
SubjectDomainName
| where Count >3

Passo seguinte