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

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

Identificar e migrar regras

O 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 justifiquem 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 compreende a terminologia da regra.
• Reveja quaisquer regras que não tenham acionado 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 o 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. Reveja 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 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 com 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 o 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 cenários de teste completos e scripts.

   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 Detetar ameaças fora da caixa.

   • 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 converter as suas consultas em KQL.

     Identifique a condição do acionador e a ação de 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 para 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 seu SIEM legado para compreender como mapear melhor a sintaxe da consulta.

     4. Identifique a condição do acionador e a ação de 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:

• Crie regras de análise personalizadas para detetar ameaças. 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 (investigate-cases.md#use-the-investigation-graph-to-deep-dive) 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 da regra

Esta tabela ajuda-o a clarificar o conceito de uma regra no Microsoft Sentinel em comparação com o ArcSight.

	ArcSight	Microsoft Sentinel
Tipo de regra	• Regra de filtro • Associar regra • Regra de lista ativa • E muito mais	• Consulta agendada • Fusão • Microsoft Security • Machine Learning (ML) Behavior Analytics
Critérios	Definir em condições de regra	Definir na KQL
Condição do acionador	• Definir em ação • Definir na agregação (para agregação de eventos)	Limiar: número de resultados da consulta
Ação	• Definir campo de evento • Enviar notificação • Criar novo caso • Adicionar à lista ativa • E muito mais	• Criar alerta ou incidente • Integra-se com o Logic Apps

Mapear e comparar exemplos de regras

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

Regra	Description	Regra de deteção de exemplo (ArcSight)	Consulta KQL de exemplo	Recursos
Filtro (AND)	Uma regra de exemplo com AND condições. O evento tem de corresponder a todas as condições.	Exemplo de filtro (AND)	Exemplo de filtro (AND)	Filtro de cadeia: • Operadores de cadeia Filtro numérico: • Operadores numéricos Filtro datetime: • há • Datetime • entre • agora Análise: • analisar • extrair • parse_json • parse_csv • parse_path • parse_url
Filtro (OR)	Uma regra de exemplo com OR condições. O evento pode corresponder a qualquer uma das condições.	Exemplo de filtro (OR)	Exemplo de filtro (OR)	• Operadores de cadeia • em
Filtro aninhado	Uma regra de exemplo com condições de filtragem aninhadas. A regra inclui a MatchesFilter instrução , que também inclui condições de filtragem.	Exemplo de filtro aninhado	Exemplo de filtro aninhado	• Função KQL de exemplo • Função de parâmetro de exemplo • associar • em que
Lista ativa (pesquisa)	Uma regra de pesquisa de exemplo que utiliza a InActiveList instrução .	Exemplo de lista ativa (pesquisa)	Exemplo de lista ativa (pesquisa)	• Uma lista de observação é o equivalente à funcionalidade de lista ativa. Saiba mais sobre as listas de observação. • Outras formas de implementar pesquisas
Correlação (correspondente)	Uma regra 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)	Exemplo de correlação (correspondente)	operador de associação: • associar • associar com a janela de tempo • baralhar • Difusão • União definir instrução: • permitir Agregação: • make_set • make_list • make_bag • empacotar
Correlação (janela de tempo)	Uma regra de exemplo que define uma condição relativamente a um conjunto de eventos base, com a Matching Event instrução e utiliza a condição de Wait time filtro.	Exemplo de correlação (janela de tempo)	Exemplo de correlação (janela de tempo)	• associar • Regras do Microsoft Sentinel e declaração de associação

Exemplo de filtro (E): ArcSight

Eis 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 na KQL.

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

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

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 (OR): ArcSight

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

Exemplo de filtro (OR): KQL

Seguem-se algumas formas de escrever a regra de filtro com OR condições na 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 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 na 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:datatime, 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 parameter:

       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 Cyber-Ark Contas de Exceção 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 ao começar 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

Eis um exemplo de regra do ArcSight 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

Eis um exemplo de regra do ArcSight com definições de agregação: três correspondências num prazo 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 o Microsoft Sentinel.

Migrar a automatização SOAR