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

Este artigo descreve como identificar, comparar e migrar suas regras de deteção do ArcSight para as regras de análise do Microsoft Sentinel.

Identificar e migrar regras

O Microsoft Sentinel usa análises de aprendizado de máquina para criar incidentes acionáveis e de alta fidelidade, e algumas de suas deteções existentes podem ser redundantes no Microsoft Sentinel. Portanto, não migre todas as suas regras de deteção e análise cegamente. Analise estas considerações à medida que identifica as regras de deteção existentes.

• Certifique-se de selecionar casos de uso que justifiquem a migração de regras, considerando a prioridade e a eficiência do negócio.
• Verifique se você entende os tipos de regras do Microsoft Sentinel.
• Verifique se você entende a terminologia da regra.
• Analise as regras que não dispararam alertas nos últimos 6 a 12 meses e determine se elas ainda são relevantes.
• Elimine ameaças ou alertas de baixo nível que você ignora rotineiramente.
• Use a funcionalidade existente e verifique se as regras de análise internas do Microsoft Sentinel podem resolver seus casos de uso atuais. Como o Microsoft Sentinel usa análises de aprendizado de máquina para produzir incidentes acionáveis e de alta fidelidade, é provável que algumas de suas deteções existentes não sejam mais necessárias.
• Confirme as fontes de dados conectadas e revise seus métodos de conexão de dados. Revisite as conversas de coleta de dados para garantir a profundidade e a amplitude dos dados nos casos de uso que você planeja 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 o Uncoder.io, pode funcionar para suas regras.
• Se as regras não estiverem disponíveis ou não puderem ser convertidas, elas precisarão ser criadas manualmente, usando uma consulta KQL. Revise o mapeamento de regras para criar novas consultas.

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

Para migrar suas regras de análise para o Microsoft Sentinel:

1. Verifique se você tem um sistema de teste em vigor para cada regra que deseja migrar.

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

   2. Certifique-se de que sua equipe tenha recursos úteis para testar suas regras migradas.

   3. Confirme se você tem todas as fontes de dados necessárias conectadas e revise seus métodos de conexão de dados.

2. Verifique se suas deteções estão disponíveis como modelos internos no Microsoft Sentinel:

   • Se as regras internas forem suficientes, use modelos de regras internos para criar regras para seu próprio espaço de trabalho.

     No Microsoft Sentinel, vá para a guia Modelos > de Regra do Configuration Analytics > e crie e atualize cada regra de análise relevante.

     Para obter mais informações, consulte Criar regras de análise agendadas a partir de modelos.

   • Se você tiver deteções que não são cobertas pelas regras internas do Microsoft Sentinel, tente um conversor de consulta online, como Uncoder.io para converter suas consultas em KQL.

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

   • Se nem as regras internas nem um conversor de regras online forem suficientes, você precisará criar a regra manualmente. Nesses casos, use as seguintes etapas para começar a criar sua regra:

     1. Identifique as fontes de dados que você deseja usar em sua regra. Você desejará criar uma tabela de mapeamento entre fontes de dados e tabelas de dados no Microsoft Sentinel para identificar as tabelas que deseja consultar.

     2. Identifique quaisquer atributos, campos ou entidades em seus dados que você deseja usar em suas regras.

     3. Identifique os critérios e a lógica da regra. Nesta etapa, você pode querer usar modelos de regras como exemplos de como construir suas consultas KQL.

        Considere filtros, regras de correlação, listas ativas, conjuntos de referências, listas de observação, anomalias de deteção, agregações e assim por diante. 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 gatilho e a ação da regra e, em seguida, construa e revise sua consulta KQL. Ao revisar sua consulta, considere os recursos de orientação de otimização do KQL.

3. Teste a regra com cada um dos seus casos de uso relevantes. Se ele não fornecer os resultados esperados, você pode querer revisar o KQL e testá-lo novamente.

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

Saiba mais sobre as regras de análise:

