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

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

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 à medida que identifica 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 Microsoft Sentinel tipos de regras.
• 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 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 obter mais informações, veja Criar regras de análise agendada a partir de modelos.

   • 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 do acionador e a ação da regra e, em seguida, construa e reveja a 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 utilizar referências fornecidas pelo siEM legado para compreender como mapear melhor a sintaxe da consulta.

     4. Identifique a condição do acionador e a ação da regra e, em seguida, construa e reveja a consulta KQL. Ao rever a consulta, considere os recursos de orientação de 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, poderá querer rever o KQL e testá-lo novamente.

4. Quando estiver satisfeito, pode considerar a regra migrada. Crie um manual de procedimentos para a 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.

Saiba mais sobre as regras de análise:

• Regras de análise agendadas no Microsoft Sentinel. Utilize o agrupamento de alertas para reduzir a fadiga dos alertas ao agrupar 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 do SOC definam entidades como parte das provas a controlar 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 utilizar provas para ver eventos, alertas e quaisquer marcadores associados a um incidente específico no painel de pré-visualização de incidentes.
• Linguagem de Pesquisa Kusto (KQL), que pode utilizar para enviar pedidos só de leitura para a base de dados do 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 terminologia de regra

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

Utilize estes exemplos para comparar e mapear regras do ArcSight para Microsoft Sentinel em vários cenários.

Exemplo de filtro (E): ArcSight

Segue-se uma regra de filtro de exemplo com AND condições no ArcSight.

Exemplo de filtro (AND): KQL

Eis 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 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.
• Encomende os filtros começando pela where instrução , que filtra a maioria dos dados.

Exemplo de filtro (OU): ArcSight

Segue-se uma regra de filtro de exemplo com OR condições no ArcSight.

Exemplo de filtro (OU): KQL

Seguem-se algumas formas de escrever a regra de filtro com OR condições no 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

Segue-se uma regra de filtro aninhada de exemplo no ArcSight.

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

Exemplo de filtro aninhado: KQL

Seguem-se algumas formas de escrever a regra de filtro com OR condições no 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

Considerações:

• 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 não sensíveis a =~ maiúsculas e !~ 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

Segue-se 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 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

Encomende os filtros começando pela where instrução que filtra a maioria dos dados.

Exemplo de correlação (correspondente): ArcSight

Segue-se uma regra do ArcSight de exemplo que define uma condição relativamente a um conjunto de eventos de base com a Matching Event instrução .

Exemplo de correlação (correspondente): 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 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

Segue-se uma regra do ArcSight de exemplo que define uma condição relativamente a um conjunto de eventos de base, com a Matching Event instrução e utiliza a condição de Wait time 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

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

Exemplo de agregação: KQL

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

Passos seguintes

Neste artigo, aprendeu a mapear as regras de migração do ArcSight para Microsoft Sentinel.