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

Este artigo descreve como identificar, comparar e migrar suas regras de detecção do ArcSight para as 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. Examine as considerações a seguir 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 você entende a terminologia de regras.
• Revise quaisquer regras que não tenham acionado nenhum alerta 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.
• Use as funcionalidades existentes 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 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 embutidos, 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 gatilho e a ação de regra e, em seguida, construa e revise 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. Você pode usar referências fornecidas pelo seu SIEM antigo para mapear a sintaxe de consulta do ArcSight para o KQL.

     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 criar e usar playbooks para ações de regras, veja Automatizar 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 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): Você pode usar o KQL 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 ArcSight.

Mapear e comparar exemplos de regras

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

Exemplo de filtro (AND): ArcSight

Aqui está uma regra de filtro de exemplo com condições AND no ArcSight.

Exemplo de filtro (AND): KQL

Aqui está a regra de filtro com condições AND no 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: =~.
• Use == se o valor não diferencia maiúsculas de minúsculas.
• Ordene os filtros começando pela instrução where, que filtra mais dados.

Exemplo de filtro (OU): ArcSight

Aqui está uma regra de filtro de exemplo com condições OR no ArcSight.

Exemplo de filtro (OR): KQL

Aqui estão algumas maneiras de escrever a regra de filtro usando 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

Aqui está um exemplo de regra de filtro aninhada no ArcSight.

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

Exemplo de filtro aninhado: KQL

Aqui estão algumas maneiras de escrever a regra de filtro usando 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 suas consultas, evite os operadores =~ e !~ que não diferenciam maiúsculas de minúsculas, sempre que possível. Use os operadores == e != se o valor não diferencia maiúsculas de minúsculas.

Exemplo de lista ativa (pesquisa): ArcSight

Aqui está uma regra de lista ativa (consulta) no ArcSight.

Exemplo de lista ativa (pesquisa): KQL

A consulta KQL a seguir utiliza a lista de observação Cyber-Ark Exceptional Accounts para filtrar os resultados da consulta.

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

Veja uma regra de exemplo do ArcSight que define uma condição em relação a um conjunto de eventos base, usando a instrução Matching Event.

Exemplo de correlação (correspondente): KQL

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

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

Práticas recomendadas

• 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

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

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

O exemplo de KQL a seguir implementa uma regra de correlação com uma janela de tempo 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

Aqui está uma regra de exemplo do ArcSight com configurações de agregação: três ocorrências em 10 minutos.

Exemplo de agregação: KQL

A consulta KQL a seguir mostra como detectar três ou mais correspondências usando agregação.

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

Próximas etapas