• Regras de análise agendadas no Microsoft Sentinel. Use o agrupamento de alertas para reduzir a fadiga do alerta agrupando alertas que ocorrem dentro de um determinado período de tempo.
• Mapeie campos de dados para entidades no Microsoft Sentinel para permitir que os engenheiros SOC definam entidades como parte das evidências a serem rastreadas durante uma investigação. O mapeamento de entidades também possibilita que os analistas SOC aproveitem um gráfico de investigação intuitivo que pode ajudar a reduzir o tempo e o esforço.
• Investigue incidentes com dados UEBA, como um exemplo de como usar evidências para exibir eventos, alertas e quaisquer marcadores associados a um incidente específico no painel de visualização de incidentes.
• Kusto Query Language (KQL), que você pode usar para enviar solicitações somente leitura para seu banco de dados do Log Analytics para processar dados e retornar resultados. O KQL também é usado em outros serviços da Microsoft, como o Microsoft Defender for Endpoint e o Application Insights.

Comparar terminologia de regras

Esta tabela ajuda você a esclarecer o conceito de uma regra no Microsoft Sentinel em comparação com o ArcSight.

Mapear e comparar exemplos de regras

Use esses exemplos para comparar e mapear regras do ArcSight para o Microsoft Sentinel em vários cenários.

Exemplo de filtro (AND): ArcSight

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

Exemplo de filtro (E): KQL

Aqui está a regra de filtro com AND condições no KQL.

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

Esta regra pressupõe que o Agente de Monitoramento do Azure (AMA) coleta os Eventos de Segurança do Windows. Portanto, a regra usa a tabela Microsoft Sentinel SecurityEvent .

Considere estas práticas recomendadas:

• Para otimizar suas consultas, evite operadores que não diferenciam maiúsculas de minúsculas quando possível: =~.
• Use == se o valor não diferenciar maiúsculas de minúsculas.
• Ordene os filtros começando com a where instrução, que filtra a maioria dos dados.

Exemplo de filtro (OR): ArcSight

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

Exemplo de filtro (OR): KQL

Aqui estão algumas maneiras de escrever a regra de filtro com OR condições no KQL.

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

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

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

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

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

Exemplo de filtro aninhado: ArcSight

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

Aqui está 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 com OR condições no KQL.

Como primeira opção, use 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, use uma função KQL:

1. Salve a consulta a seguir como uma função KQL com o ExcludeValidUsers alias.

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

2. Use a consulta a seguir para filtrar o ExcludeValidUsers alias.

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

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

1. Crie uma função de parâmetro com ExcludeValidUsers o nome e o 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, use 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

Considerações:

• Recomendamos que você use um filtro direto com uma where instrução (primeira opção) devido à sua simplicidade. Para um desempenho otimizado, evite usar join (quarta opção).
• Para otimizar suas consultas, evite os operadores que não diferenciam maiúsculas de minúsculas =~ quando !~ possível. Use os == operadores e != se o valor não diferenciar maiúsculas de minúsculas.

Exemplo de lista ativa (pesquisa): ArcSight

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

Exemplo de lista ativa (pesquisa): KQL

Esta regra pressupõe que a lista de observação Contas de Exceção do Cyber-Ark existe no Microsoft Sentinel com um campo Conta.

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 com a instrução que filtra where a maioria dos dados.

Exemplo de correlação (correspondência): ArcSight

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

Exemplo de correlação (correspondência): KQL

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 sua consulta, verifique se a tabela menor está no lado esquerdo da join função.
• Se o lado esquerdo da tabela for relativamente pequeno (até 100 K registros), adicione hint.strategy=broadcast para um melhor desempenho.

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

Aqui está um exemplo de regra do ArcSight que define uma condição em relação a um conjunto de eventos base, usando a Matching Event instrução e usa a Wait time condição de filtro.

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

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á um exemplo de regra do ArcSight com configurações de agregação: três partidas em 10 minutos.

Exemplo de agregação: KQL

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

Próximos passos

Neste artigo, você aprendeu como mapear suas regras de migração do ArcSight para o Microsoft Sentinel.